A successful push is useful evidence about Git. It does not tell me that the new JavaScript reached a visitor's browser. I want the assistant's final report to follow the change all the way to the environment the user actually cares about.
In September 2026, an Ace Media player update added version stamps to script URLs because the scripts had a very long browser cache lifetime. That is the sort of fault a source review can miss: the file on the server changes while the browser continues using its old copy.
Write down the deployment route
Before changing code, establish what a push actually does. Does it deploy a test environment, update production, or start a job that someone must approve? Which repository owns the release? A shared plugin and the site that pins its version are often separate steps.
Give the agent the existing deployment instructions. An ordinary feature change should use that process. If it discovers a problem with the pipeline, ask for the evidence and treat a pipeline change as its own scoped task.
Keep each state distinct
- Changed: the intended edits exist locally.
- Committed: those edits are recorded in a particular commit.
- Pushed: that commit reached the remote repository.
- Deployed: the release process put the intended version in the target environment.
- Verified: a relevant check observed the expected behaviour there.
A task can stop between any two of those states. Say where it stopped and why. That makes the handover useful and avoids someone assuming a customer-facing fix is already available.
Check the response and the interaction
For a script change, inspect the asset URL used by the served page, the response and the browser's behaviour. Test a return visit if caching is relevant. For a content change, check the public HTML, canonical URL and the links that bring readers to it.
A status code of 200 means the request succeeded at one level. It does not prove the correct release is present, that a menu opens or that a form submits. Choose a visible marker or behaviour that distinguishes the new result from the old one.
Measure improvements under comparable conditions
If the job is performance work, record what was measured before and after: route, cache state, viewport and relevant load conditions. A fast response from a warm cache should not be described as a universal speed improvement.
Likewise, an implementation commit proves that someone changed the code. It does not prove a percentage improvement without measurements. Ask the assistant to keep observed results and expected benefits separate.
Make the last report useful
State the deployed version and environment, link the affected public route, explain the checks performed there and list any remaining limitations. Preserve a way to reverse the scoped change.
That is the finish line I want from agentic work: a result I can inspect and a clear account of how far it has actually travelled.