I want to make a claim that might age badly, and I'm making it anyway.
The more we offload thinking to AI tools, the more we need deliberate practice to stay sharp. And LeetCode — for all its baggage — is one of the few structured ways most developers have to do that.
Not for interviews. For your brain.
Something is quietly happening to developers right now
Nobody announces it. There's no error message.
But ask yourself honestly: when was the last time you worked through a non-trivial logic problem without reaching for Copilot, ChatGPT, or a Stack Overflow snippet in the first five minutes? When did you last choose a data structure because you reasoned through the trade-offs — not because autocomplete suggested it?
AI coding tools are genuinely useful. I use them daily. But there's a cost that compounds slowly and invisibly: you stop exercising the reasoning muscle, and eventually, it weakens.
You don't notice until someone asks you why your solution works — and you have to think harder than you expected.
What forgetting actually looks like
It doesn't look like incompetence. It looks like learned helplessness disguised as efficiency.
You paste a problem into ChatGPT before sitting with it for even two minutes
You can read code well but struggle to write logic from scratch under any pressure
You know a nested loop is "probably bad" but can't articulate why, or what the better approach is
You feel vaguely anxious when the AI gives you a wrong answer — because you're not sure how to verify it
That last one is the one that should worry you. If you can't sanity-check the output, you're not using a tool. You're depending on one.
Why DSA and algorithms are actually the right antidote
Not because Google-style interviews are a good measure of engineering talent — they're often not.
But because DSA problems are the most concentrated form of a skill you use constantly in real work: breaking down a problem you've never seen before, reasoning about it carefully, and arriving at a solution you can defend.
Working through a sliding window problem trains you to notice patterns in data. Implementing a graph traversal from scratch forces you to hold state in your head. Getting a time complexity wrong and figuring out why teaches you to question your own assumptions.
None of that is interview prep. All of it is thinking.
And thinking is exactly what AI is tempting us to skip.
The bar is low — and that's the point
I'm not suggesting grinding 300 hard problems on a leaderboard.
Twenty minutes, a few times a week. One problem. No solution tab open. The goal isn't to solve it — the goal is to try before you give up. To sit with the discomfort of not immediately knowing the answer, and work through it rather than outsourcing it.
That habit — trying first, thinking before reaching — is what erodes fastest in an AI-assisted workflow. It's also what makes you the kind of engineer who can actually steer AI tools well, rather than just accept whatever they produce.
This isn't nostalgia for a pre-AI world
AI tools are here, they're useful, and they're not going anywhere. The developers who will use them best aren't the ones who delegate the most — they're the ones who've kept their own reasoning sharp enough to know when the output is wrong, when the approach is suboptimal, and when the problem itself is being misunderstood.
DSA practice won't make you immune to bad AI output. But it keeps the critical faculty alive - the part of you that reads a solution and thinks "wait, that doesn't feel right" and knows how to follow that instinct.
That instinct is worth protecting.
Are you still doing any deliberate problem-solving practice, or has AI tooling changed how you think about that? Genuinely curious where other devs land on this.
Top comments (35)
It is dangerously easy to confuse access to answers with actual understanding. When we let LLMs do all the cognitive heavy lifting, we aren't just saving time—we are outsourcing our critical thinking skills and problem-solving muscles. AI is an incredible bicycle for the mind, but you still have to pedal. If you don't know how to structure a thought, validate an assumption, or spot logic flaws on your own, a tool that generates text at lightning speed just helps you fail faster. Brilliant reminder to keep our brains engaged.
Fax, Syed!
This is exactly the line I keep coming back to with AI tools:
If you can’t verify the output, you’re not really delegating. You’re deferring judgment.
I don’t think the danger is simply “AI writes code.” The danger is AI quietly taking over
the parts of the work that used to train our judgment: framing the problem, checking
assumptions, noticing when something feels off, and deciding whether an answer should be
trusted.
I’ve been seeing a similar pattern while testing AI agent memory. The problem is not only
whether the system retrieves relevant context. It’s whether the retrieved context is
actually allowed to govern the action.
That maps to humans too. Having an answer available is not the same as understanding
whether that answer should guide your decision.
So I agree with the post: deliberate practice matters, not because we need to reject AI,
but because we need enough independent reasoning left to supervise it well.
I'll play devil's advocate for a moment: if a manager assigns a complex task to an employee who works below them on a team, a task they don't have the capability to complete themselves, would that not be considered delegating? This is actually the norm in many teams. Once someone reaches manager level, they might fall behind on technical skills while they focus on more managerial and orchestration skills.
The definition, according to Cambridge is:
It doesn't say anything in regards to requiring the delegator to have the ability to verify the output or the results from the individual who completed the task.
I suppose its semantics, but I would say that you're always delegating, its just a matter of how much. You can delegate tasks you can do yourself, but just don't have the time (largely my #1 use case I have with LLMs), or you can delegate entire swaths of work that you're actually not capable of doing yourself, and just trusting the the result that comes back. This is not uncommon in workplaces, because you trust the team below you to have the technical skills to effectively complete the task.
The rub with LLMs is that you don't actually know if the model effectively completed the task, or just completed the task and confidently stated it was done.
Balance is the key. Delegation is good when you fully understand what are you delegating. The point you should always train you brain
Just read through it. the distinction between vibe coding and deliberate delegation is
one of the most honest framings I've seen for what actually separates builders who stay
sharp from ones who drift. I've been running AI agent systems where every claim gets
pre-registered before the results come in. if I can't state exactly what the test
should find before I run it I'm not delegating I'm just hoping. the skepticism has to
be built into the workflow before the model touches anything not applied after you see
the output.
100%. Diligent and vigilant skepticism, always. I'd do the same with humans, but even more so with LLMs because they are wrong in the worst ways: they never learn and to an LLM, the "right" answer and the "wrong" answer are identical.
The manager analogy is fair and you're right that verification ability isn't the line.
What makes human delegation work even when the manager can't verify technically is that
a good employee tells you when they're uncertain. They say "I ran into a problem here"
or "I'm not sure about this part." The rub you named at the end is the actual problem:
the model doesn't distinguish between "I completed this confidently and correctly" and
"I completed this and it looks right to me." The delegation still happens. The signal
about confidence doesn't.
I think in all of the stories and analogies we can derive one key point. There's always someone responsible for the desicions made and actions taken. And in all the scenarios the executor of the task doesn't bear the whole responsibilty by himself (except if he's not a startup employee, working as a CTO, team lead and a programmer all in one).
If we're talking about non-techical managers, then there's always a technical person (let's say lead) who's responsible for completing the task and if something goes off-track, the manager will have a discussion with that very lead, not those who had eventually implemented all the quirks and culprits of the task. Then we expect that lead might again delegate the task with newly obtained iformation but it's not really relevant to our discussion. The point is we all became some kind of leads with a bunch of (really stupid and ignorant) juniors at our hands. And while they're able to complete some primitive out of context - generic tasks, when things get somewhat complicated they fail and each of their failures drags them even further in the wrong direction. At this point it is apparent that lead must get his hands dirty to complete task in an acceptable manner.
If you're a non-tech manager - find someone who knows the intricacies of the system, if you're the one behind the wheel, then take responsibility and know when to step in and assist your crew. And always verify the work they've done.
Great point! Fully agree
I used to solve some algorhythm problems to stay sharp. But for me, those problems were not enough interesting and I lost motivation. So I decided to take another method.
Now I deliberately think in my daily life. For example, I ask myself questions like 'What is the real issue here?', 'What kinds of ways are there to resolve this problem?', 'Is this code good enough?', etc.
I am not sure whether this method is as good enough as solving algorhythm problems are, but at least it's more motivating and interesting for me.
That is also a way. For me personally Leetcode is the fastest and easiest way to get my brain do the job. And still most of the companies use those problems on interviews, at least from my experience)
So true! There's no denying of importance of algorhythm problems, regardless of its purpose.
Important counterweight to the hype. The risk is real: outsource the thinking and you atrophy the thinking, the same way GPS quietly killed people's sense of direction. But I'd draw the line by task type rather than rejecting the tool. Offload the mechanical (boilerplate, lookups, formatting) and fiercely protect the parts that ARE the thinking: problem framing, tradeoffs, deciding what's even worth building. AI as a calculator is fine; AI as a substitute for knowing which equation to write is the trap. The danger isn't using AI, it's using it on the exact work that was building your judgment. I designed Moonshift around that split on purpose, agents take the grunt work so the human's attention goes to the decisions that actually compound skill. Where do you personally refuse to let AI in, to keep your edge sharp?
Personally I refuse letting AI make big decisions... For example, I am working on ideapick.app and I am making all of the sys design decisions while letting AI debug, write docs and refactor in some cases.
P.S design that AI provides just sucks
GPS is a good analogy as satnav routing often fails, especially for bicylcle traffic in a big city that constantly changes bike lanes according to political climate and construction works. If I trust Google maps blindly, I'm risking 15 minute detours that I can avoid where I know the streets and where I do have a sense of direction.
Completely agree. This push to offload our cognitive processes to a large pattern interpolator is fascinating, and terrifying, to watch. It was a large motivation of why I wrote my essay Agentic Coding is a Trap, which I feel this posts echoes a lot of similar sentiments.
Also, this push to act as if coding is something suddenly beneath us is really disturbing (and annoying, if I am being honest). Coding and the act of thinking through problems using code, is STILL a form of thinking and planning. Not all problem solving takes the form of "natural language". Code is not a dirty word and coding is not something to be avoided. It's actually some of the highest form of problem solving!
Really interesting essay. Actually I am noticing this trap in many aspects of my life. That's why some old things like Leetcode or writing articles on your own is good for you imp... Coding is one of the best way of problem solving
skeptical the LeetCode proxy works here. the cognitive work AI's actually replacing isn't algorithmic - it's judgment calls on ambiguous specs and connecting dots across context. LeetCode trains pattern matching on clean problems. that's not where the atrophy happens.
yes, I still do deliberate problem solving, but not the old grind 100 problems style.
It’s more like picking one problem, setting a timer, and forcing myself to sit with it before touching any tool. Even if I don’t finish, I try to reach a point where I can clearly explain my approach and where it breaks.
AI changed the workflow, but it didn’t replace the need for that first-pass thinking. If anything, it made it more important because it’s easy to skip it entirely now.
"if you can't sanity check the output you're not using a tool, you're depending on one" — that line should live above every AI assisted PR description.
the regression i noticed in myself: started struggling to size tickets. not write the code, size the problem. AI handles so much estimation adjacent thinking that you stop building intuition for it. realized this when we did sprint planning with no AI tooling and i was embarrassingly slow breaking down work i'd have called routine a year earlier.
for deliberate practice, leetcode stopped working after a while. what stuck was reading production post mortems and reasoning through them before reading the resolution. same cognitive work, directly applicable.
do you do anything besides leetcode, or has that been the consistent habit?
One thing I've noticed is that the more I use AI, the more important deliberate problem-solving practice feels.
Not for interviews, but to keep my reasoning sharp. AI is great until it gives a wrong or suboptimal answer, and then your ability to verify it becomes the real skill.
That's one reason I still do the occasional LeetCode/DSA problem. It's less about solving algorithms and more about exercising the "figure it out yourself" muscle that AI makes it easy to skip.
Exactly, I knew I am not alone
I fear the lack of creativity more, I thought with speed we can start having more optimized apps, better UX etc because developers and designers can now create stunning products.
But instead we got everything built with the same idea, concepts etc. Everything you've mentioned is right, now it's just about it works, works, merge, merge etc.
This should be the era where we can challenge everything we've been building, test new ideas rapidly.
AI should be making us write better codes slowly and not the opposite.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.