Agentic Coding Still Depends on Human Review

Agentic coding can turn one developer into the manager of five or six coding agents, but it does not remove the need to judge their work. The source article describes agents prototyping features, fixing bugs, running tests, and preparing pull requests while a human still reviews the code and runs tests manually. That division of labor is the useful part—not the claim that writing code has become obsolete.

Agentic coding speeds up the first pass

The author now works with roughly five to six agents, including Claude Code, OpenCode, Codex, and Pi. The agents can take on implementation tasks and get a feature or bug fix to a reviewable state. The author describes this as a major acceleration in prototyping, not as a hands-off path from request to reliable software.

That distinction matters in practice. A prototype is valuable when it helps answer a question quickly; a pull request is not valuable just because it exists. The author still reviews agent-written code and tests it manually, and says the agents need human taste and experience to avoid code that functions poorly or is over-architected. My read is that the leverage comes from moving routine implementation forward while keeping design judgment and acceptance with the developer.

More agents mean more coordination, not just more output

The account also describes the cost of running several agents: the work can become overstimulating and exhausting. The author reports spending about $3,000 a month on tokens, a detail that makes clear this is a substantial personal workflow—not evidence that the same setup is economical or appropriate for every team.

There is also a craft trade-off. The author describes losing some of the hands-on feel of programming as the role shifts toward managing agents. That is not simply nostalgia: when more work arrives as generated changes, the review queue and the developer’s attention become part of the system’s capacity. My interpretation is that adding agents only helps while a person can still inspect, test, and make decisions about what they produce. Five agents do not create five times the useful output if review becomes the bottleneck.

Keep ownership of the code and the review

The source article’s blunt line, “Writing code is solved,” sits alongside its warning that agents are not reliable enough to trust without validation. Taken together, those claims support a narrower conclusion: generating code is becoming easier for this developer, but deciding whether a change belongs in a real project is still human work.

For a practical trial, I would start with a bounded prototype or bug fix, then inspect the diff and run the relevant tests before opening or merging a pull request. I would not treat the reported pace or token spend as a promise for my own repository. The signal worth tracking is whether agents consistently produce changes that are useful after review—and whether the time saved exceeds the attention spent coordinating them. If that balance holds, add more tasks; if review and context-switching pile up, adding agents is not the fix.