Like the Greeks besieging Troy, designers have snuck into GitHub and GitLab. Armed with AI coding tools, they can now open substantial pull requests, ship design improvements and fix the bugs that never quite make it onto an engineering roadmap.
The design handoff wall has been breached. But another wall stands immediately behind it: code review.
Until recently, implementation capacity was the constraint. A designer could identify a problem and propose a solution, but turning that solution into working software required an engineer. The idea had to be explained, prioritised and translated from a design file into code.
Now the designer can arrive with the code already written. That sounds like the end of the bottleneck, but in practice it moves the bottleneck downstream. Engineers who once received design requests now receive pull requests, often containing unfamiliar patterns, generated code and consequences that are not obvious from the interface.
The work has shifted from implementation to verification.
A reviewer has to establish whether the change can break another journey, whether it uses existing components correctly, whether it is accessible and whether it will behave sensibly with real data. They also need to decide if anyone will understand the code six months from now—and whether the solution is proportionate to the problem in the first place.
If every designer-authored change requires an engineer to inspect every line, reconstruct its reasoning and test every edge case, the handoff has not disappeared. It has simply moved from the beginning of implementation to the end.
That is a problem because code generation scales more easily than expert attention. AI will allow designers, product managers, researchers and support teams to produce credible changes far faster than engineers can evaluate them manually. Adding more reviewers will not resolve that imbalance.
The answer is not to review more quickly. It is to reduce how much human review each change requires.
From reviewing code to reviewing evidence
A pull request should not arrive as a pile of changed files accompanied by the question, “Does this look safe?” It should arrive with evidence that makes the answer easier to reach.
The intended behaviour should be clear. The important states should be visible in a working preview. Automated tests should confirm that existing behaviour still works. Visual comparisons should show what changed across screen sizes. Accessibility, performance and security checks should run without being requested. The pull request should identify which parts of the product could be affected and demonstrate that the change can be reversed safely.
Much of this evidence can be generated automatically. Once it is, the reviewer is no longer forced to reconstruct the change from its implementation. They can focus on the decisions that genuinely require judgment: whether the experience is coherent, whether the trade-offs are sensible and whether the change belongs in the product.
This also means abandoning the idea that every pull request deserves the same degree of scrutiny. Correcting copy in an isolated component is not equivalent to changing authentication. Adjusting spacing is not equivalent to altering how customer data is stored. Yet many teams still push both through roughly the same process.
Review should expand or contract according to risk.
“Review should expand or contract according to risk.”
A low-risk change that stays within established components, passes automated checks and affects a limited surface area should need little intervention. Over time, some of these changes may not require human approval at all. A medium-risk change might need a domain owner to review its behaviour and fit with the wider product. Changes involving security, payments, permissions, data or core architecture should continue to receive deep engineering scrutiny.
The aim is not to make review less rigorous. It is to apply rigour where it creates value, rather than distributing it evenly as ceremony.
Building systems that can be trusted
This turns the design system into more than a collection of reusable interface elements. It becomes part of the product’s safety infrastructure.
A mature design system constrains the space in which mistakes can occur. Its components already encode accessibility, responsive behaviour and established interaction patterns. Its documentation helps both people and AI agents select those components correctly. Its tests preserve those decisions as the product changes.
The more work that can be expressed through trusted primitives, the less original code a reviewer needs to inspect. Designers do not need to become full-stack engineers before they can contribute safely; they need an environment in which the safe path is clear and departures from it are conspicuous.
Engineering remains central to creating that environment, but its leverage moves upstream. Instead of manually inspecting an endless queue of generated changes, engineers can build the guardrails that assess them: automated tests, visual comparisons, architectural rules, preview environments and clear boundaries around sensitive areas.
One reliable test can answer the same review question hundreds of times. One well-designed constraint can prevent an entire category of mistake. The useful question for engineering teams becomes: which judgments genuinely need a person, and which are we repeatedly making by hand because we have not yet encoded them?
The pull request itself will also need to evolve. Today it is organised around lines of code because writing those lines was once the scarce part of the work. When code becomes abundant, the review interface should instead be organised around intent, behaviour and risk.
What changed for the user? Which scenarios were tested? What else could be affected? Where is human judgment required?
A future pull request may look less like a highlighted diff and more like a structured case for shipping: a working preview, visual evidence, test results, risk signals and a concise explanation of the decision being made. The diff will still matter, but it will no longer always be the most useful place to begin.
Designers entering the repository is therefore not the end of the handoff problem. It reveals the next form of it. The challenge is no longer simply enabling more people to write production code. It is creating systems that allow an organisation to trust more of the code they produce.
If we fail, engineering teams will become review departments, guarding ever-growing queues of machine-generated changes. If we succeed, review will become smaller, smarter and proportionate to risk. Routine assurance will be automated, while human attention is reserved for architecture, consequences and judgment.
The first wall fell when designers learned to make the change. The next one falls when we learn how to verify it.