I use AI coding agents every day, on systems large enough that no prompt can hold them. The pattern I’ve settled on treats agents less like a smarter autocomplete and more like a team of fast, literal, slightly overconfident contractors. Three things make that team useful.

A map of the code

An agent dropped into a large repository does what a new hire does on day one: it searches for a likely word, opens the first match, and starts reasoning from a fragment. It will confidently change the wrong one of three functions with the same name.

What fixes this for both is a map: which modules exist, what each owns, which symbols call which, where the boundaries and the data stores are. I keep a code knowledge graph — symbols, call and import edges, ownership — that agents can query before they open a file: “who calls this?”, “what writes to this table?”, “what breaks if this signature changes?”. Answering those questions from the graph instead of from grep is the difference between an agent that edits the code and one that understands the change.

Narrow briefs, written down

Long, open-ended sessions drift. The agent forgets a constraint from forty minutes ago, or decides a “small refactor” is in scope. Short, written briefs work better:

  • One outcome, stated as something verifiable.
  • What not to touch, explicitly. Agents are eager; scope is a fence, not a hint.
  • The rules of the house: naming, error handling, test style, where things live.
  • What done looks like, including the commands that must pass.

Split large work across sub-agents with separate briefs — one for the data layer, one for the API, one for the review — so no single context has to hold everything. Write the briefs to files, so the next session (yours or the agent’s) starts from the same page.

Verification is the product

Generating code is cheap now. Knowing it’s right is not. Every agent loop I run ends in checks the agent can’t argue with: the type checker, the tests, a build, a diff against an invariant (“no copy changed”, “no new dependency”), and for anything visual, a screenshot I actually look at. Checkpoint after each verified step, so a bad step is a revert rather than an archaeology project.

The other half of verification is reading. Treat agent output like a pull request from someone very fast who has never been on call for this system: the code compiles, the tests pass, and it may still do something you would never have done — retry without a budget, catch and ignore an error, invent a configuration value. The places agents are most often wrong are exactly the subjects of the essays on this site: failure paths, concurrency, and the cases that don’t appear in the happy-path tests.

Who owns what

Agents type faster than any of us, and that’s genuinely transformative for how much one engineer can build. But the architecture — the boundaries, the failure modes, the trade-offs a duplicate charge or a false alarm imposes on a real person — is still the engineer’s job, and it matters more now, not less. More code arrives per day; someone has to know which of it is safe.