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?
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: 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 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.
Here's the workflow many of us learned to follow before AI became part of everyday development:
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.
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.
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.