AI should challenge your thinking, not replace it
The biggest trap of the AI era
When AI coding assistants first appeared in June 2021 (i.e. GitHub Copilot), it felt like autocomplete on steroids.
It generated a few lines of code, suggested implementations, and occasionally saved us from writing repetitive boilerplate. We still made the decisions. AI was simply another development tool.
Fast forward a few years.
Today's AI agents can read entire repositories, analyze requirements, generate technical designs, create implementation plans, write code, review pull requests and even explain architectural decisions. And with that capability, a trap becomes easy to fall into.
Instead of asking AI to help us write software, we start asking it to build software for us.
I believe this is currently the biggest trap in AI-assisted software development. Somewhere along the way, we stop delegating execution. We start delegating thinking.
This isn't a new problem
Eleven years ago, when I started my career, one of my mentors gave me advice that I still remember today.
"Don't start writing code immediately. Take a piece of paper, think, and draw the solution first."
The exercise was simple. Understand the problem. Sketch the solution. Think about edge cases. Challenge your own assumptions. Only then start coding.
At the time it felt unnecessarily slow. I wanted to start coding immediately. Looking back, the goal was never the paper. The goal was forcing myself to pause and think before committing to a solution.
Today, we no longer need another senior engineer sitting next to us. Ironically, AI can become that engineer - but only if we use it correctly.
AI should challenge your thinking, not replace it
Many developers still use AI like this: Implement a complaint form based on this Jira ticket.
The agent reads the ticket, generates a plan, writes the code, creates tests. Done. The feature might even work.
The problem is that we never stopped to ask whether we were solving the right problem.
The first prompt shouldn't be "Implement this feature." It should be "Help me understand this feature."
That's a completely different conversation. Instead of writing code immediately, AI starts asking questions - often from perspectives we wouldn't have considered ourselves.
Ask first, build later
Take that complaint form for an e-commerce platform. Instead of jumping straight to implementation, start with an "Interview Me" workflow. The AI begins asking questions:
- Who is allowed to submit a complaint?
- Can guests create complaints?
- Can one order have multiple complaints?
- Are attachments required?
- What's the maximum attachment size?
- Can customers edit complaints later?
- What happens after submission?
- Should notifications be sent?
- What if the product was purchased over a year ago?
- What if the customer submits the same complaint twice?
Notice something interesting. None of these questions required AI to write a single line of code. Its job wasn't implementation - its job was forcing you to think.
That alone dramatically reduces the probability of implementing the wrong solution.
Better thinking, not better autocomplete
Around the same time, I discovered Addy Osmani's Agent Skills. Something clicked.
Instead of asking AI to generate better code, many of those skills encourage something much more valuable: better thinking.
Interview Me doesn't solve your problem. It challenges your understanding.
Idea Refine doesn't generate architecture. It forces you to clarify what you're actually trying to build.
That shift completely changed how I started using AI. The skills stopped being prompts I pasted into a chat. They became thinking partners - structured ways to pause, question, and refine before writing a single line of code.
The hidden cost of skipping the thinking phase
Many teams are adopting Spec-Driven Development. I think that's a fantastic direction. Unfortunately, I also see a recurring anti-pattern. The workflow often looks like this:
- Write a two-sentence prompt.
- Let AI generate an entire specification.
- Quickly look through it.
- Click "Approve".
- Generate technical design.
- Click "Approve".
- Generate implementation plan.
- Click "Approve".
- Start implementation.
Nothing changed. We simply moved blind trust one phase earlier.
Instead of accepting generated code without thinking, we now accept generated requirements without thinking. The implementation becomes almost deterministic: if the requirements are wrong, the design will be wrong; if the design is wrong, the implementation will be wrong.
The mistake wasn't introduced during coding. It happened during thinking - or rather, during the lack of thinking.
The Thinking First Workflow
This is the workflow I've gradually adopted while working with AI. Not because AI requires it - because good engineering always required it. AI simply made the consequences of skipping these steps much more expensive.
Phase 1 - Understand
Don't ask AI to build. Ask AI to challenge your understanding.
This is where Interview Me lives. Your objective isn't to get answers. Your objective is to discover the questions you forgot to ask.
Phase 2 - Refine
Once the context becomes clearer, refine the idea. Challenge assumptions. Explore alternatives. Identify constraints.
This is Idea Refine's territory. Not "generate options for me" - force yourself to articulate what you're actually trying to achieve.
Phase 3 - Design
Only now should you move into Spec-Driven Development. From this point through execution, I treat it as the main skill - covering design, planning, and implementation as connected checkpoints, not as a single "generate a spec" step.
Generate requirements. Review them carefully. Challenge them. Rewrite them. Delete unnecessary parts.
Specifications aren't documentation. They're thinking tools.
Phase 4 - Plan
Split the implementation. Reduce scope. Identify validation points. Don't ask AI to build an entire feature if you can validate the first 20% tomorrow.
Within Spec-Driven Development, this is where planning lives. When the work needs a sharper cut, planning-and-task-breakdown helps you decide what to prove first.
Smaller iterations produce better decisions.
Phase 5 - Execute
Only now… delegate implementation.
This is where AI shines. Generate code. Write tests. Refactor. Review. Optimize. Spec-Driven Development still guides the loop, and incremental-implementation keeps each slice small enough to review with judgment intact.
Execution is where AI creates the biggest productivity gains. Not before.
Spec-Driven Development is about thinking checkpoints
That's why I don't believe Spec-Driven Development is about generating specifications. I think it's about introducing clear thinking checkpoints.
Going back to our complaint form. Before writing a single screen, I'd want to know whether complaints expire, whether customers can reopen them, how attachments are stored. Those aren't implementation details - they're requirements questions.
Every stage should force a different kind of thinking.Requirements challenge whether we're solving the right problem.Design challenges whether we're solving it the right way.Planning challenges whether we're solving it in the right order.
If every checkpoint survives that scrutiny, implementation becomes almost mechanical.
The warning signs
How do you know you've started delegating thinking instead of execution? I've noticed a few recurring patterns.
- Your first prompt is "Implement this."
- You approve AI-generated specifications without editing them.
- You keep discovering too many missing requirements during implementation - more than the usual edge cases you couldn't have predicted.
- You ask AI for a solution before you've fully understood the problem.
- Your implementation keeps growing because AI continuously "improves" the architecture.
If any of these feels familiar, you're probably not delegating execution anymore. You're delegating engineering decisions.
AI is the best mentor many developers will ever have
This is probably my favourite realization.
People often say AI will replace developers. I think the opposite. For juniors, AI can become an additional mentor - not because it knows everything, but because it can patiently challenge their thinking for as long as they need. For more experienced engineers, it can be a strong support across many parts of the work: exploring options, spotting gaps, and reviewing decisions.
Eleven years ago my mentor asked me to take a piece of paper before writing code. Today I ask AI to challenge my solution before writing code.
The tool changed. The engineering principle didn't.
Final thoughts
The core principles of solid engineering haven't changed - only the tools have.
The best developers won't be the ones who generate code the fastest. They'll be the ones who remain curious the longest - who ask better questions, challenge assumptions, and think before they execute.
Because in the age of AI, execution is becoming cheaper every month. Thinking is becoming more valuable than ever.
Sources
- agent-skills - Addy Osmani (Interview Me, Idea Refine, Spec-Driven Development, and more)
- Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl - Birgitta Böckeler (martinFowler.com)
- Spec Kit - GitHub's toolkit for Spec-Driven Development
Comments