Pre-Flight Spec Authoring

Problem

Agents handed an underspecified prompt produce code that runs but does not match what the team needed: assumptions get baked in silently, edge cases get skipped, and the team discovers the gap during review or in production. Quoting the Norwegian source: agents 'ignorerer instruksjoner, de produserer kode som fungerer men ikke nødvendigvis er vedlikeholdbar' — they ignore instructions and produce code that works but is not necessarily maintainable. The team needs a way to do the thinking up front and to make the agent challenge that thinking before it writes code.

Solution

Author the spec along five pillars: context (why this work, what surrounds it), requirements (what must be true), constraints (what must not be done), examples (concrete inputs and outputs or code shapes to mirror), and definition-of-done (the gate the loop must pass). Then run an explicit model-critique step in which the agent reads the spec and lists ambiguities, missing edge cases, internal contradictions, and unstated assumptions; the human resolves each before code generation begins. Store the finished spec in the issue tracker (or an equivalent durable artefact store) so every later iteration and every human reviewer reads the same target. Only then hand the spec to the implementation loop.

When to use

• The change is non-trivial and underspecified prompts are likely to produce wrong-shape code.
• The team has a durable artefact store (issue tracker, repo) that humans and agents both read.
• An agent capable of honest critique is available for the spec-review step.
• Downstream loop iterations will read the spec as their authoritative input.