What Changed After 6 Months of Reviewing AI Generated Code Every Day

A few months ago I wrote about what I fix every single time AI writes code for me. Confident but wrong logic. Loose TypeScript hiding behind a cast. Error handling as an afterthought. That post still holds up. But six months of doing this daily changed the job in a way I didn't expect, and I think it's worth writing down while it's still fresh.

The short version. The categories of mistakes didn't disappear. My relationship to reviewing them did.

The checklist stopped being a checklist

When I wrote that first post, I was running through a mental list every time I got AI generated code back. Check the types. Check the error paths. Check the assumptions about the codebase. It felt deliberate, almost effortful, like running a manual audit on every pull request.

That list is still in my head. I just don't run it consciously anymore. It's closer to how an experienced driver doesn't consciously think "check mirror, check blind spot" every time they change lanes. The checking became reflex. I catch a loose any type or a swallowed error the way you catch a typo when you're reading, before you've decided to look for it.

That sounds like a small shift. It's not. It means the review itself got faster without getting less thorough, and that's the actual productivity gain nobody talks about when they measure AI coding speed. The speed doesn't come from the AI writing code faster. It comes from your review loop getting tighter.

I stopped reviewing after the fact and started constraining upfront

Here's the real change. Six months ago, my workflow was mostly: prompt, get code back, review it, fix what's wrong. Now it's closer to: prompt with the constraints baked in, get code back that's already closer to right, review it for the smaller set of things that still slip through.

The difference sounds subtle but it changes where my effort goes. If I'm about to ask for a new API route on CrimsonWatch, I now tell it upfront what the response shape needs to be, what happens on a failed external call, whether this touches a table with access patterns that matter. Six months ago I'd get code back, notice it made the wrong assumption about the response shape, and fix it after the fact. Now I catch myself specifying that constraint before I even send the prompt.

This is the part that actually improved my skills as a developer, not just my AI usage. Learning what to specify upfront forced me to get sharper about what actually matters in a piece of code before I write a single line of it. That's architecture thinking. AI didn't hand that to me. Reviewing its output enough times taught it to me the hard way.

The mistakes that still get through are quieter now

The obvious stuff mostly stopped happening. I rarely see AI generated code with an outright syntax problem or an obviously broken happy path anymore, the models got better and my prompts got tighter. What still gets through is subtler, and honestly scarier, because it's easier to miss.

A function that handles the three error cases I asked for, but not the fourth one I didn't think to mention. A database query that's correct today but will quietly degrade once a table on CrimsonWatch grows past a certain size. A type that's technically accurate but hides an edge case in how a field can be null. These aren't things a checklist catches. They're things that only show up when you already understand the system deeply enough to notice something is slightly off, even when nothing is technically wrong.

That's the uncomfortable truth about six months in. AI made the obvious mistakes rarer. It didn't make the hard part of the job go away. It moved the hard part further out, to the mistakes you only catch if you already know your system better than the tool does.

What I'd tell myself six months ago

If I could go back and tell the version of me who wrote that first post one thing, it would be this. Don't wait to build the reflex. The instinct to catch a loose type or a missing error path doesn't come from reading about it, it comes from doing the review enough times that it stops being a conscious step.

I also underestimated how much better my prompts would get just from paying attention to my own review notes. Every time I caught myself fixing the same category of mistake twice, that became a constraint I started stating upfront the next time. The review process wasn't just quality control. It was training data for how I use the tool, except the training happened in my head instead of a model's weights.

The 42 percent of code AI writes didn't change much in six months. What changed is how much of the other 58 percent I do now without thinking about it, and how much sharper the remaining review has to be to catch what's left. That's not AI getting weaker. That's the easy problems getting solved, which means what's left is, by definition, the hard ones.

That part still doesn't get automated. If anything, it got more important, not less.