Code-Based Design

AI & Design

Code-Based Design

July 29, 20264 min readAIProduct StrategyDesign LeadershipWays of Working
Shane Bouchard
Design leader. 30 years across enterprise, SaaS, consumer, and agency.

For thirty years, product design has had an expensive limitation: we couldn't fully experience what we were designing until somebody built it.

So we worked through representations: wireframes, comps, prototypes. Then engineering turned them into the coded product, where missing states, awkward interactions, inaccurate assumptions, and other gaps became obvious. Using the product often sparked new ideas too.

Then we went around again.

Design. Dev. QA. Repeat.

It worked. It also made change expensive.

It was the best design method our tools and workflows allowed.

Today, the tools let us work differently.

Enter code-based design.

Enter code-based design

The design isn't a render of the product.
It is the product.
That changes the economics of iteration.

Today, I prototype in hours, not days. I can use the design, catch broken states and awkward interactions, tune motion in context, and explore another direction with stakeholders before engineering has committed significant time.

More importantly, that working experience can get into customers' hands sooner. Stakeholders can react to behavior instead of interpreting a comp. Customers can use something real enough to expose whether the idea works. We learn sooner, while changing direction is still inexpensive.

That is useful for designers. It is more consequential for the business. Code-based design shortens the distance between an idea and evidence that customers actually want it.

That can radically accelerate the path to market fit.

In a way, AI is finally letting design work more like Agile was intended to work: smaller bets, working software earlier, tighter feedback loops, and learning through use.

The economics changed

Same two weeks. More directions explored. Faster decisions. Less code wasted.

Traditional design Code-based design
Design → dev → QA → repeat Design and iterate in the working experience Fewer cycles
Stakeholders interpret a comp Stakeholders use the experience Faster alignment
Design gaps surface during build Design gaps surface during design Less rework
Behavior is explained Behavior is experienced Faster decisions
Motion is specified Motion is tuned live Better quality
Feedback waits for a build Feedback arrives before engineering commitment Earlier signal
Handoff starts with documentation Handoff starts with working code Less translation
Code-based design lowers the cost of iteration. More shots, faster signal, less wasted build. That's how you accelerate the path to market fit.

Wireframes aren't going away. Neither are sketches, whiteboards or traditional prototypes. They still earn their keep when they're the fastest way to answer the question in front of us.

The difference is that static artifacts no longer have to carry the full burden of product design. Working code can move earlier in the process, giving teams something usable to share sooner and radically reducing the cost of iteration.

Cheap iteration is a market advantage

Most products don't fail because nobody had ideas. They fail because finding the right combination of problem, product, experience, positioning, and timing is expensive. Companies make bets, put them into the market, and learn which assumptions survive contact with reality.

The faster a team can make those adjustments, the more shots it gets. If one team can explore five credible product directions for roughly the effort another spends getting one through the traditional loop, the advantage isn't simply productivity. It's optionality.

Engineering embraced this logic more than two decades ago. The Agile Manifesto put working software over comprehensive documentation, and engineering spent the next twenty-five years building around smaller releases, tighter loops, and continuous delivery.

Design has often remained one step removed from that loop. Code-based design closes some of that distance.

The talent market is already moving

Design hiring is down, while expectations for the role are expanding.

100 Engineering 89 11% drop from 2019 Design 52 48% drop from 2019
Q4 2019Q4 2025

Hiring signal

Design hiring fell more than four times as far as engineering.

  • Design: 48% drop from the 2019 hiring baseline
  • Engineering: 11% drop from the same baseline

Hiring at major technology companies declined much more sharply for design than engineering.

SignalFire, State of Talent Report 2026. Trailing 12-month hires indexed to Q4 2019 = 100.

Move early. The advantage compounds.

McKinsey described AI as a competitive reset, not a lasting productivity advantage. The reason matters: once everyone has access to similar tools, speed alone stops differentiating you.

What compounds is what you do with that speed. Teams that use it to explore more directions, put working software in front of customers sooner, and kill weak ideas before engineering invests heavily start learning earlier. Those learning cycles build on one another.

That is the opportunity with code-based design. The advantage isn't faster design. It's learning what works sooner.

Run the experiment

One team. One real feature. Two weeks.

  1. Build in the working experience

    Choose one real feature, not a disposable demo. Design and iterate in code before engineering makes a major commitment.

  2. Explore more than one answer

    Use the same two weeks to develop two or three viable directions around the same problem instead of polishing the first acceptable idea.

  3. Put working options in customers' hands

    Test the strongest options with customers while they are still inexpensive to change. Let people use the experience, not interpret a comp.

  4. Compare the loop

    Compare the pilot with a similar recent feature or the team's normal way of working.

    Measure:

    • Directions tested with customers
    • Time to first customer signal
    • Issues found before engineering commitment
    • Design-driven changes after engineering starts
    • Design → engineering loops

There will be a learning curve,1 and changing how work happens carries a cost. The question is whether the return justifies it.

In my experience, it does: faster iteration, faster shipping, and more shots at finding what the market wants.

The grass is greener.

1The productivity J-curve, Brynjolfsson, Rock & Syverson, NBER: adopters of a general-purpose technology often dip before they pull ahead.

Share LinkedIn ↗