A dependency upgrade lands in your repository. Three call sites need updating, one test has an outdated mock, and a type signature changed. Historically that is forty minutes of an engineer's afternoon: read the changelog, make the edits, run the suite, fix what broke, open a pull request.
Now that work can be handed to a process that reads the changelog, makes the edits, runs the suite, reads the failures and iterates until the suite is green. The pull request arrives without the forty minutes. What does not disappear is the review — and that is where the interesting consequences live.
The shift is not that code gets written faster. It is that the scarce resource in a software team moved.
The bottleneck moved from producing to verifying
For most of the history of software engineering, writing the change was the expensive step and reviewing it was cheap relative to that. Team throughput was bounded by how fast people could produce correct code.
An agent that can run the test suite inverts this. Producing a candidate change becomes cheap and parallel — several can be in flight at once. Verifying that a change is correct, appropriate, consistent with the architecture and safe to deploy remains exactly as expensive as it always was, because it still requires a human who understands the system.
Every downstream effect follows from that one inversion. Review queues grow. The value of a fast, trustworthy CI pipeline goes up sharply, because it is the only reviewer that scales. Codebases that were merely inconsistent become actively expensive, because inconsistency is what makes a diff hard to judge.
What actually changed in the loop
The technical change is narrow and worth stating precisely. Earlier coding assistants produced text; a human evaluated it. Agentic tools close the loop by executing something and reading the result — the mechanism described in the complete guide to AI agents, applied to a repository.
read src/billing/invoice.js
edit src/billing/invoice.js
run npm test -- billing
✗ invoice.test.js: expected 'EUR', received undefined
read src/billing/currency.js
edit src/billing/invoice.js
run npm test -- billing
✓ 34 passingNothing here is exotic. What matters is that the failure text is an observation the model can act on, not an error a human has to relay. That single property is why agentic tools behave qualitatively differently from completion: they can be wrong and then stop being wrong, without you.
It also explains, precisely, where they remain weak. An agent can only self-correct against signals your project actually emits. If your test suite does not cover the behaviour, the loop terminates on green and reports success. The agent is exactly as good as your feedback signals, and no better.
Codebases now have two audiences
A repository has always been read by humans. It is now also read, continuously, by a process with a fixed context budget, no institutional memory, and no ability to ask a colleague. Some things that were mild annoyances become real costs.
What makes a repository legible to an agent
Explicit over implicit. A convention that lives in three engineers' heads is invisible. A convention encoded in a lint rule is enforced on every change, by anyone and anything.
Local over distributed. A feature spread across seven files linked only by naming convention requires seven reads to understand. Cohesive modules cost fewer steps and fewer mistakes.
Named over clever. Meaningful names are the highest-density context in a codebase.
A model reading applyPolicy(order, ctx) has to open two files; reading
applyRefundPolicyForRegion(order, region) it may not have to.
Documented decisions. The most common agent failure in a mature codebase is rediscovering a rejected approach. A short architecture decision record explaining why not saves a loop the code alone cannot.
Many teams now keep a machine-readable conventions file at the repository root — the same information a good onboarding document would carry, written for a reader that starts fresh every session:
# Working in this repository
- Package manager: pnpm. Never run npm or yarn.
- Tests: `pnpm test` (unit), `pnpm test:e2e` (requires `pnpm db:seed` first).
- Do not edit files under `src/generated/` — run `pnpm codegen`.
- Money is always integer minor units. Never use floats for currency.
- New API routes require an entry in `docs/api-changelog.md`.
- Prefer extending an existing module over adding a new top-level directory.This is not an AI artefact. It is the onboarding document teams always should have written, finally given a reader that reads it every single time.
Tests became the specification, for real
"Tests are documentation" was always partly aspirational. It is now operational: the test suite is the interface through which an agent learns whether its change is acceptable. A suite that passes when behaviour is wrong actively teaches the loop to produce wrong behaviour.
This raises the value of two things that were previously matters of taste. Tests that assert on behaviour rather than implementation let an agent refactor freely without false failures. And fast tests matter more than ever, because they are now in an inner loop executed many times per change rather than once before a push.
The economics of small changes changed
Some categories of work were never worth doing because the fixed cost of context-switching exceeded the value: renaming a confusing variable across a module, backfilling tests for an untested branch, tightening a loose type, updating a stale comment. Each was ten minutes plus the interruption cost, and it always lost to whatever was on the sprint board.
Those tasks now have a much lower fixed cost, and the accumulated small-improvement work that codebases quietly carry is more tractable than it was. This is a genuine change in what maintenance can look like.
The counterweight is that review cost did not drop proportionally. Twenty small mechanical pull requests still consume twenty review slots. Teams that let generated changes flood the queue discover that they replaced a writing bottleneck with a reviewing one, and reviewing is the less pleasant of the two. Batching related mechanical changes into a single reviewable unit is now a real skill.
New failure modes in the process
Plausible-diff fatigue. Generated diffs look competent. They compile, they pass, they follow local style. Reviewers calibrated on human error patterns — typos, obvious omissions — are miscalibrated for this. The errors are subtler: a correct-looking implementation of a slightly wrong requirement.
Silent scope creep. An agent asked to fix a bug reformats an unrelated file it happened to open. Small individually; corrosive to review quality at volume.
Convention drift by majority. If two patterns exist in a codebase and one is more common, generated code will converge on the common one — including when the common one is the deprecated one. Delete dead patterns rather than leaving them as examples.
Dependency introduction. Adding a package is a one-line diff with a large blast radius. Any change touching a manifest deserves a different level of scrutiny from a change touching application code, and that should be a mechanical check rather than a matter of reviewer diligence.
Evaluation debt. Teams instrument their model features carefully and instrument their coding workflow not at all. If you cannot say whether generated changes are reverted more often than hand-written ones, you are running an experiment without reading the result.
What has not changed
Deciding what to build. Knowing which of three correct designs will still be correct in two years. Understanding why a system that looks over-engineered is actually load- bearing. Choosing what not to do. None of these are bottlenecked on typing speed, and none of them were ever the part an agent could take.
Nor has the burden of correctness moved. Whoever merges is responsible. "The agent wrote it" is not an incident postmortem line item; it is an admission that review failed.
What good practice looks like now
Make CI the arbiter. If a change passing CI is not strong evidence it is safe, fix that first — it is the only reviewer that scales with generated volume.
Constrain the blast radius per task. An agent working on the billing module should not be able to edit the auth module in the same run. Scope, review, merge, then move on.
Keep tasks small enough to review properly. The correct size of a generated change is the size a human will actually read, and that has not increased.
Instrument the workflow. Track revert rate, review cycles per pull request, and where generated changes cause incidents. This is the same evaluation discipline that production model features require, described in building production-ready AI applications.
Choose tools on their context mechanism and approval model rather than on their model version — the criteria set out in best AI coding tools for developers.
The teams getting the most out of this are not the ones generating the most code. They are the ones who made their codebase cheap to verify.
The skills that appreciate
Reading code critically at speed. Writing tests that pin behaviour rather than implementation. Decomposing an ambiguous request into verifiable units. Designing systems with obvious seams. Saying no to a change that works but does not belong.
Every one of these was already a senior skill. What changed is that they are now the constraint rather than the finishing touch — a shift whose longer trajectory is the subject of the future of agentic AI.