Confidence has dependencies

In September, I changed how one of my game’s preview catalogs decided it was stale.

The old decision depended on the overall HTML5 build stamp. Rebuild the game, and the catalog could need regeneration even when the inputs relevant to that catalog had not changed. The replacement used a narrower fingerprint of those inputs.

This is a small engineering detail, but it captures a bigger part of how I think about moving quickly with AI. A useful result has dependencies. I should know what invalidates it.

A green result is a statement about a state

When a check passes, it establishes something about the code, data, configuration, and environment it exercised. It does not create a permanent property called “tested.”

If a relevant input changes, I need fresh evidence. If an unrelated input changes, the previous result may still be useful.

That distinction is especially important when agents can run checks cheaply enough to make indiscriminate repetition feel harmless. The cost can appear in build time, browser processes, resource use, or human attention spent reading another report that says the same thing.

The practical question is what new uncertainty a repeated check will resolve.

Narrow checks require an honest dependency map

A narrow fingerprint is not automatically correct. If it omits an input that affects the output, the tool can report freshness while showing stale material. That is worse than being slow because it gives me a false basis for judgment.

So the optimization has a corresponding responsibility: make the dependency boundary explicit and verify that the freshness behavior follows it.

I want to understand both sides. What change should invalidate the result? What change should leave it valid? Those are useful scenarios for a tool check because they test the meaning of the cache rather than only its existence.

Carry evidence through handoffs

The same principle applies when an agent hands work to another agent. The next session should not have to rerun every check simply because the previous conversation ended.

It should know which state was tested, where the evidence lives, and what changed afterward. If the relevant inputs are unchanged, that evidence can carry forward. If a later edit affects the contract, the appropriate checks become necessary again.

This makes handoff quality part of validation cost. A report that says only “all tests pass” is difficult to reuse responsibly. A report that identifies the build and scenario is more useful.

Fast feedback is an architectural property

I used to think about a test’s speed mostly in terms of how quickly it ran. Now I also think about how often it needs to run and how reliably I can tell when it is necessary.

That depends on architecture, source-of-truth definitions, and tooling. A tightly coupled system makes small changes invalidate large amounts of confidence. Clear boundaries make it easier to preserve what is already known.

The September catalog change did not prove that the entire project became faster by a particular factor. It removed one unnecessarily broad reason to repeat work.

Enough improvements like that can make the daily loop easier to sustain. I want agents spending their capacity on new information, with a precise reason when old information needs to be checked again.

This is one example of building tools that make the next iteration cheaper.