You Don't Have an AI Problem You Have a Thinking Problem.

I used to think AI was making me lazy. I was wrong. AI wasn't making me lazy I was using AI as an excuse not to think.

And once I noticed it, I started seeing the same pattern everywhere - in my own code, in PRs I reviewed, in Slack messages that said "AI said this should work" like that was the end of the conversation.

So let me ask you the same question I had to ask myself: When you hit a hard problem, what's your first instinct?

Do you think? Or do you open your AI assistant?

Be honest. Nobody's watching. That one-second decision might tell you more about your current development habits than your GitHub streak ever will.

I Noticed Something Weird

A few months ago, I was working on a Node.js backend API. One of the endpoints kept returning a response with a field coming back as null not always, just often enough to be annoying and hard to pin down.

A year ago, I would've spent the next 30–60 minutes:

• rereading the endpoint and the code around it
• checking where that field was supposed to get populated
• tracing the request from top to bottom
• trying something
• breaking it
• fixing it
• finally getting it

Instead, I opened my AI assistant and described the bug: the field was null in the response even though the data existed in the database.

It suggested a fix a missing await in the chain, so the field was being read before the value it depended on had actually resolved. I applied it.

The field stopped being null.

That should have felt like a win. It didn't.

The fix worked, but when I tried to explain why it worked why that particular await mattered, what exactly was racing against what - I couldn't. I had a working endpoint and a gap where my understanding should have been.

That's the moment this whole article came from.

We've Made Thinking Optional

Here's the workflow many of us learned to follow before AI became part of everyday development:

Problem → Confusion → Research → Hypothesis → Experiment → Failure → Understanding → Solution

And here's the workflow that's becoming increasingly common:

Problem → Prompt → Answer → Copy → Done

The second one can be dramatically faster. And that's exactly why it's so tempting.

But the first one is where the learning used to happen. Confusion wasn't a bug in the process it was the process. Struggle wasn't wasted time. It was the mechanism.

So let me be precise about what the actual problem is, because it's not what most people think:

The problem isn't that AI gives us answers. The problem is that we're getting answers before we've had the chance to form our own questions.

Read that again. That's the whole article in one line.

Thinking Isn't Staring at a Blank Editor

When people say "just think about the problem," it sounds vague. It isn't. For developers, thinking is a specific, learnable set of moves:

• breaking a problem into smaller pieces
• forming a hypothesis before testing it
• predicting how the system should behave
• understanding constraints before proposing solutions
• weighing trade-offs, not just outcomes
• questioning your own assumptions while debugging
• asking "why does this exist?" before asking "how do I fix it?"
• deciding what should not be built

Writing code is only a small slice of software development. The harder, more valuable part is deciding what code should exist in the first place and that part doesn't show up in a prompt box.

The Scariest AI Answer Is a Correct One

Here's the part nobody talks about enough.

A wrong answer is easier to notice. It breaks, you investigate, and you learn something while fixing it.

A correct answer, you trust. And trust is exactly where thinking quietly checks out.

When we use AI passively, the workflow can become:

Problem → Solution

What it skips, unless you force it, is this:

Problem → Why? → Constraints? → Alternatives? → Trade-offs? → Solution

A correct answer can hide a missing mental model. You walk away with working code and a gap in understanding that won't show up until three months later, in production, at 2 a.m., when the "why" finally matters and you don't have it.

The Experiment: Paying the Thinking Tax on Purpose

So I tried something different. A self-imposed "thinking tax" before I was allowed to open the AI assistant.

