AI as a Tool, Not a Pilot: How I Use Coding Agents Without Losing the Plot
Coding agents amplify whoever holds the keyboard — for better or worse. A senior engineer's playbook for steering AI without surrendering judgment, architecture, or learning.
The discourse around AI coding tools has settled into two camps: people who let the agent drive and people who refuse to use one. Both miss the point.
A coding agent is a power tool. A circular saw doesn’t decide what you’re building. It cuts faster than a hand saw, and it removes a finger faster too. The judgment stays with the operator.
What I delegate
- Mechanical refactors with a clear acceptance test (rename, extract, codemod across N files).
- Boilerplate that I’ve written a hundred times: a new repository class, a test scaffold, a config block.
- Exploratory reading of unfamiliar codebases — “find every place we call this API and summarize the contract.”
What I don’t delegate
- Architecture decisions. The agent has no skin in the game six months from now; I do.
- Naming. A bad name compounds. I read every identifier the agent suggests.
- Anything I don’t understand yet. If I can’t explain why the diff works, I don’t ship it. The cost of “it works, ship it” is paid back with interest the first time it breaks.
The senior trap
Senior engineers are the most at risk of letting agents atrophy them — they already know how to recognize plausible code, which is exactly what these models produce. Plausible isn’t the same as correct.
Use the agent to remove drudgery, not to remove thought. The day you stop reviewing the diff is the day the codebase starts owning you instead of the other way around.