What 900,000 Lines of AI-Built Code Taught Me About Being Wrong

I owe my most popular article an update. Here it is.

A few months ago, GitHub CoPilot reviewed one of my pull requests and came back with zero comments. Not “looks good with minor suggestions.” ZERO.

Photo by Jeremy Perkins on Unsplash

My first reaction was suspicion. I assumed the review had silently failed, so I went digging through the checks to confirm it had actually run. It had. Then I re-ran my own validation pass, convinced the machines were being polite to each other. Clean again. I sat there staring at a green checkmark, like it owed me an explanation.

That PR landed in Reclaim, the product my startup is building. We’re closing in on 900,000 lines of code, and Claude Code has written nearly all of them under our direction.

If you’ve been reading this newsletter for a while, you know why that number matters. A year ago, I published the most-read article in the history of the Leadership Lighthouse, about how my all-in AI experiment fell apart as Roadtrip Ninja approached 70,000 lines. I wrote that the MIT study showing 95% of AI initiatives failing was right, and that I had lived the failure personally.

I owe that article an update. A lot has changed. Some of it in the tools. Some of it in me. And one of my core predictions from that period was flat wrong, which is exactly why I’m writing this.

---

The Article I Owe an Update

Quick recap for newer readers. In late 2025, I forced myself to build a product using only Claude Code. 3 months, zero lines written by hand. It worked right up until it didn’t. Small changes started taking longer than writing from scratch. Claude would fix one thing and break two others. My prompts grew from paragraphs into essays just to keep enough context alive to function. And then came the moment that gutted me: I needed to make a small change to my own product and realized I wasn’t confident I could. 25 years of software engineering experience, and I felt like a passenger.

Bob Galen watched the whole thing unfold and asked me the question that became the spine of that article: “Who owns that product, Josh? You or Claude Code?” At the time, the honest answer was Claude Code.

In the companion piece where I documented my whole setup, I made a prediction. I said the features would change, and the token limits would grow, but the fundamental challenges: the context complexity, the architectural drift, the non-deterministic behavior, were baked into how these systems work and weren’t going away with a feature update. To drive my opinion home, I told you to check back in 6 months.

It’s been 8. Time to grade my own homework, in public, on the most popular thing I’ve ever written. Most people spend years defending their biggest hit. I’d rather audit mine.

---

The Tools Changed a Month After I Hit Publish

I published the first article on October 22, 2025. On November 24, 2025, Anthropic shipped Claude Opus 4.5.

Go down my complaint list from last fall and hold it up against that release.

• I complained that Claude lost the thread on long tasks; Opus 4.5 delivered consistent performance through 30-minute autonomous coding sessions and became the first model to break 80% on SWE-bench Verified.

• I complained that my prompts had become essays because context kept evaporating; the release shipped context compaction so long sessions stop hitting a cliff.

• I complained that Claude would acknowledge my standards and then ignore them; instruction-following was one of the headline improvements, along with a rebuilt Plan Mode that asks clarifying questions and writes its plan to a file before touching code.

My complaint list from October became a changelog in November. Item by item.

Reclaim was born right into that window. We laid our foundation in the weeks after those model updates landed, which means our product never lived a day under the constraints that broke Roadtrip Ninja. I’d love to tell you that was strategic timing. It was dumb luck. But it means Reclaim has grown up alongside tools that keep improving underneath it, and that timing shaped everything that followed.

---

This Time, I Owned the Architecture

The tools improving explains part of the story. It doesn’t explain 900,000 lines. Because I’ve watched plenty of teams pick up the same improved tools over the past year and recreate my 2025 mess at a much larger scale.

The biggest difference between Roadtrip Ninja and Reclaim happened before Claude wrote a single meaningful line. I built the architecture myself. I researched patterns, pressure-tested options, refined the design, and landed on something we were genuinely proud of. Only then did we set Claude Code loose inside it.

That inverted everything. With Roadtrip Ninja, Claude was effectively making architectural decisions on the fly, and I was auditing a stranger’s choices after the fact. With Reclaim, I knew the architecture cold. I knew what good looked like before the first feature shipped. When Claude drifts from the pattern, I see it immediately, because it’s drifting from decisions I made and can defend.

Bob’s question deserves a fresh answer. Who owns this product? Me. Full stop.

Claude has written almost all of the code, and I own every architectural decision in it. Those two statements sit together comfortably now, and getting them to coexist was the whole lesson of the past year.

---

How I Ship Code in July 2026

I want to put a timestamp on this section on purpose. What follows is my workflow as of this month. It changes every few weeks, partly because I keep learning and partly because Claude keeps changing underneath me. I wrote back in March that any AI workflow you lock in is already aging, so read this as a snapshot with the expiration date printed right on the label. If you’re reading this in January, assume half of it has evolved.

Every task gets a fresh session. I’m aggressive about clearing context. One task, one session. When we finish, I close it and start clean for the next thing. A year ago I was writing essay-length prompts trying desperately to keep context alive across a sprawling session. Now I deliberately throw context away, because a focused session with exactly the right information beats a long one dragging around the residue of 5 previous tasks.

Everything starts in plan mode. When I know exactly what we need, I give strict direction. When there’s wiggle room on the optimal approach, I hand Claude the requirements and constraints and ask it to come back with recommendations.

There’s still a frustrating friction point here though: it almost always comes back with “do you want A or B?” and thin reasoning behind each option. I have to push back for real pros and cons before I can make a confident call. Every time. It’s a small tax, and I pay it gladly, because the alternative is deciding blind.

The plans rarely come back perfect on the first pass, and that’s frequently my fault rather than Claude’s. Reading a plan is how I discover the use case I forgot to mention, the constraint that lives only in my head. The plan review is where my missing context gets flushed out, before it becomes missing code.

