Write to a contract, not a canvas

Everyone wants their AI to build software now. The question nobody asks carefully is: build it against what? Because the target you point an AI at decides whether you get a working app or a demo that falls apart the second a real person touches it.

There are two answers on offer. A canvas or a contract. They are not close.

The canvas is built for a human's hands

Most AI app builders put you in front of a visual editor. You describe a screen, the tool generates some UI, you drag things around, you tweak a properties panel. It looks like magic in the demo. The trouble is what the app actually is underneath: a pile of editor state, positions and bindings and event wiring, that only means anything inside that particular canvas.

An AI cannot reliably drive that. The canvas was designed for a person moving a mouse, so "make the approve button call the finance webhook" is a sequence of drag gestures and menu clicks with no stable text form. The model can generate a starting layout, but it cannot read the app back, reason about it, and change one behavior three weeks later, because the app does not exist as anything it can read. You get a throwaway prototype. Good for a screenshot, not for a tool your team logs into on Monday.

The contract is built for a model to read

The other answer is a contract: a small, documented surface that an app must be written against, published as plain text an AI can read start to finish. That is what agent-native means. Not "there is an AI button in the corner." It means the whole thing an AI needs to know fits in one file, and what the AI produces is real code that runs.

On fuast that file is /llms.txt. It describes the entire capsule contract: the imports you are allowed, the shape of a schema, how queries and mutations work, how auth is handed to you. A model reads it and writes a server/ half and a client/ half that deploy as-is. You said one sentence. You got a working full-stack app, in code, that you can read, diff, and review.

The difference is not cosmetic. Writing to a contract means the AI's output is the app, not a description of an app trapped in an editor. Three weeks later you can ask it to add a daily digest, and it changes the code, because the code is the truth.

Why small and strict beats big and flexible

The instinct is that a bigger, more flexible surface helps the AI. It is the opposite. The reason an AI hits a capsule on the first try is that the surface is deliberately tiny. Server code imports only fuast/server. There is one database handle, ctx.db, not a choice between forty ORMs. Identity is always ctx.auth.userId, verified by the platform, never a guess.

A model does not hallucinate an import that the contract forbids. It does not invent an auth scheme when auth is handed to it. Constraints that would annoy a human, "you cannot npm install anything," are exactly what make the output reliable, because they collapse the space of things the AI could get wrong. Strict is a feature when your author is a language model.

Let the canvas design, let the contract run

This is not an argument that AI app builders are useless. They are genuinely good at one thing: exploring what a UI could look like, fast. If you want to see three versions of a layout before you commit, a canvas is a fine sketchpad, and we say so plainly in AI app builders vs real apps.

The mistake is stopping there and calling the sketch a product. Let a builder design the look if you like. Then have your AI write the real thing to a contract, so it runs, holds your team's data, and signs your coworkers in. Design on a canvas, ship on a contract.

The test

Here is the question to ask any "AI builds your app" tool. After the AI is done, what exists? If the answer is editor state you can only change by hand, you have a prototype. If the answer is code the same AI can read back and modify from a sentence, you have an app.

fuast is built for the second answer. The contract is right here, and the fastest way to feel the difference is to point your AI at it. Build something real.