The Repogenic Loop: How Teams Can Start Intent-Driven Engineering Right Inside the Repo
The Repogenic Loop: How Teams Can Start Intent-Driven Engineering Right Inside the Repo
Software teams do not need a new platform, a massive agent framework, or a six-month transformation program to begin working differently with AI.
They can start in the repo.
That is the idea behind what I call The Repogenic Loop.
The concept is simple:
The repository should not only contain the code. It should contain the intent, standards, architecture, reusable skills, templates, validation rules, and evidence that help produce the code.
When those pieces are connected, the repo becomes more than storage.
It becomes part of the engineering system itself.
From Prompting to Orchestration
Most developers are already using AI.
They ask Copilot, Claude, Gemini, Cursor, or another tool to build a feature, fix a defect, generate tests, or explain code.
That is useful, but it is still largely individual.
One developer may give the AI excellent architectural context.
Another may provide almost none.
One may remember the team’s testing standards.
Another may forget.
One may validate the result carefully.
Another may accept the first answer.
AI can therefore accelerate development while also accelerating inconsistency.
The Repogenic Loop changes that.
Instead of asking the developer to remember all the context, the repo carries the context.
A feature intent can begin by reading shared files such as:
/standards
/docs
/templates
/skills
/hooks
policy-check
quality-gate
/evidence
The feature intent then becomes the orchestration layer.
It can say:
Read the progressive intent standard.
Review the architecture.
Create the implementation plan using the approved template.
Implement the feature.
Run the appropriate testing and security skills.
Validate the result.
Write the evidence.
Stop when the success criteria are satisfied or escalate unresolved issues.
That is no longer simply a prompt.
It is an orchestration contract for the feature.
The Repogenic Loop
The basic loop looks like this:
Intent → Context → Plan → Build → Validate → Evidence → State → Next Intent
The AI receives the feature intent.
The intent references the architecture, standards, templates, skills, and guardrails already stored in the repo.
The implementation occurs.
Validation happens.
Evidence is produced.
Important state is persisted.
The next phase can then read that evidence and continue.
The repo becomes the connective tissue between AI calls.
Instead of relying entirely on conversation history or model memory, the engineering state is externalized into files the team can inspect, version, review, and improve.
Start Small
A team does not need twenty agents on day one.
Start with folders and Markdown.
For example:
/intent
/standards
/docs
/templates
/skills
/evidence
Then create one shared standard.
Something like:
standards/progressive-intent-standard.md
That file can define a few basic rules:
Work one phase at a time.
Read the architecture before changing code.
Produce evidence before claiming completion.
Stop when requirements are ambiguous.
Do not exceed defined retry or turn limits.
Escalate architectural conflicts to the developer.
Developers retain final authority.
Now every feature intent can begin with:
Read and follow:
standards/progressive-intent-standard.md
One line connects the feature to the team’s engineering discipline.
Add Architecture
Next, give the AI architectural context.
Create something such as:
docs/architecture.md
It does not need to be enormous.
Document the things the team repeatedly wants developers and AI assistants to understand:
architectural boundaries
preferred patterns
API conventions
dependency rules
security expectations
testing expectations
technology decisions
known constraints
Now a developer does not have to explain the system from scratch every time.
The repo explains itself.
Add Reusable Skills
Teams repeatedly perform the same reasoning.
Security review.
API review.
Testing review.
Architecture review.
Code-quality review.
Instead of rewriting those instructions into every feature prompt, put them into reusable files.
skills/security-review.md
skills/test-review.md
skills/api-design.md
A feature intent can invoke the appropriate skill when needed.
These do not have to be sophisticated autonomous agents.
They can simply be focused, reusable instructions containing:
purpose
inputs
rules
expected output
success criteria
That alone creates substantial consistency.
Add Templates and Contracts
Templates are another powerful part of the loop.
If every developer asks AI for a plan differently, the outputs will differ.
Instead:
templates/plan-template.md
templates/evidence-template.md
templates/handoff-template.md
Now the feature intent does not merely ask for a plan.
It says:
Produce the plan according to plan-template.md.
The same principle applies to testing evidence, architecture reviews, handoffs, and implementation summaries.
The output becomes predictable enough for another AI call, another developer, or even another tool to consume.
That is where Markdown begins behaving like an interface contract.
Capture Evidence
One of the most important differences between casual AI-assisted coding and Intent-Driven Engineering is evidence.
AI should not simply say:
Done.
It should show why the work is considered complete.
That might include:
evidence/test-results.md
evidence/security-review.md
evidence/architecture-review.md
The evidence can record:
what was checked
what passed
what failed
what remains unresolved
what changed
whether the intent was satisfied
Now validation is not buried inside a chat conversation.
It becomes part of the repository history.
Preserve State Between Calls
AI calls are temporary.
Repository artifacts are durable.
That makes the repo a natural place to carry state.
A simple file such as:
might contain:
Current Phase: Validate
Completed:
- Plan
- Implementation
- Unit Tests
Open Issues:
- API timeout behavior requires review
Next Step:
- Architecture validation
The next AI invocation does not have to reconstruct the entire history.
It reads the current state and resumes.
This is how teams reduce context drift and keep progressive work controlled.
Add Governance Without Killing Developer Autonomy
Governance does not need to mean blocking everything.
A useful model is to divide rules into three categories.
Required rules represent things that cannot safely be ignored: security, regulatory requirements, broken builds, or mandatory tests.
Expected rules represent architectural standards and team conventions that should normally be followed.
Advisory rules represent recommendations that the developer may consciously override.
That distinction matters.
AI should improve engineering discipline without removing engineering judgment.
The system should be able to say:
This implementation differs from the documented architecture. Here is the evidence. Continue, revise, or escalate.
The developer still decides.
Why This Matters
The most important question is no longer whether developers will use AI.
They already are.
The question is whether every developer uses AI independently with different context, different standards, and different validation—or whether the organization provides a shared engineering environment that the AI can consistently follow.
Without shared context, AI can become a variability amplifier.
With the right repo structure, it can become a consistency amplifier.
That is the Repogenic Loop.
The repo contains the intent.
The repo contains the standards.
The repo contains the architecture.
The repo contains the reusable engineering knowledge.
The repo contains the evidence.
And each feature adds something back into the system that can improve the next feature.
Start Tomorrow
You do not need to redesign your SDLC.
Pick one repository.
Create:
/intent
/standards
/docs
/templates
/skills
/evidence
Write one shared standard.
Document the current architecture.
Create one feature intent.
Add one reusable validation skill.
Require one evidence file before the feature is declared complete.
Then run the loop.
Improve it as the team learns.
That is enough to begin.
Intent + Standards + Architecture + Skills + Templates + Evidence = Repeatable AI Engineering
That is the Repogenic Loop.
And it can start with a few Markdown files in the repository you already have.
Comments