Over the past few months, I've noticed that most discussions around AI coding assistants focus on prompts.
People share:
.cursorrulesAGENTS.mdCLAUDE.md- long prompt templates
- custom instructions
The assumption is always the same:
"If I explain my engineering practices clearly enough, the AI will follow them."
For simple projects, that works.
For real software projects, it eventually breaks down.
The problem isn't intelligence.
It's governance.
Every AI coding assistant eventually produces something like this:
- giant functions
- skipped tests
- undocumented architectural decisions
- ignored security practices
- direct commits
- inconsistent commit messages
- missing pull request descriptions
Not because the model suddenly became "worse".
Because nothing prevents it from taking shortcuts.
Exactly like humans.
We already solved this problem... for humans.
Professional software engineering has never relied on trust.
Instead, we built systems that enforce discipline.
We don't ask developers to:
- write tests
We fail CI.
We don't ask them to:
- use meaningful commit messages
We reject the commit.
We don't ask them:
- not to push directly to production
Protected branches make it impossible.
Engineering isn't based on trust.
It's based on constraints.
Yet with AI...
...we went backwards.
Instead of constraints, we write instructions.
We create increasingly sophisticated prompt files hoping the assistant will remember them.
Always write tests.
Always document architectural decisions.
Use GitHub Flow.
Follow OWASP.
Keep functions below 40 lines.
Never commit directly to main.
Those aren't guarantees.
They're suggestions.
And suggestions are eventually ignored.
Rules are not enforcement.
Recently I came across an article making a simple observation:
Rules without enforcement are just hopes.
That sentence stayed with me.
It perfectly describes the current state of AI-assisted development.
An AI may fully understand your engineering rules.
It may even agree with them.
But unless something checks compliance, nothing prevents shortcuts.
The same principle applies to human developers.
Why should AI be different?
The repository should enforce engineering.
That realization completely changed how I think about AI development.
Instead of teaching every assistant how my projects work...
...what if the project itself became responsible for enforcing engineering practices?
Not through prompts.
Through mechanisms.
Imagine starting a project where, from the very first commit:
- Git Hooks reject invalid commits.
- CI blocks pull requests with insufficient test coverage.
- Security defaults are already configured.
- Branch protection is expected.
- ADR templates already exist.
- Documentation structure is predefined.
- AI assistants receive project-specific guidance automatically.
The assistant isn't simply asked to follow best practices.
The repository continuously pushes it toward them.
This is why I built GEF.
Guardian Engineering Framework (GEF) started as a project generator.
But over time I realized that's not what it really is.
It's a governance layer for AI-assisted software development.
Its purpose isn't to generate code.
Its purpose is to generate constraints.
From the first commit, a project already contains:
- engineering standards
- Git workflow
- AI rules
- documentation templates
- ADR structure
- Git Hooks
- CI pipelines
- security defaults
The repository becomes opinionated before a single feature is written.
Prompts are Level 1.
Repository governance is Level 2.
Most AI tooling today focuses on prompts.
Prompt Engineering
↓
Explain the rules
GEF moves one step further.
Repository Governance
↓
Enforce the rules
I believe the next evolution will go even further.
Agent Governance
↓
Policy Engines
↓
Runtime Verification
↓
Continuous Compliance
Instead of asking AI systems to behave correctly...
...we'll build systems where incorrect behavior simply cannot progress through the engineering workflow.
*The future isn't autonomous AI.
*
It's governed AI.
The goal isn't replacing engineers.
The goal isn't removing code reviews.
The goal isn't trusting AI more.
The goal is building engineering systems that require less trust in everyone involved—humans and AI alike.
Because great engineering has never been about trusting developers.
It's always been about designing systems that make good practices the easiest path—and bad practices the hardest.
AI shouldn't be an exception.
If AI-assisted development becomes the new normal, perhaps the real competitive advantage won't be better prompts.
It will be better engineering governance.
Top comments (0)