Rule 1 - For most non-trivial problems, spend a few minutes thinking about them before reaching for AI. (Obviously this doesn't apply to a production incident at 2 a.m. this is for the everyday problems, not the fires.)

Rule 2 - Write down my hypothesis before asking AI anything.

Rule 3 - When AI gives an answer, stop asking "Is this correct?" Start asking:

"What did I miss?"

Rule 4 - Ask for three alternatives, not one solution.

Rule 5 - Explain the final solution back in my own words, out loud, like I was teaching it to someone.

The interesting part wasn't that I solved fewer problems without AI. It was that by the time I actually opened the AI assistant, my questions were sharper. I wasn't asking it to think for me anymore. I was asking it to check my thinking.

That's the real shift: AI as answer machine → AI as thinking partner.

The THINK Method

If you want something more repeatable than "just be more mindful" (which, let's be honest, nobody sticks to), here's the framework that came out of that experiment.

Before asking AI, THINK:

• T - Try First. Give it a few minutes of genuine effort before reaching for help.
• H - Hypothesize. Write down what you think is happening, even if you're probably wrong.
• I - Identify Constraints. What can change here, and what can't?
• N - Need a Second Opinion. Now bring in AI.
• K - Know Why. Don't accept the answer until you can explain it without the AI in the room.

The goal isn't to avoid AI. The goal is to make sure you have a mental model before AI hands you one.

The difference this makes shows up in the prompt itself.

Instead of:

Fix this bug - the field is coming back null.

You end up asking:

I think this field is null because it's being read before the value it depends on has resolved possibly a missing await somewhere in the chain. Here's my reasoning what am I missing?

Same bug. Completely different developer on the other end of that prompt.

Passive AI vs. Thinking AI

The difference isn't whether you use AI. It's how much thinking you hand over to it.

The difference is who's doing the thinking.

The Best AI Users Aren't the Best Prompters

A lot of the AI conversation is about learning better prompt engineering. I think we're sometimes aiming at the wrong target.

The best AI users aren't necessarily the people who know the cleverest prompt structures. They're the people who know which questions are worth asking in the first place.

That's not a prompting skill. That's domain knowledge wearing a prompt as a disguise.

Domain knowledge → better questions → better AI output.

Without domain knowledge, it goes the other way: AI output → looks impressive → gets accepted without scrutiny, because you don't know enough to scrutinize it.

What Happens to Developers Who Stop Thinking

This isn't a fearmongering "AI will replace you" section. It's slower and quieter than that.

Stage 1 - AI helps you move faster. Genuinely great.

Stage 2 - You start asking AI first, by default, before you've even tried to frame the problem yourself.

Stage 3 - You may stop exploring alternatives. Why would you the first answer worked.

Stage 4 - You start depending on generated solutions to think for you, rather than using them to challenge your own thinking.

Stage 5 - You can still produce plenty of code. But you may struggle to explain why it exists, why it's structured that way, or what would break if a constraint changed.

That's not an AI skill problem.

That's a dependency problem.

I'm Not Going Back

I want to be clear about something, because it's easy to read all of this as anti-AI. It isn't.

I'm not going back to writing everything manually. AI is too useful for that, and pretending otherwise would just be performative.

I still use it constantly for boilerplate, debugging, tests, documentation, refactoring, brainstorming, generating alternative implementations, and exploring APIs I've never touched before.

But I changed one thing:

I don't want AI to be the first thing that thinks about my problem.

I want to be.

Maybe the Future Isn't Prompt Engineering

Here's where I think the industry conversation is slightly off.

The valuable skill stack isn't:

AI + 100 clever prompts

It's:

Domain Knowledge + Critical Thinking + Problem Decomposition + AI + Judgment

AI makes generating many possible solutions dramatically cheaper and faster. That's exactly what makes knowing which solution to choose, and why, more valuable.

When generating answers becomes cheap, knowing which answer to trust becomes more valuable.

The less expensive code generation becomes, the more valuable technical judgment becomes.

Your Big Takeaway

Don't compete with AI on raw code generation. That's a race you don't need to win.

Compete with yourself at asking better questions.

Let AI write the boring code. Let it generate the alternatives. Let it find the edge cases. Let it challenge your assumptions.

But don't outsource the one part that actually makes you a developer:

judgment.

So, Did You Solve It - Or Did You Just Approve It?

Here's the question I've been sitting with lately:

When AI solves a problem for you, did you actually solve it?

Or did you just approve the solution?

Maybe the biggest AI skill isn't prompting after all.

Maybe it's knowing when not to prompt yet.

You don't have an AI problem.

You have a thinking problem.

And I'm still learning how to solve mine.

Let's talk

When you get stuck on a coding problem, what's your first move?

• A) Think and debug
• B) Search docs/Google
• C) Ask AI
• D) Depends on the problem

If AI is usually your first move, has it ever made you realize you understood the problem less than you thought?

I'm genuinely curious.

I write about AI, software development, and how new tools are changing the way developers think and work.

If you're thinking about the same questions, follow me here on DEV. I'm less interested in predicting whether AI will replace developers and more interested in figuring out what developers need to become next.