Working with AI coding agents without losing the plot

AI coding agents can now read a codebase, edit a dozen files, run the tests, and open a pull request in the time it takes to finish a coffee. That changes what a productive day looks like. It doesn't change what a correct system looks like.

The teams getting real value from agents aren't the ones generating the most code. They're the ones who moved their effort to the parts agents are worst at: deciding what to build, and proving that what was built is right.

Write the spec before the prompt

An agent is only as good as the problem statement it receives. "Add rate limiting to the API" produces something. "Add per-API-key rate limiting to POST /orders, 60 requests per minute, return 429 with a Retry-After header, and keep the existing tests green" produces the thing you wanted.

Before handing over a task, I write down:

• The outcome, in one sentence a product manager would agree with.
• The boundaries: which files or modules are in scope, and which are off-limits.
• The acceptance criteria, ideally as tests that fail today.
• The constraints the agent can't infer: performance budgets, backwards compatibility, data that must not be touched.

This takes ten minutes and saves an hour of reviewing a confident solution to the wrong problem.

Make the tests the contract

The most reliable workflow I've found is test-first: have the agent (or yourself) write failing tests that describe the behavior, review those tests carefully, then let the agent make them pass.

Reviewing a 30-line test file is much easier than reviewing a 400-line implementation, and once the tests are right, they keep the implementation honest. Two rules make this work:

1. Tests are reviewed before code. If the tests are wrong, everything after them is wrong.
2. Tests are never deleted or weakened to make a change pass without an explicit decision. Agents will sometimes "fix" a failing test by loosening its assertion. Treat that as a red flag in review.

Keep diffs small enough to actually read

Agents don't get tired, so they happily produce changes that span twenty files. Humans reviewing those changes do get tired, and that is where bugs slip through.

I break work into steps that each produce a diff I can read in one sitting: first the data model, then the API, then the UI. Each step gets its own commit or pull request. If a change is too large to review properly, it's too large to merge, no matter who wrote it.

Give the agent the context a new teammate would need

Most agent mistakes come from missing context rather than missing intelligence: the wrong test command, an outdated pattern copied from an old module, a library the team stopped using last year.

A short instructions file at the root of the repository (many tools read files such as AGENTS.md or CLAUDE.md) pays for itself quickly. Mine usually covers:

• How to install, run, lint, and test the project.
• The patterns to follow, with a pointer to a good example file.
• The patterns to avoid, and why.
• Anything dangerous: production credentials, destructive scripts, migrations that need a human.

It's the onboarding document you always meant to write, and now something reads it every day.

Review like the author is very confident and occasionally wrong

That's the right mental model. Agent-written code is usually well formatted and plausible, which makes the remaining errors harder to spot. In review, I look specifically for:

• APIs that don't exist, or exist with a different signature or behavior.
• Over-broad changes: a refactor that wandered into unrelated files.
• Silent behavior changes in error handling, defaults, and edge cases.
• Security basics: input validation, authorization checks, secrets in code or logs, injection through string-built queries.
• Tests that pass for the wrong reason, such as mocks that make the assertion meaningless.

Reading every line is non-negotiable for anything that reaches production. The agent wrote it; you're shipping it.

Where agents shine, and where I slow down

Agents are excellent at work with a clear definition of done:

• Mechanical refactors and migrations backed by a good test suite.
• Raising test coverage around existing behavior.
• Reading unfamiliar code and explaining how a feature works.
• Boilerplate: API clients, form validation, CRUD endpoints.

I slow down, and do more of the thinking myself, for authentication and authorization, payment and billing logic, data migrations that can't be reversed, and anything where the requirements are still fuzzy. Speed is worth little when the cost of a mistake is high.

The senior skill set is shifting, not shrinking

The parts of the job that matter more now are the ones that were always the hardest: framing problems precisely, designing systems that are easy to verify, writing tests that capture intent, and reviewing code with skepticism. Engineers who are good at those things get more done with agents than without them. The code was never the hard part.