Industry

Spatial Computing & Agentic AI

Company

OpalAI

How We Merged Design and Implementation with AI

Six pipeline steps became two, and a three-day feature became a few hours.

A Pipeline Built on Handoffs

Before diving into the problem, we should know that design has two sides: design process and design production. This case study is only about design production.


Design process

01

  • Research

  • Problem validation

  • User needs

  • Flows

  • Interviews

  • Usability testing

  • Understanding the problem

Design production

02

  • Wireframing

  • UI design

  • prototyping

  • handoff

  • Producing the solution


What was problem with the traditional Pipeline?

Our traditional pipeline for shipping a feature looked like the figure below. This pipeline is standard and it works. But it is slow. Every handoff between design and development created waiting time and back-and-forth about details. For a small startup team, days of every feature were spent not on designing or building, but on passing work between people.

👴

Traditional Pipeline

Design Production

Wireframing

Team review

UI design & Prototyping

Handoff

Implementation

Refinement and testing

Release

When Claude Code appeared, I connected it to Figma and let AI generate the wireframes, UI, and prototype in one step. The accuracy was not good enough. I refined the design in Figma, then developers refined it again in code. We did the refinement work twice. Shorter on paper, not much faster in reality.


The Solution: Build the Feature, Not the Mockup

We took a bigger risk and removed the middle of the pipeline completely. No separate wireframing, UI, prototyping, or handoff anymore. The feature is designed inside the real product, in code, with AI assistance, and then I refine it as a designer, directly in the implemented product:


😎

New Pipeline

Design Production

Build the feature

Refine

Release


Three ways to start a feature

  1. Backend first. If a feature needs backend work, our backend developer builds it and implements the frontend with a raw flow and basic UI, based on our Design.md file. Then I refine the flow and interface, checking usability heuristics, accessibility (contrast, touch target sizes), visual hierarchy, spacing consistency, and interaction states like loading, empty, and error.

  2. Design first. If no backend is needed, I build the feature first with AI, and we refine it together in a team meeting.

  3. Parallel. I build the flow and a raw prototype while the backend developer prepares the backend. When both are ready, we merge.


The Design.md file

Consistency was our biggest worry. Our answer is a markdown file in the codebase that documents our design system and brand language: colors, typography, spacing rules, component behavior, and tone. One example rule: risk levels always use the same color scale, and red is never used for anything except high risk. Both the AI and the developers read this file, and when the design system changes, we update it first, like another team would update their Figma library. It is the reason AI output starts close to our style instead of a generic template.


design-rules.md

rules

## Spacing

- Base unit: 8px. All margins and paddings are multiples of 8.

## Data visualization

- Risk levels always use the same color scale: green, yellow, orange, red.

- Never use red for anything except high risk.

## Tone

- Short, calm, and clear. No alarming language, even for high-risk alerts.



How we explore ideas now

In the old flow, wireframing was also a thinking tool: sketching three cheap options was easy. Now exploration happens in code. Because building with AI is fast, I create multiple versions of a feature the way I used to sketch. Small features: different directions in separate commits. Big features: each direction on its own branch, compared in a meeting with the manager and the team. Git branches became my sketchbook.

The Result: From Three Days to a Few Hours

One example from our real work. These numbers are from our specific project and team, so treat them as one data point, not a universal promise.
Responsive components in a resizable dashboard (layout and components only, without data integration). In the previous flow, even with AI assistance: about one day to design, one day for the developer to implement with AI, and roughly one more day of back-and-forth. Around three days total. In the merged pipeline, I designed and implemented the same responsive components myself, with AI, in about 3 to 4 hours. The back-and-forth disappeared because there was nobody to hand off to.


Beyond speed, we gained:


  • Real prototypes. Stakeholders review the feature in the real, usable product, not a mockup.

  • New ideas. The AI often suggests directions I did not think about.

  • Knowledge sharing. Designers and developers understand each other's work much better.

  • Pixel-perfect where it matters. There is no gap between mockup and shipped product, because the mockup is the product.

  • Cheap exploration. Building multiple versions of a feature on separate branches is fast, so comparing real alternatives became easier than comparing static mockups.

  • Consistency by default. Every new screen starts from Design.md, so the design system is applied from the first version, not added later.

  • Testing in reality. Responsive behavior, interaction states, and edge cases are checked in the real product, in a real browser, not simulated in a prototype tool.



What to know before trying this. We are a small team, and part of our speed comes from being small, not only from AI. This pipeline needs designers comfortable near code and developers who respect design refinement. AI-generated design still needs a designer's eye. My code changes are always reviewed by developers before production. And the design process stayed untouched: research, validation, and usability testing all remain. If you remove those, you are just building the wrong thing faster.


Conclusion

Six steps became two, and a three-day feature became an afternoon. But the bigger lesson is not about AI. A pipeline is a tool, not a rule. We tested a new way, it failed once, we adjusted, and the second version worked. If we find a better way tomorrow, we will move to it, because pipelines can always improve.