19 March 2026

Why "throw-away code" is the wrong frame for agentic design prototyping

The most common objection to giving designers a code environment is that the output won’t be used in production. That objection misunderstands what the output actually is.

Main point: Designer prototype code isn't "throw-away". The code may not ship, but the components, the platform and the decisions it validates do.

When I explain Unplanned Studio to leaders, they often ask: "So is all that code just throw-away?" It's a fair question, built on the wrong assumption.

Three things that aren't thrown away

  1. Components that get promoted. Designers propose patterns in manifest.json as a componentProposal. The good ones go into @unplanned-studio/ui, which already has 25+ components proven against real data.
  2. The platform. The window manager, storage, graph data, theme editor and app discovery are maintained infrastructure that every app runs on.
  3. The decisions. Prototyping with real data and components shows what breaks before engineering commits, which saves painful rewrites.

The real comparison

The alternative isn't "engineers write production code instead". It's usually one of these:- Figma only: no real state or data- One-off code: runs, but disconnected from your system- Build in production straight away: accurate, but slow and expensive- Do nothing: find the edge cases in QA

Against those, a real prototype in a structured environment is about reducing risk.

The question I ask back

How do you validate a complex interaction before it hits production? If the honest answer is "we look at it in Figma and hope", the sandbox is already winning. Its output isn't the code. It's decisions you can trust.