Developers are shipping 10x more code today due to AI tools. But our ability to understand what that code actually does hasn't moved an inch. So I spent the last few weeks going deep on this.

The gap nobody wants to talk about

In January 2026, Boris Cherny - head of Anthropic's Claude Code - announced that 100% of his code is now written by AI. He shipped 22 PRs in one day and 27 the next. Every single one written by Claude. Company-wide at Anthropic, the figure is 70-90%. Claude Code itself? About 90% of its own code is written by Claude Code.

An OpenAI researcher said the same thing: "100%. I don't write code anymore."

At Amazon, an engineer revealed this week that 95% of her code is AI-generated - and she got promoted twice for it. Microsoft's CEO says 30% of the company's code is AI-generated. Google's Pichai puts their number at 30%+. Globally, 41% of all code is now AI-generated, with the trajectory crossing 50% by late 2026.

Anthropic's CEO Dario Amodei said at Davos this January that we may be six to twelve months from AI handling most or all of software engineering work.

Code generation is scaling exponentially. Human capacity to understand code is flat. Your team ships 4x more PRs than last year. But your QA team is the same size. Your test suite covers the same paths. And your three senior engineers - the only people who truly understand how billing interacts with subscriptions when an EU customer triggers a currency conversion during proration - they haven't been cloned. Meanwhile: 4,484 alerts per day hitting the average enterprise team. 67% ignored from fatigue. 27% of defects still escaping into production despite everything we've built. 60-80% of IT budgets spent just keeping the lights on. 40% of that on tech debt. That's the blind spot. We can generate code. We cannot understand code. And the gap is widening every single day. "We have tests for that." No, you don't. I know the instinct. Throw more tests at it. More CI checks. More review gates. It won't work. Not because tests are bad - but because the structure of the problem makes testing structurally insufficient. Your unit tests verify components in isolation. They can't tell you what happens when a customer uses a hyphenated email that triggers a legacy regex from a module written in 2019 that nobody remembers exists. Your integration tests are brittle, expensive, and growing linearly while interaction paths grow combinatorially. You're always behind. By more every sprint. And code review? I'll say the quiet part out loud: code review is theater. The reviewer sees the diff. They don't see the system. They see what changed. They don't see what that change means for every downstream dependency across twelve microservices. They can't. No human can hold that much context in working memory. 27% defect escape rate. After decades of investment. The problem isn't effort

The problem is that our verification tools were designed for deterministic machines, and our software has become a biological organism - interconnected, emergent, constantly mutating. AI agents writing code that humans never directly review. Architectures drifting. Dependencies shifting under our feet. We're checking a living system with dead instruments. The Two Clocks Problem Here's the concept that rewired my thinking. I think it's one of the most important ideas in software engineering right now, and almost nobody is talking about it. Every software system runs on two clocks. State clock - what's true right now. Current code. Config values. Open tickets. Live metrics. Event clock - why it became true. The reasoning. The decisions. The context. We've built trillion-dollar infrastructure for the state clock. Databases, warehouses, dashboards, monitoring, version control. Gorgeous. The event clock? Almost nothing. Let me make this visceral. Your config file says timeout=30s. It used to say timeout=5s. Someone tripled it. Why? Git blame shows who. The reasoning is gone. Maybe it was a latency spike in Q3. Maybe a specific customer's API was chronically slow. Maybe someone was debugging at 2am, cranked it up, and forgot to revert. That context - the single most valuable piece of information for anyone who touches this system in the future - we threw it away. It lived in a Slack thread now buried under 10,000 messages. Here's another one. A P1 bug gets fixed at 3am. The ticket says "resolved." It doesn't say the fix was a workaround. It doesn't say the real root cause is in a shared library that three other services depend on. It doesn't say the engineer who fixed it told their manager "this will break again in two months" during a standup nobody took notes on

Two months later, it breaks again. Different engineer. Starts from zero. This pattern is everywhere. The PR got merged - but the reviewer was rushed, only looked at the first 40 lines, and missed the edge case in the helper function. The architecture was chosen - but the two alternatives that were seriously debated, and the tradeoffs that tipped the decision, exist only in the memory of someone who left the company. We've built elaborate infrastructure for what's true now. Almost nothing for why it became true. This is why AI coding tools produce impressive-looking code that breaks in production. They generate code from the state clock only. The event clock - the accumulated reasoning that explains why the system works the way it does - doesn't exist in any form they can access. And every organization pays what I'd call a fragmentation tax for this. The cost of manually stitching together context scattered across tools that each see a fraction of reality. Support sees tickets. Engineering sees code. QA sees test results. SRE sees dashboards. Nobody has the complete picture. The fragmentation tax is the real reason debugging takes weeks, escalations bounce between teams, and the same bugs keep resurfacing. What if software could build a world model of itself? Now here's where I went from "this is a problem" to "wait, someone is actually solving this." And honestly, I was skeptical at first. There's a concept from AI research that's been quietly transforming robotics, autonomous vehicles, and video generation: world models. @drfeifei 's World Labs is building world models for 3D spatial intelligence. OpenAI built Sora partly as a world model - learning the physics of how visual objects move and interact

