You can't install an AI SDLC

Eighteen weeks ago PR #1 merged on my project, TrolleyRelay. This week the count passed PR #596. One human (me), a fleet of AI agents as the primary implementers, and in between: 579 merged pull requests, 372 backlog items created (and 169 closed), 21 architecture decision records, 24 sprint close-outs - and a codebase with more lines of tests than lines of code (78k to 74k).

Before anything else, let me name what this is not, it is not vibecoding. Vibecoding has a time and a place, and I use it where it makes sense: prototypes, spikes, throwaway explorations where the code’s job is to answer a question and then be deleted, or where long-term maintenance is not a requirement. Everything in the numbers above is the other thing: production code a real business runs on - other people’s money, other people’s data - where the output has to be owned. Same agent, same model. The difference is the process wrapped around it, and that process is what this series is about.

When people see numbers like that they ask for the process. “Which agent setup, which rules file, can they have a copy?” And I can hand it over, the rulebook is a single markdown file, but I have to be honest about what they would be copying.

That CLAUDE.md file started as 15 lines with two headings: Backlog and Workflow. Today it is 165 lines across 17 sections: a test-coverage ratchet, an interrogation gate the agent must pass before it can touch code, review findings with categories that cannot be skipped, human-only merge paths for anything touching secrets, pricing or decision records, a dedicated GitHub identity for the agent so an audit can tell its actions from mine.

Very little of that came from a template, and not because I skipped the homework. I have been building software for 18 years, and I started this project with the gates that experience said I would need. What the rulebook records is the part experience could not predict: the failure modes of a new kind of colleague, a fleet of AI workers. Nearly every section carries a date, and behind every date is something the agent actually did. It merged on partially green CI, so now every check must pass, not just the required subset. It shipped scaffolding against an API payload shape it had invented, so now it may never guess a shape. It cut corners on exactly the work items that looked too mechanical to deserve scrutiny, so now the interrogation gate applies to everything, regardless of size. I will name all of these properly as the series goes on, dates included.

The origin is older than this project. In March, before this codebase existed, I spent a month building an agent containment product: a sandboxed stack whose whole design was three controlled ways out and nothing else, where the agent never sees a real secret. Its first commit message: “First commit, overly complex. Time to simplify”. That product never saw the light of day, it was a failure, but its thesis, do not trust the agent, constrain it and make everything it does observable and reviewable, is the foundation of everything that came after.

For TrolleyRelay I’ve had busier and quieter months, so far, with monthly commits of: April 74, May 189, June 73, July 187, August 79 so far. May was both the heaviest delivery month and the month most of the review machinery landed. The process was not overhead on the work. It is what let one human keep turning up the agent’s autonomy without me losing the plot.

But commit counts and PR counts are volume, not velocity, and the difference matters, because there is sixty years of prior work on it. Little’s Law (John Little, 1961) is the queueing result every delivery pipeline obeys: time in system equals work in progress divided by throughput. Hold throughput constant and every extra item in flight makes everything slower. The Toyota Production System (Taiichi Ohno) built lean manufacturing on that arithmetic: shrink the batches, cap the work in progress, and flow follows. The DORA research programme (Forsgren, Humble and Kim, Accelerate, 2018) established the software version across thousands of organisations: short lead times, small batches and high deployment frequency predict throughput and stability together. Speed and quality are not a trade-off; they have a common cause.

Measured that way, this project genuinely got faster. The median time from a PR opening to that PR merging fell from hours in April (a 22.7-hour weekly median at the April peak) to between 4 and 25 minutes for every full-throughput week since mid-May, a sustained trend of roughly -17% per week. Deploys went from zero in April, before a pipeline existed, to 28 in a single week by August. Those are DORA’s lead time and deployment frequency, and they moved the way the research says they should, because work in progress stays near one: each PR arrives already reviewed, merges alone, and deploys as a release tag.

So here is my thesis on AI and velocity: AI changes none of the underlying law. Minimising work in progress is still what buys you speed, exactly as it did on Ohno’s production line. What AI changes is the toolbox. The expensive parts of working in small batches - the review that queued on a human calendar, the tests nobody had time to write alongside the change, the deploy that needed a person watching - become cheap enough to run on every small change. The agent did not repeal Little’s Law; it lowered the cost of complying with it.

But the same lever cuts both ways, and this is the adoption risk I keep seeing. AI accelerates whichever step you point it at, and almost every team points it at the same step first: writing the code. Speed up that one station and, as Goldratt’s Theory of Constraints (The Goal, 1984) has been pointing out for four decades, you do not get throughput, you get inventory piling up in front of the constraint. In an AI-assisted SDLC the constraint is verification and integration: review capacity, testing, deployment, human attention. Point the agent at code generation and leave the rest untouched, and you get branches nobody has reviewed, PRs stacking up faster than they merge, half-finished work going stale while the agent starts the next thing. The work in progress accumulates precisely because generating it became cheap, and the accumulation eats the velocity you thought you had gained. My April looked exactly like that in miniature: within days of starting, the agent could produce faster than I could safely absorb. The difference between that April and the minutes-long merges of May was not a better agent; it was pointing the same accelerant at the constraint (the reviews, the tests, the deploys) and capping the work in progress with gates. Seen through this lens, every gate in this series is a WIP limit. Work is not started until it is grilled, not handed over until it is reviewed, not merged until every check is green, not done until it is deployed and audited. The process is what converted raw production speed into flow.

To be clear, I did not build all of this from scratch, and you should not either. Parts of my workflow are Matt Pocock’s published agent skills: his grilling skills run my interrogation gate, and some other conventions carried over as well. They are excellent, and they are also the proof of the thesis: I installed the best off-the-shelf skills available and still had to grow the entire governance layer around them, because no skill pack can know which failures my project would produce.

There is a second thread running through this series. Alongside this project I am rolling out AI tooling and an AI-enabled SDLC at a global enterprise in a regulated industry, where governance is not a style preference but a regulatory fact.

That is why my own project carries more governance than a one-person team strictly needs: it is the lab. Every gate you will read about here was trialled where I could afford to watch it fail before recommending it somewhere I cannot. Patterns from that enterprise rollout, what translates, what has to change when the operator is not the owner, will appear throughout the series.

So here is the series thesis: you can’t just install an AI SDLC, mine or anyone else’s. The rules you need are functions of the failures your org, your stack, and your agents actually produce. What transfers is the loop: notice the failure, write the rule, harden the rule into code, audit compliance.

This (hopefully) weekly series runs in two tracks. Track A is process and governance: quality floors, interrogation gates, review gates for code you didn’t write, the autonomy dial, the places a human must stay. Track B is the architecture underneath: agent safety as infrastructure, designing a codebase agents can navigate, decisions as data, enforcement as code, least-privilege agent operations. I’ll try to bring along for a fully candid tour of everything the agent got wrong, because the failure log turned out to be the roadmap.

If you are running agents in your SDLC: which of your rules exists because of a specific incident, and would you recognise the next incident as a rule waiting to be written?