Spec hardening
Requirements, constraints, non-goals, edge cases, and acceptance criteria are made explicit before build.
Tempest AI
How Tempest works
Harness and loop engineering is how expert users prevent that failure path.
AI-native users manually add project instructions, clarify specs, split context, assign roles, force review, route repairs, and preserve run memory. It works, but it is operational work.
How the harness fixes it
The harness turns a single prompt into an engineered control loop.
The goal is not a bigger prompt. The goal is a managed delivery loop with explicit specs, bounded context, independent verification, targeted repair, and memory.
Assumption ledger
Hidden guesses become visible and approvable instead of becoming surprise product behavior.
Context partitioning
Bigger work is split into bounded tasks with input and output contracts.
Role-specialized agents
Planner, builder, verifier, and delivery decision roles stay focused on different responsibilities.
Verifier-driven repair loop
Functional, visual, and content checks produce evidence, then failures route to the smallest repair.
Regression and run memory
Approved specs, style, layouts, report formats, and workflow choices persist across runs.
Role separation matters
One prompt should not be builder, judge, product manager, and customer.
AI performs better when the role is narrow. A build prompt can miss the same blind spot twice if it also grades itself, so Tempest separates production, inspection, and delivery decisions.
Builder prompt
Build the bounded task.
Produce handoffs and stay inside scope.
Verifier prompt
Inspect against specs.
Do not repair. Report evidence and defects.
Delivery decision
Decide the next route.
Accept, repair product, repair packaging, retry verification, or block.
Proof discipline
Evidence, not hype.
Tempest compares work against raw frontier-agent usage by normal prompts, not expert users with perfect project instructions. Every run leaves an inspectable trail.
A visitor can see what changed, what failed, what was repaired, and what remains true at delivery time.
- Request Turn a rough product request into a launch-ready landing page.
- Contract Clear first viewport, preserved conversion flow, responsive layout, accessible form, no dead sections.
- Verifier finding The first CTA was too easy to miss, and the fallback path needed a clear next action.
- Repair route Move early access up, add a delivery trail, and test both served and static paths.
- Delivery Changed files, checks run, and remaining limitations travel with the final package.
| Claim | Baseline result to compare | Tempest evidence record |
|---|---|---|
| Specification gapsRaw agent guesses missing details. | Same prompt in a raw agent produces plausible but assumed behavior. | Blocking questions and safe assumptions are recorded before execution. |
| Production defaultsNo placeholders by default. | Raw agent ships mock data, fake buttons, or "coming soon" sections. | Verification catches unfinished behavior and routes repair before delivery. |
| Functional coverageAll requested flows work. | Raw agent misses export, mobile, validation, or a secondary workflow. | Specs map to tasks, and findings map to targeted repairs. |
| Repeatable reportsSame layout across runs. | Chat output drifts after corrections and context grows. | The approved report contract is stored and reused run after run. |
| User-facing qualityNot just technically working. | Raw agent passes basic checks but leaves confusing UX or weak trust signals. | User-facing review flags clarity, confidence, and first-user comprehension issues. |
Requested outcome, constraints, non-goals, edge cases, acceptance criteria, and approved assumptions are captured before build.
When a flow fails, the record names the route, response, viewport or interaction, and the smallest repair owner.
The final package lists changed files, checks run, remaining limitations, and the exact output path to inspect.
Get early access now.
Try Tempest