I Caught Myself Not Thinking

I was building a RAG service in Python—a language I don't reach for daily—and instead of learning the ecosystem, I asked Claude to build it. Not "help me understand FastAPI's dependency injection" or "explain how ChromaDB handles multilingual embeddings." I asked it to scaffold the whole thing. Then I asked it to fix the errors. Then I asked it to restructure the modules. I burned through tokens and hours, generating code I couldn't explain in a code review if my life depended on it.

Eventually I deleted everything and started over. This time I read the docs. I understood why BM25 and semantic search complement each other. I learned what cross-encoder reranking actually does. The rebuild was slower, but it was mine. I could debug it. I could extend it. I could argue for or against every architectural choice in that service.

That was the moment I realized I'd stopped thinking and started delegating. Not because the tools aren't powerful—they are. But because they're too easy. When Claude Code can generate a complete FastAPI service with authentication, vector search, and async workers in 30 seconds, the path of least resistance isn't thinking. It's prompting.

The Problem Isn't AI. It's Default Delegation.

I'm not against AI coding tools. I use Claude Code and Codex regularly. Autocomplete is a productivity multiplier I wouldn't give up. The issue is specific to what I'd call wholesale reasoning delegation—asking a frontier model to do your thinking for you, not just your typing.

Here's what that looks like in practice:

Using Opus for everything. Sonnet or Haiku can write a React component, generate a migration, or summarize a logfile. But we reach for Opus because it's there and the marginal cost feels zero. It isn't. Every time you ask a frontier model to reason through something you could reason through yourself, you're spending two currencies: tokens and cognitive engagement.

Not writing good prompts. A well-crafted prompt for a weaker model is itself an act of clear thinking. You have to decompose the problem, specify constraints, and articulate what you want. That's essentially design work. When you just dump a vague request into Opus and let it figure it out, you skip that step entirely—and you lose the clarity that comes with it.

Shipping code you don't understand. This is the real danger. Not that AI writes bad code—it often writes fine code. But code you didn't think through is code you can't debug under pressure at 2am, can't adapt when requirements shift, and can't explain to a teammate who asks "why this way?"

The Dependency Spectrum

Skill decay doesn't hit everyone the same way. It operates on a spectrum.

Junior developers lose faster because they never built the foundation. If your first experience with debugging is asking an AI agent to find the bug, you never develop the systematic reasoning that makes senior engineers effective. You don't build the mental model of how systems fail. You become dependent on the tool not for speed, but for capability. Remove the tool and you're not just slower—you're stuck.

Senior developers lose slower but in subtler ways. Architectural intuition degrades when you stop designing systems and start generating them. Debugging instinct weakens when you stop forming hypotheses and start asking AI to find root causes. You don't lose the ability entirely—you have years of experience to fall back on—but the edges dull. The five-second "I bet it's a connection pool exhaustion issue" gut feeling comes less frequently when you haven't exercised it.

I've been building production systems for over seven years. I've optimized JVM performance down to 10ms p90 latency handling 3M+ daily requests. I've built multi-chain infrastructure handling $1B+ in transaction volume. And yet I caught myself not thinking. If it happened to me, it's happening to developers at every level.

The Subsidy Illusion

Here's the part nobody talks about enough: AI vendors are burning VC money to build dependency, and when unit economics catch up, the rug gets pulled.

Frontier model inference is expensive. Opus-level reasoning costs orders of magnitude more than what most users pay. The $20/month plans, the generous rate limits, the free tiers—these aren't sustainable prices. They're customer acquisition costs. The business model is: get developers hooked on thinking through AI, then raise prices when switching costs (in the form of atrophied skills) are high enough.

We're already seeing it. Anthropic removed Claude Code from their $20 plan. Usage caps tighten. Rate limits appear. This is the trajectory.

When prices normalize to reflect actual inference costs, developers who've outsourced their reasoning to AI agents become expensive liabilities. Not because they're bad developers, but because they've lost the ability to work at the speed their salary implies without a $200/month AI subscription that used to cost $20.