Our standards live where the work lives. Our CLAUDE.md documentation has evolved more than any other part of the system. We used to have the classic single giant file. Today we run several CLAUDE.md files placed strategically across the project, each one holding the standards specific to its territory. The rules for shaping our API endpoints sit at the root of the API folder. Our schema rules live, you guessed it, at the root of the DB folder.

A year ago, I referenced one monolithic CLAUDE.md in every single prompt and watched Claude quote my standards back to me before ignoring them. Putting the rules where the work happens changed that dynamic completely.

I verify twice before every PR. Once the work is done, Claude outlines validation steps for me, and it’s surfaced edge cases I hadn’t considered, which still surprises me. Then, before I commit, I skim the changes in the GitHub app myself, and I run a skill I built that validates every change against the architectural standards in our CLAUDE.md files.

Early in Reclaim’s life, that skill caught variations in almost every changeset. These days it rarely finds anything. I think 3 things drove that: the product is big enough and the patterns locked in enough that Claude only sees 1 way to do things, Claude itself got better, and our CLAUDE.md approach kept improving. I can’t tell you the ratio between those 3, and that entanglement is kind of the point of this whole article.

Our standards refuse to sit still. After the PR goes up, CoPilot runs its automated review. That’s where my zero-comment moment came from, and like my own skill, it finds less and less over time. For whatever it does flag, I read every comment myself first, then kick off a “review-pr” skill I built that works through each one and returns a verdict: agree and fix, disagree and post a reply, or agree, fix, and adjust our standard.

That third option is the one I’d tattoo on the process if I could. Every PR review becomes a chance to evolve the standards themselves, so the architecture stays a living thing instead of a monument. I wrote earlier this year about the coming wave of AI-generated codebases that nobody maintains and nobody owns. A static rulebook is how you end up in that wave. Without that third verdict, our architecture would calcify and quietly crumble over the next few years, and we can’t allow that.

A human gets the final word. Once every automated comment is addressed and answered, the PR goes to my partner in crime for a good old-fashioned human review. You know how those go. They’ve been the norm for a while. Somehow, after all the plan modes and skills and automated reviewers, the last gate on our AI-built product is the oldest quality practice in software. I find that fitting.

---

The Scoreboard, With Caveats

A year ago: 70,000 lines and shrinking confidence. Today: closing in on 900,000 lines and shipping steadily. The Stanford research I cited last fall found AI productivity gains falling off a cliff as codebases grow, with the pain arriving well before 100,000 lines. We’re roughly 9 times past the spot where I personally hit that wall.

Before anyone frames that as a victory lap, the caveats matter.

• I still push back on thin recommendations in nearly every planning session.

• I still catch Claude confidently handing me answers for framework versions that are 2 major releases stale.

• I still verify everything twice, and then a human verifies it a third time.

The wall moved. I’d bet money it’s still out there somewhere past 900,000 lines, waiting, and I’d rather find it with my current discipline than my 2025 habits.

---

What I Got Right, and What I Got Wrong

The MIT study’s core finding has held up. Most AI initiatives are still failing, and they’re failing for the reason I lived firsthand: abdication.

Handing the thinking to the tool, losing the ability to own what it produces. The formula I gave you last year, AI + HI where the human intelligence stays bigger, describes every AI success I’ve seen since, including ours. I’ll stand behind all of that today.

Here’s what I got wrong. I called the context problems, the drift, the degradation at scale “baked into how these systems work” and said no feature update would fix them. Within a month, a release addressed most of my specific complaints, and the releases since have kept pushing. Some of what I diagnosed as physics turned out to be tool maturity, and tool maturity moves terrifyingly fast.

The 2 halves of this story need each other.

1. Better models raised the ceiling.

2. Owning the architecture is what let us build all the way up to it.

If I’d started Reclaim with my 2025 habits and 2026 models, I’d have hit a wall again, just further out and much more expensive.

The tools got better, and so did I, and I genuinely cannot untangle which mattered more.

My validation skill going quiet is the entanglement in miniature: better model, better standards, better placement of those standards, all reinforcing each other until the failures I documented last year simply stopped showing up.

---

What This Means for You

2 things I’d ask the leaders reading this to take away.

1. Put an expiration date on your AI conclusions. Whatever you decided about these tools more than 6 months ago, the experiment that produced that decision is stale. That cuts both ways. The team that wrote off AI coding after a bad 2025 pilot is operating on expired data, and so is the team that went all-in on a workflow that’s aged out from under them. I published a confident, hard-won, widely-read conclusion, and a month later the ground shifted. Re-run the experiment. Put it on the calendar like a fire drill.

2. Steal the pattern, and let the workflow details go. My July 2026 workflow will look quaint by spring of 2027. The pattern underneath it has survived every model release: humans own the architecture and know what good looks like before the agents start building, standards live where the work lives, and there’s a mechanism forcing those standards to evolve with every change. Get those 3 things right, and the tools improving become compounding leverage for you. Skip them and the tools improving just helps you build your mess faster.

A year ago I told you I’d become a passenger in my own product. Today I’m something closer to an architect with a very fast construction crew. The crew got dramatically better this year. But the reason the building stands is that somebody who could read the blueprints never left the site.

Stay courageous,

Josh Anderson
The Leadership Lighthouse

---

P.S. This one closes a loop Bob opened on the Meta-Cast last year, when he stopped me mid-story and asked, “Who owns that product, Josh?” That episode paired with the original article, and if you missed it, it’s worth going back for. I finally have an answer I like.

P.P.S. I want to hear yours. What did you conclude about AI more than 6 months ago that deserves a re-test? Hit reply and tell me. I read every response, and I have a feeling this one’s going to fill my inbox.