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.
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:
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.
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.
When people say "just think about the problem," it sounds vague. It isn't. For developers, thinking is a specific, learnable set of moves:
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.
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.
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.
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:
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 | Thinking AI |
|---|---|
| "Build this for me." | "Here's my approach. Challenge it." |
| "Fix this bug." | "Here's my hypothesis. What am I missing?" |
| "Write the architecture." | "Compare these approaches and their trade-offs." |
| "Explain this code." | "I'll explain it — tell me what I missed." |
| "Give me the answer." | "Help me evaluate the options." |
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.
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.
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 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.
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.
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.
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.
When you get stuck on a coding problem, what's your first move?
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.