Pace Car Design Integration Framework

The problem I was trying to solve

There is a familiar friction at the center of building software. Design needs room to explore what the product could become. Engineering has to protect what the product already is: production data, APIs, contracts, reliability, release safety.

For years, the industry tried to bridge that gap with handoffs. Static Figma files, clickable prototypes, detailed specs. They helped, but they still left the hardest work to translation: what happens when a promising interaction meets real constraints, real data, and real code?

For Astra, that friction was not abstract. We were consolidating support workflows across DoorDash, Wolt, and Deliveroo into one multi-tenant console. The product had to handle different operating models, regional expectations, dense support workflows, policy nuance, safety-sensitive customer data, payment disputes, and real-time delivery operations without becoming three separate tools wearing the same coat.

That is where static handoffs started to break. A layout could look right in isolation and still fail when it met real API payloads, long translated strings, edge-case policy states, and the density of an agent console. We did not need prettier artifacts. We needed design to prototype at the speed and shape of the product itself.

In my case, the friction also showed up as a design integration branch with months of design-driven work inside it. The ideas were useful, but the shape was wrong. The longer the branch sat, the harder it became to understand, review, and absorb into production.

The problem was not that design was moving too fast. The problem was that speed had no operating model. We needed a way for design to explore boldly without asking production to absorb the messiness of exploration.

That became Pace Car.

Why I built it now

Coding agents changed what production engineering looks like. Engineers I work with ship PRs in hours that used to take days. They move through implementation and review loops faster, and the pace of innovation in our codebase is the highest it has been in my career.

Design got new tools, but not a new accelerator. Most AI tools for designers speed up the surface acts: generating layouts, summarizing research, suggesting copy. None of them speed up the production-shaped work that is actually slow — getting a flow into code, validating it against real APIs, getting it reviewed, and shipping the slice. Engineering's accelerator is end-to-end. Design's is still partial. The automated QA (AQA) surface alone went through seven iterations in the pace-car lane before it reached production review.

When engineering ships faster than design can validate, design stops being a co-driver and starts being a passenger. Decisions get made without us. UX becomes a tax paid after the fact. I did not want to trade speed for lower quality, and I did not want to skip the work that makes design valuable: research, testing, iteration, the slow parts that earn the right to ship.

So I built the framework to give design its own end-to-end accelerator: a way to prototype in code, validate behavior against real constraints, and return only the slices production could trust.

It combines a live code lane, small production-shaped slices, a shared alignment loop, and an operating model that agents and humans both run. None of those pieces alone is the speedup. The speedup is the system.

That system catches design up to engineering and lets us push past, because the goal was never just parity. The goal is to set the pace of innovation, direct the vision, and stay anchored to production while doing it.

That is where this article shifts. After four months, 1,023 commits, and a broader rollout, Pace Car stopped being my workflow and became a team operating model.

The two lanes

In racing, the pace car has a specific job. It does not compete to win. It enters the track to control speed, smooth out chaos, and keep the field aligned so everyone can accelerate safely when the race opens back up.

That is the model. Master is the track. Production is the pack. astra/design-prototype is the pace car running ahead of it.

In software terms, the pace car is running software used as a design sandbox. It is not production, but it is built close enough to production that the work can be trusted later: real components, realistic states, production-shaped constraints, and enough code to prove behavior.

Instead of handoffs, the team aligns through drafting. Design runs ahead, engineering can see the line, and the best ideas come back as clean slices the pack can absorb.

The exploration lane · astra/design-prototype

This is a long-lived design integration branch. It is where approved design work for Astra becomes real enough to evaluate. It is also where production gets synced back in regularly. The point is to keep the prototype from drifting off into a parallel universe.

What it is for:

• designers and design engineers branch off it, build flows in code, and merge back in when the work is real enough to evaluate
• the branch uses production design-system components and realistic states, but avoids depending on every backend service
• the lane is a controlled proving ground, not a dumping ground
• UX gets made real enough to prove value before anyone cuts it into a production slice

Sync cadence I actually use:

