Beyond the Handoff: How AI Is Connecting Design and Engineering

For years, large product programmes protected engineering schedules by starting design months earlier.

Design ran ahead. We clarified requirements, mapped flows, drew screens, wrote specifications, and packed everything up for development. Only then did engineering start. On some projects, the gap between those two starts was six months.

It was easy to understand: design made the plan, engineering built the product. But it rested on a fragile idea: that design had to be translated from one file into another at one fixed moment. Almost no one defends it. In a 2025 Figma survey, 91% of developers and 92% of designers said handoff could be better.

That assumption is disappearing. AI makes it faster to produce interfaces, but speed is not the main change. The bigger change is that design decisions no longer have to live only as pictures. Colours, spacing, components, texts, and rules can be stored in a form that both people and AI tools can read and use. Handoff is fading not because designers work faster. It is fading because what we hand over is no longer a finished file.

And the people are rarely the problem. Designers, developers, and product managers are usually good at their jobs. What slows them down is where the work lives: designers work in Figma files, product managers on boards and in prototypes on their own laptops, developers in code. Each place makes sense on its own. Together they create several versions of the same product.

“

The replacement for handoff is not less discipline. It is continuous work in one shared system.

The hidden cost of handoff

A handoff can look efficient from a distance. One team finishes, another begins, and every stage has a clear owner. Up close, the model creates four kinds of cost. The first is waiting. A developer finds a question, but the designer has already moved on to another feature. A missing state becomes a ticket. A small text change waits for the design file to be updated. The change itself takes minutes; the queue around it takes days.

It adds up. According to Design Systems Collective, developers spend about 4.5 hours a week just clarifying design questions. The second is translation. A screen shows the result, but rarely the reasoning behind it. It doesn't show the options we rejected, the business rule behind the layout, or the edge case that changed the interaction. By the time the work reaches development, most of that context has been squeezed into comments and ticket descriptions.

The third is catching up. The real product brings things the design file never had: real data, long names, slow loading, errors, different screen sizes, technical limits. Design and product start to drift apart, and the team spends time working out which version is the current one. Nielsen Norman Group estimates that rework after handoff takes 15–30% of development time.

The fourth cost is newer, and AI has made it worse: fragmentation. Anyone can now build a working prototype in an afternoon. A product manager builds an idea with an AI tool on their own laptop, improves it over a few days, and sends a designer a file with “a few changes.” The designer adjusts their own copy. A developer rebuilds the good parts from a screen recording. A week later, the team has five versions of the same prototype, and none of them is the product.

“

The problem is not that people are not skilled enough. It is that everyone is skilled in a different copy.

This is why a better checklist rarely fixes handoff. A more detailed specification reduces confusion, but the setup stays the same: one team tries to predict everything before the other team starts learning. The visible output of handoff is a set of approved screens. The invisible output is a queue of future clarifications.

What actually changed

Teams have tried to fix this before: shared chats, earlier reviews, component libraries.

“

“Code is not the opposite of design. Code is material for design.”

What is different now is that design and code are starting to be truly connected, not just talking to each other.

Design decisions can travel as data

Take a colour. It no longer has to be copied by hand from Figma into code. It can be defined once, given a name, and used everywhere: on the website, in the iOS app, in the Android app. Designers don't need to know how this works under the hood; the tools and developers take care of that. What matters is the idea: one decision, made once, reaches every place where it is used. When that happens, the design system stops being a library that describes the product. It becomes part of how the product is built.

Agents can work inside the design environment

AI agents can now work directly in Figma. They don't just look at a screenshot: they create and edit real frames, use the team's components, and follow its spacing and naming rules. The result is not automatically right. AI can give different answers to the same request. But what it produces is real design work that a designer can open, check, and fix, not a flat picture you can only accept or reject.

The loop now works in both directions

It works the other way too. A working interface can be brought back into Figma as editable frames. The team can compare, comment, try alternatives, and send the chosen direction back into development. This is no longer a forecast. In February 2026, Figma and Anthropic announced a partnership built around exactly this two-way path between code and canvas.

