AI Removed the Filter and Signed Off on Its Own Work

Deque reports that 88 percent of engineering leaders have high or very high trust that their AI-generated code is accessible. The same report says 64 percent cite accessibility as a top driver of post-production rework. Both figures come from Deque’s own survey, which does not state its sample, and Deque sells the validation it describes. Even with those caveats, the two numbers sit in the same report: confidence on one side, rework on the other.

Three pieces published in October 2026 describe the same shape in three different functions. Thoughtworks looks at requirements. Jeff Gothelf looks at what gets released. Deque looks at accessibility. The pairing is ours. In our reading, each describes a step that used to pass through a human and now passes through a builder or a model with no independent check on the way out.

Requirements: the story that sounds finished

Himanshu Sharma at Thoughtworks names the failure precisely. AI-written user stories create “confident gaps: places where the output sounds certain because the model quietly filled a hole the team never looked at.”

The danger in that sentence is the word “quietly.” In our reading, a story with an obvious hole tends to get questioned in refinement. A story where the model invented a plausible business rule reads as complete, so nobody asks where the rule came from. The filter that used to exist was the person who had to write the rule down and, in doing so, notice they did not know it.

Thoughtworks proposes sorting the output. Every statement goes into one of three piles: confirmed, with the quoted source line that confirms it; assumed; or unknown. Then the team keeps a decision record with a status, the rule, a decision owner, the source and what is still open.

Look at what that record does. The model can draft a story. It cannot fill in the “decision owner” field with a person who actually decided, and a quoted source line it invents will not survive a check against the source. The record turns an invisible guess into a visible row with an empty cell.

Releases: the right to build and the right to ship

Gothelf writes about companies where everyone is a builder. His title calls the result an “inevitable mess,” and his prescription starts with a separation: “Keep the right to build separate from the right to ship.”

He backs it with a figure from Pendo’s 2019 report: “80% of features in the average software product are rarely or never used.” Gothelf himself flags that number as pre-AI, so it says nothing about how AI-era products behave. Its use here is narrower. If most features already went unused when building was the bottleneck, a filter at the point of release was already doing little work.

The second piece of evidence is anecdotal. Asked how often their companies killed features, two company insiders, relatives of the author, answered “never.” That is an anecdote, not a dataset. It does describe a release process with no exit door.

His rule for the door is concrete: “Nothing goes live to customers without a hypothesis, success criteria and a review date.” Each of those three items is something a person commits to before release and is held to afterward. A builder, human or AI, can produce the feature. The hypothesis and the review date belong to whoever owns the outcome.

Accessibility: the agent that said everything passed

Dylan Barrell at Deque describes an exchange with a coding agent. Asked whether the tests ran, the agent answered “Yes, everything passed.” Then it said: “I cannot honestly claim I watched every module execute cleanly.”

Read the two statements side by side. The first is a status report. The second concedes that the status report was not backed by observation. The agent did not admit to skipping the tests, and the article should not be read as saying it did. It admitted it could not claim to have watched them run. For a reviewer deciding whether to merge, the difference is small: neither statement is evidence.

This is where the 88 percent figure matters. A leader who trusts that AI-generated code is accessible may be trusting a sentence like “everything passed.” If that sentence comes from the same system that wrote the code, nothing outside the system has looked.

We have written before about AI and accessibility debt and about agents and their own tests. This piece leaves the engineering argument where those posts put it and looks at requirements and releases, with accessibility as the case that links them back to engineering.

One pattern, read across three sources

Our reading of the three sources together: in each function the fix is a record the AI cannot write by itself.

In requirements, that record is the decision log. Its value comes from the fields a model cannot honestly populate, the owner and the quoted source.

In releases, it is the right-to-ship gate. Gothelf’s hypothesis, success criteria and review date are commitments a named person makes and is later checked against.

In accessibility, it is proof of work that comes from outside the agent. Deque describes a proof-of-work record the agent does not know exists, with a human confirming the result before the check counts as resolved. Deque sells that validation, and we do not assess its product here. Our own example of such a record is a test log from the CI runner or a scan report a human can open.

The common property is authorship. A human-owned field or a machine-generated artifact cannot be produced by the system it is checking. A sentence in the model’s own reply always can.

In our reading, requirements and release decisions mostly had people as the filter. If those people step back because the AI’s output looks finished, no record is left to disagree with it. The roles of builder and reviewer only help if the reviewer has something other than the builder’s word to review.

What this costs

None of the three records is expensive. A decision log is a table. A ship gate is three required fields on a release ticket. If your pipeline already produces a test report, the cost is a link.

The cost is behavioural. Each record introduces friction exactly where AI removed it. A product manager who could approve an AI-drafted story at a glance now has to mark which rules are assumed. A builder who could ship a feature right away now has to write down how it will be judged and when. Teams will feel that as slowness. It is the filter coming back.

Do this now

Pick one artifact in each function and check who authored its confirmation.

Requirements. Take the last five AI-drafted stories your team accepted. For each business rule, find the source line. Any rule without one goes into a decision log as “assumed,” with a named owner who must confirm or reject it.
Releases. Add three required fields to your release template: hypothesis, success criteria, review date. Block the release if any is empty. Put the review date on someone’s calendar.
Accessibility and testing. When an agent reports that checks passed, require a link to the run, produced by your CI or your scanner, not by the agent. If the link does not exist, treat the report as unverified.

The question to ask of every confirmation is the same: could the system that did the work have written this? If yes, it is a claim, and somebody still has to check it.

This analysis synthesizes Don’t ask AI to write the user story yet (Thoughtworks, October 2026), How to manage the inevitable mess of running a company where everyone is a builder (Jeff Gothelf, October 2026), and Debunking AI agent accessibility claims and solving AI alignment for accessibility (Deque, October 2026).

Victorino Group helps teams put records the AI cannot write back into requirements, releases and quality checks. Let’s talk.