What Cheap Code Did to Design

AI is making it dramatically cheaper to produce working software.

That sounds like an engineering story, until you watch what happens next: the opportunity moves. Building speeds up, and suddenly design, the thing that used to be fast to iterate on before handoff, earns a seat at the center of the loop earlier than ever before.

What follows is how we've been operating at Highlight: when code prototypes are easy to spin up and iterate on, the process reorganizes around faster feedback loops. The designer's role shifts from "spec it before it exists" to "choose the right medium, steer the loop, and bring craft and coherence at the right time."

Build earlier, iterate in code

Here's the core difference: traditional "design then engineering" vs. an AI-accelerated loop where design and engineering converge in runnable code much earlier:

In the old system, design operates almost independently of engineering. All ideation, prototyping, and initial testing happens before engineering gets involved. In the new system, design moves earlier into the code prototype phase, eliminating the separate Figma prototype round and collapsing the back-and-forth across handoffs. Designers are now iterating on the real thing, not a simulation of it. Design and engineering are working in the same environment at the same time. We get the ability to show early prototypes to users much sooner to get a directional signal on whether it's worth iterating on. That's what makes it faster.

Design's leverage compounds earlier in the process, where it actually changes outcomes: faster learning, fewer handoff cycles, tighter collaboration from the start.

A lot of the hard questions are dynamic, so runnable prototypes beat static mocks:

• Does it feel fast?
• What do edge cases actually look like (empty/error/loading)?
• Do the interactions hold up over repeated use?

Static Figma mocks can answer visual and layout questions well. They can't answer these. Getting to runnable code earlier means getting real answers earlier. That changes what's worth doing before you build.

The bottleneck moved from implementation to craft

When the process reorganizes this way, the slow part shifts. Engineering used to be the most expensive, time-consuming part of software development. That's why "designing everything before code" made sense; it reduced risk and rework.

As code prototyping accelerates, the slow part often becomes the last 20% of quality:

• Motion and animation
• Pixel-level polish
• Edge states (empty/error/loading)
• Interaction behaviors (for chat: time to first response, streaming states, interruption behavior)
• Consistency across the system

In this new system, design becomes more critical. Great products not only work but are delightful to use. Making code cheaper means we can now spend more time making the products we build more delightful without sacrificing time.

When to polish vs. call it good enough

That shift creates a recurring pressure. When implementation is fast, there's constant temptation to keep the loop moving. Designers end up making the same tradeoff over and over:

Do we pause and polish (motion, states, interaction feel) or do we let implementation run and accept "good enough" for now?

The opportunity here is real: cheaper code means we can now spend more time on the things that make products genuinely delightful, without sacrificing speed. Motion, interaction feel, edge states. These aren't polish bolted on at the end. They're what turns a product that works into one people actually love using.

Design output earns its place by producing clarity on what matters, interaction behaviors that feel intentional, and the craft that turns speed into something users want to keep using.

What to stay ahead of when moving fast

Move fast without managing that tradeoff explicitly, and problems can accumulate. It's worth naming the patterns teams can get ahead of before they compound. Here are the three we've bumped into most:

1. System ownership: lots of fast decisions, but nobody owns the system. Components diverge, patterns fragment, and the product slowly stops feeling like one thing. Larger companies solve this with dedicated design systems teams. If you don't have that, ownership needs to be explicit and named, or it defaults to nobody.
2. Protecting the last 20%: once something exists in code, it can feel "done," even if the interaction behavior is off or edge states are missing. The feature "works," so it ships. This is exactly where the last 20% of quality gets lost.
3. Artifact drift: the design library and what's in production slowly stop matching. The only fix is backporting, and it's still painful.

Choosing the right medium

The answer to these risks isn't to slow everything down. It's to be explicit about when you're exploring vs. converging, and to assign real ownership. That leads to the biggest role shift in this model: designers increasingly act as the person who chooses the right medium for the question.

Should we explore this in Figma first or go straight into code?

That judgment is now a core design skill. To answer this question we use the following framing:

A few things this surfaces in practice:

The clearest case for Figma is a brand-new component or behavior that doesn't exist in the system yet. You're working from scratch, so you need to explore form, layout, and visual hierarchy before committing to anything. Tools like Cursor and Claude Code are excellent for interaction prototyping, but they're not built for side-by-side visual comparison, the kind that helps you decide whether a pattern belongs at all.

The clearest case for going straight to code is anything where the question is dynamic: does it feel fast? What does the empty state actually look like in context? Does the interaction hold up over time? Static mocks can't answer these. Getting to runnable earlier means getting real answers earlier.

Once that call is made and you're in code, a second shift kicks in. One that ripples further than most teams expect.

Code becomes the source of truth (and backporting keeps the system honest)

When iteration happens in code, the codebase becomes the thing you trust. Figma shifts away from being the primary handoff tool and toward something more like an exploration and systems environment. It's a real change, and it ripples further than just the design-to-engineering relationship.

Marketing depends heavily on Figma files to produce product videos, website visuals, and sales collateral. When code becomes the source of truth and Figma starts lagging behind production, those workflows break down too.

On the practical side: we still need a visual home for our design system, and that's not just a designer preference. A code-only system is invisible to everyone who isn't in the codebase: marketers producing collateral, leaders reviewing direction, designers exploring new components. It also captures design intent: the why behind spacing, hierarchy, and color decisions that code alone doesn't preserve. For now, that visual home is Figma.

The problem is keeping it in sync with what's shipping. Backporting, updating Figma to reflect what's already in code, becomes the standing tax. We've tried a few tools to close this gap. Figma MCP produced inconsistent results. Claude to turn code into viewable UI inside Paper felt more promising, but Paper is still missing fundamentals like components and variables, and can occasionally misrepresent what the code is actually doing. Claude Design is the most recent attempt: it can look at a screen and try to reconstruct it, but it doesn't yet understand the intent behind a design or the primitives that drive the logic and mental model behind what you're seeing. The tool that solves this well doesn't exist yet, but the need for a visual design system isn't going away.

There's no clean solution yet. The best we've found is treating backporting as a named, time-boxed step in the weekly workflow rather than something that happens "eventually."

A weekly operating model for fast, code-native iteration

Here's how this actually runs week-to-week at Highlight:

1. Start of week: align on what "done" means and what you're trying to build or prove.
2. Design explores a couple of directions, checks which components already exist, identifies what's truly new.
   • New components or primitives needed → trials in Figma, Paper, or Claude Code.
   • No new components or primitives → design pairs with a design engineer to prototype in code.
3. Share the runnable prototype with the broader team early and collect feedback while changes are still cheap.
4. Design and engineering refine together. Both product decisions and craft. How something feels is as much a requirement as whether it works.
5. Midweek (often Wed/Thu): converge on a shippable feature, complete in code, tested, ready to merge.
6. Backport to Figma: update the design library to match what shipped. Still a manual step, but worth protecting.
7. End of week: merged to main, library updated.

The impact of cheaper code

The old "design, then engineering" playbook doesn't hold up at AI speed. The teams shipping well right now are running a tighter loop: getting to runnable prototypes early, treating delight as something that matters rather than optional polish, being honest about when they're exploring vs. converging, and assigning real ownership for consistency so speed doesn't turn into mess.

If you're building in this world, the question isn't "should designers learn to code?" It's: how do you make it cheap to learn in code, while making it easy to ship something worth being proud of?