Skip to main content

The AI builder

The builder turns a plain description into a working setup. You write what you want ("track my yarn stash with weight, color, and how much is left; warn me when a color runs low"), and you get back custom fields and wires you review and apply, or a custom app over your existing data. It reaches the same builder from the Build page and from a request to Cobb to set up a whole workspace.

How it works​

The builder is a prompt compiler. It gathers the minimal context for your request (the relevant entity kinds, the actions those kinds can be wired to, and the exact output shape) and assembles that plus your description into one prompt. The answer to that prompt is a bundle manifest or an app definition.

For a tweak to what you already have, the Build page works out which of your kinds the change touches from your own words and field names ("add a warranty date to parts" lands on your parts), and shows what it picked and why. You are not asked to pick from a wall of chips before you have said anything; the full picker sits one click away under Change for the rare miss. Scope is capped at three kinds, because a tight scope gets more reliable results.

There are two ways it runs:

  • Copy-paste, which needs no connected provider. The builder gives you the compiled prompt; you run it in your own ChatGPT or Claude and paste the result back. This is how bundle building works with no AI connected.
  • Hosted, when a provider is connected. The builder runs the model for you inline and, if the first result does not validate, repairs it and tries again a couple of times before handing you a candidate.

Either way, Cobb is at his bench whenever a step is running, whether a prompt is being compiled, a paste is being checked, a build is applying, or a repair prompt is being drafted, so a wait never reads as a dead button.

The validation gate​

Nothing broken gets applied. Every candidate, whichever way it was produced, is graded by the kernel's own bundle or app validation before you can install it, the same check a hand-written manifest goes through. An invalid candidate comes back with the specific errors and a repair prompt (copy-paste) or an automatic repair pass (hosted). Correctness lives with the kernel, not with the model's good intentions.

What it generates​

  • Custom fields on the kinds you are tracking, with the types and choices your description implies.
  • A new tracked section when you name a thing that deserves its own page. "Track my books, call it Bookshelf" gives you a Bookshelf with its own nav entry and New Book form, an instance of a module rather than book fields bolted onto something unrelated. A section you look things up in (books, movies, records, wine) comes out lean: it keeps name, photo, location, and notes plus the fields you asked for, and drops the borrowed module's built-ins like state, warranty, and serial number. A thing you own and maintain (tools, vehicles) keeps those.
  • Nav grouping: ask to put sections under a parent ("group these under Machines") and it adds a heading over them, existing sections included.
  • Wires: the "when this happens, do that" connections, like drafting a reorder when a part runs low.
  • A whole-workspace setup: enabling the modules a design needs and adding their fields, optionally with a few starter records seeded in. You review the full plan first, every new section, field, wire, and nav grouping, before it applies.
  • A custom app: either a page of structured blocks over your existing data, or a single self-contained HTML page for when the blocks aren't enough. The HTML runs in the same sandbox a hand-written custom block does, so generated code can never do more than the person viewing it.

Refine it without starting over​

Once a result validates, you change it by describing the change, not by starting again. Under Apply there's a box for a plain request: "also add a price column," "drop the label wire," "make the intro friendlier." The builder revises the current result and leaves everything you didn't mention exactly as it was. The same validation gate applies, and each refine is saved as a draft linked to the one before it, so you can trace how the design got there. It works for bundles and for apps, hosted or copy-paste.

When a ready-made bundle already fits​

If your description matches a bundle already in the marketplace ("track my books" lands on Bookshelf), Cobb turns up to point at it, and the Build page offers to install that instead of generating one. A curated bundle is more finished than a fresh generation, so it's usually the better start. You can still generate your own if you'd rather.

Current limits​

The builder produces fields, tracked sections, wires, whole-workspace setups, and apps, including a custom app's sandboxed HTML, and it revises any of them. What it does not do is write module code: a new module is a developer task, not a described one. When in doubt about what a manifest should contain, Authoring a bundle is the reference for the shape the builder targets.