The AI skill nobody's teaching engineers
Judgement.
👋 Hey, it’s Stephane. I help engineers become great engineering managers - whether you want to become one or are already leading a team.
Paid subscribers get 50 Notion Templates, The EM’s Field Guide, and access to the complete archive.
An engineer comes to your architecture forum with five approaches to the problem they’re trying to solve. They describe each one’s pros and cons and then open up to the group: “What do you think? Which one should we take?”
None being obviously bad. They are all… fine.
So people just sit there, not contributing much, not being able to decide which one to pick based on the information provided.
AI has made producing options incredibly cheap, but it hasn’t made choosing between those options much easier.
Pick one
Faros surveyed more than 10,000 developers across 1,255 teams and found that teams with high AI adoption completed 21% more tasks and merged 98% more pull requests. Impressive.
That’s a lot more output. But the the same study didn’t find a significant relationship between AI adoption and improvement at the company level.
Meaning, we’re producing more stuff... but that doesn’t automatically mean we’re producing more value.
Someone still has to decide what we should actually build.
Producing an option can now take minutes. Choosing the right option still requires context, experience, technical understanding and, for lack of a better word, taste.
AI hasn’t really made that part cheaper (yet).
Five right-ish answers
AI more often than not is not giving you obviously wrong answers. It gives you a lot of answers that look pretty reasonable.
Knowing when something’s “almost right, but not quite” is quite hard.
We’ve spent years associating well-written technical proposals employing good thinking and rationale. Usually if somebody had written a clear, detailed design document, they had spent quite a lot of time thinking about it.
This is no longer the case today.
A beautifully written technical proposal might have taken somebody 10 minutes, which means we need to get much better at judging it.
Joel Spolsky wrote in 2000 that it’s harder to read code than to write it. That is pretty obvious today with so much AI-generated code having to get reviewed.
Twenty-five years later, DORA’s 2025 report had 90% of respondents using AI at work and more than 80% said it made them more productive.
But 30% also said they have little or no trust in the code AI generates.
So we’ve massively accelerated the producing part of engineering... while the expensive part, understanding whether something is actually good, is still very human.
We used to learn this accidentally
I don’t remember anyone teaching me engineering judgment.
You just accumulated it over time by building stuff. By getting stuck in, failing over and over again, reading documentation, until it suddenly worked. At which point you’d go back to refactor all the shitty code you had written to make it work and bring it to a state that it can be reviewed by others.
In that process you had to understand and think about so many parts of the system. And as a result, form opinions about them. “I can understand this part easily because it’s written in that way.” “That part caused me headaches, and I spent hours trying to understand it.”
And slowly you started recognising patterns.
Collins, Brown and Holum talked about why apprenticeship works decades ago: the important bit is making the thinking behind the work visible.
Software engineering used to involve producing the work yourself, and producing it gave you the reps.
AI is starting to remove some of those reps.
This worries me particularly with junior engineers.
Stanford’s Digital Economy Lab found that early-career workers aged 22 to 25 in the most AI-exposed occupations have already seen a relative decline in employment.
Charity Majors made a similar point when she wrote that “by not hiring and training up junior engineers, we are cannibalizing our own future.”
I’d add one more.
Even the juniors we do hire can now skip quite a lot of the messy producing work that used to build judgment.
Maybe that’s fine, but if we remove those reps, I think we need to replace them with different ones. Because judgment today matters more than in the past.
So I’ve started thinking about technical taste less as something senior engineers magically acquire, and more as something we need to deliberately train.
There are five fairly simple things I’d change to make that happen:
👇👇👇 (access with a paid subscription)
