It Says It Fixed It. It Didn't.
Want to talk about this essay? Email me: amitkvint@gmail.comcopied· or message me on LinkedIn
The agent says it found the problem.
It tells you what went wrong, sounds reasonable about it, and rewrites the function. You run it again.
The error is still there.
So you paste the error back in. It apologises, says that now it sees the real issue, and changes something else. Still there. Round three wraps the symptom in a try/except, so at least the stack trace goes away. By round four it has rewritten three files you never asked it to touch, and you can no longer describe what the code did back when it worked.
I have lost afternoons to that loop. Most people I know who build with these tools have.
The usual diagnosis is that you prompted it badly.
I don't think that's it.
It is guessing, and you can't tell
The agent has your error message, whatever context it managed to read, and a very good sense of what a fix for this kind of error usually looks like. Out of that it produces something plausible.
Plausible is not the same as correct, and here is the awkward part: when it is right, it looks exactly like when it is wrong. Same confident tone, same tidy account of the root cause, same clean diff.
There is no tell.
(I wrote about the same shape on the support side last week, where an agent meets a bug nobody has reported yet and answers in that same untroubled voice. Different domain, identical failure mode.)
So the question was never whether the agent sounds sure. It always sounds sure.
The question is whether you can check.
Usually you can't, because you don't know the system well enough - which is often exactly why you handed the bug over in the first place.
That is not a prompting problem. It is a debugging problem, and it has been one the whole time.
Fixing was never the hard part
I came up as a developer. Twelve years running a small open-source web agency: PHP, MySQL, Python, other people's servers. I don't ship production code any more and I'm not going to pretend otherwise. What I still do is read the code, read the logs, and reproduce the bug.
That last one is the job, and it is the part the agent cannot do for you.
Writing the fix was never where the time went. Once you know that a value is already empty by the time it reaches the third function, and you know why, the fix is usually small and often boring. Ten minutes. Sometimes one line.
Getting to that sentence is the work.
I picked up the habit before any of that, as a teenager building PCs for myself and with friends. A machine that won't boot can't tell you what it was thinking. You find out by narrowing it down.
The way out isn't a better prompt or a smarter model. It's the oldest engineering skill there is: finding where a process stops working, before you touch anything.
Narrow first, then let it write
What that looks like in practice, on my own AI-assisted projects as much as on anything else:
Reproduce it on demand. If you can't make the bug happen when you want it to, you are not debugging yet, you are reacting to reports.
Find the last point where the state is still what you expect, and the first point where it isn't. The bug lives between those two, and nowhere else.
Change one thing. Then look.
If a change makes the error go away and you can't say why, you don't have a fix. You have a coincidence, and it will come back in a month, usually on someone else's machine.
None of this is anti-AI. The agent is genuinely good at the narrowing work when you point it at something: add the logging, write the failing test, walk this function and tell me what the value is at line 40. It's good at the fix once the fault is located. What it can't do is decide that it doesn't know yet.
The difference is whether you hand it a symptom or a location.
The part I keep coming back to
There's a version of this worry that says these tools make developers worse. I don't really believe that, or at least not in that form.
What I think they do is move the skill. They take over the part that was always teachable - the syntax, the boilerplate, the fix you could have looked up - and leave you holding the part that never was: knowing what the system is supposed to do, and noticing the exact place where it stops doing it.
That part doesn't get easier as the models get better. If anything it gets more important, because the wrong answers arrive faster and better dressed.
An AI can write the fix. It cannot tell you where it broke, and it won't tell you when it doesn't know.
Plan around the second one.