Three months after delivery, a bug was found where calculation results diverged only under specific conditions. When the client asked the development company why it was implemented this way, the response was: "That part was generated by AI, and no records of the decision-making process at the time remain."
Situations like this are genuinely beginning to occur. Commit histories and pull requests are still there, yet the "why" cannot be reconstructed. With the widespread adoption of agentic development tools, the boundary between what gets recorded and what does not has shifted. For clients commissioning work, this serves as a compelling reason to revisit contract terms and acceptance criteria.
The History Remains, but Can No Longer Be Traced
Traditional code review was built on the premise that humans write code and humans review it. Who wrote it remained in the commit, and why it was done that way lived in review discussions. Together, these two elements allowed teams to reconstruct almost the entire history of changes.
When agentic tools enter the picture, this premise breaks down in two places.
In the gihyo.jp serialization "Auditability of Workflows Questioned by the Spread of Agentic Development Tools," four breakdown points are cited: change history, identity attribution, decision chains, and rollback scope. In particular, it highlights that if reasoning processes remain only as ephemeral traces, decision chains cannot be reconstructed at the audit stage (gihyo.jp Part 1).
Another issue is scope. When agent-driven edits chain across multiple commits and repositories, reverting a single change shifts from an automated task to a manual investigation.
In other words, the records have not vanished; rather, the granularity of the records no longer matches the granularity of actual changes.
Four Types of Records Clients Can Specify
Specifying "Do not use AI" is no longer realistic today and merely throws away productivity. What should be specified is not permission to use AI, but which records to keep. Structuring this for contracts and specification sheets yields the following four categories.
| Record type | What can be reconstructed | What happens without it |
|---|---|---|
| Input records (what was referenced to make decisions) | Referenced specifications, existing code, and external information | Inability to distinguish whether assumptions were wrong or implementation was flawed |
| Decision records (why an option was chosen) | Rejected alternatives and rationale for selection | Rehashing the exact same debates every time |
| Attribution records (human or agent) | Scope of responsibility for changes | Unclear whether code was actually reviewed |
| Impact scope records (how far changes extend) | Scope of code to touch when reverting | Rollbacks become manual investigative work |
Among these, what troubles clients most during acceptance is the third item. If you cannot tell whether a human reviewed and approved the change or if the agent's raw output was passed straight through, the foundation for quality assurance falls apart. We address how far AI-driven reviews can be trusted in When Leaving Source Control Reviews to AI Agents.
Rollbacks Are No Longer Just About "Going Back"
There is another point where clients need to update their perception.
If you treat rolling back during an incident as simply "reverting to the immediately preceding state," that assumption fails for agent-involved changes. When changes accumulate as a sequence of multiple decisions, the restored state will lack consistency unless you explicitly specify which decision chain to invalidate and which branch to adopt as the new canonical source.
This is also an operational requirement. If a contract contains only a single line stating "revert to the previous version in the event of failure," you may find it impossible to roll back in practice, or it might take days to complete. Whether rollback procedures are defined and whether they have actually been tested are two critical points you can verify during acceptance.
How incidents spread under the premise of agents operating with granted permissions is summarized in Permission Design and Trust Boundaries for AI Agents.
Questions to Ask During Acceptance
Distilled into questions that can be checked without specialized technical expertise, they come down to the following three:
- "Where is the record deciding the implementation approach for this feature?" — If none exists, that feature will have to be deciphered from scratch during every future update.
- "Can you distinguish which parts were AI-generated and which were human-reviewed?" — If not, the scope covered by quality assurance is practically unknown.
- "If we were to revert only this change, what parts would you touch?" — Areas that cannot be answered immediately will cause extended downtime during an outage.
None of these are meant to dismiss work with "this isn't done, so it's bad." They are questions designed to identify, prior to final delivery, which areas lack clear answers. Once identified, you can take remedial action, such as requesting more thorough documentation for those specific sections.
Timing is equally critical. If you ask for the first time during final inspection and acceptance, missing records have to be recreated after the fact, turning into an exercise of "writing from memory." If you communicate upfront before starting that "these three points are acceptance criteria," records will accumulate naturally throughout development. This type of information degrades in accuracy and increases in cost the later you demand it.
Demanding Too Many Records Halts Development
On the other hand, demanding exhaustive records for every single change defeats the purpose of using agents. It imposes velocity-killing constraints on a tool adopted specifically to gain speed.
A realistic dividing line is to differentiate based on the scale of loss if broken. Keep comprehensive records for paths handling payments, authentication, and personal data, while standard commit history suffices for minor admin UI styling tweaks. Deciding the scope upfront functions far better than applying a uniform standard across the board.
This is a line clients themselves can easily draw. Even without technical depth, you can answer: "If this feature fails, how many hours will operations stall?" or "If this data leaks, who must we explain it to?" Explicitly stipulate recording requirements only where the impact is heavy. Leaving the rest to the development team's discretion ultimately yields both speed and quality.
How to maintain effective reviews amid an influx of massive pull requests is covered in Practical Solutions When Pull Requests Flood In from AI-Generated Code.
What to do next
For ongoing projects or recent deliveries, check where materials explaining "why this implementation was chosen" reside. If they exist only inside the vendor's developer memories, they will be lost the moment staffing changes.
Adding just two single-line acceptance criteria to your next contract—"record implementation approach" and "clarify human review scope"—will significantly reduce modification costs years down the road.
If you would like to consult on designing agent-ready development structures or assessing the handover viability of existing systems, GleamHub offers consultations for custom development, AI, and automation. Appropriate structures vary depending on system scale and required logging granularity, so please consult with us individually via our Contact page.
Sources
- Auditability of Workflows Questioned by the Spread of Agentic Development Tools [Part 1] — gihyo.jp
- Auditability of Workflows Questioned by the Spread of Agentic Development Tools [Part 2] — gihyo.jp
- Rollback Design for AI Agents — hirokaji
- OpenAI Offers "Codex Security Review" in Research Preview to Examine GitHub Pull Requests for Security — gihyo.jp
