Skip to content
TypillarTypillarTypillar

The build loop

The build loop is the engine of Typillar. It’s the same sequence every time, which is what makes the system predictable: you always know where a request is, what’s been decided, and what happens next.

The stages

Section titled “The stages”

1. The ticket

Section titled “1. The ticket”

You describe an outcome in plain language — a whole project (“a feedback board where anyone posts and votes on ideas”) or an increment to an existing one (“add a contact form to the landing page”). What you typed is the ticket: it’s kept word for word, and the opening of your sentence names it. You never have to phrase it as a work item, and nothing rewrites it before the build sees it.

2. Build

Section titled “2. Build”

The build agent starts on that ticket. There’s no step in between — you talk and it builds. The build agent:

  • Generates the code, using inference that runs on your side (Your models). See The stack.
  • Turns on what the feature needs — a database, file storage, a scheduled trigger — on your Cloudflare account, as it needs it.
  • Commits the source to your GitHub repository as ordinary commits.
  • Closes the ticket with the decisions it made along the way.

3. Questions, in the thread

Section titled “3. Questions, in the thread”

When a decision is genuinely yours to make, the agent asks in the thread and waits for your answer before continuing — then resumes exactly where it paused. Ambiguity is resolved by asking about the things that matter, not by making you sign off on the things that don’t. Follow-up messages refine the same app, so the conversation accumulates rather than forking.

4. Ship

Section titled “4. Ship”

Ship deploys the project — everything built since the last deploy, not one ticket — to a live URL on your Cloudflare account, when you ask for it: the Ship button, or “deploy it” in the thread. It’s recorded in the project history, and from that moment it is reversible; see Deploys & rollback.

Where control lives

Section titled “Where control lives”

An always-on system is safe to leave on not because a gate blocks every build, but because you’re never out of the loop:

  • it asks before the decisions that would change the project;
  • nothing goes to a live URL until you say so;
  • every change is a commit, any version can be restored, and any live deployment can be rolled back offline.

The loop has a memory

Section titled “The loop has a memory”

Each pass leaves a durable trail — a ticket, its decisions, commits, and, when you Ship, a deployment. Because that history persists, the agents can reason about what already exists when you ask for the next thing, and you can always trace how the project got to its current state. The loop doesn’t just produce output; it builds a record.

Section titled “Related”