The Setup
"I caught myself unable to remember the last time I'd actually debugged something from scratch. The agents just... execute it. And it hit me: I'm letting the part of me that knows how to think through the problem go quiet."
— A note to myself, mid-sprint with Claude Code and Codex
The Paradox We Don't Talk About
Look, I'm all in on AI. I build RAG systems, orchestrate multi-agent workflows, and ship features faster than ever. But here's the uncomfortable truth nobody wants to say out loud:
The same tools making us more productive are quietly eroding the expertise that made us valuable in the first place.
It's not malicious. It's just... efficient. Why spend 20 minutes debugging when an agent resolves it in seconds? Why memorize syntax when the agent writes the boilerplate? Why think deeply when a summary will do?
But efficiency isn't the same as understanding. And understanding is what separates someone doing real engineering from someone just dispatching agents with imposter syndrome. We're past "prompt engineering" now: today the agents execute the whole job. The question changed. The trap didn't.
But here's the nuance almost nobody makes, and I want it on the record: the trap isn't using AI. The trap is delegating the thinking. Those aren't the same thing. You can live glued to the agents all day and come out sharper, or you can fire off two prompts and hand over your judgment in the process. The difference isn't how much AI you use—it's whether you're steering it to think better or to stop thinking.
Because AI does something genuinely beautiful: it lowers the barrier to abstraction. A lot of what we learn, we learn abstractly, and each of us lands the concepts differently. The greats—Linus Torvalds, the people who built Redis, Postgres, Node.js, the CEOs—operate from levels of abstraction and cognitive capacity that seemed reserved for a few. Today someone who only knows how to speak English builds a whole application, something that wasn't even remotely on the table before. It's a brutal reverse engineering of reality, and it's beautiful precisely for that: AI helps us understand that we can learn differently, and it helps us learn and prepare better itself. It's up to each person to decide to do it.
So no—this isn't about delegating the thinking. Not at all. It's about steering AI to help you think in a different way. That's the good use. Everything that follows is how I tell one from the other in practice.
The Patterns I See Repeating
Analysis: Trusting the Summary
It's easy to fall into this: AI models evaluate financials and flag risk with impressive accuracy, so you stop looking at the raw data. Here's the catch:
The hypothesis that worries me is that anyone who trains primarily on AI-generated summaries never develops the intuitive read for when the data doesn't tell the full story—and that read is exactly what saves you.
The AI is right 95% of the time. The risk lives in the 5% that matters—the edge cases where pattern recognition built from years of firsthand work is irreplaceable.
Software Engineering: The Agent Crutch
The pattern: you ship a React component in 10 minutes that would've taken an hour in 2020. Impressive, right? The agent executed the whole thing—not just autocomplete.
But if you're asked to explain why useCallback instead of useMemo, you can't. The agent wrote it. It worked. That was enough.
Until production performance tanks, and there are no mental models to debug why. Today's speed is tomorrow's debt.
Strategy: Frameworks vs. Intuition
AI-powered strategy tools are genuinely useful. They synthesize market data, map competitive landscapes, suggest positioning moves in seconds.
But building something gives you what AI can't replicate: strategic intuition. That read on a room, a market, a user—when the numbers look fine but something feels structurally wrong.
That sense comes from shipping things, watching them fail, and understanding why. If you always defer to the AI, you never build it.
Why This Actually Matters
This isn't Luddite fear-mongering. I'm not saying "don't use AI tools." I'm saying we need to be intentional about what we delegate and what we don't.
Because here's the thing about expertise: it's built in the struggle.
When you spend 3 hours debugging a gnarly async race condition, you're not just fixing a bug. You're building neural pathways. Pattern recognition. Intuition.
When you read a paper slowly, wrestling with the concepts instead of getting an AI summary, you're developing deep understanding that lets you apply those ideas in novel contexts.
When you write from scratch instead of editing AI-generated text, you're honing your voice, your thinking, your ability to articulate complex ideas clearly.
And both things are true at once: delegating your judgment makes you duller—no one gets to soften that—but steering AI well amplifies your thinking instead of replacing it. These aren't ideas at war; they're two faces of the same decision. Intention is what decides which side you land on.
The Framework: What to Delegate, What to Defend
Not all cognitive tasks are created equal. Some should absolutely be offloaded to AI. Others? You give those up at your own risk.
✓ Offload This (You'll Be Fine)
- Boilerplate code — CRUD operations, config files, standard patterns
- Syntax lookup — "How do I do X in language Y?"
- Initial research — AI can gather sources; you evaluate them
- First drafts — Let AI generate, then you refine with expertise
- Repetitive tasks — Data formatting, renaming variables, etc.
✗ Defend This (Your Expertise Depends on It)
- Core debugging — Especially edge cases and novel problems
- Architectural decisions — AI can suggest, but you need to deeply understand trade-offs
- Critical thinking — Evaluating whether something is correct, not just plausible
- Deep learning — Reading papers, understanding fundamentals, building intuition
- Original creative work — Your unique insights, connections, perspectives
Practical Strategies (That Actually Work)
1. Deliberate Practice Zones
Set aside time each week where you intentionally don't use AI assistants. Debug without an agent. Write without a model. Think without summaries.
It'll feel slower. That's the point. You're building the muscles that atrophy when AI does the heavy lifting.
2. The "Explain It Back" Rule
If AI writes code or explains a concept, force yourself to explain it back in your own words. If you can't, you don't understand it. Go deeper.
I literally keep a notion doc where I explain every AI-generated solution. Slows me down short-term. Makes me way more capable long-term.
3. Progressive AI Dependency
Start problems without AI. When you get stuck, use it strategically, not reflexively.
Example: Debugging a Next.js rendering issue? First 30 minutes, no AI. Then use it to validate your hypothesis, not replace your thinking.
4. Build Your Own Before Using Pre-Built
Want to use LangChain? Cool. But first, build a basic RAG pipeline from scratch. Understand the primitives. Then use the abstraction.
You'll know when the abstraction is hiding important complexity. And when it breaks, you'll know how to fix it.
My Personal Rules (Feel Free to Steal)
Morning Deep Work = No AI
First 2 hours of my day, the agents are off. This is when I tackle hard problems that require deep thinking.
AI Can Draft, I Must Understand
If I can't explain the generated code to a junior dev, I don't ship it. Period.
Read Papers, Don't Just Summarize
For core topics (RAG, agent design, AI systems), I read the actual papers. AI summaries for tangential stuff only.
Weekly "From Scratch" Project
Every week, I build something small entirely without AI assistance. Keeps the fundamentals sharp.
Teach to Learn
I write these blog posts without AI drafts. Helps me crystallize my own thinking.
The Uncomfortable Question
If you removed all AI assistance tomorrow, how much would your productivity drop?
If the answer is "catastrophically," you might want to check in with yourself. Because the goal isn't AI independence—it's AI augmentation, not AI dependency.
Here's the difference:
- Augmentation: "AI helps me ship 3x faster while maintaining deep understanding."
- Dependency: "I literally don't know how to solve this without asking an agent."
One makes you powerful. The other makes you fragile.
The Meta-Skill: Knowing When to Struggle
In the era of agents that execute the whole job, the skill that matters isn't orchestrating the perfect agent. It's knowing which struggles make you stronger.
Not all struggle is productive. Spending 4 hours formatting JSON? Waste of time. Let the agent handle it.
But struggling to understand why your retrieval system is pulling irrelevant chunks? That's the struggle that builds expertise.
The founders, engineers, researchers who thrive in the next decade won't be the ones who avoid AI. They'll be the ones who use it strategically while defending the cognitive processes that make them irreplaceable.
This is how I decide what to delegate. I'm building RAG and orchestrating agents every day; every task I hand off is a bet on which muscle I want to keep and which one I'm fine losing. The framework above isn't theory—it's the rule I actually use to split my own work between what the agent executes and what I keep for myself.
The Bottom Line
AI is a cognitive prosthetic. Like any prosthetic, it can restore capability—or it can create new dependencies.
Use it to amplify your strengths. Don't let it replace the hard-won expertise that makes you valuable.
Be faster, be more productive. But don't become helpless.
The paradox isn't that AI makes us more productive while eroding skills. The paradox is that the solution is counterintuitive: to get the most value from AI, you need to know when to not use it on autopilot.
But the core of it is simpler and harder at the same time—it's about steering AI to think differently, not to stop thinking. I keep writing about how I make these calls while I build—stick around.