The PR had 47 changed files. Three new React components, two API routes, a context provider, and what appeared to be an entire form validation library. All generated in under two hours by an AI agent following a prompt I wrote while eating lunch.

"This is incredible," I thought. "This would have taken a week."

Six weeks later, I'm still untangling that PR. The components work — mostly. The forms validate — sort of. But nobody on my team can explain why the state is being lifted to a context provider when a simple prop would suffice. The AI didn't know our existing patterns, so it invented new ones. And now we have two patterns doing the same job, and zero documentation explaining which to use when.

This is the Ghost Implementation problem — code with all the bones (components, functions, imports) and none of the meat (justified logic that explains why those bones are arranged that way).

The Ghost Implementation Problem

Ghost Implementation is the natural byproduct of velocity-obsessed AI tooling. You get the output you asked for. The code compiles. Tests pass. But nobody can explain why it was written that way — not the AI (it doesn't have context), and not the developer (they approved it without fully understanding it).

The Qiita post that sparked this reckoning described something similar: a developer using AI agents to build five business screens in one day. The speed was real. The productivity gains were real. But the post was conspicuously quiet about what happened to that codebase in the weeks after delivery.

Here's what I observe in my own consulting work, consistently:

• Implementation Amnesia: Developers who can describe requirements fluently but mentally stall at "what does the actual function signature look like?" They reach for AI before their brain finishes the thought.
• Reviewer's Blindness: Engineers who click "Accept" on AI suggestions faster than they read them. Architectural decisions get made by a model that wasn't in the room when the product requirements changed.
• Debugging Reflex Atrophy: Running to AI before isolating variables. The 15-minute bug that used to be a learning opportunity becomes a 3-hour thread of AI-generated rabbit holes.

The pattern is predictable. AI tools are optimized for generating code fast. They succeed brilliantly at this objective. What they sacrifice is the developer's understanding — the mental model that lets you maintain, debug, and evolve the system when requirements change.

The Velocity Trap

There's a false equivalence being pushed in dev circles right now: "AI handles the boilerplate, I handle the architecture."

This sounds reasonable until you realize what it means in practice. "Boilerplate" isn't just repetitive code — it's the connective tissue that reveals system design. When AI generates your form validation, your API client, your error handling, you lose the opportunity to notice patterns that should inform your architecture.

I've watched three teams in the past year make the same architectural mistake twice: they didn't recognize they were building a god-object because AI was generating it incrementally, one "reasonable" class at a time. Nobody saw the whole picture until it was a 2,000-line monster that every new feature had to touch.

The Skeptical Take

Here's where I'll admit I was wrong about my own medicine.

I spent most of 2025 telling teams to be careful with AI tooling. And they largely ignored me — because the velocity gains were real. Teams shipping features in days that used to take weeks. Developers who were blocked on frontend work suddenly building complete UIs. The productivity numbers weren't fake.

The problem isn't that AI tools don't work. They work. The problem is that the success metric is incomplete.

We're measuring "time to first working version" but not "time to maintainable, evolvable system." These are different things. And the gap between them is where Ghost Implementations live.

To be fair: I understand the pressure. Deadlines don't care about technical debt. Product managers don't ask about your mental model of the state management layer. The incentive to ship is immediate; the cost of architectural decay is deferred. I'd take the same shortcut if my quarterly goals were measured in shipped features.

But the debt is real, and it compounds.

The Anti-Atrophy Survival Guide

This isn't about rejecting AI tooling. It's about maintaining the baseline competency that makes you dangerous enough to use AI effectively. You can't evaluate AI output if you've forgotten what good output looks like.

1. One weekly "explain it twice" session: Write out the explanation for a concept you use daily, then read it back. If you can't articulate why a tool works the way it does without referencing its docs, that's your gap.

2. Maintain one "dumb" side project: Something you code without AI, where inefficiency is the point. The goal is to keep your hands remembering what your brain is forgetting.

3. Architecture decision log: For every non-trivial decision, write three sentences: what you chose, what you rejected, and why the winner won. Future you will thank present you when the AI can't explain why the system was built this way.

4. Track your "AI dependency score": Rate each coding session: 1=fully autonomous, 5=AI wrote everything. If your 30-day average drifts above 3.5, you're losing ground.

The AI agent that built five screens in one day? That's not the end of the story. That's the beginning of the maintenance cycle. The question is whether you'll be the developer who understands the system — or the one who just approves whatever AI suggests next.

Go look at your most recent AI-generated PR. Try to explain, out loud, why the state is arranged the way it is. If you can't — that's your Ghost Implementation.

---

What's your take?

I'd love to hear how this plays out in your specific context. Drop a comment below — I respond to every one.

Has your team noticed developers becoming less capable of independent debugging without AI? What's your experience been?

---

Based on "AIエージェントで業務開発はここまで来た｜1日で5画面作った話" on Qiita (miyakiyo) — a Japanese developer's firsthand account of building 5 business screens in one day using AI agents.

Discussion: Has your team noticed developers becoming less capable of independent debugging without AI? What's your experience been?