Comparisons and approach
Three comparisons with other ways of building software with AI, then how a platform is built, from the brief to the app.
01 · Comparison
For anyone weighing how to build an app with AI: what changes between generating it from a prompt on a platform and building it through a controlled process, and when the first route is the better one.
Here «no-code platform» means platforms that generate an app from a prompt, for example Base44. The comparison is about the category, not one product.
Prompt-to-app platform
The method
| Axis | Prompt-to-app platform | The method |
|---|---|---|
| Approach | A prompt describes the app, a model generates interface and backend inside the platform. The complexity stays behind the chat. | A control system: the written brief fixes the problem, agents carry out the work, a person acts as controller. Nothing ships before its behaviour is checked. The method adapts a few practices from safety-critical software (numbered requirements, every requirement proven by a test, impact analysis before every change) without their formal guarantees. |
| Quality over iterations | Each request regenerates parts of the app. Without tests, a change can break logic that used to work, and context from earlier requests can get lost. | The ratchet: tests that only tighten, the same test cases run in the client and in the backend, CI gates that stop the release on any regression. |
| Traceability | The app’s history lives in the chat: which request changed what, and why, is rebuilt by rereading the messages. | Cockpit keeps the thread: every request in the words of whoever made it, the requirement a person confirmed, the commits and tests that cite it, the verdict on the release. A file can be traced back to the requirement that asked for it. |
| Stack and ownership | Hosting, database and tooling are those of the platform. Code export and limits depend on the provider and the plan. | A standard stack: React, TypeScript, Postgres on Supabase with Row-Level Security, Deno edge functions. The code lives in a git repository, readable and portable. |
| Lifecycle | Each app starts from its own prompt: what one project learned does not carry over to the next by itself. | Each project leaves tested modules (sign-in, telemetry, AI spending cap, security), tests and lessons the next one starts from. |
Read in full: The method
02 · Comparison
Tools such as Spec Kit and Kiro work on the first half of the loop: they turn a request into a specification, then into a plan and tasks for the agent, before any code is written.
| Axis | Spec tools | The method |
|---|---|---|
| Where they work | Before the code: request, specification, plan. | After the code: tests that only tighten, a guard test for every incident, probes in production, a person’s verdict. |
| What remains | A specification that describes what to build. | Numbered requirements tied to the tests that prove them and the releases that contain them, in Cockpit. |
| Who decides | Whoever writes the specification approves it before the agent starts. | A person confirms the requirements and decides every release, with the evidence in front of them. |
They work together: a specification written with one of these tools can be the request the loop starts from, and the method adds what happens next.
Read in full: What the specification covers
03 · Comparison
The most common way to keep an agent in check is to read every pull request it opens. It works as long as the code to read fits in a person’s time.
| Axis | Review by hand | The method |
|---|---|---|
| What the person reads | Every changed line. | The evidence: which requirements the change touches, which tests passed, which ceilings tightened, which incidents are still open. |
| What remains afterwards | A comment on the pull request. | A test: every mistake found becomes a check that runs on every push. |
| When it falls short | When agents write more code than a person can read with care. | Control moves from lines to rules; the person decides on the release. |
Reading everything is still the right choice for a small codebase, for a change that touches security and when learning a new codebase.
Read in full: The evidence and the verdict, in Cockpit by RiftSeed
04 · Approach
For the lab, a tailored platform is cloud software shaped around the work of the people who use it, with AI inside the product and a person on the decisions that matter.
The parts every platform repeats are written once. The lab’s apps already run on them, and their tests hold them in place.
Read in full: Platforms
05 · Approach
Before any code is written, what is being built has to be clear. A guided AI interview turns an idea or a work process into confirmed requirements.
The AI proposes the requirements and rewords them after every correction; they can be added, dropped or split in two, and the decision stays with whoever writes the brief.
When the list is settled, the requirements freeze and stay as approved, copied word for word.
The brief is the document the agent implements against and the one the result is read against. If the behaviour does not add up, the comparison is made against the written brief.
Read in full: The brief generator
06 · Approach
A standard stack and, around the code, the rules of the method: a gate before every release, ceilings that only go down, probes on the published site, a guard test for every incident.
Read in full: The rules of the method