Designing with code, without writing code

For a decade, my professional identity was designer-who-can-code. I was in VS Code more often than Figma. My deliverables were often functional prototypes. “Here’s how it would feel to use it.”

But now? Every designer can ship functional prototypes with their new coding agent friends.

Did I just lose my differentiation? Did I waste my time learning to code? No. If anything, the years of practice working with code is a force multiplier for doing interesting and ambitious projects. To understand why, let’s start from the beginning. Why bother learning to code at all?

Why code as a designer?

Shipping code was never the goal. Code is a means of exploring, finding, and proving a design direction. Using Figma (or Sketch back in the day) felt like doing a lot of work to build a facsimile of the experience. Writing code, long and tedious as it were, at least had the virtue of being real. A big focus of my design work is data visualization, which you literally cannot mock up. You can’t see how well a design works until you put data through it, and you can’t do that without code. The new generation of agentic design tools (e.g. Lovable) is better, but still feels like facsimile. Prompting your way to pixel perfection feels… wrong. It’s Figma with extra steps.

Which brings me back to code. If your work is a UI, there is just no higher fidelity material than code. And now coding agents makes that material more accessible than ever.

The core loop hasn’t changed

A few weeks ago, Amelia wrote about the painter’s loop.

Watch a painter work and you'll notice something obvious. They don't just paint. They step in, make a stroke, step back. Look at the whole canvas. Think. Step in again.

That in my mind is the core of a designer’s inner loop. This was the work when the making was in Illustrator, in Sketch, in hand written HTML/CSS. This is still the work when prompting an agent (or a fleet of agents) to refine a design. It’s faster, higher fidelity, but as Amelia mentioned, “You still need the same time to figure out whether you're building the right thing.”

Coding agents (and agentic design tools for that matter) still requires that “step back”, that moment of judgement, and yes, taste. I would argue that the most exciting part of these new tools is that we get to spend less time pushing code/pixels, and more time judging/refining the work.

It also means you can do more iterations now. Which means more opportunities to refine and sharpen our own tastes. It will be interesting to see what good design looks like when the best designers can do 50 iterations a week instead of 5.

Code as a material hasn’t changed

With coding agents, I no longer type out code by hand, but how I reason about the code is more important than ever. It’s still the same code that the browser/OS runs under the hood, subject to the same constraints. So you still have to understand code, and its execution environment (browser, operating system, etc.) as a design material.

Without an understanding of code as a material, agentic design can actually make things worse. One disadvantage of coding agents vs. your engineering colleagues is that, while your colleagues will tell you up front what you’re asking for is impossible, agents will go in cycles while trying to deliver the impossible, fail, and still not able to tell you why.

Knowing your material matters more now, because that knowledge is multiplied by every agent you can wield. Instead of pushing pixels, or writing the code, designers can task a fleet of agents with generating code via prompting. Knowing what to prompt for is very high leverage. And with that new leverage, projects that once felt unrealistic start to feel tractable. Which brings me to what actually has changed — what's now possible for a single designer.

One designer can do much more now

Code map for PyTorch

There’s a project at Augment that I’ve been working on the side for a bit. It’s a codebase map, based on the codebase embeddings in our context engine. I wanted it to feel like a city map you can navigate, with buildings and roads and neighborhoods.

This isn’t live yet, but here’s a sneak peek.

Zooming in on the ATen Core Infrastructure and Dispatch System neighborhood

Before coding agents, this would have been weeks of work on a proposal just to get it off the ground. Compiling sketches, decks, etc., to run through the gauntlet of getting a project on the roadmap. And rightly so, because engineering time is expensive both in terms of time, and opportunity cost.

With coding agents? I asked a colleague to give me a parquet dump of a single repo’s embeddings. Then I iterated on it on the side, for months, in my spare time. No permissions needed.

The DAG of the data pipeline

With a lot of effort and time, I could have built the front end side of this without coding agents. The pipeline side? Never. Using Augment, however, I built the pipeline one piece at a time, one question at a time. Each of these nodes was its own mini project. The agent taught me about Leiden clustering when I asked for a hierarchical organization of code. When I fretted about loading speed, we went down two diverging, deep paths, one on mesh instancing in Three.js, and the other on reducing download size with binary file formats. Knowing how to ask these questions, it turns out, is the most powerful legacy of immersing in code all these years.

For the spatial layout — how buildings cluster, how dense the map is, how roads connect them — I went through the painter’s loop: looked at the output, iterated (i.e. tuned parameters on the algorithm) and looked at it again, until it looked right. This is the design process, just not in any recognizable design tool.

Coding agents change the prototyping calculus

The Code Maps project is one I wouldn’t even have pitched in the “before” times. Too big, too ambitious, too ambiguous. With coding agents, I had far more runway to tinker and experiment. Coding agents gave me the room to go through the make-look-make loop, again and again, in a way that just wasn’t feasible before.

With coding agents, the designer’s in-the-trenches work is changing.

• From “working the organization” — spending time on decks, mocks, meetings — to get on a roadmap.
• To “steering the agents” — spending time on prompts, iterations, review — to get a vision realized

I do wonder what this looks like at scale. My hope is that more weird, ambitious, ambiguous ideas get a chance to breathe. More divergent ideas gets explored. Perhaps everything will still need to compete for space on the roadmap. But ideas won’t die simply because they are too risky, too ambiguous, or too costly to prototype.

Designer-who-prototypes is evergreen

In a world with coding agents, the designer-who-codes may not be as relevant, but the designer-who-prototypes will persist. The workflows may change, but the painter’s loop will remain. In this way, coding agents is not so different from other workflow shifts. How design is done will keep changing. What design is — the pursuit of the intuitive and the delightful — that remains the same.