It is not perfect sync, and it's better not to promise that. But there are fewer dead ends: work can start in code, move to Figma when you need to explore, and come back once the direction is clear.

The tools will change quickly. What stays is this: code and Figma are becoming two views of the same product.

Designers can change the product source directly

This is the part that changed my own work the most. With Claude connected to GitHub (where the product's code lives) I can ask for a change to the design system or the interface and have it made directly in the product: a colour, a new button state, a spacing fix. I don't redraw it in Figma and wait for someone to rebuild it. And no, it does not go straight to users. The change arrives as a separate version with a preview link. Developers review it, and someone decides when to publish it. I don't read code, and I don't need to; reviewing the code stays with developers. But my work starts in the real product, not in my own copy of it.

Prototypes can live there too. A prototype saved in the shared project, with a link, can be opened, commented on, and continued by the whole team. A prototype on someone's laptop can only be forwarded.

The shift is not that everyone writes code

It's tempting to conclude that everyone now has to learn developer tools and work the way engineers do. That would confuse a shared source of truth with a shared interface. Developer tools are great for developers. They are not a good place to explore a layout, compare visual directions, or see a whole flow at once. And a designer doesn't have to learn them: the AI agent takes care of the technical steps, while the designer keeps working in Figma and in conversation. The goal is not to make every role work in the same tool.

“

Everyone works against the same source of truth. Nobody has to work through the same interface.

A designer works in Figma and through an AI agent. A developer works in code. A product manager builds prototypes in the shared project and updates texts in the place the product actually uses. Everyone keeps the tool that suits their work, while colours, components, texts, and decisions stay connected. No one has to learn a new profession. The team simply stops waiting for another person to translate every small piece of intent.

The strongest objection to unification

Not everyone agrees that unification is the goal. Karri Saarinen, who helped build Airbnb's design system and now runs Linear, agrees that handoff loses information along the way:

“

“Handoffs are lossy.”

But he also warns that full unification has a shadow side. His argument goes like this. Shared systems raise the floor. They make consistency easier, save the team from making the same decisions again, and help both people and AI produce work that fits the product. But they can also quietly lower the ceiling, if the easiest path is always the most ordinary one. When every new screen is built from the same pieces, habit starts to shape the product. A component made to keep things consistent becomes a reason not to try a better interaction. A rule written to keep AI predictable replaces judgement.

He is right, and it sharpens the case for one source of truth rather than weakening it. It clarifies what should be unified.

Unify what has to stay consistent: colours and type, components, texts, accessibility rules. Don't unify the way people think, explore, and question the system. So a healthy design system needs room to break out. Teams should be able to test a new pattern before turning it into a component. Designers should be able to explore outside the library. Developers should be able to ask whether a shared component still fits the product. A shared system is infrastructure for good decisions. The moment it decides what is worth attempting, it has become a constraint on the product itself.

What one small change looks like

Consider a product manager reviewing the empty state on a reports screen. The page tells users that no reports exist, but not why, what data is required, or what they should do next. In the old model, this can create a surprisingly long chain: a product ticket, a design request, an updated frame, a handoff note, sprint planning, implementation, design review, and a final correction when the real text does not fit. In a connected model, the work can move differently.

First, the product manager rewrites the message right where the product takes its texts from, not in a local prototype that someone will have to copy later. The new text explains what is missing and what to do next. Second, the designer looks at the real screen and sees that the current component doesn't fit the new text. They ask an AI agent to update it using the design system. The result uses the same spacing and type, covers the states it needs, and arrives as a change others can review.

Third, the developer checks the change instead of rebuilding the design from a screenshot. They fix what the agent missed and make sure the screen behaves well while loading, without access, or when something fails. Finally, the team validates the change in the product, with real content and real constraints.

The decisions did not disappear. Neither did accountability. What disappeared were several waits between people who already understood the same problem.

Who owns what

Shared access only works when everyone still knows who is responsible for what.

The agent is deliberately absent from the table because it owns nothing. An agent can repeat a known pattern quickly. It can create variants, update repeated elements, apply the design system, and spot inconsistencies. It can't be responsible for whether the team picked the right problem, whether the layout reflects what users need, or whether the result is safe to release. An agent may produce a visually correct settings screen without understanding which settings belong there, what order they should appear in, or which defaults could harm the user.

“

“The agent handles production; you handle product thinking.”

What breaks when teams implement this badly

Review becomes theatre

If changes that come from design get approved automatically because they are “only visual,” the product quietly gets worse on the inside. Messy fixes and inconsistent components still cost the team later, no matter who or what made them. A faster way to contribute needs a real review. Reviewing the code stays with developers: it can be light, but it can't be a formality.

Accessibility regresses invisibly

A generated screen can look right and still fail people who use a keyboard or a screen reader: the wrong focus order, missing labels, poor contrast in some states, too much motion. And accessibility often comes in late: according to Level Access, only 27% of organisations deal with it at the design stage. AI doesn't invent new problems. It scales the quality standard the team already has. If accessibility is built into components and reviews, AI helps apply it everywhere. If it is a checklist someone opens before release, the team will simply make inaccessible screens faster.

Figma and code drift apart

Many teams say they have one source of truth, but keep one set of colours in Figma and another in code. The names match, but every change depends on someone remembering to update both. It is common. In a 2026 review of design systems, 84% of teams said they use shared design values, yet many of them still keep two separate sets.

That is not one source of truth. It is two sources with a naming agreement. It only works when each decision is defined in one place and everything else takes it from there. Checking for mismatches should happen all the time, not in a clean-up project twice a year.

Speed replaces thinking

When producing an option becomes cheap, teams can mistake the number of options for progress. Ten generated directions do not reduce uncertainty if no one can explain the decision between them. Speed helps when it gets you to evidence sooner: a prototype tested earlier, a limitation found sooner, an edge case checked before release. It creates noise when the team simply produces more. The purpose of the new workflow is not to maximize output. It is to reduce the time between a question and a responsible decision.

Local copies creep back

The most common failure is quiet. The shared source exists, but the habit of working locally does not change. Someone prototypes “just quickly” on their laptop, a designer keeps a private file “until it is ready,” and within a month the team is reconciling copies again. One source of truth is not a tool decision. It is a working agreement: if it is not in the shared source, it does not exist yet.

Where to start

Do not start with agents. Start by deciding where the product lives.

1. Name the one source

Agree on one place where the product lives: usually the product's code and the design system inside it. Figma, boards, and prototypes stay useful, but they take from that place and bring changes back to it instead of competing with it.

2. Move prototypes off laptops

Every prototype worth showing lives in the shared project and has a link. No more zip files, “it works on my laptop,” or “I'll send you my version.” If the team can't open it, it isn't ready to discuss.

3. Connect each role's tool to that source

Designers work in Figma and through an AI agent connected to the product. Product managers work in shared prototypes and in the place where texts live. Developers work in code. Different doors, one room.

4. Keep versions and releases explicit

Every change arrives as a separate version that someone can review, and publishing stays a conscious step with a clear owner. A shared place without review isn't collaboration: it's a shared mess. Only then scale agents. An agent working in one clean source multiplies the team's leverage. An agent working across five copies multiplies the confusion.

One source, everyone in it

The handoff was never really about slow designers or impatient developers. It was a workaround for a time when design, product, and code could not live in the same place. That time is ending. Figma, the board, the prototype, and the code can now connect to one place. What remains is the harder part: agreeing to stop keeping private copies. Five versions of the same prototype are not a sign of a productive team. They are a sign of a team without a shared place to work.

“

Stop passing the product around. Work on it together, in one place.

If your team wants to bring design, product, and code into one shared place with AI, let's talk.