You give a coding agent a feature request. It raises a PR the same afternoon.
Is the feature closer to production? Probably. But how much of the delivery work did the agent actually finish?
Someone still has to know which services are affected, whether the change follows the agreed design, which tests matter, what the reviewer needs to see, and how the change can be released safely. Coding agents have made writing code faster. That has made the rest of the path easier to see.
I would trace a change through five questions before calling it delivered.
Feature request
↓ Do we understand the intended behavior and existing decisions?
Plan and affected systems
↓ Are teams, repos, contracts, and agent work aligned?
Implementation and review
↓ What evidence shows the behavior works across boundaries?
Verified change
↓ Who authorizes release, and what must we observe in production?
Production delivery
↓ What did we learn that should improve the next change?1. Did the agent start with the right context?
Consider a request to let account admins change a team member’s role. The UI needs a control. The API needs to enforce who can make the change. An audit event may be consumed by another service. Existing roles and grandfathered accounts may need different treatment.
This is an illustrative feature. The code for a new dropdown may be straightforward. The important questions are elsewhere: which role rules are current, who owns the permissions API, whether an old client still calls it, and what happened the last time permissions changed.
If that knowledge lives in three repositories, a ticket, a chat thread, and one engineer’s head, the agent will need someone to reconstruct it. A longer prompt can help once. It does not make the decision available to the next agent or the next team. The system needs a way to carry current contracts, owners, decisions, and known failures into the work, with enough provenance to correct stale information.
2. Are the handoffs coordinated?
An agent can update the UI while another updates the API. Parallel work is useful only if both use the same permission contract and acceptance criteria. If the API team changes the response shape, the UI agent needs that new revision. If an audit consumer requires the old event field during rollout, implementation and release order need to account for it.
Today a senior engineer often acts as the coordination layer. They remember the dependencies, ask an agent to revise its work, and make sure the pieces are tested together. Those minutes rarely appear in a PR-generation metric.
The change should have one visible outcome, even when many agents or repositories contribute to it. Each handoff needs to say what artifact was produced, which revision it used, what is blocked, and who is accountable for the next decision.
3. What did verification actually prove?
A green unit test may prove that the new API handler returns the expected role. It may not prove that a non-admin is denied, that an old client still works, or that the audit consumer accepts the event. A browser screenshot may show the dropdown while missing the permission rule behind it.
Verification should begin with the requested behavior and the change’s blast radius. For this feature, I would want the permission rules tested, the UI flow exercised with the right users, the API and audit contract checked, and the relevant services run together in a sandbox. If a check fails, the fix and rerun should be tied to the new code revision.
The reviewer then needs a compact answer: what was checked, why, under which conditions, what failed, and what remains unknown. That is stronger than “tests passed.” A sandbox result establishes the scenarios that ran there; production can still behave differently.
4. Who controls release?
A verified PR is not the same as a production change. The team still needs to decide whether old and new versions can coexist, whether a migration or feature flag is involved, which monitor will show a bad role update, and what rollback would actually restore.
Agents can prepare that analysis and gather evidence. The organization sets who may merge, deploy, or approve a sensitive change. It also sets which repositories and environments each agent can access. This is governance in practical terms: named owners, scoped permissions, decision gates, and an action trail that lets the team see what happened.
For low-risk work, some gates can be automatic. A permissions change probably deserves a closer look. The policy should follow the risk, not force every change through the same ceremony.
5. Will the next change start from this one?
Suppose an integration check catches an audit-event mismatch. Fixing the PR solves today’s problem. Updating the accepted event contract and adding a regression check can help the next agent avoid it. If the reviewer had to repeat a role rule already decided last month, that rule belongs in shared context with an owner and source.
That is what I mean by learning. The model does not magically retrain after a run. People review which facts, tests, skills, or workflow checks should be retained. Old rules need to be replaced when the system changes.
The useful measure is whether later changes need fewer repeated explanations and less reviewer rework while still passing meaningful checks.
Look at one recent change end to end
Take a feature your team shipped with coding agents. Start the clock at the request and stop it only when the intended behavior was checked in production. Record the human minutes spent supplying context, coordinating agents, reviewing and fixing the change, verifying it, and making the release decision. Keep a separate mark for when the first PR appeared.
That gap will tell you whether the agent accelerated delivery or mainly accelerated code generation.
For an example of how we are building the connected workflow around those steps, read How Prinevo Takes a Feature Request to Production Delivery.