Why now
The usual worry is that a spec is scaffolding a strong model has outgrown — training wheels for a system that can ride. It's the opposite. Specline helps more as the model gets stronger, because the thing it rations — judgment, context, and a falsifiable definition of done — is exactly what even a frontier model still can't hand itself.
One-shot lives in the pair, not the model
Frontier models advertise first-shot correctness on complex, well-specified problems. Read the qualifier. One-shot isn't the model reading your mind — it's the model, handed a problem specified well enough that the answer is already determined, producing it in one pass instead of ten. The bottleneck didn't vanish when models got better. It moved — out of the model's reasoning and into the spec you hand it.
One-shot is a property of (model × spec), not of the model. Specline manufactures the spec half.
A vague prompt doesn't one-shot. It confidently builds the wrong thing, or builds three things you didn't ask for, because nothing told it where to stop. Intent stated, mechanics left out; non-goals named; reserved decisions made up front; a done you can falsify. That list isn't advice. It's the spec body.
The vendor's own guidance draws Specline's boundaries
Here's the strongest evidence the methodology is aimed right. A frontier model's official prompting guide, written with no knowledge of Specline, prescribes the same moves on its own.
| Frontier-model guidance | Specline |
|---|---|
| "Give the reason, not only the request." | Intent over description (B6) |
| "State the boundaries… don't add features beyond the task." | The Non-goals section |
| "Fresh-context verifier subagents beat self-critique; verify against the spec." | The outer loop — a fresh-context verifier against the judgeable checks (each naming a spec section) |
| "Construct a memory system — one lesson per file; delete wrong notes." | status.md + graduated knowledge |
| "Pause for the user only on a destructive action, real scope change, or input only they can give." | The two human gates |
When the vendor converges on your methodology without having seen it, the methodology is tracking something real about how these models work. It isn't an old process in new clothes.
There's exactly one way to get this wrong
The same guides warn that instructions "too prescriptive" for a frontier model degrade its output. So Specline's one failure mode is breaking its own rule. A mechanics-heavy spec — restating what the code will do, enumerating steps the model would choose better itself — measurably lowers a frontier model's quality. Intent over description stops being a tidiness preference and becomes a performance requirement. Specline helps exactly to the degree it stays intent-heavy and mechanics-sparse.
Where this lands
Specline supplies the three things a frontier model can't source for itself — reserved judgment, the right context, and a falsifiable done — and gets out of the way on mechanics, which the model now does better than any spec could dictate. As capability climbs, the margin widens. One-shot was never a rival to this methodology; it's the same claim from the other side. And producing the well-specified half — cheaply, with the model co-drafting — is exactly what Specline is for.