The companies that over-indexed on AI-first engineering cultures will face a choice: absorb significantly higher tooling costs, or ask their teams to do something they haven't practiced in months—think through problems without an AI agent.

The Shifting Definition of a Good Developer

There's a subtler shift happening too. The metrics of what makes a strong developer are changing—and not entirely in a bad way, but in a way that demands awareness.

Historically, the signal was: writes good code, fast. Can you implement the feature? Is it clean? Does it work? How quickly?

Increasingly, the signal is shifting toward: reads code fast and spots deviations from expectations. When AI generates 80% of your codebase, your value isn't in the writing—it's in the reviewing. Can you look at a 400-line diff and instantly see the off-by-one error, the missing null check, the architectural inconsistency? Can you distinguish between code that works and code that's right?

This is a real skill. It's also a skill that's harder to develop if you've never written the kind of code you're reviewing. The best code reviewers are people who've made (and learned from) the mistakes they're now catching. If you've never wrestled with a tricky concurrency bug because Claude always handled your goroutine synchronization, you won't spot the race condition in someone else's AI-generated code.

A Framework for Intentional AI Use

Not all AI usage is equal. After catching myself and rebuilding my approach, I started categorizing tasks into three tiers. This isn't rigid—it's a mental model for staying intentional.

Tier 1: Think First, AI Second

When: Architecture decisions, debugging root causes, understanding tradeoffs, evaluating technology choices.

How: Reason through the problem yourself first. Form a hypothesis. Sketch the architecture. Identify the constraints. Then use AI to validate your thinking, catch blind spots, or explore alternatives you hadn't considered.

Why: This is where cognitive depth matters. If you delegate architecture to AI, you don't understand your own system. You can't make informed tradeoffs later because you never understood the tradeoffs that were made. You can't debug production issues quickly because the mental model isn't yours.

In my case, deciding between semantic search, BM25, and a hybrid retrieval strategy for the RAG service—this was Tier 1. The first time around, I delegated it. The second time, I read the papers, understood the strengths of each approach for my specific use case (multilingual technical documents with part numbers and procedures), and built something I could actually defend.

Tier 2: AI Accelerates, You Validate

When: Scaffolding, boilerplate, well-understood patterns, implementing a design you've already thought through.

How: You know what you want. Use AI to generate the initial structure faster than typing it yourself. But you review every line. You understand every line. If you can't explain what the generated code does and why, you're not in Tier 2—you've slipped into delegation.

Why: This is the sweet spot for productivity. You're using AI as a force multiplier for execution, not for thinking. The thinking already happened. The code is just the implementation detail.

When I build Go services, this is most of my AI usage. I know the patterns. I know the error handling conventions. I know how I want the HTTP handlers structured. AI just gets me there faster.

Tier 3: AI Owns, You Review

When: Tests, documentation, refactors, rote implementations, anything where the requirements are unambiguous and the output is verifiable.

How: Let AI handle it with minimal supervision. Write a clear spec, let it generate, run the tests, review briefly. If the tests pass and the output matches the spec, ship it.

Why: Not everything needs your full cognitive engagement. Writing boilerplate tests for a CRUD endpoint doesn't make you a better engineer. Generating JSDoc comments doesn't sharpen your architectural intuition. Be honest about what needs your brain and what doesn't—and allocate accordingly.

The Operating Principle

The framework boils down to one question: Am I using this tool because it's faster, or because I don't want to think?

If the answer is speed, you're fine. That's what tools are for.

If the answer is avoidance, you're eroding a skill. And unlike most skills, cognitive atrophy is silent. You don't notice it until you need it and it's not there.

The developers who will thrive in the next decade aren't the ones who use AI the most or the ones who refuse to use it at all. They're the ones who stay intentional about which parts of their craft they automate and which parts they protect.

Think first. Use the tool. Don't let the tool do your thinking for you.