In robotics, world models let you simulate a robot's actions before executing them. Train in imagination. Explore dangerous scenarios safely. The core idea: a world model is a learned, compressed representation of how an environment actually works. It encodes dynamics - what happens when you act in a specific state. It captures structure - what entities exist and how they relate. And critically, it enables simulation - given the current state and a proposed action, predict what happens next. Now here's the thought that stopped me in my tracks: The same logic applies to software. But the physics is different. Software physics isn't mass and momentum. It's data flow dynamics. How does a request propagate through microservices? What happens when you change this config while that feature flag is on? What's the blast radius of this deploy given the current state of all dependencies? If you could build a world model for a codebase - one that understands not just what the code says, but how it behaves as a system across all interactions - you could do something that has never been possible: Simulate how a code change affects production before it ever runs. Not a unit test. Not a static scan. An actual simulation - tracing a user scenario through your entire distributed system, predicting state changes across dozens of services, telling you whether this commit breaks something, what specifically, why specifically, and which customers get hit. Code simulation: the missing primitive When I first heard "simulate code without running it," I assumed it was marketing fluff. Then I looked at the actual implementation and the numbers. And I'll be honest - it changed my mind. A team called @playerzero_ai has been building this approach for years

They've shipped something called Sim-1 - a reasoning engine that simulates how complex codebases behave, directly from natural language scenarios, without compilation, execution, or deployment. The way it works deserves a careful explanation, because I think it represents an entirely new category. Scenarios are memories, not test scripts. This is the first thing that clicked for me. Instead of writing brittle test code tied to implementation details, the system captures scenarios - plain-English descriptions of how the software should behave. These get generated automatically from support tickets, bug reports, customer feedback, PRDs, even past incidents. Example: "When a customer with an EU billing address generates an invoice during a plan change, the proration calculation should correctly handle FX rounding and reconcile on the invoice run." That's not test code. That's institutional knowledge - the kind that usually lives in a senior engineer's head and walks out the door when they leave. Each scenario is a memory of how the system should work. And the system builds these memories continuously, from real operational data. On every commit, the system simulates. When a developer pushes a change, the engine analyzes the diff, identifies the most relevant scenarios, and runs simulations. Each simulation traces the full execution path across the entire codebase - following data flow through microservices, simulating API calls, predicting database state changes, reasoning through algorithmic logic. This isn't executing code. It's simulating what the code would do. No compilation. No test infrastructure. No databases to seed. No services to spin up. Simulations run in parallel, at scale, on every commit

The system maintains coherence across 100+ state transitions and 50+ service boundaries in a single run. When something fails, you don't get a vague "test failed." You get: The root cause - down to the file and line number The blast radius - which customers, which workflows, which business metrics A proposed fix - with the code change ready to review Across 2,770 real-world scenarios from production codebases, their Sim-1 model achieves 92.6% simulation accuracy, compared to 73.8% for leading general-purpose models. This is purpose-built code understanding, not general-purpose LLM reasoning applied to code. To put a finer point on it: this is AI that can read your codebase, take a natural language description of expected behavior, simulate that behavior across your entire distributed system, and predict whether your latest commit breaks it. In under 15 minutes. Without running a single line of code. The context graph: this is the part with trillion-dollar implications OK so far I've described a really good simulation engine. Impressive, but you might be thinking: is this just fancy testing? No. And this is where it gets genuinely interesting. Every simulation that runs, every bug triaged, every customer ticket resolved - these aren't just events. They're decision traces. Evidence about how the system actually behaves in reality, captured at decision time, not reconstructed after the fact. These traces accumulate into something PlayerZero calls a context graph. And once I understood what that actually is, I realized this is the real unlock. A context graph is not a knowledge base. It's not a vector database with your docs chunked up. It's a living, evolving world model for your production software. It's the event clock that never existed before - finally being built

It captures what no existing system does: Which code paths are fragile and how they interact dangerously Which configurations have caused incidents and under what conditions Which customer workflows exercise the riskiest parts of the system The reasoning behind past decisions, fixes, and architectural choices - the "why" that we've been losing for decades Here's the key insight: the system gets smarter by using it. Not by retraining. By accumulating evidence. Think about what the best senior engineer at your company has that a new hire doesn't. It's not different cognitive ability. It's a better internal world model. They've seen enough production incidents, enough edge cases, enough "we tried that in 2022 and it broke billing" moments to simulate outcomes in their head. "If we push this on Friday, on-call will have a bad weekend." That's not retrieval from a database. That's inference over an internal model of system behavior built from years of accumulated experience. The context graph is that senior engineer's intuition - externalized, compounding, and available to every person on the team. Including the junior dev who joined last month. And the economics are elegant. The agents aren't building the context graph for its own sake - they're solving real problems worth paying for. The context graph is the exhaust. Better context makes agents more capable. More capable agents get deployed more. More deployment generates more traces. More traces deepen the world model. The flywheel spins. Because the world model supports simulation, you get something even more powerful: counterfactual reasoning. Not "what happened last time?" but "what would happen if I take this action?" The system imagines futures, evaluates them, surfaces the dangerous ones. Before you merge

