Start with behaviour, not confidence

A model can explain its output fluently and still miss a boundary condition, misunderstand an API contract or produce a fix that only works for the example it saw. The useful question is specific: what must this software do, with which inputs, under which conditions?

Write the expected result before running the check. If the question cannot be stated clearly, the result will be difficult to defend.

Use a five-part verification process

  1. Define the decision. State what will happen if the check passes, fails or remains uncertain.
  2. Fix the scope. Identify the component, behaviour, inputs, environment and version being examined.
  3. Choose discriminating checks. Include normal use, meaningful boundaries and a case likely to expose the suspected failure.
  4. Preserve evidence. Record commands, inputs, outputs, logs and relevant code changes so another person can inspect the result.
  5. State the limit. Describe exactly what the evidence supports and what was outside the check.
A passing test is evidence for the tested condition. It is not proof that every surrounding behaviour is correct. Good verification keeps that boundary visible.

What should be checked?

Requirements and assumptions

Compare the implementation with the actual requirement, not only the prompt used to generate it. Check assumptions about units, time zones, data shape, permissions, network state and error handling.

Boundaries and failure paths

Exercise empty values, maximum sizes, invalid states, retries, partial failures and incompatible versions where they are relevant. Many AI-generated defects live just outside the happy path demonstrated in the prompt.

Regression risk

Confirm the proposed change fixes the target issue without damaging a nearby behaviour. A narrow regression check is often more useful than a broad test that cannot isolate the cause.

Dependencies and generated interfaces

Verify that library versions, API contracts, schemas and configuration match the environment in which the code will actually run.

When independent verification helps

Independent review is useful when the author and reviewer share the same assumptions, the release affects a customer commitment, a regression keeps returning, or the team needs a clear external account of what the evidence supports.

Spotted Ridge Engineering begins with one agreed question. The standard AI-generated code verification service is A$249 for one issue; broader workflow checks are scoped separately.

Continue reading