For the Glory of the Repo
For the Glory of the Repo
There is a tendency in AI-assisted software development to keep adding more.
More agents.
More orchestration.
More platforms.
More automation.
More infrastructure.
But lately, I have been moving in the opposite direction.
Back to the repo.
Not because the repo is new. Because we have underestimated what it can become.
The Repo Is Becoming the Engineering System
A modern repository does not have to be just a place where source code lives.
It can contain the intent of the work.
It can contain the rules.
It can contain the guardrails.
It can contain reusable instructions.
It can contain contracts between steps.
It can contain templates, validation criteria, architectural guidance, testing expectations, and the instructions for calling specialized agents or external tools.
And increasingly, the repo itself can coordinate the work.
That changes the way I think about AI engineering.
Instead of immediately building a complicated external orchestration platform, I can start with something much simpler:
Put the engineering intelligence next to the engineering work.
Start With Files, Not Infrastructure
A team can begin with a surprisingly small structure.
An intent file defines what needs to happen.
A standards file defines the rules that every change must follow.
Contracts define what goes into and comes out of important steps.
Templates create consistency.
Skills or specialized instructions handle repeatable engineering tasks.
Tests and validation determine whether the intent was actually satisfied.
None of that requires a massive AI platform.
It requires a disciplined repository.
That is one of the biggest lessons I have learned recently.
The Repo Can Become the Orchestrator
This is where the idea becomes more interesting.
A feature intent does not have to be a static requirements document.
It can become the starting point for the entire engineering loop.
The intent can reference standards.
The standards can enforce guardrails.
The workflow can invoke specialized capabilities.
Those capabilities can return structured outputs.
Those outputs can be validated against success criteria.
The results can become evidence for the next engineering decision.
That creates something I have started calling the Repogenic Loop.
The repository begins generating the context, constraints, execution guidance, and evidence needed for the next step of engineering.
Not completely autonomously.
And that is important.
The engineer is still involved.
The Human Still Has to Push Back
One of the most important things I have learned while working this way is that AI output is not automatically good engineering.
I have spent a lot of time lately building things, reading the results, testing them, and saying:
No.
That is not good enough.
That does not prove the intent.
That test is too vague.
That automation will not actually run.
That success criterion cannot be measured.
That repo structure does not support the workflow we are trying to create.
Then we refine it.
That process matters.
AI makes it very easy to generate something that looks complete.
Engineering still requires someone willing to ask whether it actually works.
I have always been a strong tester, and I am beginning to believe that may be one of the most valuable skills in AI-assisted engineering.
The ability to look at something that appears finished and ask:
Did we actually prove it?
The Repo Creates a Natural Boundary
There is another reason I like this approach.
The repo gives AI a boundary.
Instead of giving an AI system unlimited freedom, we can give it a controlled environment containing the information it needs.
The architecture.
The intent.
The standards.
The contracts.
The implementation.
The tests.
The evidence.
The history.
That makes the repository one of the most natural control planes for AI-assisted engineering.
It is also where developers already work.
That matters.
The best transformation strategies do not always require replacing the entire development environment.
Sometimes they simply make the environment developers already use much more intelligent.
This Is Where Intent-Driven Engineering Becomes Practical
Intent-Driven Engineering does not have to begin with an enterprise AI platform.
It can begin with a folder.
Then an intent file.
Then a standards file.
Then a contract.
Then a reusable capability.
Then validation.
Then evidence.
Over time, the repository becomes more capable.
The team becomes more consistent.
And the AI becomes more useful because it is operating inside a clearer engineering system.
That is the direction I am increasingly interested in.
Not AI replacing the software engineer.
Not endless agents talking to other agents.
A repository that understands enough about the work to help engineers move from intent to implementation with discipline.
The repo already contains the software.
Now it can begin to contain the engineering system that creates the software.
For the glory of the repo.
Comments