This reframes the entire continual learning debate in AI. The common objection: AI can't transform organizations because models can't learn on the job. But world models suggest an alternative - keep the model fixed, improve the world model it reasons over. The engine doesn't need new weights if the map it's navigating keeps expanding. More traces. Better inference. Not because the model updated. Because the world model grew. This is already working in production I want to ground this in real results, because frameworks without evidence are just stories. Cayuse - a research platform serving 700+ global institutions - deployed this approach. Their engineering team was stuck in the classic loop: ship features, drown in support tickets, context-switch constantly. Debugging a single customer issue could take weeks because nobody could reproduce the conditions. After deploying PlayerZero: 90% of issues caught and fixed before reaching customers 80% reduction in average time to resolution Junior engineers gained the autonomy to resolve complex bugs without waiting for senior guidance - because the context graph provided the institutional knowledge they were missing "PlayerZero has improved our ability to proactively detect and address issues earlier in the development lifecycle. It's helped us streamline ticket resolution and enhance overall product stability." - John Nord, CTO at Cayuse Zuora - one of the largest subscription management platforms in the world - deployed it across their entire engineering organization, including their most complex billing and revenue systems (we're talking billions of lines of code, 900+ repos): "We can now predict, with much higher confidence, how code changes might impact customers before those changes are ever deployed

Its deep understanding of our code architecture - especially through its Code Simulations - has been a game-changer." - Mu Yang, SVP Engineering at Zuora Cyrano Video cut engineering hours spent on support by 80%. Key Data went from bug replication cycles of weeks to minutes. These aren't pilot programs. These are production-scale transformations at companies running complex, critical software. Why this matters more than most people realize Let me zoom out, because I think there's a larger structural shift happening that most people are missing. The last era of developer tooling optimized for speed. Faster CI/CD. Faster deploys. Faster code generation. And it worked - we can ship code faster than ever. But speed without understanding creates fragility. Every AI-generated function that nobody fully reviewed is a potential time bomb. Every 10x increase in code velocity without a corresponding increase in code comprehension is technical debt compounding at a rate we've never seen. I keep thinking about the manufacturing parallel. When production lines got too fast for human quality inspection, we didn't hire more inspectors. We built systems that could predict defects before they happened. Statistical process control. Six Sigma. The entire field of predictive quality emerged because human attention couldn't scale with production speed. Software is having its predictive quality moment right now. And the companies building this infrastructure - world models for code, context graphs that accumulate institutional reasoning, simulation engines that predict production behavior - are building something that has never existed before: software that understands itself. Not AI that writes code. AI that comprehends code

Not tools that find bugs after they ship. Systems that predict them before merge. Not dashboards that alert you when production is already burning. Engines that tell you it will burn before you light the match. The backing tells you this isn't just me being speculative. PlayerZero has $20M in funding from Foundation Capital, with angel investors including @rauchg (Vercel), @zoink (Figma), @matei_zaharia (Databricks), @drewhouston (Dropbox), and the co-founder of OpenTelemetry. The people who built the modern developer ecosystem are betting that this is the missing layer. What this means for you If you lead an engineering team, here's what I'd actually do with this: 1. Audit your "understanding gap." What percentage of your entire system can any single person on your team fully explain end-to-end? If the answer is less than 30% - and at most companies it is - you have a world model problem, not a testing problem. No amount of test coverage will fix a comprehension deficit. 2. Start treating bugs as training data, not just tasks. Every bug you fix contains a scenario your system should remember forever. Every customer escalation reveals a behavior path worth simulating on every future commit. If that knowledge dies in Slack threads and Jira comments, you're losing your single most valuable dataset. 3. Reconsider what "quality" means in the AI era. Quality isn't "all tests pass." Quality is "we can predict how our system will behave under conditions we haven't explicitly tested for." That's a fundamentally different standard, and it requires fundamentally different infrastructure. 4. Look at the teams building code simulation infrastructure. This is an emerging category, and it's where I'd place my bets

PlayerZero is the most advanced implementation I've found - Sim-1, code simulations, context graphs - and they're already running in production at companies like Zuora across billions of lines of code. If you're dealing with complex distributed systems, it's worth seeing what they've built. The bottom line We're in the middle of the biggest explosion of code generation in history. Every week, the gap between what we produce and what we understand gets wider. $1 trillion wider per year, if you believe the data. I do. More tests won't close it. More engineers won't close it. More code reviews definitely won't close it. The gap closes when software can finally understand itself. World models that simulate behavior. Context graphs that remember reasoning. Simulation engines that predict what breaks before you ship it. The last era of developer tooling was about speed. Ship faster. Deploy faster. Generate faster. The next era is about understanding. And the companies that build the understanding layer will own the most important infrastructure in software for the next decade. We gave AI the ability to write code. We forgot to give it comprehension. That's the $1 trillion blind spot. And it's closing.