How Much Should You Verify Before Relying on AI-Assisted Work?

You can either spend time verifying your code or spend time troubleshooting it.

With AI-assisted coding, you can write a detailed spec, agree on what the feature should do, test it yourself, and build a repeatable set of checks around that workflow. You can also write the spec, let the agent build it, and keep working until you notice a bug.

Both approaches are valid. The choice depends on how important the feature is, which constraints it has to respect, its security requirements, and how directly other people will encounter it. It also depends on whether you can afford to discover a problem while using it.

Write the spec, then check the behavior

A good spec describes the behavior you want clearly enough that you can tell whether the finished code delivers it. Include what the feature should do, what must stay unchanged, and the conditions it needs to handle.

NIST’s systems engineering guidance describes verification as using objective evidence to determine whether specified requirements or characteristics have been met. That means deciding what must be true, how you will check it, and what result will count as success.

“Check the output” is too vague. “Confirm that every quoted figure matches its linked source” identifies both the requirement and the evidence. Give a coding spec that same specificity about the behavior you expect.

The litmus test is whether you and the agent agree on that behavior, then whether you can confirm it yourself. Work through it in this order:

1. Write the spec. Describe the intended use and the constraints that matter. Include security requirements where they apply.
2. Agree on what working means. Have the agent explain what it will build and how it will check the result. Resolve differences in that understanding before implementation.
3. Try the behavior yourself. Use the feature for its intended purpose. Inspect the actual code changes and results, including the parts where a mistake would matter.
4. Sample the results. Check representative cases and the important exceptions described in the spec. Keep track of what the sample leaves unexamined.
5. Keep the useful checks. Put them into a test harness, a repeatable set of tests and steps you can run as the code changes. Keep your own inspection where it still tells you something those checks cannot.

The NASA Systems Engineering Handbook distinguishes meeting specifications from accomplishing the intended purpose. A script can follow every written instruction and still be unsuitable for the environment where you plan to run it. Testing it yourself helps you check whether the spec described the thing you actually needed.

Build it and troubleshoot as you go

You can also write a spec, build the feature, and start using it with fewer checks beforehand. When a bug appears, you investigate and fix it. This approach makes sense when you can tolerate discovering problems during use and can repair or undo the change without much disruption.

The spec still matters. It gives you a starting description of what the code should do, including any constraints and security requirements. You leave more of the checking to use, then revise the code or clarify the spec when the result falls short.

Google’s guide to effective troubleshooting describes a process that starts with an observed problem, develops possible explanations, and tests them. For a coding workflow:

1. Describe the bug. Record what you expected, what happened, and how to reproduce it if you can.
2. Inspect what happened. Look at the relevant code, output, and available logs.
3. Test an explanation. Choose a plausible cause and check whether the evidence supports it. Some tests will narrow the possibilities without settling the cause.
4. Repair the behavior and update the spec where needed. Check the fix, and keep a repeatable test when it will help catch the same problem later.

Troubleshooting can remain uncertain, especially in a complex system. Keep notes on what you tried and what the results established so you can continue the investigation without repeating it.

Check the parts that can still go wrong

A feature can do what you asked and still leave an important problem behind.

Cognition reported an example in its FrontierCode 2.0 evaluation. In a Mock Service Worker task, a repair made the next request restart as requested by discarding the old generator reference. The old generator was not closed, however, so its finally cleanup never ran.

Checking that the request restarted would have confirmed the visible behavior while missing the cleanup problem. This is Cognition’s reported evaluation, not a result independently reproduced here or a conclusion about the benchmark as a whole. It illustrates why the constraints and side effects that matter belong in the checks.

The public Article Flow repair in commit 0622893 shows another kind of check. It examined the dispatched task, accepted output, gate receipt, selected route, and hashes binding those records together. The records show that the controller accepted the work. They do not independently establish server-side model execution.

When you build a harness, be clear about what each check establishes. A completed run, an accepted result, and a feature behaving as intended answer different questions.

Choose how much to check before use

Spend more time checking beforehand when the feature is important to someone’s work, a mistake would violate a constraint or security requirement, or the change would be hard to undo. Consider who will encounter a failure and how visible it will be. Code that can alter important data deserves close review even if few people see the feature directly.

For a less consequential, easily reversible change, you may prefer to build it, use it, and troubleshoot what you find. You are choosing when to spend the checking effort and which problems you are willing to discover during use.

Time and expertise matter too. NIST’s systems security engineering guidance treats feasibility, qualified personnel, complexity, cost, and time as constraints on verification. Choose checks you can perform and interpret, with enough attention to the behavior that matters.

Neither workflow covers every condition. A spec can miss something, a sample can leave a case untested, and a test can check the wrong behavior. Record what you checked, what passed, and what remains uncertain. Preserve a way to roll back, recover, or continue troubleshooting.

When the result depends on the current behavior of a model, tool, configuration, documentation, or dependency, check that behavior again before relying on it. Repeat the checks that the change makes relevant.