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 st...
For further actions, you may consider blocking this person and/or reporting abuse
The “thinking tax” idea really resonates. I’ve found AI works much better when I first form a hypothesis and then use it to challenge my reasoning instead of just accepting the first fix.
Great read. And this post makes me rethink about the use of AI. We are continuously figuring out how to best use of this new tool. When I am working on my project, I always have a bunch of docs opened so that I can look things up and verify.
Harsh, the missing-await story hit close. I've had that exact moment building RAG pipelines, a fix that works but I can't explain the race behind it until I actually trace it myself.
Your THINK method is basically what I do without a name for it: hypothesis first, AI to check it rather than generate it.
Rule 5 is the one I skip most tho. explaining it out loud. Do you actually do that step or does writing the hypothesis down count as enough for you?
Thansk Daniel For me writing the hypothesis down is only the starting point. I verify the fix by explaining it back to myself in plain language what happened, why it happened, and why the fix addresses the root cause. If I can't explain it without reopening the AI's answer I don't consider the debugging finished.
That's really what I meant by Rule 5: a working fix isn't necessarily an understood fix. Your RAG example is a great illustration of that gap.
I like the distinction between getting an answer and keeping the debugging muscle. The expensive failure mode is accepting a patch before you can explain the causal chain. My rule is simple. If I cannot restate the fix without the assistant open, I have not finished the work.
Exactly I can’t explain the fix without the assistant open is such a good test for whether we actually understood the solution. Getting the code to work is one thing; being able to reconstruct the reasoning behind it is another. Thanks for putting that so clearly.
This is a great perspective. AI can make us faster, but speed without understanding can create a dangerous illusion of competence. I especially like the shift from AI as an answer machine to AI as a thinking partner. The real skill isn't knowing how to get AI to write more code it's knowing what to ask, why you're asking it, and whether the answer actually makes sense.
Absolutely. AI as a thinking partner is exactly the shift I was trying to describe. Bring the hypothesis and context first, then use AI to challenge it, explore alternatives, and expose gaps not simply to hand over the reasoning. Speed matters but only when we can still judge whether the answer makes sense.
The scariest case with coding agents is the one you name: a correct answer you cannot explain. A missing await that makes a field stop being null is the easy version. The harder one is a multi file change that compiles, tests pass, and still rewires an invariant you only catch when you force yourself to read the diff instead of trusting the summary. Your Rule 3 is the one I keep. I treat every agent solution as a hypothesis to attack, not a finished answer to accept.
This is exactly the failure mode I was trying to get at with the correct answer section. A clean compile and passing tests can give you a lot of confidence while still hiding a broken assumption somewhere in the system.
I really like your framing of every agent solution as a hypothesis to attack. That also changes how you read the diff you're not just checking whether the code works, you're actively looking for what assumption the change might have violated. That's a much stronger review loop than trusting the summary.
"Great insight. I empirically tested this recently while building an MCP server for AI agents. When the agent's memory was contaminated with false facts, the model didn't 'think' to correct it—it confidently hallucinated. The fix wasn't a better prompt; it was building a deterministic 'Verify-On-Read' layer (a mechanical constraint) to challenge the AI's semantic claims against the live codebase. You can't solve a thinking problem with just more tokens; you need architectural guardrails."
Thanks for the post! In my case it depends on the problem: sometimes the LLM is just a brainstormer/search engine to discover new things, other times it's a huge source of frustration when things don't work out (going back and forth the chat) essentially while vibe coding snippets. In this last case I just go back to the "DIY" method and it works out, since the AI already excluded some of the wrong answers. The method you describe should make things surely more productive.
Remember that these chat platforms are also built for retention, so answers could be made partially wrong on purpose, not mentioning constant sycophancy.
I'd like to add that it's helpful for the AI agent to always briefly explain what it did and why it did it that way. I know from experience that you can quickly learn many interesting solutions simply by reading the AI agent's response on how to do something.
Beautifully written @harsh2644. It's funny that the only solution for developer skill atrophy is going back to the tried and tested. Struggle, discipline, and understanding. There's a reason why failure is the greatest teacher of all. It forces you to think of a solution yourself. That makes you better everyday.
I'm also not entirely against AI. I use it too for boilerplate and code that I have done multiple times and code that I could explain with my eyes closed. But what I'm against are engineers pretending they know every AI generated solution and treating it as the final answer. That's a one-way ticket to skill regression.
AI is supposed to be a tool that help you expand what you already know. It should help you understand it. If something is suggested, go try it, fail, and try again until you know it through and through. But if you end up not understanding a thing but approving the changes anyway, then are you still considered an engineer or an zombie accepting bot for AI. That's something to think about.
This is a really important distinction. I don't think the answer is to bring back struggle for the sake of struggle either. The valuable part of the struggle is the understanding you build while working through the problem.
I especially like your point about treating an AI-generated solution as the final answer. That's where the real risk is for me too. AI can expand what we know, but if we can't explain, test, or challenge what it gives us, we're not really building the mental model we're just accepting the output.
Try it, fail and try again until you know it through and through is a great addition to the Think idea.
This matches how I try to use these tools: the value shows up when I have already decided what a good answer looks like before I ask, otherwise I just get fluent output I cannot check. The people I see struggle most are the ones who skip that step and let the model define the target. Does the "thinking first" habit transfer to your team, or does it stay a personal discipline?
Kartik I think it can absolutely transfer to a team, but it has to become part of the workflow rather than relying on individual discipline. For example, before asking AI for a solution a developer can write down the problem, their hypothesis, and the constraints they're considering. Then AI becomes a second opinion rather than the first source of the solution.
That also makes code reviews more meaningful because the discussion shifts from does this generated code work? to “does this solution actually make sense given the system we're building?
For me, that's where the habit becomes a team practice instead of just a personal rule.
This hit hard — I lived the "scariest AI answer is a correct one" failure mode verbatim.
I built a macro scenario classifier (ISM PMI → GOLDILOCKS/CONTRACTION/SOFT_LANDING) and an AI-generated backtest summary claimed "GOLDILOCKS +1.2% vs CONTRACTION -2.1%." It matched my prior perfectly (contraction = risk-off, right?), so I published it. Three platforms. 234 readers.
Then I ran the real event study myself: 72 ISM releases, 1530 real S&P 500 trading days via yfinance. Result: GOLDILOCKS +0.80% vs CONTRACTION +1.13%, Welch p=0.643, and the signal was backwards at all 4 horizons (5/10/21/42d). CONTRACTION releases actually outperformed — markets are forward-looking, contraction → policy easing → rallies.
Your Rule 3 ("What did I miss?") is the exact step I skipped. The fabricated numbers were plausible, so I trusted them without re-deriving. It took 5 sessions to retract the public claims across Dev.to/Juejin/CSDN.
The meta-lesson I would add to THINK: event-study your classifier before you sell it. A backtest is not a prompt you can eyeball — it is a deterministic procedure you re-run. The fix was not a better prompt; it was running real_backtest.py myself and reading the p-value.
Open-source repro: github.com/473185670/macro-scenario-api (real_backtest.py + multi_horizon_backtest.py). The "correct answer you trust" gap is real — I am still cleaning up the liability it created.
This is sow true
Thanks for reading Farhat.
I'm glad there are still developers who value the mental models we build and maintain while developing software.
Having that mental model makes debugging easier, helps us reason about the system, and makes building on top of it with reliability much easier 😎
Absolutely. A strong mental model is what lets us debug beyond the immediate symptom and reason about what happens next. I think AI is most useful when it helps us build and test that mental model rather than replacing the reasoning behind it.
AI isn't the enemy—our thinking is. Use it to sharpen judgment, not outsource it.
Well put. I think the goal isn't to use AI less, but to use it in a way that keeps us thinking. Let it challenge our assumptions, surface alternatives, and speed up the work without handing over the judgment.
this resonates. the real bottleneck isnt AI capability but our own thinking patterns. teams that slow down to define the problem clearly before reaching for AI tools get way better results.****
Exactly I think that's one of the biggest shifts AI is forcing us to confront. If we slow down enough to define the problem clearly, AI becomes much more useful because we're giving it something meaningful to reason about instead of asking it to figure out the problem for us.
mostly claude code with MCP for dev work. tried autogpt and crewai but they burn through tokens fast.
That's an interesting setup. MCP + Claude Code can definitely make the workflow much more powerful especially when the context is already available to the model. The token cost is an interesting trade-off though faster access to more context can also make it easier to over-generate.
README is 80% of it. if someone can't understand what your project does in 30 seconds they're gone.
Absolutely. A good README is almost like giving the developer or the AI a mental model of the project before they start making changes. If you can't explain what the system does clearly, it's much harder to judge whether an AI-generated change actually makes sense.
I want developers to become pizzas.
I like pizzas 🥰