# What a team loses when designers ship their own code

By Bart Dunweg, Oct 13, 2026 · 6 min read

Designers can now take their own work live, and the speed is real. So is the loss: a second reader, an engineer's objections, and code that more than one person owns.

When a designer puts their own work live, straight into the product people use, the team does not lose its engineer. It loses the things the engineer used to do without anyone asking: read the design closely enough to build it, object when something would be slow, notice the state nobody drew, and own the result afterwards. Those were never on a process diagram, so nobody plans to replace them, and they disappear the first time a designer approves and publishes their own code.

This is no longer a thought experiment. The [AI in Design report from Designer Fund and Foundation Capital](https://stateofaidesign.com/chapters/craft), based on a survey fielded in the first quarter of 2026, found that half of its respondents had shipped AI-generated code to a live product. The same chapter reports that 20 percent said collaboration had decreased, against 5 percent the year before. The report does not claim one causes the other, and I will not either. But I read the two numbers next to each other, because from where I sit they describe the same afternoon.

This is not an argument for or against designers shipping. It is an inventory of what goes missing when they do, and what has to be put back by hand.

## The review nobody scheduled

Implementation is the most thorough reading a design ever gets. A reviewer looks at a screen for ten minutes. An engineer building it has to decide what happens on every path through it, in every state, with every shape the data can arrive in. That is a review, even though nobody calls it one and nobody books a room for it.

I have [written before](https://bartdunweg.com/articles/the-handoff-is-not-a-document) about why the handoff works better as a conversation than as a document. The point here is narrower. Whatever form the handoff took, it guaranteed one thing: a second person had to understand the work well enough to make it run. When the designer ships, that guarantee is gone. The first reader of the code is the agent that wrote it. The second reader is the user.

### "This will be slow"

The objections an engineer raises during a build are easy to resent and hard to replace. This page asks the database once for every row. This image is four megabytes. This list has no empty state, and most accounts will see it empty. This screen assumes the money has arrived, and it has not.

Those arrive as friction, which is exactly why they work. An agent asked to build a screen builds the screen, including the parts that should not have been asked for. It will not tell you the brief was the problem, because the brief is the only thing it was given. [Performance is decided in the design file](https://bartdunweg.com/articles/performance-is-a-design-decision) long before anyone measures it, and the engineer's "this will be slow" was the moment a team found out what the file had decided.

### Code with one owner

The third loss is the least visible. When an engineer builds a feature, the engineering team knows it exists, knows roughly how it works, and can fix it when it breaks. When a designer ships it alone, the code has exactly one person who understands it, and that person is usually the one least likely to get the call when it breaks at night.

On a product of your own this is fine. You are the only owner and the only person who gets woken up, so the arrangement is honest. In a team it is not fine, because the code joins a product that other people maintain, under a rota for night-time problems that does not include the person who wrote it. A feature nobody else understands is a small debt with interest, and the bill arrives at the worst moment, sent to someone who never agreed to it.

## What the team gains

It would be easy to stop there and call it a warning. That would be dishonest, because the gains are real.

The gap between intent and result shrinks to nothing for the parts a designer builds. The spacing is the spacing that was meant. The empty state says what it was supposed to say, because the person who wrote it is the person who knew why. Most of the small disagreements that used to be filed as defects never happen, because there was no translation to get wrong.

The designer learns the material. Building states teaches you what states exist. Connecting a form to the system behind it teaches you what that system cannot do. That knowledge comes back into every design afterwards, including the ones someone else builds.

And engineers get time back from work that was mostly copying a design into code, which they can spend on the problems only they can solve.

## What has to be put back on purpose

The losses are specific, so the repairs can be too. These are the ones worth holding to, in a team and, where they apply, alone.

### A reader who is not the author

Every change a designer ships gets read by an engineer before it goes live. Not for style, and not as a gate on the designer's competence, but with three questions: what happens when this is slow, what happens when this is empty, and who gets called when it breaks. My coding agents work against [a written set of standards](https://bartdunweg.com/articles/the-standards-i-give-my-coding-agents), and those catch a lot. But a standard only checks for what I already thought of. A colleague checks for what I did not.

### An owner named before it goes live, not after the incident

Decide who owns the code once it lands. If the answer is the designer, say so, put them on the rota, and accept what that means. If the answer is the engineering team, they have to have read it, which brings you back to the first repair.

### Into the system, never beside it

A designer's code uses the team's building blocks, the team's tests and the team's way of releasing. Code that lives next to the system rather than inside it is a copy that has quietly gone its own way, and it will be noticed by whoever has to move it later.

### The conversation the handoff used to force

The handoff, whatever its faults, made two people talk. Shipping it yourself removes the obligation, not the need. If collaboration is falling, as that survey suggests it is for a fifth of its respondents, it is falling because nothing forces it any more. So something has to: a standing review, a pairing hour, a channel where sharing half-built work is normal.

### A line around what you ship alone

Some surfaces are cheap to get wrong and some are not. A layout change on a side project is the first kind: if it breaks, you fix it and nobody loses anything. Anything that moves money is the second kind, and the state a designer forgets on that surface is someone's rent. Knowing which side of that line a change sits on is part of the job, and it is a judgment to make before the code exists, not after it ships.

## The work was never the only thing being handed over

The handoff looked like a transfer of files. It was also the moment someone else had to understand your work well enough to be responsible for it. A designer who ships no longer needs anyone to do that. A team still does.