The Consultation Trap

There's a version of this that looks like productivity.

You're shipping more than ever. The velocity metrics are up. Features that used to take days are merged in hours. Your commit history looks like a productive quarter — except you're not sure how much of it is actually yours.

The thing nobody warns you about is how exhausting it is to be the person at the end of the AI pipeline. Not writing, not designing — just: receiving, evaluating, approving, correcting. The work of reception rather than origin. And the cruelest part is that reception costs nearly as much cognitively as origination, but it doesn't feel like work. It feels like you're being efficient.

What the Trap Actually Is

The consultation trap has a precise structure: AI generates, you evaluate. The ratio tilts until you're spending more time in the evaluate role than the originate role. Your job title might say "software engineer" but functionally it's "AI output controller."

This is distinct from normal code review. In traditional code review, you're evaluating work by a peer — someone who made specific choices for specific reasons. You can ask them to explain their reasoning. You can push back on the design. You can suggest alternatives and have a conversation about tradeoffs. The review is collaborative, even when critical.

With AI-generated code, there's no one to ask. The AI made no choice — it generated a plausible next token. The output has no provenance. There's no reasoning you can interrogate, no author whose thinking you can understand. Every time you receive AI output, you're doing deconstruction: taking a finished artifact and reconstructing what problem it solves, whether it's the right approach, and what edge cases it handles. You have to do the generative work anyway — you're just doing it in reverse, and without the solution's initial momentum.

This is why people report being more tired after a day of "reviewing AI code" than after a day of writing code from scratch. Reverse-engineering a correct solution is harder than generating one. The AI gives you the answer and you have to reconstruct whether the question was right.

The Three Stages of Entrapment

Stage 1: The Helpful Tab. AI starts as a useful second opinion. You write the core, let AI handle the boilerplate. You feel like you're working with a senior who's read the docs. This stage feels good — it's genuinely additive.

Stage 2: The First Draft Reversal. At some point, the direction flips. You start waiting for AI to generate the first version of something, and your job becomes shaping it. Not because you can't write the first version — but because the path of least resistance has shifted. Prompt → AI output → review is now faster than idea → implementation. The efficiency is real. The authorship cost is hidden.

Stage 3: The Consultation Rig. Now it's structural. You no longer write first drafts of anything that can be AI-generated. Your role is permanently downstream of the tool. You are, in the language of the industry, "the human in the loop." But the loop isn't checking the AI — the AI is generating and you are the loop. The work that built your expertise — origination, trial-and-error, the slow construction of mental models through failure — has quietly been removed from your workflow.

The Hidden Cost Nobody Counts

There are metrics being tracked: velocity, PRs merged, features shipped. These look great. But there's a column that's not being counted: generative capacity.

Generative capacity is the ability to look at a blank file and produce a solution from scratch — not a good-enough solution, not a plausible token sequence, but a considered response to a specific problem with an understood set of tradeoffs. This is different from recognizing a correct solution. It's the difference between being able to evaluate a proof and being able to construct one.

The mathematician GH Hardy observed that mathematical intuition is the capacity to see the way forward in a blank landscape — not the capacity to verify someone else's path. The consultation trap erodes exactly this faculty, and it does so invisibly. Your ability to verify AI output stays intact. Your ability to originate from scratch quietly atrophies.

Senior engineers who've been in the trap for 12-18 months report a specific experience: when they try to solve something without AI, the blank file is somehow more blank than it used to be. Not because they've forgotten the language — they can still read and evaluate perfectly. But the "getting to first word" step has become harder. The muscle of origination has gone soft from disuse.

Why the Industry Doesn't See This as a Problem

The consultation trap is economically rational from a team perspective: the output looks fine, the velocity is high, the code ships. The hidden cost — the slow erosion of generative capacity — isn't visible in any metric the business tracks. By the time it's visible, it's already significant.

This is the same pattern that played out withStack Overflow. When Stack Overflow became the first-resort for answers, there were concerns about deskilling — that engineers would become dependent on pre-written solutions and lose the ability to derive answers independently. The concerns were valid. But the deskilling was invisible in every metric that organizations tracked. Code shipped, velocity held, nothing looked broken.

The consultation trap is Stack Overflow's deskilling problem, but faster and deeper. The AI doesn't just answer questions — it generates entire architectures, implementations, test suites. The dependency forms faster and the atrophy is more fundamental.

The Exhaustion Is Real

People in the consultation trap describe a specific flavor of tiredness that doesn't match the output. They shipped six features today. They reviewed and approved more AI-generated code than any previous era engineer would have written in a week. By every visible measure, it was a productive day.

