All the Tests Passed

I’d been having pretty good luck getting AI to write code. I’d settled into a process: write the documentation, write the ticket, have AI write the prompt, then set the agent to work and review the result with AI backing me up. I was seeing fewer bugs and spending less time dragging the implementation back toward what I’d asked for.

So I decided to see what would happen if I let it go nuts for a few tickets.

All the tests passed, including the tests it had written for the new code. Then I asked it to review the work, and it came back with a list of issues. I asked it to look again, and it found more. We kept going until it thought the code was good.

I initially started fixing the findings, but there were enough that I stopped and fed the work back into tickets. I made four.

I wasn’t angry or sad. I was disappointed. If you’ve ever onboarded a developer, gotten comfortable with their work, and then opened a pull request so bad you weren’t sure it was worth iterating over, you probably know the feeling.

One defect involved a temporary permission. The code checked that it was valid, then waited for access to some shared data. The permission could expire during that wait, but when the wait ended, the operation went ahead anyway.

The expiration check was there. It happened at the wrong time.

That’s easy to understand once you see it, and it’s the kind of thing I expected a developer to reason through. The documentation covered it, too. The agent had been told to read that documentation and review its work.

There are a lot of ways to get ketchup out of a bottle, but I felt like I’d watched the agent put a hotdog under it and hit the bottle with a hammer until the ketchup exploded. It dressed the dog—if by “dressed” you mean created a fucking mess, and by “dog” you mean hotdog-flavored mush.

The tests are the part I keep coming back to. The agent wrote the code and tests from the same mistaken understanding. The tests were written to confirm that the world worked wrong, and everything went green.

I don’t mean every test explicitly demanded the wrong outcome. The misunderstanding survived in both the implementation and the checks meant to establish that it worked.

The agent eventually identified the defect when I explicitly asked it to review against the original documentation. That’s weird. It could find the problem, but asking it to review as part of the original assignment hadn’t produced the same result.

I suspect the earlier reviews operated under the same misunderstanding. Or perhaps it saw green tests and went, “Super cool, brah.” I can’t prove either explanation. I know what I asked, what it produced, and what it found when I asked again.

Can AI get lazy? I don’t know whether that describes anything happening inside the model, but the behavior was familiar: misunderstand the requirement, produce something that looks finished, and discover the trouble when somebody pushes harder.

The recovery was familiar, too. Real developers review, find defects, fix them, and review again. I’ve since started asking models other than the one that wrote the code to review it. That seems to help, but I don’t have data. It’s my gut.

I haven’t repeated the larger experiment. I’ve returned to one ticket at a time, with explicit instructions to consult the documentation and ticket at the beginning and check the result against both at the end. If something is unclear, use the source material rather than guess, and tell me when the work is proceeding without a clear understanding.

This project has enough documentation to support that process. Whether those instructions are sufficient is something I’m still working out.

I’m still getting useful work from AI, but I’ve lost some confidence in the agent’s ability to handle a bigger assignment—and in my ability to write a prompt that won’t produce another mess. The earlier prompt already asked for review, after all.

And all the tests passed.