Wyzer Logo ← Back to Blog

Software is obedient, not psychic

The Delay Starts Before Software. (Part 2 - From Clay to Code) The cost of vague requirements is invisible until the worst possible moment: integration, validation, and certification. That is when the bill for "moving fast" arrives. AI has made this easier to explain. Vague prompts lead to "hallucinations" or garbage output. Structured prompts with constraints lead to excellence.

By Peter Virk January 7, 2026 5 min read

Software is obedient, not psychic.

The Delay Starts Before Software

( Part 2; From Clay to Code)

Image

In the last post, “From Clay to Code” I talked about how we all recognize physical rework. You can see it, touch it, and feel the cost when a late change hits tooling or manufacturing.

But we still underestimate the Software Ambiguity Tax.

The cost of vague requirements is invisible until the worst possible moment: integration, validation, and certification. That is when the bill for "moving fast" arrives.

The Diagnosis: Why Programs Slip

When a timeline slides, the default labels are:

  • Software is late.

  • The supplier underdelivered.

  • Integration is hard.

Sometimes that’s true. But usually, the slip started months earlier with unresolved decisions and untested assumptions. If instructions are vague or contradictory, software will not fix them. It will implement them exactly as written.
Image

The AI Mirror

AI has made this easier to explain. Vague prompts lead to "hallucinations" or garbage output. Structured prompts with constraints lead to excellence.

Software teams are no different. They don’t need more tools; they need better inputs.

A 10-Point "Requirement Readiness" Gate

Before you commit to a build, pressure-test your requirements. If you can’t answer these, you aren’t ready to code:

1. Capability Owner: Is one person actually accountable?

2. Explicit Scenarios: Is the "why" and "how" mapped out?

3. Written Assumptions: Are they out of people's heads and on paper?

4. Upfront Constraints: Are Safety, Cyber, and Regulatory baked in early?

5. Interface Ownership: Who owns the "handshake" between modules?

6. Acceptance Criteria: What does "done" look like?

7. Non-Functionals: Have you defined boot time, power, and reliability?

8. Fallback Behaviour: What happens when it fails?

9. Unambiguous Handover: Is the supplier contract testable?

10. Testability: If you cannot test it, you cannot build it.

The Question for Leaders

If you had five working days to lift your requirements quality by 20%, where would you start?

  • Tightening the governance gate?

  • Clarifying ownership?

  • Better tooling?



Why this matters at WYZER: We help teams close the gap between intent and execution. We surface these risks early, before they become expensive "software delays." If you're looking to pressure-test an RFQ or a capability pack, let’s talk.

Email: info@wyzer.it

About the Authors