• merge origin/master into astra/design-prototype at least weekly
• also sync before any major slice-selection or promotion-review session
• the designer owning the current pace-car lane resolves the conflicts unless an engineering-only production concern requires escalation
• the hosted prototype surface lives outside the production app and gets refreshed after each merge

The shipping lane · origin/master

Stable, production-safe, real APIs, real contracts, engineering-owned reliability. Everything that ships to production users has to survive here.

Designer branches

Short-lived branches off astra/design-prototype. A designer or design engineer branches from the pace car, builds a focused piece of exploration, and merges back into the design integration branch when the slice is ready for review.

Shipping branches

Fresh branches off origin/master. They get opened only after a slice is approved, and they contain only the code we intend to ship. They become PRs to production.

How it actually runs

Not everyone was sold on this immediately. One engineering lead put the skepticism plainly: could designer-authored code be trusted, and should design-driven work live this close to master? That concern was fair, and it is what the six rules below are built to answer.

Six operating rules make the difference between this working and this becoming another integration dump. These rules are not just documented. They live in the team's skills/ directory as SKILL.md files, runnable by agents and humans the same way. That part matters — it is what makes the framework portable. The mechanics are below; the executable version is what gets shipped alongside the code.

1. Explore in the pace car lane

Designers and design engineers build in code, not in static isolation. They branch from astra/design-prototype, wire mock-backed states, test flows as real experiences, and validate the work as a product. This is where design earns the right to ship.

2. Keep the pace car close to the track

The design branch has to stay close enough to production to be useful. We sync origin/master into astra/design-prototype every week, and production logic, contracts, safety, and data boundaries do not get replaced by design drift just because they are inconvenient.

If a prototype deviation matters, we name it and preserve it intentionally so it survives syncs. If it does not, it loses to production over time.

3. Cut slices, not chunks

We do not merge the design branch into production wholesale. We take one bounded slice at a time: a single visible behavior, a coherent user-facing improvement, and a production-ready story. If the change does not fit that shape, it is not ready to ship.

4. Rebuild every production PR from master

When a slice is approved, we do not ship from astra/design-prototype. We open a fresh branch from master, port only the approved files or hunks, verify them, and review the result as a clean production artifact. The prototype branch is where we learn, and master is where we commit.

5. Use separate worktrees for discovery and shipping

Lane separation should be physical, not just conceptual. I keep two persistent worktrees open: one for the prototype and discovery lane, and one for shipping and the production port. The prototype worktree is where design integration, experimentation, and slice selection happen, and the shipping worktree is where production branches are created from origin/master and where approved slices are rebuilt for PRs.

Keeping them separate keeps the shipping lane clean even when the prototype lane is intentionally messy.

6. Keep the team and agents aligned

Speed creates its own coordination problem. We were not one co-located pod: the work moved across San Francisco, New York, Berlin, Munich, and London, and if the branch moved faster than the team could understand, the system would fail even if the Git model was correct.

So the pace-car lane came with an alignment loop: daily written updates until the operating rhythm stabilized, shared prototype branches for active workstreams, short video walkthroughs for important changes, and a shared Markdown knowledge base that designers, engineers, PMs, and agents could all pull from and push back into.

The updates kept the team current. The videos carried intent. The prototype branch carried the runnable state. The knowledge base carried the decisions, product direction, design patterns, implementation notes, and review criteria that had to survive across time zones.

That mattered for the LLM agents too. An agent is only useful if it starts from the same product reality as the team. The shared KB gave people and agents the same durable context before they touched the branch, and the goal throughout was to keep everyone close enough to the same mental model that async work did not become parallel work.

How a slice actually ships

The sequence I run every time:

1. Identify a candidate slice in astra/design-prototype.
2. Run a Promotion Audit on it.
3. Pass Gate 1 on the prototype branch.
4. After approval, switch to the shipping worktree.
5. Branch from fresh origin/master.
6. Manually port only the approved slice.
7. Start a local server to verify the port and refine.
8. Open a draft PR against origin/master with the ported slice.
9. Pass Gate 2, then mark the PR ready for review.

