| Hi HN! I'm building Hopsule. If you use AI coding tools like Cursor, Copilot, or Claude, you’ve probably seen this happen:
The AI writes good code - but it ignores your architecture. It doesn’t know:
- why you chose a specific pattern
- which conventions your team agreed on
- which decisions are already locked in
So it falls back to generic patterns, outdated examples, or random GitHub training data.
Over time this slowly breaks the consistency of the codebase. Most teams try to fix this with:
- giant Markdown files
- wiki pages
- long prompts
- Slack threads
But those aren't machine-readable rules. So we built Hopsule.
Hopsule turns architecture decisions into enforceable context that AI tools must follow. Example:
Your team approves a decision: “All database access must go through the repository layer.”
Hopsule records this as a rule and injects it into the AI context before code generation. No giant prompts.
No manual context stuffing.
No architecture drift. Website: https://hopsule.com
Docs: https://docs.hopsule.com
App: https://app.hopsule.com |
IIUC, the core of your approach is that decisions get locked as immutable constraints and then served to agents via MCP when they query for context — is that right? Is there anything you can do to ensure that the MCP actually gets called?
I've been experimenting with an approach that triggers a set of checks on the Claude Code stop hook for lightweight, deterministic checks, then does a quick AI-powered review as a pre-commit hook, with a mechanism in place to ensure that appropriate elements of context from repo docs get loaded into context during the review.
One thing I've had to put a good bit of work into is orchestrating what happens when the existing rules don't cover some particular case. How do you think about that?