What a Designer Does When the Code Writes Itself

For most of my career the fidelity ladder was a fact of life. Sketch, low fidelity wireframe, mid fidelity with annotations, high fidelity with the client's brand, interactive prototype, then a handoff document and a wait while engineering built something close to it. Each rung existed because the next one was expensive. You did not build a high fidelity screen until the low fidelity one had settled the structure, because rework at high fidelity cost days.

That ladder has partly collapsed. This year I have designed and shipped an owner console, a two-sided marketplace with seller and buyer dashboards, and a personalised insurance portal, and in each case the prototype was the product. I sketch, I write the flow, and then I build it in code with AI tooling, in the actual repository, with the actual data model. The gap between what was designed and what shipped is zero, because they are the same file.

Wireframes are not dead

I still draw wireframes, and I still start low. The reason is not cost any more; it is attention. A low fidelity frame forces a conversation about structure, priority and flow before anyone is distracted by colour. When the seller dashboard for the marketplace was a grey box with three regions, the argument was about what a seller needs first thing in the morning: active listings, pending pickups, payouts. Once it had a brand on it the argument would have been about the brand. Fidelity is a tool for controlling what people look at, and that has not changed.

What has changed is what happens after the wireframe. Instead of a mid fidelity and a high fidelity and a redline document, there is a working screen, with real data, that a person can use. Usability testing happens on the product. The design system is not a Figma library that engineering re-implements; it is tokens that Figma and the codebase both read, and a component that is accessible in the library is accessible on every page that uses it.

What the designer is for

If the code writes itself, the question people ask is what the designer is for. The answer is the same as it always was, with the busywork removed.

The designer decides what to build and, more often, what to leave out. The designer decides who the first screen is for and what it assumes about them. The designer writes the rules the system enforces: what a state licence filter does to a product list, what an approval workflow does to a piece of content, what happens to an order when the buyer does not turn up. The designer decides how you will know whether it worked, and reads the numbers afterwards. None of that is generated. It is judgment, and judgment is the part I was always hired for.

There is a risk in the new tools, and it is worth saying plainly. Left to themselves they produce the same page: a pale ground, a serif headline, a rounded card with a shadow, an accent bar. I see it everywhere now and I reject it in my own work, because a product that looks like every other product tells the user nothing about who made it or what it is for. The tools make sameness easy. Making something specific is still work, and it is still design work.

The handoff that no longer exists

The part of the old process I do not miss is the handoff. The document that described the interaction, the developer who read it differently, the two weeks of screenshots and comments. When the designer builds the screen, the interaction is what it is, and the conversation with engineering moves to where it should have been all along: the data model, the edge cases, the performance budget, the security of the thing.

I build with AI tooling rather than by hand, and I say so, because it matters to how I work with engineers. I am not a substitute for one. I am a designer who can now put a real thing in front of a real person on the day the idea arrives, and then find out whether it was a good idea. That was always the goal. It just used to take a lot longer.