Choosing proportionate checks for each AI coding task

Choosing proportionate checks for each AI coding task means giving every task at least one explicit check that would fail if the task's criterion were not met, plus a fast baseline that runs everywhere, and widening only when the change reaches shared or risky code. Running the full suite on every small agent task wastes time and buries the one check that matters in a wall of green. Running nothing beyond "it compiles" lets broken work through. The middle path is a short decision you make when writing the task, not after the agent finishes. This workflow gives you the steps, a few worked examples and the triggers that should make you widen the check set. It pairs with writing tasks an agent can finish, since a clear criterion is what makes a proportionate check possible, and with why narrow acceptance tests miss regressions, which covers what happens when the check set is too small.

Step 1: turn the criterion into a check that can fail

Start from the task's acceptance criterion and ask: what command would exit non-zero if this were not done?

For a bug fix, that is a test reproducing the bug. For a new function, a test of its contract, including at least one edge case. For a configuration change, a script that loads the config and asserts the new value. For a documentation change, sometimes nothing more than a link checker or a docs build.

Then prove the check can fail. Run it against the code before the change and confirm it fails for the right reason. A check that already passes on the untouched code proves nothing about the change. In BRAIN FLUID's own benchmark work (October 24-27, 2026), each of six synthetic coding tasks had an independent correctness check that failed on the untouched fixture, and all 24 counted runs then passed it. That ordering is what made the passes meaningful.

Write the check into the task text: "Done when tests/test_invoice.py::test_negative_discount passes; it fails before the change." If you cannot write a sentence like that, the task is probably not ready for an agent.

Step 2: add a fast baseline that always runs

Alongside the task-specific check, keep a baseline that runs on every task regardless of size: the build or type check, the linter and the fast unit tests. Its job is not to prove the criterion. It catches the collateral damage agents commonly cause: a broken import, a syntax error in a file touched in passing, a formatting rule ignored.

Keep the baseline fast enough that nobody is tempted to skip it, ideally a couple of minutes. If it grows slow, split it: the fastest subset per task, the rest in CI.

The task check and the baseline together are the default. Most small tasks need nothing more. Three examples:

Rename a button label. Task check: a component test or snapshot asserting the new label. Baseline: build and lint.

Fix a date parsing bug. Task check: a unit test with the failing input from the bug report. Baseline: build, lint and unit tests.

Add a field to an API response. Task check: a contract test asserting the field and its type. Baseline as above, plus the tests of the client that reads the response, because that client is a consumer. That last addition is already the start of widening.

Step 3: widen when the change reaches shared or risky code

Widen the check set when any of these is true, and say so in the task.

The change touches shared code: a helper, a base class, a schema, a utility module imported in several places. Add the tests of the known consumers, and if you are not sure who the consumers are, run the full suite. The October 30, 2026 regression probe on a BRAIN FLUID development build shows why: a money helper changed from rounding to truncation, the checkout check passed, and an export check that used the same helper failed. See estimating the blast radius of a change.

The change alters a public interface, a data format or a migration. Add contract tests and a round trip on realistically shaped data.

The change involves money, authentication, permissions or deletion. Add the relevant integration tests and route the result to a person, as covered in deciding which tasks need sign-off.

The agent changed files outside the declared area. Whatever it touched now needs its own checks.

The full suite still runs at merge or release. Proportionate checks decide what gates each task, not what gates the product.

Step 4: record the checks with the result

Write down which checks were chosen, why, and what they returned on which revision. One line per task is enough: "Checks: test_negative_discount (task), build, lint, unit (baseline). Widened: no, change local to invoice.py. Result: pass on 9c1e0b2."

The record serves two purposes. It lets a reviewer see at a glance whether the check set was proportionate, which is easier to judge than whether the code is right. And when something breaks later, it shows whether the failure was outside the chosen checks (a coverage decision to revisit) or inside them (a check that was wrong or stale).

Over a few weeks these lines also show patterns: the modules that always need widening, the tasks that never had a failing-first check, the baseline that keeps getting skipped. Those are the places to invest in better tests.

BRAIN FLUID keeps recorded attempts and outcomes with the work [C4], and its Build workspace brings checks together with the project goal and current work, tracks implementation and acceptance separately, and leaves missing or stale checks visible [N02].

QUESTIONS

Should an AI agent run the full test suite for every task?

Not necessarily during the task. Give each task one check that proves its criterion plus a fast baseline, and widen to the full suite when the change touches shared code, interfaces or risky areas. The full suite should still run before merge or release, because that is where breakage across tasks shows up.

How do I write a test that proves an AI agent fixed a bug?

Reproduce the bug first. Write a test using the input from the bug report, run it against the unfixed code and confirm it fails for the reason described. Then let the agent fix the code without editing that test. A pass now means the reported behavior changed, not just that the agent wrote a test it could pass.

What is a baseline check for AI coding tasks?

A small, fast set of checks that runs on every task regardless of size, typically the build or type check, the linter and quick unit tests. It does not prove the task's criterion. It catches collateral damage such as broken imports or syntax errors in files the agent touched in passing.

RELATED GUIDES

• How to read project progress in BRAIN FLUID Build
• How to create a project card in BRAIN FLUID Desk

RELATED HARNESS PAGES

• Why narrow acceptance tests miss AI regressions Why narrow acceptance tests miss AI regressions: a task's check can pass while a shared change breaks another consumer. A worked example and a fix.
• How to write a task an AI coding agent can finish How to write a task an AI coding agent can finish: one outcome, a scope, dependencies, completion criteria and the check that proves them.
• Stale test results Stale test results describe code that has since changed. Bind each result to a revision and rerun checks on every completion attempt.
• The blast radius of AI code changes The blast radius of AI code changes: what one agent edit can break elsewhere, a worked rounding example, and how a reviewer finds affected features.
• Deciding which AI agent tasks need human sign-off Deciding which AI agent tasks need human sign-off: a risk-based policy, who signs off what, and why DONE is not the same as released.