Thoughts After a Month of Using a Coding Agent
I spent about a month using a coding agent in real work. The conclusion: productivity definitely goes up, but it requires proportionally more judgment.
The biggest change is that boilerplate work has disappeared. I barely spend time building CRUD APIs, setting up test scaffolding, or writing migration scripts anymore. It feels like about half the code I used to write by hand each day is gone.
On the other hand, new work has appeared:
- Time spent reading and understanding code the agent wrote
- Time spent asking why it was written that way and judging whether the explanation is convincing
- Time spent reverting parts that don't fit the existing codebase's conventions
In other words, "typing" has turned into "review." It's definitely more comfortable than before, but it doesn't mean I think less—I just think differently.
The caveats have also become clear. If you don't give it narrow context, it touches the wrong files. And at first it often writes something that looks plausible but is subtly wrong, so if you don't write tests, it comes back much more expensive later.
After a month, my conclusion is this: it's dangerous for someone who doesn't know code to use, and it's a powerful tool for someone who does. The best description seems to be not a replacement but an amplifier.
7 answers
True—I totally agree that typing turns into reviews.
Oh, I didn’t know this. Keeping the context narrow seems really important.
Got a source? After using it for a month, the “half” figure seems a bit exaggerated.
I don’t agree. The increased need for judgment isn’t because of agents—isn’t it just that people with low skill have always been like that? Feels like blaming the tool.
True, but the scariest case is when it's 'subtly wrong.' It looks plausible, but one variable name or one boundary value is off, and it blows up in production. If you don't write tests, you'll spend several times as long debugging later. When I get an agent's output, I've made it a routine to always look at the diff first, and if the logic changed, check the test coverage for that function. It's annoying, but if you don't do this, at some point half your codebase becomes of unknown origin.
Well, that’s a bit... It’s good that boilerplate is gone, but if review time increased by that same amount, total time may not have dropped much. I actually measured it, and simple CRUD was down about 40%, while complex logic actually increased. The felt experience and actual measurements turned out to be different.
I tried it similarly for a month or two, and ultimately code review skills determine productivity. People who can quickly read what the agent produces and judge “this isn’t right” genuinely get two or three times faster, but if you can’t make that judgment, you just accumulate technical debt. So when introducing it to the team, I started by organizing the convention docs. If you specify “things not to do in this project” in a rules file—CLAUDE.md or whatever—the problem of touching the wrong files drops sharply. The same goes for tests: I switched to writing tests first and then throwing them to the agent, and the time spent reverting dropped a lot.