Agents good in the end?

Agents can unblock refactorings and bug fixes while you keep shipping features.
Using agents to add tests and boilerplate can multiply long-term maintenance costs.
Tool dependency and parallel work increase mental load, not outcome quality.
Iterate with agents to delete code, refine domain models, and challenge architecture.
Humans still own readability, reviews, and responsibility; productivity rises, not 10×.

The Never-Ending Backlog

Hey, let’s integrate consumer-driven contract tests with Pact, because we’ve inherited these 23 microservices that we’re supposed to maintain with three people. A BDD test suite would totally help us out, tackle this ultra-complex domain, and ensure that everything is transparent. But we really don’t have time to fix the Selenium setup every two weeks for three days, because in the meantime five browser updates happened, leading to 70% failing tests—and we’re totally lost.

There’s this one refactoring we always push into the future, but if we do it, it would touch the whole codebase. It would take at least three days of manual labor, Sisyphus labor, and deliver no meaningful impact for users. If we don’t do it, we’ll feel the pain in two to three years, because our delivery speed will drop. There’s really no glory in prevention.

Now Agents Will Fix Everything

Helpful project infrastructure that would require either a high initial time investment or long-running maintenance costs will often not be pursued. Either the teams are not well enough staffed, or the necessary backing throughout the organization is not in place. No matter the reason, resources are not allocated for what would often be necessary for the project.

But should we now tackle all these things with agents? Would our life and work really become better? My initial reflex was: yes, for sure. And I started doing some of the mentioned refactorings very efficiently while, in parallel, working on new features. That felt really, really good.

There were times when I felt completely unleashed. Every second, there was something useful to do, and I could finally focus on the “meaningful work”—focus my time on solving domain issues. Technology wasn’t standing in my way but instead was elevating me, doing the things I really care about.

If I was tripping over weird bugs or wrestling with frameworks, I didn’t even start trying to understand them in the first place. Just copy and paste -> a short note to the agent —> “fix this!” —> switch to another task -> get a push notification later “Pling!” -> tests are green -> repeat. I finally had the feeling of getting into a real flow again. No interruptions from hour-long step debugging or researching poorly maintained API documentation and digging through Stackoverflow (RIP). Did everything turn out well in the end? Finally?

In the next step, I was tempted to introduce completely new classes of tests into the project. There was this neglected BDD test suite that constantly caused bad feelings. Just as I was about to start, I had a moment of enlightenment and stopped.

Did I really want to use tools that could be ripped from my hands in a second if the VC money was burned, just to introduce a whole new level of project complexity? Aren’t resource constraints exactly what let us focus on the things that really matter? I realized that this way of working was mentally exhausting and could lead to the exact same situation in the future—with the only difference being tenfold complexity to care about.

More is More. Right?

Maybe my brain could recharge during these kinds of mind-numbing refactorings and regain new problem-solving energy. I took a step back and radically changed my style of working. Together with the agent, I took my time and used many more iterations to reduce the generated code—to make it much more expressive and truly reflect the domain concerns. I let the agent challenge my architectural decisions and was able to bring more refined concepts into discussions with my team. I used the agent to produce less code, but better code than before.

Because in the end, I must be able to read the code, review it, and take responsibility for all the code I produce, no matter how it was created. The results are better, productivity is higher—but not tenfold.

Building different features in parallel led to a high mental load, and the results weren’t better than before. So I used agents to give myself more time to think and to unblock myself from annoying bug research.

Divide and Conquer: How to Actually Use Agents

Because of this experience, here’s my call to action: Please generate good, domain-focused code and build secure and stable frameworks with agents—but not at the same time. Divide and conquer. Don’t fall into the trap of generating huge amounts of boilerplate. That’s what frameworks are for. Frameworks aren’t obsolete; they’re becoming even more important as a harness for your agent. Not everyone has to whip up their own ORM or authentication code. Please don’t.

Less Coding, Better Engineering

I believe AI will make me a worse programmer, because I don’t need to have as many concepts directly accessible in my brain. I only have to understand them on demand. But do I even want to be a good programmer? Producing huge amounts of code didn’t solve problems in the past. Creating more problems was often the case. Software development was never about producing code. Code is a tool to solve domain issues, business issues. That’s what I’d rather use agents for.

Real people are still needed to ask agents the right questions and give the correct answers. That’s where i’m in the same boat with Karl Marx: Machines elevate human productivity, but it always takes human work to deliver value. Machines can never do that alone[1]. But is everyone in the same boat? There are still people measuring developer productivity in lines of code. A positive outcome would be that those people now understand—through huge amounts of code slop—that this was never a good idea and never will be.

“Machinery, like every other component of constant capital, creates no new value, but yields up its own value to the product that it serves to beget.” https://www.marxists.org/archive/marx/works/1867-c1/ch15.htm ↩︎

Blog Post