PATTERN Cited by 2 sources

Verify before changing code

Definition

When an automated coding agent acts on a ticket, treat the ticket as context, not as proof of the current state of the code. The agent's first step is to search the repository and confirm the world still matches what the ticket assumes — before making any edit. If reality disagrees (the target is already gone, its value changed, or the situation is ambiguous), the agent stops and reports rather than applying a stale change.

"A cleanup ticket is useful context, not proof that the codebase is unchanged. Search for the flag and confirm its final state before making edits." (Source: sources/2026-09-24-atlassian-how-we-automated-feature-flag-cleanup-with-agentic-pipelines)

Why

Tickets are generated at one point in time; codebases move continuously. Between ticket creation and agent execution, developers touch adjacent code, other rollouts complete, values flip. In Atlassian's feature-flag cleanup:

"Repositories move fast and devs frequently [touch] adjacent code, the repo state can diverge from the initial rollout plan. Sometimes the flag had already been removed; sometimes its final value had changed. That is why verification became the first step in the workflow, not an optional safeguard."

A blind edit driven by a stale ticket is worse than no edit: it can re-introduce dead code, delete the wrong branch, or produce a plausible-looking-but-incorrect PR that consumes reviewer trust. Making verification the first step (not a downstream check) also makes runs naturally idempotent — a second run over an already-cleaned flag detects "nothing found" and stops, instead of thrashing. (concepts/idempotent-operations)

Shape

1. Read the structured context from the ticket (e.g. flag name + final value).
2. Search the repo for it before editing. Look for both the identifier and its expected state.
3. Branch on what you find:
4. Not found → stop; the change may already be done.
5. Found, but state disagrees with the ticket (e.g. final value is the opposite of what's assumed) → stop and ask / escalate.
6. Ambiguous survivor (unclear which branch to keep) → stop and ask.
7. Found and consistent → proceed with the bounded change.
8. Re-validate at the end — run the repo's checks; if they can't be made to pass safely, stop and report rather than open a broken PR (patterns/tests-as-executable-specifications).

The escalation cases are chosen deliberately: they are exactly where a wrong automated edit is most damaging (deleting a live branch, guessing a survivor), so those route to a human (concepts/human-in-the-loop).

Seen in

• sources/2026-09-24-atlassian-how-we-automated-feature-flag-cleanup-with-agentic-pipelines — canonical wiki instance and the source of the "verification is the first step, not an optional safeguard" framing. The flag-cleanup agent searches for the flag name and final value before any edit; stops if the flag is already gone; and the skill explicitly escalates "if the final value is false, or the surviving branch is unclear."
• sources/2026-08-28-atlassian-agentic-automation-in-practice-putting-standard-engineering-work-on-autopilot — the vulnerability-remediation agent likewise verifies the current codebase before changing anything and stops-and-reports when the ticket and code disagree or a safe passing change can't be produced — the same verify-first discipline inside the Dispatcher → Coding Agent → Closer loop.

Related

• patterns/dispatcher-coding-agent-closer — the loop this safety step lives inside.
• concepts/idempotent-operations — verify-first makes re-runs safe.
• concepts/human-in-the-loop — ambiguity escalates to a human.
• concepts/feature-flag — the stale-flag-cleanup workload.
• patterns/tests-as-executable-specifications — the end-of-run validation gate.
• systems/rovo-dev — the coding-agent runtime that applies it.
• companies/atlassian