You Can't Drive Using the Rearview Mirror
The AI productivity studies are accurate. They're also dangerously misleading.
Two reports from people I trust recently told me that AI productivity gains are going to be modest. DX published a longitudinal study of 400 companies showing that while AI usage increased by 65%, PR throughput went up by just 10%. CTO Craft surveyed 450 engineering leaders and projected linear growth to 2028 with a median expectation of a 20-50% productivity improvement by 2028.
The data is real. DX tracked companies for 15 months. They filtered out metric gaming. They did the work. I’m not saying they’re wrong.
I’m saying that if anyone infers from this that the impact of AI in the SDLC is going to be modest, they’re taking away dangerously misleading conclusions from the data.
The rearview mirror is crystal clear
The DX study measures what happens when you give engineers AI tools and count PRs. That’s the old workflow with AI bolted on. One developer in the study put it perfectly: “A four-day task might take three. But that doesn’t mean I’m shipping 3x more PRs.”
Read that again. The task got faster. The system around it didn’t change. The planning meetings are the same length. The code reviews follow the same process. The handoffs work the same way. The developer is right that PRs didn’t 3x. But that’s not evidence that AI is limited to 10%. That’s evidence the organization hasn’t adapted yet.
PR throughput is a rearview mirror metric. It measures how the existing SDLC performs with a slightly faster coder in the loop. It cannot see what happens when you redesign the SDLC itself.
What the windshield looks like
While the studies were measuring the last curve, a small number of teams were building something different.
StrongDM has a three-person AI team shipping production software: 16,000 lines of Rust, 9,500 of Go, 6,700 of TypeScript in a single release. No human-written code. No human-reviewed code. Verification happens through automated scenario testing with holdout sets the agents never see during generation. Their target: $1,000/day per engineer in tokens as the floor for adequate AI utilization.
Dan Shapiro (Glowforge CEO) built trycycle: a specification-driven loop that delivered over a dozen production features in its first 24 hours while he was in meetings. He describes it as “an unstoppable bulldozer that can bury any problem with time and tokens.”
Geoffrey Huntley (of Ralph loop fame) is building Latent Patterns, an embedded software factory where the platform itself is the IDE. He’s cloned Posthog, Jira, Pipedrive, and Calendly through AI to demonstrate that software development now costs less than minimum wage. His “Everything is a Loop” essay describes the paradigm shift: software is clay on a pottery wheel, not bricks stacked vertically. You throw it back on the wheel until it’s right. His core question to engineers who think they can wait: “What if the models don’t stop getting good?”
Steve Yegge built Gastown, a multi-agent orchestration framework for autonomous software development. His AI Vampire essay makes an unintentional case for the magnitude of change: engineers are burning out from the intensity of AI-augmented work. You don’t burn out from 10% productivity gains. The exhaustion itself is evidence that the transformation is real.
Ali Dasdan (CTO of Dropbox) made AI adoption a company-level priority, treating it like a product rollout: soft mandate from the CEO, removing friction, AI champions sharing real examples with peers, show-and-tell every two weeks. In a recent O’Reilly CTO Hour, he described the result: “From less than half of people using [AI tools], we came over 90% [in under two quarters], and we have a blog post actually saying that now it is close to 100%.” Engineers who regularly use AI tools are shipping 20% more PRs while reducing change failure rate. This isn’t a startup experiment. It’s a 4,000-person company deliberately redesigning how it builds software.
Rob Duffy (CTO of HealthEdge) is building systems for his 1000+ engineers to share their learnings, updated skill prompts, agent files, and contexts. A platform team reviews what resonates, adopts the best PRs, and pushes the insights across the org.
These teams aren’t getting 10% more PRs. They’re moving towards a fundamentally different paradigm. The gap between “AI bolted on” and “SDLC redesigned” is not the difference between 10% and 20%. It’s the difference between measuring horse-drawn carriage speed on a highway and building a car.
The compounding gap
Here’s the part that should concern you. The teams investing now are compounding in two dimensions simultaneously.
First, capability compounds. It takes months to build good practices, restructure flows, retool roles, train people, and develop the intuitions that come from doing this consistently. Those months are not wasted time. They’re foundation. It’s like building a skyscraper. Right now the companies investing hard just look like they’re investing in a big hole in the ground. You might not even notice. But once the foundation is set and it starts rising, it goes up incredibly fast. If you haven’t started digging your foundation by then, you’ll be at least six months behind. And catching up with a competitor with a compounding software factory and a six month lead is an incredibly difficult thing to achieve.
Second, talent compounds. The companies investing in agentic engineering are attracting the people who want to work this way: the product-minded engineers who want to accelerate the feature delivery and the AI engineers who want to build and refine the harnesses. That’s a twofer. You get better AND you attract the people who make you better faster.
Why you can’t just catch up later
I went from zero to really getting agentic engineering in a few weeks. That’s because I had no systems of record, no tacit knowledge to extract, no people to retrain, no processes to rebuild. I was starting a one person business, clean.
Your org is not starting from zero. There is no one good way to write software. When you onboard a new engineer, they might have killed it at Stripe, but it’s going to take them time to figure out how to ship code at JP Morgan or Airbnb. The culture and values, the codebase, the practices, the architectural choices: these deeply inform what “good” means at your company.
What that means in the agentic era: the process of extracting that organizational taste, building good intuitions across your entire engineering org, restructuring how you handle meetings, planning, conversations, and documentation to ensure it’s all discoverable and mapped so that agentic project managers can share context with the software factory. That takes months of deliberate effort. It is not something you can skip when the models get better. The models will get better. Your organizational knowledge still has to be extracted, captured, and structured by humans who understand the context. That work starts now or it starts later, but it will have to be done sometime before you can create an agentic software factory that delivers the right code for your organizations needs.
Pick your lane (but pick it now)
Not every company needs to be an innovator on the technology adoption lifecycle curve. If you run ski resorts, you have physical assets that no software factory can re-create. Heck, your biggest existential risk is probably climate change, not AI. You have time.
But if you’re a SaaS vendor, if you sell tools for building websites, or if you’re in any industry that could be disrupted by AI native competitors or AI impacted business processes, you are taking a much bigger risk by sitting in the early or late majority. The technology adoption lifecycle usually says the late majority can afford to wait for proven patterns. That math changes if you might be competing with early adopters who are using daily enhancements to their systems to compound the speed at which they can ship.
The DX study tells you that bolting AI onto your current workflow gets you 10%. That’s accurate. It’s also the floor, not the ceiling. The teams redesigning their SDLC from end to end are getting the multiples. We all need to learn lessons from the scouts on the frontiers of agentic software development, in both single-player mode (one engineer with better tools) and the much harder multi-player mode (systems that generate and verify code autonomously steered by teams of co-operating humans).
If AI can disrupt your business or you could face a credible AI native competitor, you should be planning right now how to scale adoption of agentic engineering across your org. Not because the current tools demand it, but because the foundations take months, the compounding has already started for your competitors. And the gap gets wider every week. If you haven’t already, you also need to get your hands dirty to understand what is possible.
How seriously are you prioritizing building an agentic SDLC? And if you’re not investing today are you confident that you’ll be able to catch up with the competition in Q4 once you finally start to invest in building an agentic SDLC?


Thanks for all the examples!
Indeed, it depends on rethinking the value stream, not just improving the slowest part.
The distinction between "AI bolted on" and "SDLC redesigned" is the right frame. But I think the compounding gap you describe has a deeper root than most people realize.
The teams that are compounding aren't just faster at shipping code. They've done something harder first – they've extracted the tacit organizational knowledge that used to live only in people's heads and made it explicit enough for agents to work with.
That extraction step is the bottleneck. Not the models, not the tokens, not the tooling. It's the organizational specification. What does "good" mean here? What are the constraints? What does our architecture actually assume?
The companies that specified their processes before the agentic wave hit are the ones compounding now. The ones that didn't are discovering that faster agents just compound the ambiguity.
The skyscraper foundation metaphor is right. The foundation isn't the tooling. It's the specification that the tooling executes against.