全部笔记
Directing coding agents, not writing code

2026年5月15日

Directing coding agents, not writing code

A short note on what changes when the implementation layer is an agent — what stays the same, what disappears, and where the new bottleneck lives.

本文尚未翻译为您的语言——正在显示英文原文。

I do not write the code anymore. I direct coding agents — currently Claude Code on Opus — and own the architecture, the spec, the review. This is what changes in practice.

What disappears

Keystrokes. A senior engineer's day used to be 30% reading code, 20% writing code, 50% everything else. The writing-code line drops to something like 5% — handwritten patches for things the agent can't reach yet, or for changes too small to be worth a prompt.

Boilerplate fatigue. A new endpoint with auth, validation, tests, and a migration used to be a two-hour task. Now it's a five-minute prompt and a ten-minute review. The mental cost of "I should write a test for this edge case" disappears — of course there's a test, the agent wrote it.

The IDE. I'm in a terminal-shaped tool more than half the time. The IDE shows up when I need to read something the agent reasoned about but didn't show me, or when I'm reviewing the diff before merge. Otherwise the loop is prompt → diff → comment → next.

What stays exactly the same

Architecture. What should be built, where the boundaries are, what the data model is, what the failure modes are. None of that delegates. A coding agent will happily build whatever you describe. The whole job is describing the right thing.

Code review. Every line the agent writes is a line I read. I block changes I don't agree with the same way I'd block a junior engineer's PR. The agent is fast but not infallible — it skips assertions, overcomplicates control flow, occasionally invents API calls. You catch those by reading.

Production judgment. The instinct that a particular abstraction will leak, that a particular index will go missing, that a particular async boundary will deadlock under load — none of that is in any agent's training data. It's in twenty years of fixing things.

Where the bottleneck moves

The new bottleneck is specification quality. If I write a prompt that's ambiguous about an error path, the agent commits to one interpretation and ships it. If I write a prompt that's complete but mis-prioritized, the agent gets the wrong thing right. Both feel like agent failures from the outside; both are spec failures.

The discipline that used to go into "write correct code" now goes into "write correct specifications and review correct code". The product of time spent and thought density is roughly conserved — it just moves earlier in the pipeline.

I find the work more interesting. I read more, write more prose, re-write the same paragraph three times before sending it to the agent, and end the day having shipped roughly five times as much as I did two years ago. The tradeoff is a good one.

评论

暂无评论

登录以参与讨论。

做第一个分享想法的人。