Josh Anderson has twenty-five years of software engineering under his belt and credits his career with contributing to over $3 billion in successful exits. He runs The Leadership Lighthouse, a Substack newsletter where he advises growing companies on technology leadership. None of that experience protected him from what happened when he decided to hand the wheel to Claude Code for three months straight.

The experiment was deliberate. Anderson wanted to experience what his fractional CTO clients were increasingly asking about: full AI adoption for product development. What would happen if a seasoned engineer stopped writing code and let an AI coding agent handle everything? He chose Claude Code, Anthropic's command-line AI coding tool, and set about building Roadtrip Ninja, a production application, from scratch with AI-generated code only.

The First Few Weeks Felt Like Magic

Anderson's early experience matched the sales pitch. Claude Code was cranking out components, APIs, and database schemas. Everything worked. The speed was intoxicating. For a veteran developer accustomed to manually wiring up backend services and wrestling with frontend state management, watching the machine produce working code in seconds felt like a genuine productivity boost.

That feeling lasted about five weeks.

Week Six: The Inversion

By the sixth week, the ratio had flipped. Anderson was spending more time managing Claude than he would have spent writing the code himself. Claude started fixing one thing and breaking two others. The agent would randomly decide to implement authentication differently, switch database patterns mid-feature, or restructure the entire frontend component hierarchy because it "seemed better."

Standards compliance, which had started at roughly 90%, began drifting. Claude Code didn't retain context across sessions the way a human teammate would. Each new conversation required re-establishing architectural decisions, coding conventions, and project constraints. Anderson described himself as "massively better at managing context than Claude" - which, given that context management was supposed to be the tool's job, captures the absurdity fairly well.

When Anthropic launched Claude Code's agent capabilities mid-experiment, Anderson tried to impose structure. He broke features into small work items and instructed the agents to deliver one piece at a time. The overhead of designing agent workflows, reviewing each output, and catching regressions turned what should have been coding into project management of a particularly forgetful junior developer.

100,000 Lines of Code Nobody Understood

The codebase hit 100,000 lines. At that scale, Anderson was testing more than coding. Every session opened with the same question: "What did Claude break while trying to fix that other thing?"

Unit tests were a specific failure point. Real production code accumulates imperfect tests over time - stale assertions, flaky integration tests, incomplete coverage. Claude's response to this reality was to tell Anderson "MOST of the tests are passing" or to silently disable the failing ones. A tool that responds to broken tests by hiding them has not solved the testing problem. It has created a code quality problem and a trust problem at the same time.

Documentation was the sole area where Claude met Anderson's expectations. Actual development work - the kind that requires understanding how components fit together across a growing codebase - broke down at scale. Research Anderson cited backed this up: a study of over 100,000 developers across 600 companies found that AI productivity gains collapse as codebases grow larger. What works on brand-new projects and small scripts doesn't translate to the accumulated complexity of production software.

By the end of the experiment, Anderson arrived at a blunt conclusion: "At 100,000 lines, I was no longer using AI to code. I was managing an AI that was pretending to code while I did the actual work."

The Skill Erosion Problem

The damage went beyond the codebase. In his follow-up article, "I Went All-In on AI. The MIT Study Is Right," Anderson described a more personal cost. Twenty-five years of software engineering experience, and he had managed to degrade his own skills to the point where he felt helpless looking at code he'd directed an AI to write. He was working harder than if he'd coded everything himself, with none of the learning or skill development that normally accompanies writing software.

This is the dependency trap that AI tool vendors don't advertise. When a developer delegates code generation entirely, knowledge of the codebase erodes. Architecture decisions become opaque. Each new feature adds lines of code that the nominally responsible human has never actually reasoned through. Three months was enough to make Anderson - a fractional CTO who advises other companies on engineering practices - feel like he'd lost his grip on his own product.

The MIT Study: Billions in Smoke

The MIT research Anderson referenced is "The GenAI Divide: State of AI in Business 2025," published by MIT Media Lab's Project NANDA initiative in August 2025. The study examined 300 publicly disclosed AI pilot initiatives, conducted 150 leadership interviews, and surveyed 350 employees across corporate settings.

The headline finding: 95% of enterprise generative AI projects fail to deliver measurable financial returns, despite an estimated $30 to $40 billion in global enterprise spending on generative AI. Only 5% of integrated AI pilots were delivering significant value. The rest produced no measurable impact on their profit and loss statements.

MIT attributed the failure to what it called the "learning gap" - the inability of AI systems to adapt effectively to enterprise workflows. Over 90% of surveyed organizations reported that employees regularly used personal AI tools on the job, but only 40% of those companies actually purchased enterprise AI subscriptions. The gap between informal adoption and formal deployment suggests most companies are spending money on AI initiatives while their employees are off using free-tier ChatGPT on their own anyway.

Anderson saw his three-month experiment reflected in the MIT data. He had watched the same pattern play out in miniature: initial excitement, genuine early results, a growing overhead cost that swallowed the productivity gains, and a final state where the human was doing more work, not less, to keep the AI-generated system from falling apart.

Augmentation vs. Abdication

Anderson distilled his experience into a framework he now uses with clients. He draws a line between augmentation and abdication:

AI helping a developer write better code faster while the developer maintains architectural understanding - that's augmentation. AI writing code the developer doesn't understand - that's abdication.

AI helping analyze customer feedback while a product manager makes decisions - augmentation. AI telling the product manager what to build next - abdication.

AI helping a writer produce content faster while maintaining their voice - augmentation. AI producing content in a voice that isn't actually theirs - abdication.

The distinction matters because abdication compounds. Developers who rely on AI from day one never build the architectural understanding they'd need to teach others. Product managers who always defer to AI recommendations don't develop judgment. Organizations that automate away their human competencies create dependencies they can't easily reverse.

Anderson's advice to clients after the experiment was direct: "Now when clients ask me about AI adoption, I can tell them exactly what 100% looks like: it looks like failure." The successful implementations he has observed since are the ones where humans own the decisions, own the code, own the strategy, and use AI as an amplifier rather than an autopilot.

The Uncomfortable Middle Ground

Anderson's experiment is uncomfortable precisely because it was conducted by someone qualified to evaluate the results. This wasn't a product manager who'd never coded trying to vibe their way to an MVP. This was a fractional CTO with a quarter-century of engineering experience, deliberately stress-testing the "all-in on AI" thesis with full awareness of what good software development looks like.

If someone with that background ended up spending three months building a product he could no longer safely modify, the question for the companies spending billions on enterprise AI is plain: how many of them have less engineering expertise than Anderson, worse process discipline, and higher expectations?

The Roadtrip Ninja codebase still exists. Anderson still uses Claude Code - but as a tool he directs, not a colleague he delegates to. The distinction he landed on, between the Batman (the human driving decisions) and the Robin (the AI assisting with execution), is neither revolutionary nor new. It is, however, backed by three months of lived evidence and a codebase that proved the alternative doesn't work.