.png)
5 hours ago
2
Coding agents / LLMs are not engineers or system architects at present (June 2025). You cannot sit back and play product manager just yet. If you go in with this expectation, you will certainly have a poor experience.
LLMs are tools - not replacements for humans (yet)
LLM-powered coding agents are not comparable to any existing human role or tool and therefore cannot be used interchangeably. They are a fundamentally new and novel type of tool that enable incredible productivity IF and only if you use them effectively.
Much of the criticism among engineers first dipping their toes into the world of LLM-augmented software engineering is caused by improperly calibrated expectations and a naive understanding of how to use them. The tool is not the problem, the user is.
The ceiling of usefulness is much, much higher than you probably think
I'm building a non-trivial SaaS platform and the cursor agent has written 90%+ of the code in the codebase. However, it has architected ~0% of the codebase. It has modeled ~0% of the data layer in the codebase. Yet it has enabled me to move at least 10x the speed of implementation and debugging (yes, it is incredible at debugging if you use the right techniques).
I use the word implementation because that is almost exclusively what I use it for. I do the planning, design, architecture, engineering. Then, I communicate those specifications to it in digestible chunks, and it implements them incredibly fast. It makes mistakes, comes up with poor naming conventions, fails to reuse existing modules in the codebase, etc. But that's fine - I simply give it feedback, point it in the right direction, and within seconds it's back on course.
RL[LLM]F
As opposed to fine-tuning the LLM, the LLM is continuously fine-tuning me. Each time it screws up, it's almost always my fault - I failed to provide it with sufficient context, or left too much ambiguity in my request. Through this tight, collaborative feedback loop, my implementation delegation skills have sharpened tremendously. My hit-rate while working with the cursor agent, in terms of successful, one-shot attempts at achieving what I'm looking for, is probably close to 80%.
You must own your codebase.
You cannot delegate all critical thinking to the LLM. The optimal use-cases I've found so far are treating it as a) an ideation tool, b) an analysis tool, and, most importantly, c) a super fast implementation minion.
If it gets something wrong - that's your fault. You failed to communicate your expectations clearly and provide sufficient context.
I still use my brain just as hard, if not harder, while engineering alongside the LLM. I'm just deploying my mental computing power at a higher layer of abstraction - instead of worrying about which syntactic tokens to type into the editor.
It scales, too.
Much of the criticism regarding coding agents only being useful on small, greenfield projects is unfounded. If you truly 'own' your codebase, you will know exactly which context to provide to the agent and how to describe the implementation you're seeking. If you want the agent to analyze how a certain system works in your codebase, you'll know exactly which direction to point it in. The degree to which coding agents are useful is constrained by the user's knowledge and skillset, not the LLM's knowledge or skillset.
There's a sweet-spot of abstraction.
The power is in your ability to steer it and communicate in clear terms what you want, and maintain the right level of abstraction in your instructions. Too specific and you lose some of the efficiency gains beyond just writing the code by hand. Too vague / high-level and you risk leaving too many blanks for the LLM to fill in by itself. You'll end up with something over-engineered and totally different from what you intended.
In conclusion
As of now, you're still the engineer. Treat LLMs as really smart semantic code generators and brainstorming/analysis partners, not engineers.
I've been a cursor power-user for only a few months and I already can't imagine a world without coding agents. The productivity delta is massive, and they're become an integral part of my workflow.