Shipping worktree rules

• Never stage production-port work from the prototype worktree.
• Never clean, reset, or stash the prototype worktree to make shipping easier.
• Always start the shipping branch from fresh origin/master.
• If the shipping worktree is dirty, stop and fix the environment first.

Who owns what

Slicing is joint work, but the responsibilities are different.

• The designer defines the slice scope, the intended user-visible outcome, and what to exclude.
• The assigned engineer performs the production re-cut onto a fresh master branch.
• Both review the Promotion Audit before implementation begins.
• Engineering owns the final production-safe adaptation work required for shipping.

This keeps design responsible for product intent and engineering responsible for release correctness.

Porting default

Manual extraction is the default. I use cherry-pick only when the source commit is already narrow, self-contained, and production-safe, but in practice, most prototype commits are too mixed to trust as direct shipping artifacts. The burden of proof is on the cherry-pick, not on the manual port.

What it gave us

The result that mattered was not the commit count: it was what shipped, and how little chaos production had to absorb to ship it. Production PRs stayed under a few hundred lines. They went from approval to merge in single-digit days. The cycle from idea to production kept shrinking as the team learned the cadence, and design reviews happened on running code instead of static screens.

The activity behind that result: between March and June 2026, the team landed 1,023 commits and roughly 126 merges into astra/design-prototype. The work was in code, not just in mockups.

The pace-car lane made the work visible, reviewable, and cheap to throw away when it needed to change. It also gave the global console a shared product language: one place to test how support work should behave across brands, regions, roles, and operational edge cases before production had to commit.

It is easy to say "designers ship in code"; it is more useful to see what they actually shipped. In that same four-month window we shipped:

• AQA, an automated quality-assurance surface — seven iterations from a single dispute flow to a versioned rollout with manual review, calibrator and auditor roles, a 10-day dispute window, dual-track score pills, and a dockable review window
• AMR, an account-management resolution flow — five iterations across verification versions, store operations and payouts sidesheets, deactivation and privacy flows
• Lyra, an AI-powered diagnosis and resolution assistant — live transcript, speech-to-text, full-page and panel views, in-body resolutions
• Go-Kart, a training simulator — live practice loop, scenario builder, versioned wizard, and post-solve debrief

All of it landed in the pace-car lane first. Each iteration was a small, bounded change on astra/design-prototype, scoped narrow enough to review and throw away when needed. Most never reached a Figma file.

What changed in the team

The numbers mattered less than the shape of the work behind them. The team split structurally. I wrote the largest share of the prototype commits in the four-month window. Two engineering integrators absorbed most of the merges into astra/design-prototype. A parallel AI-resolution workstream had its own lead, and a small group of specialist contributors rounded out the work.

That is not a flat team. It is a writer–integrator pattern: the writer pushes the pace car forward, and the integrators keep the track from buckling under the weight of new work. Both roles are necessary. Neither works without the other.

The distributed shape of the team mattered too. Pace Car only worked because the prototype branch, walkthrough videos, daily updates, and shared knowledge base gave everyone the same place to look. The coordination system was not overhead. It was part of the production system.

The branch showed what changed, the videos explained why, and the KB preserved the decisions long enough for teammates and agents in another time zone to act on them.

Designers stopped handing off Figma and started shipping code. PMs stopped asking for static screens and started asking for working prototypes. Research partners started committing seeded test scenarios and QA scripts directly to the branch, instead of dropping reports over the wall.

By June, the design integration branch was no longer a design-owned artifact. It was a cross-functional prototype surface that anyone with a real idea could push to. The boundary between "design work" and "engineering work" got thinner in the place where exploration happens, and that was the point.

The cultural move was small in language and large in consequence: design earns the right to ship. Earning it looked like real commits, real reviews, real accountability for the slice from idea to production, not a separate prototype universe the team had to translate later.

Where it surprised me

A few things I did not expect going in.

The first was that the manual port turned out to be a feature, not a chore. Rebuilding an approved slice onto a fresh master branch is the best review surface in the system. Every line gets re-read in the context of production. Production-safe design stops being theoretical and starts being enforced by the act of porting.

