AI Can Write the Change. What Accepts It?

Consider a team that uses a coding assistant to repair a checkout failure. The assistant produces a plausible patch and a confident explanation. The reviewer still needs to answer the commercial question: can a customer now complete the purchase without creating a second problem?

That is the right place to introduce DamageBDD. Do not ask the buyer to replace their coding assistant. Give the buyer a repeatable way to accept or reject the change it proposes.

In the 2025 Stack Overflow Developer Survey, 46% of respondents to the accuracy question distrusted AI-tool output, compared with 33% who trusted it. This is evidence of a verification problem, not proof of demand for one particular product. A DamageBDD pilot should test that demand against an actual review bottleneck.

Product and engineering should agree the important outcomes before evaluating a candidate patch. For the checkout example, these might be one successful purchase, rejection of an invalid payment and safe handling of a repeated submission. Those are business requirements, not assertions that an existing step catalogue already implements the whole workflow.

Translate each outcome into supported steps against a controlled target. Unsupported behaviour needs an explicit step implementation. Do not allow the model to invent a sentence, mark it green and quietly redefine success.

The readable runner source contains scenario/background handling, outline processing, failure propagation and checks against catch-all step definitions. Those mechanisms make an explicit acceptance boundary possible; source presence does not establish a passing execution on the buyer's system.

For a first pilot, define a packet containing the agreed feature, target identity, candidate revision, execution configuration, result and report reference. Include the failing baseline as well as the proposed fix. This packet is a proposed handoff convention, not a claim that every field is already populated automatically by every integration.

Keep the tests in a review path separate from the generated patch. A candidate that changes an acceptance assertion should attract attention instead of silently making the suite easier. Keep a small set of independently chosen negative cases that the generator did not optimise against.

The useful output is not a verdict about all possible behaviour. It is a bounded statement: this revision satisfied these checks in this environment, with these exclusions. A failed or incomplete run belongs in the packet too.

Use a disposable service with a known regression. Record the failure, apply a candidate fix and repeat the same checks. Then deliberately break one assertion, submit an unsupported step and interrupt a run. The review path should distinguish failure, unsupported behaviour and missing evidence.

Only after these cases are understood should a CI job consume the result. Define the exact response parsing and deployment policy for the installed release. An HTTP transport success alone must not be interpreted as evidence that the application-level checks passed.

Measure reviewer time, time spent reconstructing the target environment and the number of changes for which the complete packet is available. Compare those observations with the team's existing process. Do not publish a productivity percentage until the pilot has produced one.

This is a good fit for an engineering team already shipping AI-assisted changes to an API or service it controls. A narrow workflow gives the team a clear baseline and makes a failed demonstration inexpensive.

This is not a replacement for code review, security testing or product judgement. A shared mistake in the requirements and tests can still produce a passing result. Independent review matters precisely because the test runner only knows the expectations it was given.

This article is an adoption proposal, not a new validation report. The acceptance-evidence reference explains the existing report workflow and its scope. Current source and runtime results must be pinned before presenting this as a release-specific capability.

Start with one HTTP scenario and the execution manual. Make the first evaluation deliver a clear acceptance result for one change, not a promise that an AI can never be wrong.