The False Speed of Coding Agents
The world of Coding Agents has given us an incredibly powerful tool.
For those of us paying for a subscription to one of these platforms, the promise is very attractive: build faster, solve complex tasks in less time, and rely on an assistant that seems capable of producing code at a pace no human could match.
But this is where I think the problem begins.
That feeling of speed can lead us to assume that what an AI agent returns is automatically comparable to what a senior developer with years of experience would produce.
And honestly, I think that is far from reality.
How many times has this happened to you...?
The other day I made some changes to one of my side projects.
I asked it to make certain changes in one of the modules I already had covered with unit tests and all their edge cases defined.
Well, the tests started failing and, when I asked it to fix the tests, what it did was modify the implementation so that, without touching the tests, they would pass green...
This kind of problem is what reinforces my idea that you need to invest some time in building a robust workflow so these situations don't happen.
Generating code quickly is not the same as building software
An Coding Agent can generate code very quickly.
It can suggest solutions.
It can read part of our context.
It can help us explore alternatives.
It can even execute complete tasks if we give it the right tools.
But that does not mean it understands the product the way a person does.
It does not mean it knows all the technical trade-offs in the project.
It does not mean it has real architectural judgment.
It does not mean it knows when a solution is maintainable in the long term.
And it certainly does not mean we can stop thinking.
AI needs us not to be lazy
After using these kinds of agents for quite some time, my feeling is that AI needs us not to be lazy.
It needs context.
It needs constraints.
It needs good prompts.
It needs examples.
It needs limits.
It needs us to know exactly what we want to achieve.
Asking an agent to “implement a feature” without further context is very similar to walking into a library and saying:
I want an interesting book.
It might recommend something useful.
It might partially get it right.
But it might also return something that has nothing to do with what you actually needed.
On the other hand, if you ask:
I want a science fiction book, based on galaxies and spaceships, in Spanish, and one I have not read before, considering this list of books I have already read.
The chances of getting a good recommendation increase significantly.
Something very similar happens with Coding Agents.
The better you define the problem, the better AI can help you
The better you define the problem, the better your chances of getting a useful answer.
But that requires work.
It requires judgment.
It requires knowing your project.
It requires understanding which constraints matter.
It requires knowing which parts of the output you can accept and which parts you should question.
And this is where I think we are starting to confuse speed with productivity.
Just because something is generated quickly does not mean it is good.
Just because something compiles does not mean it is correct.
Just because something passes a few tests does not mean it is maintainable.
Just because a solution looks elegant does not mean it fits your product architecture.
Speed can also hide costs
AI can accelerate many parts of development, but it can also move the cost to other phases:
- Review.
- Debugging.
- Testing.
- Refactoring.
- Technical debt.
- Complete rewrites.
That is why I think the conversation should not simply be:
Which AI agent do you use?
But rather:
How are you working with that agent?
What context are you giving it?
What constraints does it have?
What tools can it use?
How do you validate what it generates?
Where does human judgment come in?
Which parts of the process are you not willing to delegate?
Using AI is not the same as doing engineering with AI
For me, that is the difference between using AI as a code-generating machine and using it as a real engineering tool.
An AI agent can be incredibly helpful, but only if we surround it with a solid way of working:
- Good specifications.
- Good context.
- Clear constraints.
- Automated validations.
- Tests.
- Human review.
- Technical judgment.
- Well-defined limits.
And that is where it starts to make sense to talk about Harness Engineering.
Conclusion
The important question is not whether we use Coding Agents or not.
The important question is:
Are we using these agents to think better, or to stop thinking?
Because if we only chase speed, we will probably end up generating more code.
But not necessarily better software.