Going against the grain on AI topics right now is uncomfortable. Promoting the latest trends is enough to be seen as a specialist. Questioning them puts you on the defensive. But I think the agentic coding loop (where an AI agent is given a goal and autonomously reads context, writes code, runs tests, fixes failures, and iterates until done) is being applied too broadly, and that's worth saying out loud.
I'm not against AI-assisted development. I'm against the paradigm of always letting the agent do more and more of the work, and the human do less and less.
My approach
I write the important code myself. For plumbing (boilerplate, wiring, scaffolding) I use autocomplete or chat. Once I have a meaningful diff, I ask the coding agent to review it: find gaps, edge cases, inconsistencies. From there, we co-create the feature.
For tests, I'm a bit more relaxed. I write the test names, the inputs, and the assertions. The agent fills in the mocks and setup, the boring and time-consuming part that I have no interest in doing manually.
This takes more time than letting the loop run. That's a trade-off. But what you get back matters: you stay in control of how things are done, you understand the inner workings of your software deeply, and you keep your brain engaged in a way that avoids the slow erosion that comes from reviewing code you no longer truly own (aka brainrot).
Basically, it's choosing to work with AI instead of being replaced by it. To remain capable of doing it.
The real danger isn't under-delegation
A common pushback against this kind of position is that the human becomes the throughput bottleneck, too central to the implementation, leaving efficiency possibility unused. Maybe. But it misses where the actual risk tends to sit.
There are two ways a human can be "too central." One is refusing to learn the AI tools or use them at their useful capacity. Result: the developer loses leverage, the team loses efficiency.
The other is not delegating enough to the agent. In practice, I think this is the rarer failure mode. Humans have efficiency (laziness?) built into our nature. That's why we invented tractors and washing machines. The natural tendency is to do less, offload more, and take the path of least resistance. Which means the real discipline isn't knowing what to delegate. It's knowing what not to delegate.
The agentic loop is rewarded short-term: more tickets closed, faster PR velocity, less tedious work. The costs come later: weaker understanding of the system, harder debugging, reduced awareness. The slope is naturally downhill toward "let the agent do it," and that's exactly what needs to be pushed back on, but that's hard.
The useful analogy is the tractor: it removes physical labor, not cognition. A coding agent can remove both toil and understanding. The whole art is to automate the toil without surrendering the understanding.
Where the loop does make sense
None of this means agentic loops are always wrong. For specific, repetitive, or low-stakes tasks (framework migrations, dependency upgrades, broad refactors, lint and build repair, test scaffolding across existing code) the loop is genuinely good. The agent isn't replacing judgment; it's replacing mechanical iteration.
For core business logic, architecture, security-sensitive paths, and anything in poorly-tested areas: human-led. For bounded, mechanical tasks with clear acceptance criteria: agent-led. Most real work lives somewhere in the middle.
On skills and agent complexity
One more thing I want to address: agent skills. Not tools, but skills, in the sense of feeding the agent a large list of capabilities and asking it to pick what it needs.
That pattern makes me think of the Google "I'm Feeling Lucky" button. In practice, it creates opaque behavior, prompt bloat, and inconsistent outputs across sessions. You end up with a overengineered complexity when a reliable hand tool would do.
My preference is simpler: put the stable operating norms in an AGENT.md file, and keep specific workflows in separate prompt files that I explicitly inject when needed, like activating frontend testing via a browser MCP. I, as the user, decide when a workflow applies. That keeps the agent's behavior predictable.
Skills used by automatic selection make sense for long-lived autonomous agents that need to retrieve capabilities on demand to fulfill requests. That's a fundamentally different context than an interactive coding agent, and the two shouldn't be designed the same way.
The principle
If I had to reduce all of this to one rule, it would be: don't let the agent take over the parts of the work that were secretly teaching you how the system works. Delegate toil. Keep the understanding.