A lot of the conversation around AI coding agents still assumes the goal is replacement. Hand the machine a task, come back later, and software happened.
That does describe some of the work. Just not most of the work that matters.
On a normal day, maybe 30 to 40 percent of what I do fits the clean version. The task is scoped. The surrounding patterns already exist. The agent can read the codebase, make the change, run the obvious checks, and hand back something close to done. That work should feel almost boring. Give it the job. Let it disappear for a bit. Review the result. Move on.
The easy work is real
People sometimes undersell that first category because it sounds unglamorous. I think that is backwards.
If an agent can take a clearly bounded task off your plate, that is useful. Rename the field in three layers. Add the filter to the admin table. Wire the existing component into the new page. Clean up the repetitive test fixtures. Those jobs matter because they consume real time, and most of them do not need a dramatic amount of human originality.
That is the part that feels closest to delegation. You still review it, because you should review everything that changes your codebase, but the shape of the work is straightforward.
Most software work is not that clean
The other 60 to 70 percent is where the framing breaks down.
That work usually involves taste, product judgment, stale assumptions, old architecture, customer history, and all the half-buried context that never made it into a ticket. Sometimes the code technically works, but you know not to copy the pattern again because it came from a rushed decision in 2021. Sometimes the obvious implementation is the wrong one because support has already seen that edge case blow up twice. Sometimes a feature request is really three different requests wearing the same clothes.
I do not want an agent replacing my process there. I want it extending my process.
Acceleration beats imitation
For the messy category, the agent works best when it gives a good developer more hands inside the same workflow.
I am still solving the problem. I am still reading the existing code, checking the edges, testing in the browser, deciding whether the solution fits the rest of the product, and throwing out approaches that look fine in a diff but feel wrong in the system. The agent helps by doing more of the typing, searching, scaffolding, repetition, and first-pass exploration.
That is a very different promise from full automation.
It is closer to acceleration. You stay in the loop, but the loop moves faster. You can inspect more options, cover more surface area, and spend less of your day manually digging through files or writing the same mechanical code again.
What bad agent usage looks like
If it is obvious that the agent did the work, something usually went wrong.
Maybe the code follows the local style only on the surface and misses the deeper conventions. Maybe it solved the ticket while ignoring the surrounding product logic. Maybe it introduced a pattern that will quietly make the next five changes worse. Maybe the copy sounds clean but has no real point of view. Maybe the implementation works, though nobody who understands the system would have shaped it that way.
That is not an argument against agents. It is an argument against treating them like autopilot in places where judgment is the actual work.
The better framing
I keep coming back to a simple split.
For the clean 30 to 40 percent, agents act like delegation.
For the messy 60 to 70 percent, agents act like acceleration.
That second category is where most senior engineering work lives. Not because the code is harder to type, but because the right answer depends on memory, taste, tradeoffs, and context that sit outside the narrow text of the task.
The real value is not fully automated software development. It is giving a good developer more hands inside the same workflow.
That same framing applies outside feature work too. I wrote about using an agent to probe my own site in I hacked my own site with agentic AI. You probably should too.
