The cost of writing code dropped while the cost of handoffs stayed the same. See how teams are closing the gap by bringing every role into the code.
AI is making the cost of generating code trend toward zero. Features that used to take a sprint can happen in an afternoon, and bugs and updates that sat in the backlog for months cost cents to fix. The economics of writing software have shifted dramatically over the last couple of years.
The way most teams work has not changed with them. Look at how a typical product organization is structured: weeks of planning to decide what's worth building, a sprint to build it, another to test it, another to ship it. That whole rhythm was designed around the assumption that code is expensive, so you spend most of your time deciding what's worth coding before you actually code it. The assumption stopped being true a while ago, and the rhythm built around it is still running.
You can see the results by taking an inventory of your backlog. There are features customers have asked for a dozen times, bugs everyone knows about, and polished work that never makes the sprint. The gap between what your team should be shipping and what it actually ships keeps widening, even as coding speeds up.
The standard software development workflow is over 25 years old, and it predates AI by decades. You know the shape of it: idea, spec, design, prototype, code, review, ship. Each step hands off to the next, and each handoff is a translation between tools and between teams. The translation is where the work loses its shape, and it is also where most of the time goes.
Spec gets translated into design, design into prototype, prototype into code, and every translation along the way loses some of the original intent. The friction is so familiar that the language teams use to describe it has become a script. You have probably said one of these in a review:
"That's not what I meant."
"That's not how it was designed."
"That doesn't work in our application."
So the team loops back. They update the spec, rebuild the prototype, rework the code, and start over. Week after week.
What most teams have done with AI is layer it on top of this same workflow. Designers reach for Figma Make, PMs spin up something in v0, and engineers run Cursor or Claude Code. Each function gets faster in isolation, and the choreography between them stays exactly as it was. The translation problem persists, with agents now handling some steps in between, and the handoffs remain where things go wrong.
A technical objection comes up here, especially from architects: doesn't MCP solve this? Connect the tools, share the context, and you're done. The answer is that MCP accelerates the handoff itself, which is helpful, and the translation problem is something different.
A developer, with their own context and intent, is still trying to verify whether what was built matches what was originally intended, and they're doing that work in a separate environment from where the original work was done. Stitching better connectors between isolated tools has limits because the tools remain isolated.
Imagine a workflow where the team starts together. A PM has an idea and tells an agent what the experience should be, and the agent builds it using your real codebase, components, design system, and coding standards. A designer opens the same project and refines it directly. When an engineer steps in, they pick up a project that already carries context from every role that has touched it. The work has been moving forward in one place, in code, the whole time.
Code is the canvas. When the whole team builds on it together, the product meant to be built is the one that gets built.
The shift sounds abstract until you look at what it changes for each role. The work each person does, and the artifacts they hand off, look meaningfully different when code becomes the starting point for the whole team:
| Role | What they do in a code-first workflow |
|---|---|
PM | Describes the experience to an agent and gets a working first draft on the real codebase, then validates it directly with stakeholders or customers |
Designer | Refines the live implementation with full pixel-level control over spacing, typography, components, and interactions |
Engineer | Reviews and merges code that already uses real components and follows team patterns, with time freed up for architecture and harder problems |
QA | Validates in a real preview environment before merge, catching bugs at the source while the work is still in progress |
Code as the canvas is the principle. Building it into a workflow your team can actually run is a different problem, and the rest of this post walks through how Builder approaches each piece, from where work starts, to how it moves through the team, to how it gets validated and shipped.
The work begins wherever the idea lives, whether that's a Jira ticket, a Slack thread, a customer support escalation, or a problem someone spotted on the live site. The Builder agent picks it up, takes a first pass, and because it is connected to your codebase and design system, what it builds uses your real components, patterns, and tech stack.
That matters because most ideas die in the gap between where they show up and where the work happens. By the time a Slack thread becomes a ticket, becomes a sprint item, becomes a design, the original spark is buried. Builder connects to the tools your team already works in, so that gap closes:
- A marketer who notices something off on the live site clicks the Chrome extension and starts a fix on the spot.
- A designer who gets a request in Slack tags Builder in the thread, and it reads the context and builds a first pass.
- A PM who files a ticket in Jira assigns it to Builder, and it picks up the work directly.
The real measure of an agent is how far along the work is when your team picks it up. The closer the first draft is to something your team can actually ship from, the more time the agent has saved you. That depends on whether the draft is built from your real components and patterns, because that's what determines whether the team can refine it or has to rebuild it.
Builder builds with the components your team already uses, in the patterns they already follow, and it pulls in the context that shapes the work: Figma designs, PRDs, product specs. The agent knows your code, what you are trying to build, and why, so the team spends its time refining the concept while the agent handles the mechanical work of putting it together.
From there, the team takes over. Product, design, and engineering iterate on the same branch, each in their preferred environment.
The most expensive part of building software these days is the feedback loop around the code, where a designer reviews a screenshot and files a comment, a PM reads a spec and flags a misunderstanding, a developer gets a PR and rewrites half of it, and each round costs the team days.
Builder collapses that loop by giving every collaborator a link to the live implementation. A designer adjusts spacing in the style tab, a PM tests a user flow and has the agent resolve a logic gap, and an engineer reviews the diff in the code tab and makes changes directly. Everyone works on the same thing, at the same time, in the way they prefer, and feedback happens on what is actually going to ship.
Collaboration has to work for every role, and developers are the role most likely to push back on a new tool. They live in their IDE for good reason, and asking them to leave it for review or refinement work is how adoption stalls. Builder is built so they can stay there.
The branch the team has been working on syncs directly into Cursor or VS Code. A developer pulls it, reviews the diff, makes changes, and pushes them back to the same branch the team is using. Builder's MCP connects the platform to Claude Code and Cursor, so whatever the team is building in Builder (a prototype, a page, a component), the developer can pull it into their IDE and work with it as code. When they push changes back, the team picks up where they left off. The two environments remain linked, and no one has to switch contexts to participate.
Code-as-a-shared-canvas changes how the team builds together. It also changes what's possible at the validation step, which is the part of the process that tends to get the least attention and produces the most expensive mistakes when it goes wrong.
The step most teams skip is the one that matters most: getting real feedback before shipping. Teams skip it because every way to get it adds friction. Screenshots get marked up with notes that no one can act on. Prototypes built outside the codebase lack the fidelity to surface real issues. So validation gets dropped, and the team hopes for the best.
Builder changes the cost of validation. You send a preview URL with no account required, no staging environment to spin up, just a link. What the recipient sees is the real implementation, built from your design system, and they can interact with it, leave feedback, and have the team resolve it on the spot. Put it in front of a customer, and the feedback you get is specific: what broke, what confused them, what they would change. When validation is this easy, teams stop skipping it.
The faster teams move, the more leadership worries about what slips through. New tools and new contributors generate AI code at volumes nobody is quite sure how to police, and the question is always the same: how do we know this is safe to ship? The answer cannot be "trust the team" alone. It has to be built into the workflow.
Builder's approval workflows require the right people to sign off before a PR is submitted. The QA Agent validates the implementation in a real browser, writes test cases, and posts a video walkthrough. The Code Review Agent checks every PR and flags issues by severity. Your team has already defined what good code looks like, with linting rules, formatting standards, test suites, accessibility checks, and Builder follows all of it. The code that comes out is held to the same quality bar your team set before Builder was introduced.
On the trust side, Builder is SOC 2 Type 2 compliant, we don't train on your data, and you own your inputs and outputs. We work with Fortune 500 companies that hold us to their standards.
Change like this doesn't happen overnight, and it doesn't have to. Teams usually find their way in through one of a few starting points, and where you begin depends on what your team needs most. Each of these is a low-risk way to test the workflow on real work without committing the whole organization on day one:
| Starting point | Who it's for | What it looks like |
|---|---|---|
Prototyping | Product and design teams validating ideas before engineering invests | Working prototypes built on your real codebase and design system, so what stakeholders review is what actually ships |
Internal tools | Any team with backlog dashboards, trackers, and workflow apps | Apps connected to your APIs and data sources, built without an engineering ticket and without competing for the roadmap |
Software development | Teams shipping bug fixes, UI improvements, and backlog items | Direct changes through the same quality gates as any other code change, with the people closest to the problem shipping the fix |
Most teams pick one of these and grow from there. Prototyping is a common entry point because every team prototypes anyway, and getting prototypes built on the real codebase means the feedback you collect is feedback on what will actually ship. Internal tools work well because the team gets value immediately, with low risk to production systems. Software development is where the long-term payoff lives, and once the team is comfortable with the workflow, this is where most of the throughput gains compound.
Code is cheap to write now, and the teams that have adjusted to that, the ones that treat code as the place where the whole team works together from the start, are the ones closing the gap between what they want to ship and what they actually ship.
Connect your repo and run a prototype, an internal tool, or a backlog item through the workflow yourself. Try Builder for free.