Your designers are designing faster. Your developers are coding faster. But delivery timelines haven't moved.
Engineering leaders have invested in AI tools. Their teams are using them. Individual productivity is up. And somehow, the sprint is still two weeks, the backlog is still growing, and releases are still measured in months.
The problem isn't the tools; it’s the workflow around them.
The entire modern software development lifecycle was designed around one assumption: code is expensive and slow. Every habit that followed made sense: design before building, specs before coding, stakeholder alignment before a developer writes a single line.
So teams built processes to do exactly that: detailed specs, high-fidelity mockups, full alignment before work reached engineering. The idea was to front-load all the thinking so that by the time you got to code, nothing needed to change.
That assumption no longer holds. AI systems generate working code in seconds. The step that used to limit everything now moves faster than everything around it. But most teams changed almost nothing. They inserted AI into the coding phase and left the surrounding process intact.
You sped up one step in a ten-step workflow. The other nine didn't move.
Think about what happens between the idea and the shipped code: a spec becomes a design, a design becomes a prototype, a prototype becomes a ticket, a ticket becomes code. Every step is a translation, and every translation loses something.
"That's not what I meant." "That doesn't match our design system." "That doesn't work with our API." So you loop back. Update the spec, rebuild the prototype, rework the code. Week after week.
The real cost is the waiting. A designer files a redline, it sits in a queue, an engineer interprets it and gets it mostly right, the designer reviews and files another note, and the cycle starts over. What should take a day takes two weeks.
Everyone is optimizing their own step. The workflow itself goes unexamined.
AI coding tools made coding faster. AI app builders made prototyping faster. Both sped up one group while leaving the handoffs intact. The broader organization isn't moving faster because every handoff between steps is still there.
When engineering leaders tell us their team is at capacity, the first instinct is usually to hire. More engineers mean more throughput.
But look at where the capacity actually goes. The biggest backlog on most product teams isn't complex architecture work or systems redesigns. It's frontend tickets: spacing changes, component updates, new page variants, interaction tweaks, copy updates. Work that requires a developer today, but doesn't have to.
This work lands in engineering queues because engineers are the only people with access to the codebase, not because they're the right people to do it. A designer knows exactly how a component should look. A PM knows exactly what the flow should do. But neither can touch the code, so they file a ticket and wait.
The engineer who picks it up has to interpret the request, match it to the design, implement it, get it reviewed, and ship it. For a spacing change. That cycle is the bottleneck, and hiring more engineers just means you have more people processing the same broken loop.
The teams shipping in days instead of weeks didn't just reduce wait time — they eliminated the handoff.
When a designer can make a spacing update directly in the codebase, there's no need for a ticket. When a PM can spin up a working prototype using your actual components, there's no throwaway Figma file that engineers rebuild from scratch. When QA can describe a bug and verify the fix without filing a report or waiting for a sprint, the feedback loop closes in hours rather than weeks.
Giving non-technical team members access to the codebase sounds risky. It isn't, if the right conditions are in place.
The AI has to know your system. Not generic code generation, but output that uses your actual design system, your component library, your coding patterns. Generic AI tools generate plausible-looking code that doesn't use your real components and needs rewriting before it can ship. You haven't saved anyone time. You've created more review work. The AI needs deep context into your codebase for the output to be meaningful.
Everyone needs to work in the same environment. Designers, PMs, engineers, and QA are looking at the same branch, the same implementation, the same source of truth. Everyone sees the real product, not an approximation.
When everyone is working on the same codebase, feedback is about the real product.
Guardrails have to be built in. Every change goes through review and approval workflows before a PR is submitted. Design lead, product lead, QA lead, whoever needs to sign off can do so before the code ever reaches an engineer. Nothing reaches the codebase without passing the quality gates your team sets. Engineers still have a final review. Nothing merges without their approval. The difference is that by the time they see a PR, it's already been validated by everyone else who has a stake in it.
When those three conditions are in place, the workflow changes entirely:
- Engineers focus on architecture and complex problems
- Product validates ideas directly with customers
- Design ships component updates without filing tickets
- The front-end backlog stops being an engineering problem
A PM has an idea for a new onboarding flow. In the current model, they write a spec, hand it to design, wait for mockups, hand it to engineering, wait for implementation, review it, file feedback, wait for revisions. Six weeks later, they have something to test with users.
In an AI-native workflow, the cycle looks like this:
- The PM describes what they want, and an agent generates a working version using the real component library.
- The PM reviews it in a live preview, makes visual adjustments, and sends it to a designer for refinement.
- The designer tweaks it in the same environment, and QA validates it.
- By the time it reaches an engineer, everyone has already signed off. They review the code, approve it, and merge.
The whole cycle took days. That's what happens when the whole team can work in the codebase, not just file tickets into it.
The same pattern applies to smaller work. In a traditional workflow, a designer updating a button component and a QA engineer finding a layout issue in production both create tickets. With a shared codebase and review built in, each person can make the change themselves and ship it without pulling an engineer away from other work.
Most engineering leaders we talk to are focused on making their engineers faster. The more useful question is which work actually requires engineering judgment.
The teams moving fastest restructured who can contribute to production and where review actually happens, not just how fast their developers work.
AI made coding fast. The bottleneck now is everything around it: the handoffs, the queues, the waiting.
The tools your team is already using are fast. The question is whether the workflow around them is.
Builder connects your entire team to the real codebase. Every change moves through structured review before engineering sees it, nothing merges without passing your quality gates, and the handoffs that were slowing you down disappear. If your tools are fast and your delivery isn't, the workflow is the problem.
We built Builder because we had the same problem. The tools were fast, but the workflow wasn't. Fixing that changed how the entire team builds.
Builder.io visually edits code, uses your design system, and sends pull requests.
Builder.io visually edits code, uses your design system, and sends pull requests.
Connect a Repo
