645 Thought Leadership

Managing the Chaos

How AI has changed the software product development lifecycle and the myth of consolidation

Last month, the 645 engineering team was in a routine standup, discussing a product, when an engineer asked, "Is this the prototype, or the actual build?" Nobody was sure.

That question illustrates just how completely the line between planning and building blurs when you can spin up code fast… and throw it away just as fast. When the same confusion came up a second time, we realized we needed a new process. Going back to first principles, we compared our current workflow against how we operated a few years ago. We knew things felt less hectic (albeit slower) before AI, so we wanted to see where the chaos crept in. The exercise was cathartic and highlighted the tools we are still missing. So we wanted to share it.

Context on the chaos

Every PM, engineer, and designer is likely sick of hearing about AI by now. Yet, we can't stop talking about it, because it has fundamentally rewritten how we work. It made us faster, yes… but it also made everything feel more chaotic.

AI was supposed to collapse product development into a lean, seamless sprint. But if you look closely at the workflow, focusing on the steps themselves rather than team size, AI has actually added steps. Tasks that used to be distributed across distinct, specialized roles can now fall on a single person expected to own the entire cycle. No wonder the job feels overwhelming.

To really dig into why we feel overwhelmed, we mapped the new product development lifecycle against the old, tracing the steps AI has added and the ones it has consolidated. We are putting out a call for a fresh set of tools to manage this faster, more complex way of building.

How AI broke the product lifecycle

For anyone whose career started before 2022, the old product development lifecycle was a neat, orderly empire. At this time, building software was slow and expensive, and a single misstep could cost an enterprise millions or a startup its credibility. So to ensure that did not happen, we (Product, Engineering, and Design) essentially built an empire to prevent mistakes. Sharply defined roles governed each territory. Product Managers owned the why and the what. Designers owned the look and feel. Engineers owned the how and when. QA held the gates. Roads ran between the territories with checkpoints, and various libraries stored every spec, design, and test in their proper places. It was bureaucratic, but that was the point. When building is expensive, order is survival.

Then AI hit like an earthquake in 2022, with aftershocks still rolling today. It left our neat, orderly product lifecycle empire in pieces. The single assumption it stood on, that building is slow and expensive, had dissolved. In this new world, builders threw away decades-old blueprints. There was no process, or at least no "right" one, and new products were built in completely different ways. The software products that survived the quake are trying to bolt new tools onto old foundations. And while the new products rose incredibly fast, they carried their own security and structural concerns, and some designers rightfully argued originality was lost.

In short, we are in a new world with a new empire being actively built. Things remain chaotic, but we have seen many new processes emerge with massive opportunities for new tooling.

The product lifecycle, before and after AI

The product lifecycle today

To solve the chaos, we first have to define it. That means looking closely at how different engineering organizations are actively rebuilding, and comparing their new processes against the traditional model.

Specifically, we looked at Block, Meta, and Anthropic. Interestingly, we found that all three companies still execute the classic four stages of development: Define, Design, Build, and QA, though they take wildly different approaches to who actually does the work. Additionally, all three have introduced two entirely new phases to the lifecycle. While their internal names for these steps vary, they fundamentally center around managing Agent Directions and Agent Context — or what we call Recipes and the Brain.

A quick caveat on the sample: These are three of the most AI-forward companies in the world, so they are outliers, not the median team. We are generalizing from the outside, based on what we have read and heard, so these snapshots will not hold for every team within these companies and generally, the process may have already changed.

Comparing the product lifecycle of Block, Meta, and Anthropic (software)

StepBlockMetaAnthropic
DefineRoadmap and product areas set by leadership and the open-source Goose community. Owners take it from there.Set through product leadership and OKRs. The least negotiable step of the three.Researchers pick the work.
DesignThe spec is the recipe. Someone authors it in YAML, and that one artifact carries the intent. No separate design doc.Engineers specify the constraints agents build within.Humans give direction, but the spec emerges through dynamic workflows with Claude, not a full design doc up front.
BuildGoose spins up subagent flocks that write the code, around 90% of fixes in maintained codebases (1).DevMate writes about half of code changes (3). The company wants 65% of engineers in its Creation org writing 75%+ of code with AI in H1 2026 (4).Claude writes more than 80% of merged production code (5). For practical purposes this step is gone as human work.
QAA reviewer agent inside the flock checks the work before any of it surfaces.The one genuinely split step. Diff review plus tooling, with people still in the loop on much of it.An automated Claude gate runs on every PR. The human is-it-correct review has largely been handed to an agent.
RecipesThe step Block bet on. Authored workflows in a shared library, so a recipe written once gets reused across the org.Hybrid but thinner. Internal agent templates, centralized on platform teams rather than an author-it-yourself culture.A curated skills and prompt library agents draw on. The closest analog, framed as skills and prompts rather than YAML.
BrainA world model. A team specifies the context and intent agents reason from, and over time it should shape the roadmap (2).In-house models in the Llama lineage running alongside frontier models.Claude itself, plus the memory and context files that tell it what right looks like.

The pattern across all three

When you compare the traditional product lifecycle to the new one, a stark reality emerges. The classic phases (Define, Design, Build, and QA) haven't vanished. They have simply been heavily augmented by agents. We didn't actually collapse the product lifecycle. Instead, we expanded it by adding two entirely new foundational steps: Recipes and Brains.

