Ratchet Agentic Engineering: why it covers the second half of the loop
· 6 min read · metodo, agentic-engineering, cricchetto, harness-engineering
Spec tools carry a request as far as the code. The method covers what happens next: ceilings that can only go down, a guard test for every incident, probes on the published site, and a release decided by a person.
At 00:33 on 7 September 2026, Seantral’s error telemetry recorded “Minified React error #310”: a component had called more hooks than on the previous render. In GoodWindowTimeline a hook had ended up below an early return. At night, for swimming, the list of hours was empty and the component returned before reaching it. As soon as the list filled up, the hook was called and React crashed.
The lint rule that catches this mistake, react-hooks/rules-of-hooks, was already configured, as a warning. In CI the full lint does not block a deploy, because of an old backlog of explicit any types.
The same day, npm run lint:hooks was added: it runs that one rule at error level over all of src, inside the quality job the deploy depends on. The fix moved one line in one component; the rule keeps the same mistake out of every other file.
Ratchet Agentic Engineering, the method the lab works by, is mostly about this part of the loop: what happens after the code is written.
Where spec tools stop
GitHub’s Spec Kit takes a request to a written spec, then to a technical plan and a task list that an agent works through. Kiro, the AWS development environment, keeps three files per feature under .kiro/specs, for requirements, design and tasks. Both work on the road from intent to code.
With error #310, a sharper spec would have changed nothing. The fault was the position of one line, and it only surfaced in production, at night. The method covers the second half of the loop: what stops a change before release, who decides the release, what happens when something breaks, and how the mistake is kept from coming back.
The two halves can be used together. A spec written in Kiro, for instance, can become the numbered requirement list the method starts from.
Ceilings that only go down
In the method, a ratchet is a test with a number in it. The test accessibilita.test.ts counts the eslint-plugin-jsx-a11y warnings in Seantral’s code and fails when they exceed the ceiling written in the file, the count of 2 October 2026. Removing a warning means lowering the number; adding one means fixing the code.
Copy gets the same treatment. The test credibilita.test.ts reads the site’s public pages and the articles of this diary, and fails on a first-person verb or an em dash. A sentence that fails gets rewritten.
A ceiling written in a file has a weak spot: whoever can edit the test can also raise it. In Cockpit by RiftSeed, the tool where the lab applies the method, the ceilings live on the server, in a table that only accepts new rows. A CI reading that reports a ceiling above the one on record turns the gate red with ceiling_raised_without_decision. Raising a ceiling takes one function, which requires a signed-in person and a written reason, and records the decision. No MCP tool calls it.
A test for every incident
In Cockpit a failure becomes an incident, and the incidents table has a database constraint: the resolved state needs both the fix commit and the guard test. When the Commander, the agent that assigns tasks inside Cockpit, closes one, the check goes further. The commit must have a gate run on the release branch, and the guard test’s latest result must be a pass. An incident can also be dismissed, with a written reason.
Probes on the published site
Tests run before release; probes run after, against the production site. They are Playwright scripts, in scripts/sonde, that replay real scenarios on desktop and phone and count errors, blank pages and crash screens. On 21 September 2026 one of them found a Seantral crash: the thunderstorm circles were mounted before their map pane existed, and Leaflet fell over.
The probes have a declared limit. A bundle wired to the wrong backend, while the page still answers, slips past them. That case has a guard before the build: guardia-backend-seantral.mjs stops Seantral’s build when the backend address is not its own.
The verdict
In this repository, a release is a push to main. The deploy job depends on the quality job, which runs the typecheck, the Vitest suite, the Deno tests of the edge functions and the hooks lint. If any of them is red, nothing goes live.
In Cockpit, a release waits for a person’s verdict. An agent can only ask for it, with verdict.request, which returns the page where the person approves or rejects. That page holds the result of every gate check, the requirements the release carries, the address where it can be tried, and the open incidents. Approval needs a green gate, and while an incident is open the approve button does not appear. Rejection needs a note.
What it shares with harness engineering
On 5 February 2026 Mitchell Hashimoto described a habit he called “engineer the harness”: every time an agent makes a mistake, build something so that it never makes that mistake again. It can be a line in AGENTS.md or a real tool, such as a script that runs only the relevant tests. On 2 April, on martinfowler.com, Birgitta Böckeler split the controls around an agent into guides, which steer it before it acts, and sensors, which observe afterwards.
The method starts from the same habit, and the hooks rule of 7 September is a sensor in Böckeler’s sense. What it adds sits outside the agent. Ceilings and incident closure are database rules, and no tool in the protocol gets around them. The loop carries on past the merge, into production, through the probes. The release is decided by a person. And commits carry a Refs: line with the requirement key, so a file or a test traces back to the request it came from.
Where it comes from, and what is missing
Some of the practices come from safety-critical software, the kind written for aviation and cars: numbered requirements confirmed by whoever answers for them, a trace from requirement to code to test, impact analysis before every change, a problem report that closes with evidence, a release authority. In those industries they are expensive. Code agents bring the cost down far enough to use them on a sea-conditions app.
The formal guarantees of those industries are absent here. No verification is independent of whoever wrote the code. Structural coverage is not measured; what is counted today is how many requirements a test cites. Assurance levels are not defined yet. And the person who confirms the requirements is the same one who decides the release.
Written the way everything in this lab is built: with AI, then edited and approved by a person.