Current best practices for the agentic SDLC place human sign-offs at major transitions. In these processes, agents generate so much code and documentation so quickly that people can barely follow the work, let alone understand it. This increases the likelihood that required decisions will simply be rubber-stamped.
This concerns the Owner role in the spec-driven development SDLC that I documented here. This person approves the plan, authorizes implementation stages, and decides on the merge. Each decision becomes a repository entry alongside the verdicts of the review models. Between these points, implementers, subagents, and review models do the work. What the Owner knows of their work is what they present at the return point.
Recent research is examining this problem as well. Five papers from the past six months show two patterns: attention declines during a run, and reviewers rely on material supplied by the agent. That undercuts the purpose of their review.
The position paper “AI Agents Push Humans Out of the Loop” by Margaret Mitchell, Avijit Ghosh, and Samir Passi sharpened this argument on August 24, 2026. It brings together research on automation and human-computer interaction.
Oversight During a Run
Coding agents produce plans, tool calls, and test results alongside the code. They change their approach during a run and delegate work to other agents. Mitchell, Ghosh, and Passi describe what a person would have to do to supervise this process. The person would have to follow the stream, retain earlier steps, and assess the effect of the next action. At the same time, they grant permissions and attend to their own domain work. The interfaces offer little help. They display long logs that have not been prepared for live review, and they repeat approval requests until those requests become routine. The paper identifies another risk: people may lose domain practice and independent debugging skills after working with automated systems for a long time. No one has yet measured the strength or duration of this effect for coding agents.
A formative study with four software developers shows what happens to attention during a run. The four participants worked on a single task with the coding agent Cline, and their observed cognitive engagement declined over the course of the work. They reviewed the visible result more often than the path that produced it. Four participants cannot establish a general effect. An interview study of 17 experienced software developers found a similar pattern in daily work. The interviewees saved effort by using heuristics. Some treated the agent’s plan as a record of its actual behavior. Others relied on green tests as a guarantee of correct code. Twelve of the 17 participants worked at the same large technology company, so the researchers classify their findings as exploratory.
Both heuristics depend on material supplied by the agent. The plan records the agent’s intention. Green tests prove what the tests check. When the agent wrote those tests itself, it is also assessing its own work. Anyone who relies on this material reviews the self-report of the system under review. A run produces so much material that little else remains possible as long as supervision means watching the agent work.
Review Before Execution
The most extensive direct comparison so far comes from a study of 48 participants published in April. It tested four forms of oversight for agents that operate websites. The tasks involved privacy problems, prompt injection, and manipulative interfaces. Problematic actions occurred less often when participants reviewed the agent’s plan before execution. Once such an action was already visible, participants did not intervene successfully more often because of it. None of the four variants performed best in every situation. According to the interviews, intervention also depended on whether the interface marked the critical moment as a decision early enough.
For human sign-off, this is the most relevant result. A person made a difference when reviewing before execution. At that point, the interface marked a decision and presented a plan. During a run, successful intervention depended less on the oversight variant than on whether the interface marked the moment. The agents in this study operated websites. Applying the result to repositories remains an assumption. It is consistent with the heuristics in the interview study and with the decline in engagement observed in the Cline study.
What the Owner Actually Sees
The documented process in the spec-driven development SDLC assigns every operational role to agents. Only the Owner is human. The agent-supported workflow begins with a ticket and a feasibility check. Then come a pre-gate, a plan gate, implementation stages with their own review loops, completion, and merge. An independent Judge reviews the Implementer’s work. The process returns to the Owner after two failed correction rounds, when the plan contains a conflict, or before an irreversible external action.
This review chain finds errors. The audit artifacts from project A contain 77 failed, 53 passed, and 9 inconclusive verdicts. In project B, 23 of 82 recorded gate runs failed. Each verdict has its own review run and raw log. No Owner read that many runs in full. The Owner saw the states presented at the return points and the agents’ summaries of them. The decision stored in the repository must not claim more. An entry that contains only “approved,” a date, and a name leaves open which state the Owner saw and which criteria they applied. A later reader cannot infer that the Owner reviewed the entire run.
The process already provides an autonomy mandate for this purpose. The implementation stream operates within an agreed scope and reports at defined return points. These points lie where the studies find human review effective: before an execution step, at a marked decision, with a plan or fixed state available. Mitchell, Ghosh, and Passi propose the same arrangement. They call for fixed autonomy boundaries, reviews of related changes as a group, and machines that check in advance what can be verified automatically. At a return point, the Owner needs a clearly identified state of the work and its supporting evidence. A conversation log or the agent’s summary is insufficient. The reason is the same as for the interviewees: the agent’s plan did not record its actual behavior. The right-hand column of the table shows what continues without another sign-off.
| Return point | Owner decision | Required evidence | What continues without another sign-off |
|---|---|---|---|
| Pre-gate | Are the task, scope, and acceptance criteria sound from a domain perspective? | Ticket, conflict list, affected systems, criteria defined in advance | Checks for completeness and contradictions |
| Plan gate | Are the architecture choice and planned external effects acceptable? | SHA-pinned plan, unresolved assumptions, expected migrations | Detailed planning within the approved boundaries |
| Stage loop | Should the scope be reduced or implementation stopped? | Diff, failed evidence, two correction reports, Judge verdict | Implementation, tests, and passed stage checks |
| Completion | Does the fixed release state meet the domain expectations? | Held-back E2E cases, deviation register, open findings, rollback path | Preparation of the merge artifact |
| Activation | May the release change the designated environment? | Deployment plan, backup, tested rollback, external effects | The explicitly approved activation |
The Sign-Off Package
Before work begins, the Owner records the domain expectations and the permitted external effects. Only then does the Owner see an agent’s plan or verdict. Mitchell, Ghosh, and Passi recommend this order so that the record shows whether the model shaped the person’s judgment. For sign-off, the order has a second purpose. It provides the criteria against which a fixed state can be assessed. Without those criteria, the Owner is left with the agent’s assessment at the return point, the same shortcut used by the interviewees.
At the return point, the Owner answers six questions:
- Which commit and state change are being approved?
- Which domain expectations were recorded before the agent’s verdict?
- Which evidence exercises the real execution path?
- Which deviations and open findings remain?
- Which systems, data, or people may be affected?
- Can the change be reversed, and has that path been tested?
The questions address the shortcuts observed in the studies. Question 3 requires evidence from the real execution path because the interviewees treated the plan as a record of actual behavior. The expectation recorded in advance places question 2 before the agent’s verdict, which might otherwise become the standard. Question 1 puts the commit hash into the decision. A later reader can then identify the state under review. Question 6 examines a condition in Gaube et al.’s model of effective oversight: the right to intervene. The sign-off evidence must therefore show that the rollback path has been tested.
The answers form the sign-off package together with the diff, test results, and review report. The Implementer assembles it. An independent review model cross-checks the statements against the repository, raw logs, and runtime evidence. The approval applies to the named commit and one state transition. After any change, the Implementer submits the new state again.
When the machine verdict is inconclusive, the team resolves the finding or reduces the scope. Besides approval and rejection, the process needs two further outcomes: resubmission with conditions and termination.
In my experience, people cannot keep pace with agents producing results at every step.
Conclusion
Cognitive overload is real. Placing a person in an SDLC as the human in the loop creates the appearance of safety and human participation. Only consistent validation by Judge or Auditor agents, in my experience, safeguards the running process. Domain-level end-to-end tests must also take on a new role in the SDLC.
Sources
- Margaret Mitchell, Avijit Ghosh, Samir Passi: AI Agents Push Humans Out of the Loop, arXiv 2608.23642 (August 24, 2026), https://arxiv.org/abs/2608.23642
- Chaoran Chen et al.: Comparing Human Oversight Strategies for Computer-Use Agents, arXiv 2604.04918 (April 6, 2026), https://arxiv.org/abs/2604.04918
- Shipi Dhanorkar, Samir Passi, Mihaela Vorvoreanu: Human oversight of agentic systems in practice, arXiv 2606.05391 (June 3, 2026), https://arxiv.org/abs/2606.05391
- Carlos Rafael Catalan, Lheane Marie Dizon, Patricia Nicole Monderin, Emily Kuang: “I’m Not Reading All of That”, arXiv 2603.14225 (March 15, 2026), https://arxiv.org/abs/2603.14225
- Susanne Gaube et al.: Keeping an Eye on AI: A Framework for Effective Human Oversight of AI Systems, arXiv 2605.16278 (April 9, 2026), https://arxiv.org/abs/2605.16278