The Confidence That Wasn't Earned

The Opening

A staff engineer I know — sharp, thoughtful, genuinely good — ran an experiment recently.

He was preparing for a technical interview at another company. Not because he wanted to leave, but because he'd started noticing something: when he tried to solve problems without AI, he felt slower and less certain than he had two years ago. He wanted data.

So he did three practice problems. Algorithmic. Harder than anything he'd touched in production for months.

His AI-assisted solutions: elegant, fast, clean. He was pleased.

Then he tried them without AI. Cold. No hints.

He solved one fully. He got close on another but abandoned it after 40 minutes. He couldn't start the third.

He scored himself: strong intermediate. He knew the vocabulary. He could reason about approaches. He could review AI-generated code and spot most issues.

He could not, without AI, build a solution to a problem he could clearly describe.

And this is the thing about that experience: it didn't immediately feel bad. It felt educational. He thought: "Okay, now I know what I need to work on." He felt motivated, not devastated.

It took three days before the implication hit him: he had described a senior engineer's skill set — the vocabulary, the judgment, the reasoning — as if it were a learning goal. Not because he was learning it. Because it was the thing he used to just be.

What Confidence Without Struggle Actually Is

There are two kinds of confidence you can have as an engineer.

The first is earned confidence — the kind that comes from having done something hard, failed at it, pushed through, and come out the other side knowing you can do it. This confidence is robust. It doesn't collapse under pressure because it's been pressure-tested. It's the reason a senior engineer can look at a gnarly architecture problem and not panic — not because they've seen this exact problem before, but because they've solved enough genuinely hard problems that they've built a base of confidence that generalizes.

The second is AI-boosted confidence — the kind that comes from approving correct solutions. You look at the output, it looks right, you approve it, it ships, nobody calls it back. Over time, you start to feel like you have good judgment because your approvals keep working out. But the approvals are working out partly because AI is very good, and partly because the stakes in production are lower than the stakes in a genuinely difficult diagnostic moment.

The problem: these two kinds of confidence feel identical from the inside. You feel confident either way. You can't feel the difference between "I have good judgment" and "AI has good judgment and I'm good at verifying it."

But there's a specific test that makes the gap visible.

The Question That Exposes It

Before you use any AI tool this week, try this:

Ask yourself: "Do I know what I want before I ask for it?"

Not "do I know what I want the code to do" — you probably do. But "do I know what kind of solution I'm looking for, what tradeoffs I want it to make, what constraints matter and which don't?"

If you don't know what you want before you ask, the AI is not executing your vision. It's forming one on your behalf.

This is not always bad. Sometimes you genuinely don't know what you want and AI exploring the problem space is useful.

But there's a version of this that's become a habit: you open the AI tab before you've thought about the problem. You describe a vague direction. You get back something plausible. You approve it or ask for revisions. By the end, you've built something, and you're not sure how much of it came from your judgment and how much came from the AI's.

The confidence you have at the end is boosted, not earned. And the problem with boosted confidence is that when you need the earned kind — when something breaks in production and you need to understand it without the AI, when you're in an interview and can't use the tool, when you're mentoring someone and need to explain not just what but why — it's not there.

The Specific Pattern This Week

Here's where it shows up most painfully:

In estimation. You estimate a task at 4 hours. AI generates the scaffolding in 20 minutes. You approve it. The task finishes in 5 hours total. You think: "See, my estimate was right." But the 4-hour estimate was your AI-assisted judgment, and the 5-hour reality was partly AI-assisted execution. The comparison is meaningless.

In code review. You review AI-generated code. It looks correct. You approve it. Three weeks later a subtle bug surfaces — the kind that requires reading the code very carefully to catch. You missed it. Your confidence in your review ability was higher than your actual review ability, and you didn't notice.

In technical decisions. You're doing architecture work. You have AI generate three options and evaluate tradeoffs. The evaluation sounds sophisticated. But did you have the tradeoff framework before the AI generated it, or did you adopt the AI's framework? Can you defend the choice without the AI's framing?

The pattern is always: you feel confident right up until the moment you need the confidence to be real. And by then it's too late to build it for the moment you're in.

The Practice

This isn't about anxiety. It's about the specific skill of maintaining earned confidence while using AI as a productivity tool.

One concrete practice this week:

The goal is not to stop using AI. It's to stay in the loop — the one where you have a judgment, AI helps you execute it, and you can tell the difference between "AI executed my judgment well" and "AI made a judgment and I approved it."

The Closing Note

The staff engineer I mentioned? He told me he's changed his approach since that experiment.

He's not doing fewer AI-assisted tasks. He's doing one thing differently: before any significant decision, he writes down what he thinks. Not to be right — to stay in practice at having an opinion.

That's the whole practice. Two sentences before the tab. Just enough to stay in the loop.