The Idea
There’s an idea going around tech right now. Raj Nandan Sharma puts it bluntly: when AI makes building easy for everyone, good taste is the only real advantage left. The Last Software Engineer says something similar: once writing the code is cheap, the hard part is deciding what should be built.
Taste, judgment, call it what you like. I mean the calls that aren’t written in any instruction. What’s worth doing and what isn’t. What to leave out. What actually matters in this situation. How to say something to this particular person.
AI can do everything else, the idea goes, but not that. That sounded right to me. Then I watched something I built at work.
The Tool I Built
A while back I was told I needed to review more of my colleagues’ code. I was already using AI to fix my own code, improve it, and sometimes write or debug it. So the next step felt obvious: let it do the reviewing too.
Now it does. It reads the change, writes up its comments, and nothing reaches my colleagues until I approve it. I use it every day.
Watching It Grow Up
At first I checked everything it wrote before letting it out. I wanted to steer it enough that it could learn from my corrections.
My corrections fell into two groups. Sometimes it was simply wrong, because it didn’t know enough about the code. Other times it was technically right but didn’t sound like me: the wrong words, the wrong examples, the wrong tone.
That second group is exactly what I’d have called judgment: how you’d say something, what you’d point out, what you’d let go. It learned that. Every correction was, in a way, me writing my judgment down. I still have a “mark wrong” button, but these days I rarely need it.
What’s left isn’t tone anymore. It’s how things actually get released at work: the manual steps, the unwritten habits, the stuff that isn’t in the code or in any document.
The Checkbox Complication
I’ve seen the opposite at work more than once. One feature I remember: we changed how it worked so it followed the official standard it was always supposed to follow. Correct, overdue, good. And then we added a checkbox, so anyone could switch it back to the old behaviour. Because adding it was easy, and “what if someone needs it the way it was?”
Each checkbox like that is cheap to add. Together they make a product harder to understand. Nobody decided it should be confusing. It got that way one reasonable “what if” at a time.
Not adding that checkbox would have been the right call, and it’s written down nowhere. Not in the standard, not in the code.
My Problem
And yet the reviewer keeps absorbing things I’d have filed under judgment. Rico Mariani describes automation as taking over the repetitive steering so your attention is free for the decisions that really need you. That matched my experience, except the line kept moving while I watched. Things I thought needed me turned out to be patterns I just hadn’t spelled out.
And honestly, even my own tool didn’t come from some grand act of judgment. I built it because someone asked for more reviews, and because I love watching things happen on their own.
What I Can’t Answer
My reviewer learned to sound like me in a matter of months. If someone documented our release process tomorrow, what’s left would shrink again.
If everything we know eventually gets written down, is there any judgment left that’s only ours?