Where Does Judgement Come From When AI Does the Grunt Work?

There's a line you now hear in almost every conversation about AI and work: as intelligence gets cheap, judgement becomes the scarce thing. I agree with it. I've said versions of it myself.

What I don't hear nearly as often is the follow-up question. If judgement is the scarce skill, where does it actually come from?

The honest answer is that it comes from experience, and specifically from making calls, living with the results, and noticing why they went the way they did. That's slow, and it's uncomfortable. It also happens to be exactly the kind of experience that AI is now making easier to avoid.

What the Grunt Work Was Really Doing

Think about what a junior person's first few years used to look like. Reconciling numbers that didn't quite match. Drafting the first version of everything. Reading through a pile of customer feedback and working out what was noise. Writing up the meeting notes. Building the first rough cut of the analysis that someone senior would tear apart.

None of that looked profound at the time, and most people were glad to see the back of it. But it was doing a quiet second job. Every time a draft came back covered in someone else's corrections, you learned what good looked like. Every time you spotted a number that felt wrong before you could say why, you were building pattern recognition. Over a few years, the grunt work added up to something nobody put on a job description, which was the ability to look at a situation and know that something was off.

Now AI is very good at the first draft, the reconciliation, the summary and the rough analysis. That's genuinely useful, and I'm not arguing for going back. The problem is that nobody has redesigned the apprenticeship that used to ride along with that work.

We've kept the output and quietly dropped the training.

The effect won't show up this quarter. It shows up in five or ten years, when there's a thin layer of people with well-built judgement at the top and not much behind them.

What Organisations Can Do About It

If you lead a team, the practical response isn't to hand juniors the tedious work back out of nostalgia. It's to deliberately create the experiences the tedious work used to provide. A few that I think are worth the effort:

Put people closer to real decisions earlier

Junior team members should be in the room, or at least in the written trail, when a meaningful call is made and when its results come in. Watching the reasoning and the outcome side by side is where a lot of the learning happens.

Make them commit before they see the answer

Ask a junior to form their own view on a problem, with their reasoning, before they look at what the AI produced. Then compare. The gap between their view and the machine's, and between both and what a senior person would do, is the lesson. Skipping straight to the AI answer removes the part where the muscle gets worked.

Give small decisions real ownership

A decision with a small budget, a small customer, or a small internal process that someone genuinely owns teaches more than ten hypothetical exercises. The consequences have to be real, even if they're modest.

Review the reasoning, not just the output

When a decision is reviewed, spend the time on how the person got there, not only whether it worked. A good outcome from bad reasoning is luck, and a bad outcome from good reasoning is just a bad day. Learning to tell those apart is most of the skill.

What You Can Do About It Yourself

If you're an individual rather than a team lead, you can't redesign your organisation's apprenticeship model, but you can build the feedback loop yourself. The simplest tool I know for it is a decision journal.

The idea is plain. Before an important decision plays out, write down what you decided and why. Then, later, look at what actually happened. Most of us skip both steps. We make the call, move on, and let hindsight quietly rewrite what we thought at the time, which means we never learn much from our own track record.

A useful entry doesn't need to be long. Capture:

• The decision. What you're choosing, in a sentence.
• The options you considered. Including the one you rejected.
• Your reasoning. Why this option, in your own words.
• Your confidence. A rough percentage that the decision will turn out well.
• What would change your mind. The evidence that would tell you that you were wrong.
• A review date. When you'll look back, usually 30 to 90 days out.

When the review date arrives, compare outcome against reasoning. Did it work, and was it because of your thinking or despite it? Were the things you thought mattered the things that mattered? Over a few months, the confidence numbers become the most interesting part. If the decisions you rated at 80% only work out about 60% of the time, you've learned something specific and useful about where you're overconfident. That's a calibration you can't get from reading about judgement. You only get it from your own record.

Making It Stick With a Second Brain

The reason most decision journals die is friction. If logging a decision takes longer than making it, you'll stop within a fortnight.

If you already run a persistent memory layer, as I described in my earlier post on connecting a second brain to every AI tool, the friction mostly disappears. A decision entry is just another stored note, tagged consistently (I'd use a simple "decision" tag alongside the project tag), written in a few lines from whichever tool you happen to be in. When a review date comes around, you recall everything tagged "decision" from that period and go through it. Because the memory is available to your AI tools, you can ask them to pull out the decisions you were most confident about, or to flag where your stated reasoning and the eventual outcome disagreed. You get a review that's grounded in what you actually wrote at the time, not what you now remember thinking.

You don't need that specific setup. A notes app and a recurring calendar reminder will do the job. The tool matters far less than the habit of writing the reasoning down before you know how it turns out.

Use AI as a Sparring Partner, Not an Oracle

One last practical habit, because it ties the organisational and personal sides together.

The easiest way to let your judgement atrophy is to ask an AI what to do and then do it. The better pattern is to form your own view first, write it down, and then ask the AI to argue against it. Ask it what you're missing, what the strongest case for the option you rejected looks like, and what would have to be true for you to be wrong.

That keeps you doing the part of the work that builds the skill, while still getting the benefit of a fast, tireless second opinion. You're using the machine to sharpen your reasoning rather than to replace it. And it keeps accountability where it belongs, because at the end of the day a model doesn't own the outcome of a decision. You do.

The Short Version

Judgement isn't a trait you have or don't have, and it isn't something you can declare. It's trained, through making decisions with real consequences and learning honestly from how they turn out. AI is removing a lot of the low-stakes practice that used to build it, which means the practice now has to be designed deliberately, by organisations for their people and by individuals for themselves.

None of that is complicated. It's mostly a matter of writing things down before you know the answer, and being willing to look at the record afterwards.

If you're thinking about how to build judgement across a team, or how to redesign junior roles now that AI is absorbing so much of the early-career work, I'm happy to talk it through.