The challenge
Every developer had an assistant. Every developer had their own way of using it. The output ran quick and clean one day, then tangled and hard to review the next. Why would the same tool produce clean code on Monday and a mess by Thursday?
The answer sat in what nobody wrote down. A developer opens a chat window, describes the change in whatever words come to mind, corrects the model three or four times, and commits the result. The thinking that got them there stays in the session. What reaches the branch is an answer with its question deleted.
That holds up while the author is at their desk and still remembers. It holds up less well at review, where a reviewer can confirm that code runs and has no written target to check it against. It holds up less well the following month, when someone else opens the file. And in a bank it runs out entirely at audit, where the question is why the code was written this way, and the only person who ever knew has moved teams.
Speed was never really the problem. Their developers were already fast. The trouble was that the speed belonged to individuals, arrived in different shapes from each of them, and left the organisation with work it could not verify at the rate it was being produced.
The brief was short: make the engineers genuinely faster and the code more reliable, with the tools already in the building. So we ran a two-day, hands-on training with the teams themselves, on their own repositories.
The method
What we install is a loop your engineers run many times a day. The spec is the shared artifact inside it: the model builds against it, the reviewer checks against it, the auditor reads it months later. One thing has to exist before the loop turns for the first time.
Step 0
Your coding standards, your security rules and your compliance requirements go into the workflow before anyone writes the first spec. Every task that follows inherits them by default, so an engineer never has to hold them in their head on a Thursday afternoon with a release pending.
Step 1
A short written target that a model and a reviewer read the same way. It is the thing the generated code will be judged against, so it is written before anything is generated.
Step 2
The assistant asks what is missing and waits, instead of filling the gap with a guess. Most of the rework in an AI-assisted change starts with a guess nobody noticed.
Step 3
Code written toward a stated target, judged against something written down. The same prompt, pointed at a document instead of at a memory.
Step 4
Checklists catch issues at the developer's desk, while the change is still cheap to fix. What the checklist contains comes from step zero, so it is your standards doing the checking.
Step 5
Multi-agent workflows for the tasks big enough to split, each with a scope it stays inside. Added where they pay for themselves, rather than everywhere at once.
Step 6
Nothing merges on the model's say-so. The gate is part of the workflow, so it holds on the busy weeks too, which is the only week that matters.
Back to step zeroEvery pass through the loop teaches you something about your own rules. A checklist item that never once fires. A standard the model keeps reading the wrong way. A review comment that three different people have now written by hand. Each of those goes back into the constitution, so the next task starts from a better baseline than the last one did.
The training
Both days ran on the teams' own repositories, with the assistants they already had. The only thing added across the two days was one open-source spec toolkit, copied into a project on day two.
We let the cracks show. Teams worked the way they already worked, on code they already owned, until the failure modes surfaced on their own screens rather than in our slides.
Each one traced back to the same missing thing: the target was never written down, so nothing could be compared to it.
We put the loop in front of the same work. Teams ran it on their own code and produced the artifacts themselves, which is the part that makes a habit stick after everyone goes home.
What changes for the team
A prompt is a private object. It lives in one person's session, in that person's shorthand, and it is gone when the tab closes. A spec is a document. It sits in the repository, in language the whole team reads, and anyone can pick it up.
That single change is the difference between one developer going faster and a team going faster. Work moves between people without a translation step. Someone away for a week leaves the target behind, not only the answer. Two engineers can split a feature in the morning and still be building the same thing by the afternoon, because the thing they are building exists in writing.
For most teams this is the largest single gain, and it is the one that never shows up in a demo. AI coding is usually sold as a private speed-up. A written spec turns it into shared work.
Nothing about a spec requires an engineer to write it. It is a short statement of intent in plain language, which is already the thing a product owner produces every sprint. When the first draft arrives from the product side, the argument about what the team is building happens before anyone generates code, in a document both sides can edit.
Specs sized to a sprint slot into the iteration you already run, so the method sits inside your process instead of beside it. And because the constitution is where a team's rules live, it is also where you can state what you want counted: what makes a change done, what evidence it carries, which business outcome it was written to serve. Teams that go that far get their delivery measures as a by-product of how the work is written, which is a quieter and more honest number than one assembled at the end of a quarter.
What changes at the commit
The spec is written first and the code follows from it, so both land in the same commit. Changing behaviour means changing the spec and letting the code follow, which makes the document and the system move together by construction.
Documentation drift is what happens when the explanation is reconstructed afterwards by someone half-remembering a decision. Here the decision was the starting point, so there is nothing left to reconstruct and nothing to fall behind.
A reviewer opening a merge request gets the diff and the spec it was written against, side by side, in the same commit. The question changes from "does this look right to me" to "does this do what it says it was meant to do", and the second question is one a reviewer can answer in minutes and defend afterwards.
It also gives review a place to disagree that is not the code. If the spec is wrong, that is the thing to argue about, and the argument happens over two paragraphs rather than two hundred lines.
What your team walks out with
Results
Other governed AI work: a trust company's booking workflow and a public-tender compliance review.
Questions