The new process

  • Recipes: The true starting point. This is where a builder defines the various agents and specialized workflows that will execute the rest of the project.
  • Brains: The context layer. This step defines the deep data, constraints, and organizational knowledge that the agents need to ingest to effectively execute and augment the subsequent steps.
  • Define: This remains relatively human-driven in most organizations. While Block is the most vocal about actively shifting roadmapping over to agents, humans still largely steer the ship here.
  • Design: Emerging as a fascinating hybrid. While Block folds design directly into their YAML recipes and Anthropic lets it surface dynamically through agent workflows, Meta still maintains a distinct, human-led spec step. Most startups are taking a similar hybrid approach, hiring product designers who are strictly tasked with protecting and refining the core user experience.
  • Build: Almost entirely offloaded to agents. Anthropic, for instance, recently noted that more than 80% of the code merged into their production codebase is now authored by Claude. As a purely manual human task, typing out syntax is rapidly disappearing.
  • QA: Though humans remain in the loop as final gatekeepers, the initial, heavy-lifting QA pass has been entirely handed over to automated agents, varying slightly based on the complexity of the product itself.

The myth of consolidation

So yes, everything got faster. But we didn't streamline the process. We actually added steps. And in software, every step you add widens the surface area for human and systemic error. On top of this, because code can be spun up instantly, it is now functionally faster for a single person to run a product entirely end-to-end. But doing that requires understanding it all. Instead of splitting the work into neat, isolated buckets where a specialist owns one specific territory, we added two complex new steps and now expect a single builder to be an expert at all six.

In short, you used to get one step. Now you get the whole staircase. No wonder the job feels chaotic. Those heavily loaded individuals then have to coordinate with other builders who are also managing all six steps themselves, all while trying to ship a safe, reliable product.

What's needed

The crisis we are facing isn't just about speed. The reality is that the entire structure of product development has been compressed. By adding two net-new phases to the loop and forcing individuals to span across all six steps, we didn't just create a coordination problem; we created a systemic bottleneck around intent, throughput, and visibility.

Building code has been commoditized. Everyone can do it instantly. But humans can only parse so much data, manage so many agents, and verify so many changes before the process breaks down. To fix the chaos, we need an entirely new infrastructure layer that breaks apart, edits, and visualizes exactly what is happening across this expanded lifecycle.

Here is the stack we believe is required to manage it:

  • Recipe management. The authored workflows that define what each agent does and how. Written once and stored in a shared library, so the same recipe gets reused across the team instead of being rebuilt in every project. This is the first thing you build now, because before anything gets made, you have to decide who, or what, is doing the work.
  • Agent brain management. We need a standardized framework or tool that helps humans manage this. The world model that tells every agent what right looks like, and the recipes that define how each agent thinks, how many shots it gets, and what it can touch. A single, coherent home for intent. For a product manager, this is where taste becomes durable, the place where your judgment about what to build gets encoded once and reused by every agent instead of re-explained in every ticket.
  • A review protocol. When agents ship faster than humans can check, review becomes the jam. Zendesk gave the problem a name: absorption capacity, the amount of change an organization can actually take in (7). And even Anthropic, the most aggressive adopter, reports that with code generation effectively solved, human review became the bottleneck (8). So the review protocol is that step rebuilt as infrastructure. A way to verify and ship huge volumes of agent output cheaply and reliably, without bottlenecking on a single person. Review as a protocol, not a meeting.
  • A surface to collaborate. The layer on top, where the other two, and every other step, become visible and manageable. The why, the what, the how, the when, the who, the result, and the preview, all in one place, where anyone can act on any part of it. A strong example of this is a favorite company of ours, Lightsprint (6). It is where the brain, the agents, and the humans actually meet, and it is the only one of the three that a designer, a PM, and an engineer can all stand on at once.

Conclusion

There is a lot left to build, and even more to retrofit. We are already seeing automated verification gates rush to solve the review bottleneck, while memory agents and context engines race to feed the agent brain. The surface remains a critical missing piece. We need a unified workspace that pulls the entire lifecycle, from initial intent to final code, into one visible, manageable space.

The old empire fell because it stood on an assumption that no longer holds: that building is slow and expensive. But we do not have to live in the rubble. Roles haven't vanished; they have simply moved up a level, shifting from manual execution to strategic judgment. Everyone can build fast now. The teams that win will be the ones who can stand on the same surface and build fast together without losing the thread.

PS, I would love any and all feedback on how people are tackling these problems!

Sources

  1. Block's Goose handles ~90% of code submissions — VentureBeat; Gradient Flow.
  2. Dorsey & Botha on replacing the roadmap with a world model — Block, "From Hierarchy to Intelligence"; Fortune.
  3. Meta's DevMate agents submit ~half of code changes — LinearB.
  4. Meta target of 65% of engineers writing 75%+ of code via AI (H1 2026) — People Matters.
  5. Claude writes 80%+ of Anthropic's merged production code — VentureBeat; Tom's Hardware.
  6. Lightsprint, AI-native product platform (YC P26) — lightsprint.ai; Y Combinator.
  7. Zendesk's "absorption capacity" — InfoQ.
  8. Anthropic rolls out code review for Claude Code — VentureBeat.