How Coding Agents Should Decide What Could Break and What to Test

Updated October 29, 2026

What consumes the response? Does a worker in another repo depend on the old payload? What happens when the frontend and backend are running different versions?

Someone still has to work this out before the change reaches review.

Change impact analysis connects the behavior being changed to the services, contracts, data and business rules it could affect. A coding agent should use that map to choose relevant checks, explain why each check matters and identify what remains unverified. Start with focused feedback, widen verification when dependencies or risks require it, and keep required CI checks in place.

This is where context becomes useful. The agent needs enough understanding of the system to answer a practical question. What could break outside the files I am changing?

Start with the behavior that is changing

Consider an illustrative feature. A billing admin needs to export their organization’s invoices for a selected date range. A background worker prepares the file, and the admin downloads it when it is ready. Viewers should not be able to request or download the export.

The implementation may look like a button, an endpoint and a worker change. Before touching those files, write down the accepted behavior and the rules that must continue to hold.

Which date are we filtering on? Invoice creation, issue or payment? Which timezone applies? If an admin loses access while the export is running, what should happen to the job and the download?

Those are decisions for the accountable owner. The agent should surface them before building tests around its own interpretation.

In my domain-model essay, I wrote about agents needing to understand the meaning of the business concepts they work with. An invoice date can mean different things in different services. A code dependency graph alone will not resolve that.

The first useful output is a short record of the accepted behavior, its source and any open decisions. If the requirement and an older contract disagree, keep that conflict visible.

Trace the change beyond the repository

For the invoice export, follow the user outcome through the system.

Admin selects a date range
    → Frontend submits the request
    → API checks access and creates a job
    → Queue carries the job payload
    → Worker selects invoices and generates the file
    → Storage retains the file
    → Download path checks access again

Each arrow is a boundary worth investigating. What crosses it? Who consumes it? Which contract and deployed versions apply?

Use code references, API and event schemas, deployment configuration, existing tests and relevant architecture decisions to find those relationships. Runtime traces can help confirm observed interactions, although a trace only shows the paths that ran. If a relationship is suspected rather than confirmed, record it that way.

In my earlier account of building a software factory, I described a service emitting created_at while its consumer expected createdAt. Tests passed in isolation. The integration check exposed the mismatch when the services ran together.

That is the kind of boundary the impact map needs to include.

An unchanged service can still be affected. The download service may need no edits, but it belongs in verification if the feature depends on its authorization behavior. The same applies to an older consumer of a changed event.

Keep sources and owners beside the relationships. Give each agent the relevant part of that shared map, including the decisions it must follow. Loading every transcript into every agent makes it harder to find the context that matters.

Turn the impact map into a verification plan

Once the agent understands the affected behavior, it can select checks for a reason.

For the illustrative export, seed invoices before, inside and after the agreed date range, plus invoices belonging to another organization. Establish the expected records from the accepted rule before comparing them with the generated file.

The plan could look like this.

For each selected check, record the risk it addresses and the source of the expected result. If a dependency is mocked, say so. A simulated consumer agreeing with a payload does not establish that the actual consumer accepts it.

The QA verification guide goes deeper into what to establish before handoff. The impact map supplies the reasoning for which scenarios belong in that verification.

Choose the fastest useful feedback, then widen it

Should the agent run unit tests, integration tests or the whole suite?

It depends on the failure we are trying to find and how quickly the check helps us locate it.

I discussed this in my testing feedback-loop post. If a date-boundary test can identify a wrong filter directly, that is useful early feedback. A browser export failure may tell us the flow is broken while leaving the agent to investigate the frontend, API, worker and storage.

Run the focused check while implementing the rule. Then exercise the real boundaries the change crosses. The sandbox guide explains the services, fixtures and access the agent needs to do that.

Broaden verification when a shared component changes, several consumers are affected or the map is incomplete. If the agent cannot identify who consumes an event, it needs more investigation or an owner’s input before claiming a narrow set of checks is sufficient. Required CI still runs.

I would be cautious about claiming an agent can always find the minimum set of tests. First check whether the selected tests catch known regressions and whether broader verification keeps finding failures they missed.

The goal is to detect, locate and fix the relevant failure with useful feedback. Test count alone does not tell us whether that happened.

Keep the map current as agents discover more

Impact analysis continues during implementation and review.

Suppose the Implement agent discovers that another worker consumes the export event. It should add the consumer and supporting source to the impact record, then return the new dependency to the responsible owner. The contract decision and verification plan may both need to change.

If QA finds the exported records are wrong, it should return the expected and observed records, reproduction steps, tested revisions and relevant logs to Implement. After the correction, rerun the checks affected by that fix. Earlier evidence belongs to the revision it tested.

That loop may happen several times. A new finding can require another implementation pass, another contract decision or a wider verification scope.

The coordination backbone article explains the state and handoff mechanics behind this. The practical requirement is that agents work from the current approved decision and artifact revision, with an accountable owner for each material decision.

This is how I think about the shared context layer in Prinevo. It should help agents carry the requirement, contracts, findings and decisions through the change, so the human does not have to reconstruct them between sessions.

Give the reviewer a compact impact record

The reviewer should be able to follow the reasoning from the requested behavior to the checks and results.

For one change, keep these fields together.

• Accepted behavior and its source.
• Affected components, consumers, contracts and owners.
• Confirmed dependencies, suspected dependencies and unresolved decisions.
• Selected checks, their rationale and any important exclusions.
• Tested revisions, environment, results, failures, fixes and reruns.
• Remaining gaps, compatibility assumptions and separate release checks.

A missing credential should appear as a blocked scenario. An untested download path should remain visible. Passing checks in a sandbox establish the behavior checked under those conditions; production rollout and observation remain separate work.

If the agent wrote the implementation and tests from the same mistaken rule, a green result can still mislead. The guide on checking agent-written code and tests explains how to inspect those expectations and assertions.

After review, retain the useful corrections with their source and approval. A newly confirmed consumer can update the system map. A missed boundary may need a regression check. An ambiguous domain rule needs an owned decision. An agent’s guess should not become shared truth just because it appeared in a run.

The guide on how coding agents learn from review feedback follows a missed consumer into a reusable correction and a check on a later run.

Try it on one cross-service change

Before your next cross-service PR, ask the agent to produce the impact record and explain its test selection. Have the responsible engineer review the proposed scope before relying on it.

Then compare the plan with what implementation, verification and human review uncover. Which dependency was missed? Which check caught a meaningful failure? How much context did a person still have to add? Did the reviewer have to rediscover work the agent should already have done?

Use the real-change evaluation scorecard to track human effort and reviewer rework alongside verification results. A shorter test run is useful only if the relevant risks remain covered.

For a Prinevo walkthrough, bring one representative change with a service boundary your team already worries about. Use it to inspect how the delivery workflow connects context, agent handoffs and verification evidence, and where your team still needs to steer the work.