The RiftSeed method
Ratchet Agentic Engineering (RAE) is RiftSeed’s agentic engineering method, for governing AI coding agents with practices taken from safety-critical software, in which the project’s rules are tests that can only tighten and a level chosen at the start sets which decisions need a person’s signature.
Specification 0.11, draft · Version 0.11 · 16 October 2026
The titles of the twelve rules, before and after the code. Which ones apply depends on the project’s level. The text of each, with the why, the check and the limit, is in the full specification.
The level is chosen at the start of the project, according to how critical it is, and sets which decisions need a person’s signature and how strict the automated gates are. Each level includes the ones below it. Next to the level chosen there is the level reached, shown with the evidence kept. Numbering and thresholds are being defined. Cockpit does not compute the levels yet, so the self-check is done by hand.
Comparisons and approach
Four comparisons with other ways of building software with AI, from vibe coding to manual review, then how a platform is built, from the brief to the app.
01 · Comparison
Vibe coding, a term coined by Andrej Karpathy in February 2025, means building software by prompting an agent and accepting the code without reading it, in an open loop where no measure comes back. RAE, RiftSeed’s agentic engineering, puts the same agent inside rules drawn from experience. Every mistake becomes a rule, and rules can only tighten.
| Axis | Vibe coding | The method |
|---|---|---|
| How the work goes | A request in chat, the agent writes, it is tried by hand and accepted. | A requirement with a key, the impact analysis, tests written before the code, the CI gate. |
| What remains afterwards | The code and the conversation. A later change can break what worked, and it shows up while using the app. | A regression test for every fault and ceilings that can only tighten. The quality reached stays. |
| Who decides the release | Whoever wrote the prompt, once the app seems to work. | The project’s level. From level 1 a person approves every release with the evidence in front of them, and no agent approves. |
For a throwaway prototype or an afternoon’s experiment vibe coding is fine, and faster. The closed loop is for software that has to last and change without breaking.
Read in full: The levels of the method
02 · 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. | Every release is a notch that stays, with tests that only tighten, the same test cases run in the client and in the backend, and 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 signed requirement, 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 loop of the method
03 · 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 and the sign-offs the level asks for. |
| 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. | The level, chosen and signed at the start, sets what a person signs; whoever signs has 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: The full specification
04 · 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
05 · Approach
For the lab, a 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
06 · 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
07 · 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
The rules one by one, with the why, the check and the limit of each; the levels with the self-check; the lineage and the glossary. It is reserved, and it is requested by writing to the lab. Write to the lab