The speed is real. A team using AI assistance well produces working software faster than the same team did two years ago, and no sensible response to that involves slowing them down on principle.
What goes wrong is rarely a single bad change. It is drift. Each contribution is defensible on its own, and over a few months the codebase acquires four ways of doing the same thing, a dependency list nobody can account for, and a set of assumptions that exist only in the chat history of whoever was working that week. By the time anyone notices, the cost of establishing what the software actually does exceeds the time the speed saved.
The guardrails below cost days to set up and hold for years. They are the difference between a team that gets faster and a team that gets faster for a quarter.
Write the rules where the assistant will read them
An AI assistant follows the conventions it can see. If the repository states its conventions in a file the assistant reads before it starts, the output arrives already shaped. If the conventions live in a wiki nobody has opened since onboarding, they are decorative.
Worth stating explicitly: how errors are handled and logged, how the code is layered and what may depend on what, how data access is done, how configuration and secrets are read, which libraries are already in use for common jobs, and how tests are structured. Each of these prevents a category of drift rather than a single mistake.
Keep it short enough that people read it too. A document of forty rules is a document of zero enforced rules.
Let the pipeline be the arbiter
Written standards decide what should happen. The pipeline decides what does happen, and it is the only participant with no opinion about deadlines.
A workable minimum is formatting and linting applied automatically, type checking where the language supports it, the test suite, a dependency vulnerability scan, and a check that nothing resembling a credential has been committed. Every one of these is a rule that stops needing to be argued about, which is most of their value: nobody has to be the person who raises it.
Make the gates fast. A pipeline that takes twenty minutes gets bypassed, and a bypassed gate is worse than no gate because it produces a false sense that something is being checked.
Be explicit about where AI works alone
The useful distinction is blast radius rather than difficulty. Some work can go wrong without anyone outside the team noticing, and some cannot.
Test coverage, internal tooling, documentation, refactoring with a test suite watching, and the routine parts of a feature are all reasonable places for AI to work with light review. Authentication and authorisation, anything handling payments, anything that writes to a system of record, database migrations, and infrastructure configuration are not, regardless of how straightforward the change looks.
Write the split down and revisit it. A team that has never moved anything from the second list to the first is not learning; a team that has moved everything is not paying attention.
Keep the human review where it earns its place
Review capacity is finite, and the volume of change goes up when a team adopts AI assistance. Spreading the same attention across more code makes every review shallower, which is the failure mode to avoid.
Concentrate it instead. A senior engineer reading the changes that touch the second list properly is worth considerably more than the same engineer skimming everything. Our note on direct technical leadership makes the same argument for delivery generally, and it applies with more force here.
What the reviewer is looking for is set out in the patterns that recur in AI-generated code.
Know what the software is doing in production
Guardrails on the way in are only half of it. Structured logging, an alert when the error rate moves, and a dashboard someone actually looks at are what tell you whether the last month of accelerated delivery improved anything or quietly made the system less reliable.
Without that, the honest position is that you do not know, and the first evidence either way arrives as a customer complaint.
Set this up once
All of the above is a few days of work and it is worth doing before the codebase grows rather than after. Retrofitting standards onto eighteen months of accumulated drift is a much larger job, and it tends to get deferred indefinitely because it delivers nothing visible.
If you want help establishing it, or an independent view of whether what you have is holding, see software productionisation and technical assurance, or get in touch.
