# Coding agents: the boost is real, and so is the plateau > What a year of working with coding agents gave me, where they stop helping, the traps worth keeping in mind — and the one habit that changed how I work with them. By Aleksandr Kondaurov · Oct 24, 2026 · 6 min read Tags: llm, agents URL: https://kondaurov.dev/blog/dont-follow-the-agent/ Six months ago I wrote that [LLMs don't write production code for me](/blog/best-use-of-llms/). That is no longer true. Today most of the code I ship is written by an agent, and I ship more than I ever have. But along with the boost came something I didn't expect: a plateau. A point where the agent stops helping and starts producing work that only looks like progress. This post is about both — what the agent actually gave me, where it stops, the traps I've learned to watch for, and the one habit that changed how I work with it. ## The things I never built I now have native iOS apps I use every day. None of them existed a year ago, and the ideas had been sitting around for much longer. Not because they were hard to build. Because of everything _around_ the build: code signing, App Store Connect, TestFlight, provisioning profiles, build pipelines, push certificates. None of it is difficult. Every piece is documented. It just eats hours of patience, and after a working day that patience is exactly what I didn't have. So the ideas stayed ideas. ## What the agent took off my plate That whole layer is gone now. The agent reads the docs, sets up the pipeline, fixes the certificate error, resubmits the build. It handles the hundred small steps between "I want this" and "it's on my phone", and it handles them without getting bored. This is the honest, unglamorous value of a coding agent: **it gets you to a point through routine.** Not the clever part, the long part. And for a one-person project the long part was the whole reason nothing shipped. So yes, the boost is real. I'm not going to pretend otherwise. ## The plateau Here is what I didn't expect. On some tasks the agent can't get there, and it doesn't tell you. It doesn't stop. It keeps going: another fix, another confident "done", another large diff. When you read closely, it's the same idea it already tried, rearranged. The summary is articulate, the code compiles, the tests pass. And the problem is still there. The pattern is always the same. I describe a failure. The agent fixes exactly that failure, and the fix sounds reasonable. The next day it fails again, slightly differently. I describe the new failure. The agent fixes exactly that one. After a few rounds I notice I'm reading the same idea with different variable names, and nothing has moved. This isn't a weak-model problem. I've seen it with the best models I can run. It's **an illusion of work**, and it's convincing precisely because the agent is good at everything around the actual problem. What breaks the loop is never another fix. It's a different question. "Why are we guessing here at all?" "Is there a signal the system already has?" "Are we solving the right thing?" More than once the answer turned out to be sitting in plain sight, and the agent never reached for it, because it was busy fixing its previous fix. I had to bring that question. And that's the point. ## What I actually need at that point When I hit the plateau, what I need is not more output. I need a bold idea, a different angle, a view from outside the problem. Someone to say "you're solving the wrong thing." That is exactly what an agent doesn't bring. Its next proposal grows out of its last one. It doesn't step back; it steps forward along the same line. At the moment I most need a fresh perspective, it gives me a slightly rephrased version of the old one. That doesn't just fail to help, it actively confuses: every new confident diff pulls me deeper into the approach that was already wrong. An agent is extraordinary at execution and surprisingly poor at **questioning the frame it's executing in.** ## What to keep in mind A year of this taught me a few things about how agents fail. None of them is a reason not to use one. All of them are reasons not to use one blindly. 1. **Confidence is not correctness.** The report that says "done" reads exactly the same when it's done and when it isn't. Check the result, not the summary. 2. **Volume is not progress.** A large diff often hides the absence of a new idea. The more code a "fix" touches, the more I want to know what's actually different about it. 3. **It fixes the symptom you described, not the cause.** Each patch answers your last complaint precisely. Nothing in that loop ever asks why the thing keeps breaking. 4. **It goes to the code, not to the runtime.** Faced with "why does this behave like X", it re-reads the source instead of looking at logs, traffic, or what the system actually did. The runtime had one behaviour; the code describes every behaviour it could have. 5. **It rewrites when it could extend.** Ask for a small change and you may get a redesign, because starting over is easier than understanding what's there. 6. **It improvises silently.** When the proper tool is missing it falls back to grepping, guessing, poking at files — without saying it's working around a gap. The workaround looks like method. 7. **It agrees with your framing.** Suggest a direction, even a wrong one, and it will go there and do it well. It won't push back; you have to. 8. **It never says "I don't know."** A dead end looks like one more iteration. Nothing in its output tells you the task is beyond it. You have to notice. ## Don't follow — challenge So I changed how I work with it. The rule is simple: I don't take the agent's plan on trust. Ever. - **Challenge every proposal.** "Why this approach and not something completely different?" Half the time the answer reveals the agent chose the first path it saw, not the best one. - **Watch for the loop.** If the same mechanism gets "fixed" twice and still fails, that's not a bug anymore, it's a design that's fragile. Stop patching. - **Look at the runtime before the code.** The signal that solves the problem is often already there, and the agent won't go looking for it while it has a plausible patch in hand. - **Think yourself at the wall.** The agent gets me to the wall faster than I'd ever get there alone. Getting over it is still my job. The second point is now literally written into my agent's instructions: > When a fix to the same mechanism fails a second time, stop patching: say what makes it fragile and which sturdier designs or signals exist — including ones the system already has — and recommend one before writing more code. It helps. Not always, the agent still sometimes rolls into a third patch, but it's a tripwire, and when it fires it saves me an evening. ## Where this leaves me I'm not disappointed in agents. I'm more productive with them than I have ever been, and the apps on my phone are proof. What changed is that I know where their part of the work ends and mine begins. An agent is a tool that gets you to a point through routine. It is not a tool that tells you the point is wrong. The judgment, the bold idea, the "wait, what are we actually solving" — that is still on you. And the better the agent gets at the routine, the easier it is to forget that, because its work looks so much like thinking. Don't follow it past the point where it stopped thinking.