AI-accelerated, architecture-gated: an SDLC that survives fast code

The failure mode this prevents

The naive adoption story is "the team writes code 3× faster." What actually happens is that the team produces 3× more diff, and every downstream capacity stays exactly where it was: review attention, test coverage, architectural coherence, and how well anyone actually understands the system. The bottleneck has not gone away. It has moved somewhere nobody is measuring.

The symptom is a repository that passes CI and that nobody can confidently change six months later.

Gate 1 — Spec before generation

The artefact a human writes first is not the implementation. It is the boundary:

• Type signatures and data shapes
• The failing test that defines "done"
• The interface the rest of the system sees

The model fills in the middle. This inverts the usual review problem, because reviewing a diff against a spec you wrote is a bounded question — does this satisfy the contract? — where reviewing an unspecified diff is unbounded.

Gate 2 — Repository rules are checked in, not remembered

Conventions communicated in a code review are applied once. Conventions committed as a workspace ruleset are applied on every generation, by everyone.

The rules worth writing down are almost never style — formatters already own that. They are the things a model has no way to infer: which module owns which concern, which dependencies are deliberately absent, which patterns were tried and rejected, where the transaction boundaries are.

If a rules file only repeats what the linter already enforces, it is doing nothing. The useful entries are the ones recording an approach that was tried and dropped, and why.

Gate 3 — Tests are the review surface that scales

A test suite can absorb a larger diff without getting slower or more careless. Human attention cannot. So generating code faster raises the level of automated verification you need rather than lowering it.

The distribution that has worked for me:

• Unit tests on pure logic, written before generation as the spec.
• Integration tests across the seams the model is most likely to get subtly wrong — anything touching transactions, auth, or external APIs.
• End-to-end on the two or three flows whose breakage would be a real incident, and no more; broad E2E suites rot faster than they catch things.

Gate 4 — Architectural review stays human, and stays early

Everything above is about verifying implementations. None of it catches the expensive class of mistake, which is a correct implementation of the wrong structure — a boundary drawn in the wrong place, a synchronous call that should have been an event, a shared database between two services that now cannot deploy independently.

That review has to happen at the design stage, because it is the one category tests cannot express and the one that is most expensive to unpick later. It is also where this playbook stops being useful. The gates catch bad implementations of a sound design; none of them will tell you the design is wrong.

What I do not do

• Ban the tools. The failure is a process gap, not a tool problem.
• Require a human to read every generated line. That does not scale and produces rubber-stamp approvals that are worse than an honest gate.
• Trust coverage percentage as the signal. Generated tests inflate coverage while asserting almost nothing. What matters is whether a deliberately introduced bug fails the suite.