Two reviewers look at the same security patch and reach different verdicts more than a third of the time. Before you buy a better coding model, check whether your review process can tell a good repair from a bad one. Otherwise, a model upgrade may just give you a different argument. This is the Augur Dispatch for Wednesday, September 16th, 2026. A quick disclosure before we begin. Portions of the Augur Dispatch podcast are generated using artificial intelligence. The written dispatch contains the full source trail and verification notes. The disagreement comes from Trail of Bits's reanalysis of a study published by OnePassword in August. The original headline said AI agents produced clean security fixes about a quarter of the time. Trail of Bits filtered the trials and found that 86% of the remaining patches blocked the supplied exploit, the test demonstrating the security hole. Those numbers answer different questions. Blocking one known attack doesn't establish that the underlying vulnerability is gone, and a clean fix is supposed to preserve the behavior people depend on. Picture an engineering lead deciding whether agents should help with a backlog of security repairs. One headline says they're barely useful. The other looks like a reason to accelerate. Neither tells that lead what will happen in their own code. The working conditions explain part of the gap. According to Trail of Bits, the original headline pooled attempts where agents could run tests with attempts where testing was forbidden. It also included runs where the instructions deliberately pointed the agent toward the wrong fix. The recount kept trials where agents could execute code and weren't told to make the wrong repair. The vulnerabilities were still chosen for their difficulty rather than to represent ordinary patching work, so the filtered result isn't a forecast for your engineering team. Trail of Bits also says the models weren't tested at their highest reasoning settings. That could matter, but it doesn't tell us how much a stronger setting would improve the result. That experiment wasn't done. Then there is the grading. Two model reviewers assigned different outcomes to about 37% of the same patches. When a model judged its own repair, a human reviewer agreed on the full verdict roughly two-thirds of the time. These were five category judgments, not a simple vote on whether the known exploit still worked. Changing the rubric changes what agreement means, which is why a simpler internal check shouldn't be compared directly with the published disagreement rate. Cherl of Bitz also found cases where the grading punished behavior changes that the repair was supposed to make. A security fix sometimes has to stop software doing something it previously allowed. The reviewer needs to distinguish that intended change from a new defect. There is a familiar management problem here. A precise percentage arrives in a slide deck, and the assumptions that produced it arrive several meetings later. Auger's recommendation is a bounded pilot of the review process, with an engineer still responsible for every decision. Start with already fixed vulnerabilities in your own code, where you have a test that demonstrates the original problem. Let the agent see and run that test in an isolated environment approved for the work. Then ask an engineer and a model separately whether each proposed patch blocks the exploit and whether it breaks intended behavior. Count where they disagree and investigate those cases. Don't let either reviewer turn agreement into permission to merge automatically. They could agree because both missed a vulnerable path that the supplied test never exercised. For an engineering manager, the useful outcome is learning which repairs demand scarce review time and which checks repeatedly catch mistakes before someone has to find them in production. The security lead should own the pilot. Compare review time and verified repair quality with the team's existing process, and set a two-week review point before the trial starts. Stop if tests can't run reliably, or proposed fixes leave security questions unresolved. Expand only if the team can demonstrate sound repairs without buying speed through weaker scrutiny. That is a proposed operating test, not a result this benchmark has established. The advantage would come from accumulating useful tests and knowledge of your own software rather than from buying a model your competitors can buy too. The permission decision comes first. Running agent-selected code inside a company environment carries risks that an attractive patch score doesn't settle. A similar distinction matters when the agent speaks instead of writes code. Google's new Gemini 3.8 live extended thinking leads one speech quality ranking with a reported score of about 83. Google reports roughly 69% on a voice task benchmark, but about 35% on Sierra's banking version. These are Google's reported figures, not an independent production trial. They measure different tasks. A broad ranking can't tell a bank how reliably an agent will complete its particular customer requests. Imagine a service manager listening to a polished demonstration. The conversation sounds easy, but the question for that manager is whether the request ends with the right action or another employee quietly fixing it afterwards. Augur's posture is to test representative call scenarios before making a deployment decision. Simon Willison has published a browser tool that can help make an initial experiment accessible. That doesn't turn the experiment into a regulated call center system. Enterprise access to extended thinking remains in private preview in Google's announcement. Keep that availability limit separate from the appeal of the demonstration. The name on an AI service deserves its own check. Anthropic alleges that Chinese labs harvested Claude's answers to train their models. In the reporting discussed in today's brief, DeepSeek, Moonshot, and Xiaomi sent user queries to Claude, and Moonshot returned some answers as though Kimmy had produced them. Those are allegations attributed to Enthropic, not findings Augur independently verified. They raise a concrete procurement question: which service actually receives the customer's request? Model ancestry is a related but different issue. Salesforce's COA is built on NVIDIA's Nimatron and tuned with synthetic training examples, rather than customer data. Interconnects has argued that Nimatron itself draws substantially on distillation from Chinese open weight models. An upstream training relationship doesn't by itself mean today's customer requests go to an upstream lab. Buyers need to ask about both the origin of the model and the handling of live data without treating one answer as proof of the other. A familiar brand on the invoice isn't a complete description of the service behind it. Cost controls introduce a more immediate operational question. What happens when access stops? Snowflake's pro-user quotas are generally available, with separate tracking for warehouse compute and AI services. Its built-in blocking applies to supported AI services, including Cortex Functions and Agents, Co-work, and Coco. It does not block warehouse compute. Enforcement takes effect within minutes, so spending can exceed the configured limit before the block lands. Databricks also offers hard spend caps that stop further requests. Picture an overnight workflow using a shared service account. Reaching its spending limit could stop work that several teams depend on, even though the control is doing exactly what somebody configured it to do. Augur recommends a separate response plan for agent accounts. Who gets notified, what work waits safely, and who can authorize a restart. Finance and operations should agree on that before the first blocked request. A spending limit is a poor place to discover that nobody owns the recovery. Two dated predictions close today's brief. These are auger calls with explicit hit or miss criteria so they can be graded later. The written brief carries the criteria and the website tracks the calls. Augur gives a 45% chance that one password publicly responds to trail of bits with a revised or clarified methodology by October 31, 2026. A qualifying response must address the pooled testing conditions or the greater agreement figures. Augur gives a 60% chance that Google looms Gemini 3.8 live extended thinking into general availability in Gemini Enterprise by December 31st, 2026. A narrower availability status would be amiss. For now, keep human review of security repairs, pilot checks against your own code, and watch for evidence that changes the deployment decision. The Trail of Bits recount hasn't been independently reproduced here. The written brief with every source is at augurdispatch.ai. That is the Augur Dispatch for Wednesday, September 16th, 2026. Thank you for listening.