AI Engineering

AI Proposes, Measurements Decide: Building Evidence-Driven AI Systems

articleSeptember 30, 2026By Ali Haghighi

Engineering Reliable AI Systems, part 1

If a model tells me a code change made an application slower, my first question is: compared with what?

A convincing explanation is useful, but I still need the baseline, the new measurement and the conditions under which both were collected. Without those, I have a hypothesis dressed up as a result.

While building AI-assisted engineering tools, I have found one boundary particularly useful:

AI proposes. Measurements decide.

The phrase needs a qualification. Measurements can be noisy, incomplete or misleading. They do not settle every question, and they rarely establish a root cause on their own. What they give us is a way to check a claim without relying on how confidently a model presents it.

Start with a decision that does not need a model

Suppose a benchmark has a baseline mean of 100 ns. A later run reports 106 ns, and the configured regression budget is 5%.

The arithmetic is straightforward:

Change = (106 - 100) / 100 × 100 = 6%
Budget = 5%
Result = budget exceeded

There is no reason to ask an LLM to calculate that result or decide whether six is greater than five. Ordinary code can do it consistently, cheaply and with an exact record of the inputs.

That result means the observed mean exceeded the configured budget. It does not, by itself, prove the code change caused a repeatable slowdown. Before reaching that conclusion, I would check whether the runs are comparable, inspect the variation and repeat the measurement where necessary.

AI has a more useful job here: explain the change, suggest which execution paths to inspect and help plan a follow-up experiment. The policy check and the investigation answer different questions.

Give the explanation something to point to

An answer such as “memory allocation increased significantly” leaves too much work for the reader. Which operation? Which runs? What changed?

I prefer to build an evidence record before asking for an explanation. For a fictional allocation comparison, it could look like this:

{
  "baselineRunId": "example-baseline",
  "currentRunId": "example-current",
  "operation": "SerializeOrder",
  "metric": "AllocatedBytesPerOperation",
  "baseline": 1024,
  "current": 1280,
  "changePercent": 25,
  "budgetPercent": 10,
  "status": "BudgetExceeded"
}

The application calculates the percentage and status. The model receives the record and can refer to its run IDs when explaining the result. Environment details and the underlying samples should remain available for anyone checking the comparison.

This also makes it possible to challenge the explanation. If the model claims that latency increased, but the supplied evidence only covers allocation, the system can flag the unsupported claim. A longer answer would not fix the missing evidence.

The evidence should remain useful when AI is unavailable. A report with measurements and a budget result still has value if a model request times out.

A tool result is evidence, not an instruction

Tool calling gives a model access to information it would otherwise have to guess. That is valuable, provided the application still controls access and validates the requests.

For example, the model might request CPU measurements for a service around a deployment. The application checks the service and time range, calls the monitoring provider and returns the observed values. An empty response stays empty. A failed request stays a failure. Neither should quietly become zero CPU usage.

The same boundary applies to the text returned by tools. Logs, issue descriptions and commit messages can contain arbitrary instructions. Those strings are data to examine, not permission to change the system's behavior.

A model can propose the next query. The application owns which queries are allowed and how their results are handled.

Keep causes provisional

Imagine CPU rises shortly after a deployment, then latency increases and errors follow. That sequence is worth investigating. It is not enough to conclude that the deployment caused the incident.

A useful AI explanation would identify the timing, name the evidence and propose checks: compare request volume, inspect the changed code paths, examine expensive operations and look for dependency failures in the same window.

An unhelpful explanation would announce a root cause and recommend rollback without acknowledging what is missing.

I want the output to make that distinction visible. Observed changes, possible explanations and proposed actions should be easy to tell apart. If an action can affect production, its execution needs its own policy and verification. Generating a recommendation does not authorize it.

Test the boundary as well as the answer

Unit tests cover the arithmetic, budget rules and evidence handling. They cannot tell me whether a new prompt produces better explanations.

For that, I need evaluation cases. A small set can already expose useful failures:

• A comparison with missing baseline data should not produce a percentage.
• A CPU spike without deployment evidence should not become a deployment-related root cause.
• A failed tool call should not be described as a healthy service.
• A log containing instructions should not redirect the analysis.
• A suggested action should refer to evidence the system actually has.

Some of these checks can be automated exactly. Others need a rubric and human review. I would not treat a model grading another model as unquestionable evidence either.

When a prompt or provider changes, I can run the same cases and inspect what improved and what broke. I also want to know whether the improvement costs more tokens or adds enough latency to make the feature less useful.

Where I draw the line

Before adding AI to an engineering decision, I ask whether the available data and explicit rules are enough to make it. If they are, I put that decision in code.

When the work involves interpreting several signals, explaining an unfamiliar result or choosing a useful experiment, a model may help. Its contribution should be checked against the evidence, and uncertainty should survive into the answer.

That is the role I want AI to play in these tools: shorten the path from a measurement to an investigation I can verify.

The next article in this series will look at building a small evaluation harness and deciding which failures are worth testing first.