The speed of innovation has become a requirement for most teams. AI tools have enabled faster work than ever, and the companies pulling ahead are the ones figuring out how to make those tools serve their workflows rather than bolt them onto old habits.
The way we stay ahead comes down to the workflow itself: a collaborative coding model where your whole team builds, reviews, and ships alongside AI agents in shared workflows. Here's how that model works and how you can adopt it in phases.
Three shifts have happened over the past two years, and each one builds on the one before. Together, they explain why the old way of working is starting to break down.
Coding agents got better. You can get real work done now without being a prompting expert, because you ask in plain language and get something built. As that happens, the lines between product, engineering, and design start to blur, and people who were never considered developers are becoming first-class builders.
The cost of writing code is trending toward zero. It will never actually hit zero, though the old assumption that code was the slowest and most expensive step no longer holds. You used to front-load everything: meetings, planning, debate, design, more planning, all so that by the time anyone touched code, you wouldn't waste a line. Ideas become code almost immediately now, so you can put real product in people's hands instead of staring at a Google Doc where everyone pictures something different.
People are running agents in parallel. A year or two ago, you still wrote most of the code yourself with a copilot helping here and there. Now you can prompt, sit back, and watch an agent do most of the work. Once one agent can run on its own, you start wondering why you'd run only one, and the answer creates a fresh problem. Human review becomes the bottleneck. You can spawn fifty agents for fifty tasks, and then you have to review all of it. Does it work? Does it look right? Does the button do what it should when you click it? That's where the time goes now, which is part of why developers end up drowning in AI-generated PRs.
You designed your workflows around the idea that code is slow and expensive. You stacked steps in front of coding so you'd never write the wrong thing, and you ended up with a waterfall. Everyone agrees waterfall is bad. Everyone uses it anyway. The reason is that agile only works when the people involved can complete a full cycle in two weeks, which takes people who can design, code, and carry product sense all at once. Those people are rare and hard to hire, so teams fall back on handoffs.
When the workflow already runs on handoffs, inserting AI into it works about as well as building an electric car by swapping out gas parts one at a time. An electric car is a different machine from the ground up. The same goes here: AI is an invitation to redesign the workflow from scratch, because AI alone won't save your development process if the process itself stays the same. That's why organizations spend a fortune on tokens and watch organization-wide delivery stay flat. The work still sits in queues, waiting for the next handoff, exactly as it did before.
The new workflow exists to clear those queues. The shifts add up to a different way of working, one that doesn't fit neatly into the old stages. Five patterns show up again and again once you build around them:
1. Ideas become code instantly, so design and product work move to after the first version. You kick off an agent, get a first draft of working code, and put it in front of people right away. The endless arguing over a PRD that everyone reads differently goes away, because when you can touch a version of the product, the reaction is immediate and visceral. A perfect PRD becomes a perfect design becomes perfectly architected code, ships, and falls flat more often than anyone likes to admit. People find it confusing, or they realize they never wanted it. You want to learn that early, with customer zero being you, then with a handful of close customers on a preview link, well before you build the real thing. This is the heart of the new path from prototype to production.
2. Your whole team collaborates with agents directly, in parallel. Today, the engineer is the middleware. PMs, designers, and QA all hover with feedback, and the engineer juggles agents while translating everyone's notes. That's a poor use of engineering time. When each expert talks directly to the agent, the work moves much faster. Designers refine the pixels they care about. PMs add the customer nuance that the original prompt missed. QA verifies fixes in real time, eliminating the back-and-forth of filing bug lists and waiting. Everyone works in their own loop, between themselves and the agent. That's what happens when agents work for the whole team rather than for one person.
3. Move the work to before the pull request. You spent decades building review workflows around waterfall, and plenty of them should stay: pull request reviews, code review, security checks, and QA. The change is moving the validation earlier. By the time a developer reviews the final PR, design has signed off, the pixels and responsive details are right, QA has verified, and the product has confirmed it matches requirements. The engineer's only job at that point is the code itself: how it looks, how it's structured, how it's architected. We adopted this internally, and our velocity in high-quality, vetted pull requests climbed. The Builder bot is now the top contributor to our codebase, and people are happy about it because every contribution takes work off their plate.
4. Work attaches to wherever it starts: Slack, Jira, product feedback. Leave feedback in Builder, and it lands in a Slack channel, where someone tags the bot to fix it and shares a link to try. You assign it to QA or design from there. Jira tickets work the same way, including the useful tickets that aren't on fire and normally lose every prioritization fight, the ones that pile up as cruft over time. Our sales team uses it too. When a prospect needs a single unblock, the sales engineer asks the bot to draft it and shares the draft with the product team. Sometimes Product ships it, sometimes they pass, and sometimes they take a different approach with a starting point already in hand. Beginning from a rough draft tends to create urgency to get the good version out.
5. The first version matters least. Versions two through one hundred matter most. The first version is an idea waiting for validation. What ships are the product of human review, feedback, and craft from every person who touched it? We're trying to bring humans closer to AI. When everyone lets agents run on their own for days, everyone ends up with the same product. AI is genuinely bad at judging whether an experience feels right to a human, so the craft your team puts in becomes your differentiation.
You don't have to change everything tomorrow, because there's a maturity curve you can climb one rung at a time.
Start with conceptual prototyping: a simple prototype repo that mirrors production and your design system. You prototype rapidly with no connection to production code, then use the MCP to turn it into production code when you're ready.
The next rung is code-based prototyping, where you prototype in your own code, with your design system and the same React components from npm that you run in production. You get higher fidelity, the same guardrails, and a jump to production that comes down to mostly copy-and-paste.
The top rung is production code editing, connected to the real repos. It's the fastest, and it's there for you when you're ready.
A few recommendations: Take the rungs one at a time. Start with a small team that likes getting its hands dirty, find the workflows that fit your company, and grow from there. And whatever you do, hold the line at the pull request and beyond. Humans always review the code. Security reviews, code reviews, and AI reviews all stay exactly as they are.
The goal is to deliver good-quality code faster, with your team's craft at every step.
