What 6 months of AI code reviews taught me about my own code.
I started having AI review every PR I opened. The patterns it flagged were the same ones, over and over. Here's the unflattering self-portrait that emerged.
Last September I started routing every PR I opened through an AI reviewer before asking a human to look at it. Not because I thought it would catch real bugs. I thought it would catch the embarrassing ones, the typos and the dead imports, so my coworkers would have less to comment on.
That part was true. That wasn't the interesting thing.
The interesting thing was what got flagged, over and over, for six straight months.
What it kept catching me on
After about twelve weeks I started keeping a private note of patterns the model flagged in my code that I'd ignored, dismissed, or pushed back on. Then I went back and read the note in March.
| Pattern flagged | Times in 6 months | Was it actually wrong? |
|---|---|---|
| Inconsistent naming (same concept, two names) | 47 | Always. The AI sees it at a glance; I'd stopped noticing. |
| Missing null/undefined check | 23 | 60% real bugs, 40% paranoid but cheap to fix. |
| Duplicated logic across files | 19 | Mostly real. The duplications I'd "meant to clean up later". |
| Magic number / hard-coded value | 16 | All real. Easy fixes I kept punting. |
| Overly long function (>40 lines) | 12 | Half real. The other half was fine, just intimidating. |
| Test missing for new branch | 9 | All real. The cases I'd "test manually". |
The same five things, over and over.
I name temporary variables badly. Specifically, I reach for data, result, response, and tmp on autopilot, and the model would politely suggest something like parsedShippingAddress instead. I'd push back and merge anyway. Three weeks later I'd open the file, see data, and have no idea what kind of data.
I write helper functions that do two things and have an unclear primary one. The model would suggest splitting them. I'd say "that's overengineering". Then a coworker would touch the function, mis-use the side behaviour, and I'd be debugging it on a Wednesday.
I default to early returns even when a single guarded block would read more cleanly. This one I still disagree with the model about, but it kept flagging it, and at least now I notice when I'm doing it.
I write comments that explain what the code does instead of why it does it. The model kept rephrasing my comments, and the rephrases kept being clearly better, and I kept ignoring them, and the original-me comments kept ageing terribly. Three months later I'd reread one of my own comments and have no idea why past-me thought this was the right approach.
I leave debug logs in. Constantly. I keep telling myself I'll clean them up before merging. I clean up about 60% of them.
The biggest surprise: naming
Of all five, the naming one was the one I underestimated.
I'd always thought I was reasonable at naming. Most of my career, I'd been on teams where the bar for naming was extremely low, and "reasonable" looked great by comparison. The AI didn't care about my team's bar. It compared my code to every codebase it had seen during training. And by that standard, my naming was sloppy in specific, repeated ways.
The AI doesn't make me a better engineer in the moments I'm thinking hardest. It makes me a better engineer in the moments I'm tired, and the moments I'm tired are most of the moments.
It wasn't that my names were bad. They were lazy in patterns I'd never noticed. I reused i for outer loops where a real word would have been clearer. I called configuration "config" and options "options" and parameters "params" without distinguishing them. I had two variables in the same function called user that referred to different things.
The model kept gently pointing this out. After about month three I started paying attention. After about month five I was a meaningfully better namer of things. The PRs I open now read more clearly than the ones I opened a year ago. I can tell. It's the most concrete change in my actual code that the experiment caused.
What I think this was, really
The popular story is that AI is going to teach junior engineers, fast. Maybe. The more interesting story, for me, has been what AI taught the senior engineer.
For about a decade nobody had reviewed my code line by line with infinite patience. Reviews from coworkers come in batches, focus on the most important problems, and politely skip the minor recurring ones. Reviews from yourself happen in five-second bursts at 11 PM with your finger already on the merge button.
The AI reviewed everything. Every single line. With the same fresh attention each time. It didn't get tired. It didn't get polite. It told me the same boring truths every week.
It turns out a decade of nobody really pointing out my small habits had let those small habits compound into a kind of personal style I wasn't proud of when I finally saw it written down.
What you might find if you tried it
I am not going to make confident claims about what you'd discover, because the whole point of this experiment was that I didn't know what I'd discover. Probably you'd find something different from what I found. Probably you'd find that you do one specific thing on autopilot that's worse than you think.
The actual practice is just: route your PRs through an AI reviewer for two months. Don't argue with the suggestions in your head. Write down the ones you push back on. Read the list at the end.
It's a slightly humbling exercise. It made me a better engineer than any code review I'd had in the last five years from a human. I think that's the part nobody is going to write a viral tweet about, but it's the part that mattered.