{"slug": "openai-s-software-factory-can-skip-human-review-who-evaluates-that-decision", "title": "OpenAI's Software Factory Can Skip Human Review. Who Evaluates That Decision?", "summary": "A developer examining OpenAI's agentic software factory workflow argues that its low-risk pull request classifier, which can remove human review from the release path, is itself a release decision that needs independent evaluation. The analysis contends that risk is not a permanent property of a change and that teams should judge the gate by production outcomes and what was knowable at classification time, not just by clean deployments.", "body_md": "A pull request is green.\n\nThe specialist reviewers found nothing that should block it. The risk classifier marks the change as low risk. The human-review branch disappears, and the change continues toward production.\n\nEvery component may have done exactly what it was asked to do.\n\nThe remaining question is whether the system was right to stop asking a human.\n\nThat question jumped out at me in [Gergely Orosz's diagram of OpenAI's agentic software factory](https://newsletter.pragmaticengineer.com/p/openai-software-factory). \n\nThe public workflow includes code-writing agents, CI, specialist agent reviews, risk classification, deployment agents, production monitoring, and feedback loops. The article says that areas of the codebase can opt into automatic approval for low-risk pull requests, while higher-risk changes can receive stricter review.\n\nI have not tested OpenAI's system. I am looking at the evaluation problem the design raises.\n\nThe small diamond marked \"Low-risk change?\" is not merely organizing work. Its answer can determine whether human review remains in the release path.\n\nThat makes it a release decision.\n\nA green CI run can provide strong evidence about the change under the conditions the pipeline checked.\n\nThe code built. The selected tests passed. The linters accepted it. A performance harness may have found no unacceptable regression. Specialist review agents may have found no issue within their assigned domains.\n\nAll of that matters.\n\nNone of it automatically proves that the change belonged in the low-risk route.\n\nThe classifier is making a different claim. It is saying that the available evidence, affected surface, expected consequence, and uncertainty are compatible with less human scrutiny.\n\nThat claim needs evidence of its own.\n\nOtherwise, a team can evaluate every component around the gate while leaving the routing decision itself mostly assumed. The code is tested. The review agents are monitored. The deployment agent watches production. But the decision that removed the human is treated as a label rather than behavior that can be right or wrong.\n\nRisk is not a permanent property attached to a file or type of change.\n\nA change that was low risk yesterday may stop being low risk after a dependency changes, a permission boundary moves, a feature becomes widely used, or a once-correct operational rule is reversed.\n\nThe code can still pass the same local checks.\n\nThe route can still be wrong.\n\nThat is why evaluating the gate requires more than collecting examples of clean deployments. Easy successes mostly confirm that obvious low-risk changes can pass through a low-risk path. The harder cases sit near the boundary.\n\nFor example:\n\nThese are challenge cases, not claims about observed OpenAI failures. Their purpose is to ask whether the classification still holds when the surrounding conditions become less convenient.\n\nThe gate should not be judged only by whether the pull request was green when it arrived.\n\nIt should be judged against the consequence of the route it selected.\n\nDid the supposedly low-risk change preserve the required production state?\n\nDid it trigger a rollback, incident, manual intervention, or delayed repair?\n\nDid monitoring capture the condition that actually mattered, or only the signals the deployment agent expected to matter?\n\nWould an informed reviewer, given the same evidence available at classification time, have selected the same route?\n\nThis does not mean every negative production event proves the classifier was wrong. Systems fail for many reasons, and hindsight can make risk look more obvious than it was. The evaluation has to preserve what was knowable when the decision was made.\n\nBut it also cannot stop at the classifier's own explanation. A confident risk label is still a claim produced by the system being evaluated.\n\nThe useful answer comes from connecting the decision to independent evidence about the resulting state.\n\nIf a team wants to defend an automatic approval later, the record needs to make the decision reconstructable.\n\nAt minimum, I would want to know:\n\nThat record turns \"the system marked it low risk\" into something another person can examine.\n\nIt also creates the foundation for replay. When a policy, dependency, or requirement changes, the team can rerun earlier decisions and ask whether changes previously sent down the easy path would still belong there.\n\nWithout that evidence, the gate can report that it made the correct decision, but the organization cannot show why the decision was defensible.\n\nThe [Nugalaxy Evaluation Cases](https://nugalaxy.ai/evaluation-cases) examine this broader gap between visible success and the behavior the evidence can actually support.\n\nAn agentic software factory can make code creation, review, deployment, monitoring, and repair much faster.\n\nThat speed changes the role of the risk classifier. It is no longer sorting a small queue for convenience. It is controlling where scarce human judgment enters a high-volume system.\n\nFalse positives have a cost. If the gate sends harmless changes to humans too often, the bottleneck returns and reviewers learn to distrust the alerts.\n\nFalse negatives have a different cost. The system removes review precisely where a human might have challenged the assumptions shared by the surrounding agents.\n\nBoth errors matter, but they are not equally consequential in every part of the codebase. The evaluation has to reflect the real cost of the wrong route, not merely report overall classification accuracy.\n\nThis is where the harness contract matters. The system needs to capture the decision inputs, expected route, executed route, and production outcome in a form that can be compared consistently. [Read more about harness engineering here](https://nugalaxy.ai/guides).\n\nThe public diagram shows an ambitious feedback system. Code is written, checked, reviewed, classified, deployed, observed, and repaired through connected agentic loops.\n\nThe more capable that factory becomes, the less useful it is to ask only whether each pull request passed CI.\n\nThe factory is also deciding when its own evidence is sufficient to proceed without a person.\n\nThat decision should be evaluated as seriously as the code it lets through.\n\nA green build can show that the change passed the checks.\n\nIt cannot, by itself, show that removing the human was safe.", "url": "https://wpnews.pro/news/openai-s-software-factory-can-skip-human-review-who-evaluates-that-decision", "canonical_source": "https://dev.to/sara_mo/openais-software-factory-can-skip-human-review-who-evaluates-that-decision-21bf", "published_at": "2026-09-16 08:07:23+00:00", "updated_at": "2026-09-16 08:13:15.303945+00:00", "lang": "en", "topics": ["ai-agents", "ai-safety", "ai-tools", "developer-tools", "mlops"], "entities": ["OpenAI", "Gergely Orosz", "Pragmatic Engineer"], "alternates": {"html": "https://wpnews.pro/news/openai-s-software-factory-can-skip-human-review-who-evaluates-that-decision", "markdown": "https://wpnews.pro/news/openai-s-software-factory-can-skip-human-review-who-evaluates-that-decision.md", "text": "https://wpnews.pro/news/openai-s-software-factory-can-skip-human-review-who-evaluates-that-decision.txt", "jsonld": "https://wpnews.pro/news/openai-s-software-factory-can-skip-human-review-who-evaluates-that-decision.jsonld"}}