The Claude Code team ships 60-100 internal releases per day, merges 5 PRs per engineer daily, and threw away two days of work on their subagents feature without slowing down. Factory digitalizes everything from meeting transcripts, chalkboard jams, to design docs for feeding into their own AI development tools. OpenAI runs weekly demos where teams share new tools and workflow changes, treating tools as artifacts rather than just enablers.

Multiple signals point to something shifting. Whether it generalizes beyond AI companies building AI tools is unclear, but a patterns is shaping up.

Code deletion as progress. Traditional teams accumulate complexity over time. Each feature or bug adds lines, each edge case adds conditionals. Claude Code’s codebase shrinks with model improvements:

“Every time there’s a new model release, we delete a bunch of code… We try to put as little code as possible around the model.”

The model handles what used to require scaffolding. This inverts the normal relationship between time and technical debt. Most codebases grow; theirs shrinks. It’s a different cost structure for maintaining functionality that can’t be measured in simple lines-of-code.

Throwaway work as exploration strategy. For subagents, Claude Code prototyped over 10 different UI approaches, discarding most. That’s not waste when prototyping costs approach zero. The economics of iteration fundamentally change. You no longer have to carefully plan 2-3 designs and pick one. You try 10+ in parallel and converge on what works. The traditional “minimize rework” mindset becomes friction.

Infrastructure determines outcomes more than AI quality. Factory found that following best practices like good specifications, automated tests, verification before review mattered more than which AI they used. The tooling and process around the AI predicted success better than the model itself. That’s counterintuitive if you think AI quality is the main variable, but consistent with what we’ve learned from other technology shifts.

Tools as artifacts, not just enablers. OpenAI’s weekly tool demos aren’t show-and-tell. Teams build internal tools, share them, iterate on each other’s work. The cadence is different from traditional sprint planning that take anywhere from two to eight(!!!) weeks. Here tools emerge from use rather than being planned upfront. That’s closer to how open source communities operate than how enterprise IT typically works.

This maps to what I’ve seen at work. The gains show up in unexpected places instead of sprint velocity. Like in how many ideas get explored, how many dead ends get identified quickly, how often the right approach emerges after trying five wrong ones. Traditional story points don’t capture “we validated this won’t work in 2 hours instead of 2 weeks.” That’s what agile methodologies always aspired to—rapid iteration, embracing change over planning, throwaway work as a feature not a failure. The constraint was always the cost of iteration. AI tools lower that cost enough to actually iterate your way to the right answer instead of trying to design it upfront.

The uncertainty is whether this transfers. Dropbox found engineers using AI merge 20% more PRs weekly while reducing change failure rate. CloudKitchens reports a median 3 hours saved per week, though they “have not been able to tie back any of these improvements to overall engineering project velocity.” Those are real gains, but not Claude Code’s 5 PRs per engineer daily.

The compounding loop might be the difference:

“The tech stack was chosen to be ‘on distribution’ for the Claude model… around 90% of Claude Code is written with Claude Code.”

AI building AI. Each model release makes their development tool better, which makes development faster, which produces better models. When the thing you’re building is the tool you’re using to build it, you get feedback loops that traditional product teams can’t replicate. Meta’s building custom diff risk models, Cursor’s training specialized coding models. The infrastructure investment is nontrivial.

“Product overhang means that a model is able to do a specific thing, but the product that the AI runs in isn’t built in a way that captures this capability.”

This explains current AI tooling frustration from power users. Claude Code folks found the model could already navigate and modify files, but the product interface hadn’t surfaced it. How many other capabilities are sitting unused because the wrapper product hasn’t caught up?

Different organizational models are also emerging alongside these patterns. OpenAI now hires “super senior + super junior” teams—AI-native early-career engineers who use tools in ways that surprise experienced colleagues. That suggests the skillset for working in this paradigm might be different, not just the tools.

The evidence points to something real but hard to isolate. AI companies building AI tools see extreme gains, but they’re also exceptionally well-funded with organizational freedom to experiment without typical enterprise constraints. Traditional companies using AI tools see moderate gains while navigating legacy systems and approval processes. The delta could be the compounding feedback loop, or the resources and permission advantage, probably both. We can’t cleanly separate them yet.

What’s clear is that ignoring this entirely because “we’re not an AI company” or “AI is bubble” is probably wrong. The patterns are worth understanding even if they don’t fully transfer. Smart organizations are running experiments, tracking what actually changes, staying ready to adapt. The worst move is waiting for certainty before paying attention.