But they feel hollow. They can't point to anything they actually made. They have the artifact — the merged PR, the shipped feature — but not the felt experience of having made it. And the tiredness isn't physical. It's something closer to grief: the sense that you've been through the motions of work without the substance of it.

This is not burnout. Burnout is exhaustion from prolonged high demand. The consultation trap exhaustion is different: it's the tiredness of doing work that looks like work but doesn't feel like it. It's the fatigue of constant reception without origination — always receiving, evaluating, approving, never starting.

How to Know If You're in It

Three diagnostic questions. Answer honestly.

1. How does your commit history feel when you look back at it?
If you feel a sense of ownership and recognition — "I built that, I know why it looks the way it does" — you're probably okay. If you feel mild dissociation, like you're reading someone else's work, you may be deep in the trap.

2. When you solve something small without AI, how does it feel?
If it feels like a relief and a reminder of why you became an engineer, pay attention. That's a signal that the generative work has become rare enough to be notable. If solving something without AI feels pointlessly slow and irrelevant, the trap is advanced.

3. Can you explain your system's design from scratch, without AI, to a new team member?
Not the high-level architecture — the actual decision process. Why this pattern over that one. What tradeoffs were weighed. If you can do this confidently, your generative capacity is intact. If you can explain the what but not the why — if you'd need to go back and reconstruct your reasoning from the code — your generative thinking has been outsourced.

The Way Out Is Deliberate — Not Just Using Less AI

The obvious response is "just use AI less." This is right in principle and hard in practice, because the efficiency is real and the organizational pressure is real. The goal isn't to use less AI — it's to use AI in a way that preserves your generative capacity.

Principle 1: Keep origination AI-free. Designate specific problems as AI-free origination. Not as a moral stance, but as maintenance. The problems you solve from scratch — even if the solution is messy, even if it takes longer — are the reps that keep your generative capacity alive. Pick one class of problems you always solve yourself: system design, complex algorithm design, tricky debugging, anything where the thinking IS the work.

Principle 2: Use AI to implement your design, not to generate it. This is the crucial asymmetry: when you use AI to implement a design you already have, you're still in the origination role. The AI is a productivity multiplier on thinking you've already done. When you use AI to generate the design — even if you then review and revise — you've handed over the generative step. The work of design is where your mental models get built and refined. If that's happening inside the AI, it bypasses you.

Principle 3: Maintain a ratio. Some teams have adopted a rough rule: for every three AI-assisted tasks, complete one from scratch. Not as a restriction, but as maintenance. The math works out: if AI gives you a 3x productivity boost on the tasks where you use it, one full-effort task per four total still nets you roughly 2x overall productivity — but with your generative capacity preserved.

Principle 4: Review with reconstruction, not just validation. When you do review AI output, don't just validate it — decompose it. For each chunk of output, ask: what problem is this solving, what would a wrong answer look like, what would an alternative approach look like. Make yourself do the generative work that the AI skipped. It's slower, but it keeps the muscle active.

What This Means for Teams

If you're managing engineers, the consultation trap has team-level implications. Velocity metrics will look good while generative capacity erodes. By the time the atrophy is visible — someone can't solve a problem that "should" be in their range — it's already advanced.

Watch for these signals at the team level: engineers who can review and critique AI-generated code fluently but hesitate when asked to architect something from scratch. Engineers whose PRs contain increasingly less of their own voice — solutions that are technically correct but stylistically generic, with no fingerprint of the specific engineer who reviewed them.

The structural fix: make sure some work is always AI-free by policy, not by individual discipline. The teams that navigate this best are the ones where "we do X without AI" is a team norm, not a personal resolution. This isn't about restricting AI — it's about preserving the conditions under which expertise develops.

There is no sustainable version of AI-assisted engineering that doesn't include deliberate origination. The teams that figure this out will have engineers who stay sharp. The teams that don't will have high-velocity output and a slowly emptying reserve of the thing that made their engineers valuable in the first place.

The Question to Ask Yourself This Week

Before the week starts, before the standup, before the next PR review: open a file and write down the architecture of something you shipped in the last month — not what it does, but why it looks the way it does. What decisions are embedded in the structure. What you considered and rejected. The shape of your thinking, not just the shape of the code.

If that file is easy to write and feels grounded in your actual thinking — you're probably okay. If the words come out vague, or you find yourself reconstructing reasoning from the code rather than recalling it — that's the consultation trap. It's not a failure. It's a signal. And signals are useful.