The App Spec IR: describe the app instead of coding it

For twenty years, building a web app has meant thinking in components. You describe a button, a form, a route, a state hook, a data fetcher. The framework holds you accountable to that vocabulary. React is components. Vue is components. Angular is components. Even server side frameworks like Django and Rails settled into their own component analogues.

That vocabulary was correct for the apps we were building. It is not correct for the apps we are building now.

An AI product is rarely a page or a form. It is usually a loop.

There is a user with an intent. There are one or more agents with tools they can call. There is a body of data the agents reason over. There is a stream of output that appears as text, image, audio, or structured records. There is a way to hand the finished thing back.

You can build all of that in React. You can also build a house with only a hammer. The vocabulary of components makes you translate every AI concept into a framework primitive, and the translation is where most of the bugs and most of the wasted time live.

Studio builds apps from a document we call the App Spec. It is an intermediate representation. Not code, not a database schema, not a UI mockup. A description of what the app is, in the vocabulary AI apps actually use.

The App Spec captures four things.

• Chat behaviour. What the user can say, what the agent should do, which tier of intelligence answers.
• Tools. The named functions the agent has access to, with their input schemas and their handlers.
• Data. The records the app manages, the fields on each, and how they relate to each other.
• Surfaces. The generation outputs the app produces. Text, image, audio, video, structured data. Where they get rendered.

Everything the app does is one of those four. Studio reads the spec and provisions the rest.

Given an App Spec, Studio does the mechanical work.

The data models get provisioned automatically as isolated tables per project. The tools get wired to the agent runtime and included in the tier profile you picked. The UI gets composed from primitives that match what the spec describes. A chat pane if there is chat. A records view if there is data. A gallery if there are image surfaces.

You can edit any of it. Change the spec, the UI updates. Rearrange the UI in the visual editor, the spec updates. Both directions stay in sync.

You never touch a React component unless you want to.

Two reasons.

Speed. Describing an app is faster than building one. The mechanical translation from intent to code is the part that AI is genuinely good at. Doing it once in a shared, versioned representation is dramatically better than a raw prompt to prompt loop scattered across a codebase.

Portability. The App Spec is framework agnostic. When the next generation of AI app tooling arrives, your spec still describes what the app is. You are not locked into React or any specific rendering approach. The IR outlives the runtime.

If you want to see it, build one at taskclan.com/studio. The docs walk you through the spec vocabulary in five minutes.