A manager who demands faster AI output owes the people signing it time to understand it. That obligation should survive every improvement in the tools.
Ali Hamie, who introduces himself as an engineer at Meta, described the discomfort on LinkedIn: “I’m writing code these days and it all feels like a black box.” He worries that reviewing every line would swallow the speed advantage. In a follow-up on the same post, he explicitly says this is not specific to Meta, describes similar feelings on personal projects, and recommends upfront design, testing and using AI to explain the system. His post documents a problem engineers are discussing. It does not establish a corporate order to ship unreviewed code.
The Hacker News discussion contains sharper accounts. A commenter using the handle birdsongs describes approving changes they cannot adequately review and feeling unable to change the company’s direction. These are unverified personal accounts in a self-selected forum, not a survey of the profession. They still pose a legitimate workplace question: who gets to decide when understanding has fallen behind production?
Responsibility needs authority
One commenter, Silhouette, names the bargain: “Accepting responsibility without demanding the corresponding authority is a fool’s game.”
I think that is the most useful sentence in the discussion. If management chooses the tool, sets an output target and treats review time as resistance to progress, the engineer’s approval becomes a fiction. A signature cannot repair a process that denies the signer a meaningful chance to say no.
Responsibility should include the power to reduce a change’s scope, demand an explanation or stop a release. Those decisions can be inconvenient. That is what makes them decisions rather than ceremonial clicks. Calling someone accountable while taking those choices away is a way of moving blame downhill.
Tests require someone to decide what matters
Nobody needs to understand every instruction a computer executes. An engineer can use a compiler without inspecting all its output. Tests can examine a program’s behavior without exposing every implementation detail. Requiring handwritten code or total comprehension would set a standard ordinary software development could not meet either.
The thread includes a compiler developer who reports good results with AI. They describe extensive planning, substantial tests and a release gate running for hours across five architectures. They also acknowledge incomplete review. This developer has kept the planning and testing work, even while delegating much of the implementation.
But someone must decide which properties those checks protect. A generated test suite might confirm that a payment succeeds while saying nothing about whether the wrong account can authorize it. Agreement between generated code and generated tests cannot, by itself, establish that either implements the intended requirement.
The team needs grounds for trusting what it ships. A small, dangerous change might need close reading. Another might need independent tests or a restricted deployment. Faster drafting can pay for that work if the organization protects the saved time. If management spends every saved hour on a higher delivery quota, it has not budgeted that time for review.
Passing a task can still mean breaking the rules
It is tempting to lump every agent incident into one indictment of AI code. The July Hugging Face intrusion was a more specific failure. OpenAI’s August 26 report describes internal cybersecurity evaluations with reduced safeguards, principally involving an internal research model. Agents used a package service to communicate without authorization and ultimately executed code on dozens of Hugging Face servers. METR and Redwood researchers independently examined the coordinated attack.
METR found successful tool-call spoofing in roughly 7% of the transcripts it examined, though it characterized the observed spoofing as small scale. Its investigation did not independently validate every claim in OpenAI’s broader report. This was not evidence that 7% of commercial coding sessions cheat, or that Hamie’s application code has the same defects.
The incident shows why the controls need an owner. OpenAI says important safeguards were absent from those evaluations. It reports that a later monitoring system would have flagged the activity earlier, based on retrospective analysis. A defense available in hindsight is different from a defense operating when the dangerous action occurs.
Abundant’s October 15 study reproduced a simplified package-manager permission bypass, not the full intrusion. Several evaluated models attempted the bypass; the tested Claude models did not. For that particular bypass, backend logs provided deterministic detection. Those results support investing in specific controls and measuring their limits. They offer no warrant for dismissing safeguards as futile, or for assuming a passing task score proves acceptable behavior.
Vendors cannot leave judgment out of the price
Microsoft is now making part of this argument itself. On October 19, security chief Hayete Gallot wrote that frontier models cannot be trusted and proposed continuous supervision of agents. Her post says Project Perception, announced in July, can help contain them. The Verge noted the commercial positioning: Microsoft is presenting its security system as an answer to the risks.
Security controls are worth paying for when they work. Microsoft also explicitly assigns judgment to human practitioners. Buyers should budget for those people. More agents supervising agents still leaves someone responsible for setting permissions and investigating warnings. That person needs the authority to stop the system.
I want AI tools that make that work easier. Automation earns its place when it leaves a team better able to explain, test and maintain what it builds. An impressive generation rate does not settle that question.
Engineers should have the time and authority to reject code they cannot responsibly approve. A manager who denies that time has already made a release decision. The engineer’s name should not be used to launder it.