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 practi...
For further actions, you may consider blocking this person and/or reporting abuse
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.
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.
At work, I try to do as many code reviews as possible. Git fetch, go through all files involved in the code change and if possible, compile and run the code. That one way to keep sane.
I agree that solving leet code challenges is probably a good way to exercise ones problem solving capability, but you can also do the opposite and construct a leet code challenge, create a solution (maybe not in your first attempt) and then let an LLM solve it and 'chat' about the output.
I understand that it might be difficult initially to pose such problems but one could start by combining problem sets from different discrete mathematics subjects and chain them.
We have gyms because we built machines to do all the heavy lifting for us. It is a fair prediction that AI will eventually make "gyms for the mind" mainstream.
This is a very real concern. AI can make developers faster, but we still need to practice problem-solving so we can understand, verify, and challenge what the tool gives us.