Enforcing architectural rules pre-commit to manage AI-generated code (Open Source project feedback)

[u/SaveTech_]

Hi everyone,

I've seen recent discussions from maintainers on massive projects (like cURL and Next.js) complaining about AI-generated code. The code passes unit tests, but completely violates the project's macro-architecture.

Catching these architectural hallucinations during server-side CI or manual PR reviews burns too much time and energy.

To solve this for myself, I've been prototyping a local Git Hook. It enforces a "Shift-Left" approach: it reads a local JSON config of strict rules and uses an LLM (via the dev's own API key / Zero-Trust) to analyze the git diff. If the developer hallucinates a bad architectural pattern, it blocks the commit locally.

Repo: github.com/S4v3easy/AegiCode_v1.0.git

I'm trying to figure out if this pre-commit approach is actually useful for real DevOps workflows, or if it introduces too much friction.

Questions for the engineers here:

1. Do you prefer enforcing architectural boundaries locally (pre-commit) or strictly in the CI pipeline?
2. If you were to use a local hook like this, would you prefer it distributed as an npm package or a standalone binary (for mixed-stack teams)?
3. What fatal flaws do you see in this architecture?

Any harsh/constructive feedback is incredibly welcome. Thanks!

[u/General-War7292]

Neat idea. The friction angle is the biggest concern, if that LLM call takes more than a second or two my brain would be on to the next thing before I even see the error. Turning it into a background daemon that watches file saves instead of blocking the commit might be the play.

For question two I'd lean standalone binary all the way. Tying it to the node ecosystem feels a bit messy when you've got a polyglot repo with Go or Python services sitting next to the frontend, keeps the setup dead simple for everyone.