The Dispatch #88 — The Calibration Problem

The Question Most Engineers Stopped Asking

There's a question that used to come naturally to every good engineer:

"Do I actually know this, or do I just know how to find it?"

It was the question behind every "I've never seen that API before, let me figure it out" moment. Every late-night debugging session where you traced a bug to its root cause. Every architecture decision where you weighed trade-offs you understood deeply.

It was the question that separated engineers who understood systems from engineers who could operate them.

Most engineers stopped asking it somewhere around month six of heavy AI use.

Not deliberately. Not maliciously. It just became unnecessary. AI always knew. AI always had an answer. The question dissolved into the workflow because the workflow stopped requiring the answer.

The problem is what happens when you stop asking the question and the AI is suddenly gone.

What Calibration Actually Means

Calibration is the word cognitive scientists use for the relationship between your confidence and your actual knowledge.

A well-calibrated engineer knows what they know and knows what they don't. The confidence matches the competence.

An poorly calibrated engineer — one whose confidence has drifted from their actual capability — can think they understand something they don't. Can think they're capable of something they've outsourced. Can believe they're growing when they're actually delegating.

This isn't unique to the AI era. It's happened before:

Calculators made mathematicians feel like they understood arithmetic they couldn't do mentally
GPS made drivers feel like they knew routes they couldn't navigate
Stack Overflow made engineers feel like they understood errors they just copy-pasted fixes for

The difference now: AI accelerates every one of these effects simultaneously, across every layer of the work, faster than any previous tool.

And the drift happens so gradually that most engineers don't feel it until it's significant.

How to Know If You're Calibrated

Here's a simple test that takes about three minutes:

Think about the last five problems you solved — real problems, with real debugging, real architecture decisions.

For each one, ask: could I have solved this without AI?

Not "would it have taken longer?" — yes, it would have. That's not the question.

Could you have done it? Starting from a blank file, your own brain, your own knowledge?

Yes, fully. — I understood it deeply and could have built it independently.

Mostly. — I understood the pieces but couldn't have assembled the whole.

Partially. — I understood the requirements but couldn't have generated the solution.

No. — I needed AI to get this done.

If your answers cluster toward "mostly" or "partially" for most recent work — that's not a failure. That's just calibration data.

And calibration data is only useful if you do something with it.

Why This Matters More Than Your Velocity Number

Here's the uncomfortable part:

Your shipping velocity is probably going up. Your code quality metrics probably look fine. Your team probably thinks you're doing great.

And you might be calibrated so far from your actual capability that you'd be startled by a week without AI tools.

This isn't about being bad. It's about the gap between what you can demonstrate with AI and what you can do alone — and whether that gap is growing without you noticing.

The engineers who navigate this best aren't the ones using AI the least. They're the ones who've figured out which capabilities they want to maintain at full depth — and which ones they're comfortable delegating.

The key word: chosen. Not defaulted. Not drifted. Chosen.

The One Practice That Helps

Here's the thing that actually works:

Once a week, solve something without AI. For 20 minutes.

Not because it's efficient. Not because you'll produce better output. Not because it's the "right" way to work.

Because it's the only way to maintain the calibration signal.

When you go without AI — even for 20 minutes — you get real data on where you actually are. The gap becomes felt rather than theoretical. The "I could probably do this" becomes "I can do this" or "I actually can't."

That feeling is information. It's worth having.

The engineers who've maintained their skills through heavy AI use almost all have some version of this practice. Not as a productivity ritual. As a calibration check.

Why This Is Recoverable

If you took the test above and found the gap — don't panic.

The gap is recoverable. The brain is not a fixed-capacity machine. Skills that atrophy can be rebuilt. Understanding that drifted can be re-anchored.

The 30-Day AI Detox Plan is a structured protocol for exactly this: rebuilding the skills that matter most, one deliberate practice at a time.

But you don't have to do the full protocol. You can start with the 20-minute check-in. Once a week. Sunday morning, before the week starts. One problem. No AI.

The data you get from that 20 minutes is worth more than another sprint's worth of AI-assisted output.

What is the one problem — the single, specific thing — that you most want to still be able to solve without AI in a year from now?

Not the most commercially valuable skill. The one that, if you lost it, would make you feel like you were losing yourself as an engineer.

Start with a 3-minute readout on where you stand.

Take the AI Fatigue Quiz →

P.S. The AI Fatigue Quiz takes three minutes and gives you a real readout on where you stand. Over 2,500 engineers have taken it. Some found out they were more independent than they felt. Others found out the gap had grown further than they'd realized. Either way: clearing-ai.com/quiz.html