How I split the work with coding agents

I use coding agents every day. They make implementation cheaper; they don’t make the decisions that keep an app maintainable. This is how I split the work.

Architecture before prompts

Module boundaries, data ownership and invariants are decided before code gets written, by me or by an agent.

More on this in Agents don’t architect reliably: why system design still matters.

Agents work in narrow slices

One feature path or one migration step at a time, reviewed for effects on the rest of the system, not just for style.

More on this in The feedback loop that changed how I write code.

Review effort follows risk

Mechanical code gets a glance. Code that touches concurrency, persistence or the network gets integration tests.

More on this in Testing code you didn’t write: the trust framework for agentic development.

Rules live in the repo

If an agent needed hidden context to get something right, that context becomes a lint rule, a test or a doc.

The architecture context file in Agents don’t architect reliably is one example.