You cannot verify what you cannot reason

To provide more clarity, this post will help you identify where AI-assisted testing is helpful and where you might want to combine it with traditional approaches. We'll cover what it is and how to do it, plus some real-world examples.

You cannot verify what you cannot reason about

Before you can test whether a system behaves correctly, you must be able to say what "correctly" means. You must know what must be true. When you are generating and shipping at the speed of light, this clarity disappears. The codebase, edge cases, and interactions grow too quickly for anyone to develop the mental model required to say what should be true in the first place.

What the software crisis actually was

The "software crisis" was a period in the 60s and 70s when software projects failed at alarming rates. Budgets exploded. Timelines slipped. Systems that worked in testing failed in production.

• •This wasn't a quality problem. The root cause was unmanaged complexity, not incompetence.
• •Because programming had suddenly become too powerful, systems behavior exceeded human comprehension.
• •Codebases outpaced the ability to reason about them, and productivity collapsed.

AI is replaying the crisis, faster

LLM-assisted development lets one engineer produce what once required a team. The output is real, functional code — but the conceptual overhead doesn't scale with the developer. The codebase grows faster than the mental model.

Why "test more" fails as a primary response

The instinct when things break is to add more tests. But tests are only as good as the invariants they encode. If you can't articulate what must be true, you can't write a meaningful assertion. Random coverage doesn't save you from reasoning gaps.

Defining what must be true

The answer is invariant-first development. Before generating code, define the system boundaries: what must always hold, what must never happen, what inputs are valid, what outputs are acceptable. Spectr's eval pipeline forces this discipline — you can't gate a release on a metric you haven't defined.

An old answer to a new problem

The structured methods of the 70s — formal specification, design by contract, layered architecture — emerged from exactly this crisis. The names have changed. The principle hasn't: you can only verify what you can reason about.