The second was distance. The pace car has to stay ahead, but not too far ahead. If the prototype outruns production by too much, the work starts drifting toward a parallel product. Weekly syncs kept us honest. We stopped designing against imagined APIs and started designing against the system we actually had.

The third was component discipline. The model breaks if the pace-car lane fills up with one-off CSS, custom components, or interactions that production cannot reasonably absorb. The lane can push the system, but it still has to respect the system.

The fourth was shared ownership. The pace car cannot be a design-only toy. It has to be a shared workspace where design, engineering, PM, research, and agents can all see the current product reality and shape the next slice.

The fifth was that the framework made it easier to say no. If a candidate did not fit the slice shape, it did not ship. That rule kept the integration branch from turning into a permanent fork and kept the bar for production real.

What this is not

It is not a staging branch that eventually gets merged wholesale.

It is not a prototype fork with no return path.

It is not designers pushing random code straight to production, and it is not engineering acting as cleanup for unresolved design exploration.

It is a working system for converting design momentum into production value without one team or the other absorbing the cost.

What the rules actually are

These are the defaults every slice runs through.

The alignment target. We aim to keep astra/design-prototype inside an 80% alignment band on prod-owned and shared surfaces. Perfect parity is not the goal. Staying useful to production is.

Per-surface drift heuristics. The default is not the same for every surface.

• production-owned first pass for surfaces where production behavior is safety-critical or contract-bound
• smart-blend by default for shared surfaces — keep what is intentional, defer to production where it is not
• prototype-ahead by default for tooling, dev surfaces, and scenario-heavy work where the prototype is the source of truth

Two review gates. Gate 1 happens on the prototype branch — the designer and the engineer agree the slice is bounded and production-shaped. Gate 2 happens on the draft production PR — engineering and design confirm the port is clean before review opens.

Four PR dispositions. Every incoming PR into astra/design-prototype is classified as one of four: merge as-is, blend before merge, defer, or escalate to engineering. The disposition is named in the PR review. There is no fifth option.

The Keep Intact ledger. Every durable intentional prototype deviation is logged in the team's sync ledger with its surface, rationale, allowed prototype layer, and owner. If it is not in the ledger, the next sync erodes it back toward production. If it is in the ledger, it survives.

The shared knowledge base. Durable direction, design patterns, decisions, implementation handoffs, review criteria, and ways of working live in a shared Markdown repo. The branch shows the work. The KB keeps the team and the agents oriented to why the work exists. It is the decision memory that makes a distributed, AI-assisted team coherent instead of fast in five different directions.

Where we're going next

The framework was built to be launched, not to sit on one team's branch.

Next, we are rolling it out across the rest of the design org at DoorDash. The onboarding work is less about the branch model and more about the operating rules — the alignment band, the per-surface heuristics, the two gates, the four PR dispositions, the Keep Intact ledger, the shared knowledge base, and the alignment loop. The mechanics are easy to copy. The discipline is the actual lift.

We are also tightening the AI-agent loop on the design side. The same acceleration gap that triggered the framework is now the next bet: design-specific tooling that gives prototyping, testing, and iteration the same multiplier engineering has had, without trading rigor for speed.

The longer-term direction is the one the framework is built for: design sets the pace and the direction of the vision, while production follows at a sustainable speed because the slices it absorbs are real, small, and reviewable. That is what we are launching into.

The short version

The pace car does not win the race.

It makes the race winnable by setting the speed for innovation.

That is the job of astra/design-prototype: let design run ahead of production far enough to discover what matters, but stay close enough that the work can be absorbed.

Master is the track. It keeps what ships stable, intentional, and real.

The operating model is simple: explore ahead, draft against production, sync often, keep the team aligned, cut clean slices, rebuild each slice from master, run two review gates, log intentional drift, and ship only what production can trust.

Pace Car gives design a way to lead from running software instead of static intent. It lets design set the speed and direction of innovation without taking production off the track.