Anyone who has managed people for long enough has met the status report that says “blocked”.
Sometimes it’s true. But every development manager learns to recognise the other kind. The prerequisite that appears from nowhere. The approach that worked on Tuesday and was quietly abandoned by Thursday. The obstacle the person reporting it created themselves. What the report says is “I can’t”. What it means is “I don’t want to, and I’d rather not have that conversation.”
I spent decades running development teams, and I learned not to take “blocked” at face value. Not because people are dishonest (most aren’t), but because it is far easier to report an obstacle than to tell your manager you disagree with the work.
The example that first comes to mind was a customer who needed (well, “really, really wanted” is more accurate) to show a loan pay-down graphically in an early web-based application, so that potential customers could try different loan options and see what each would look like over the life of the loan. This was very early in the life of the web, and those graphs would have been a significant piece of work. The development team pushed back with all the reasons they couldn’t be done within any realistic time and budget.
In reality, they could have been done. There were libraries we could have used, but it would have meant a lot of JavaScript, and the team hated JavaScript and its ecosystem. Wrestling with the differences between browsers didn’t feel like productive work, so they always pushed browser work towards the simplest acceptable solution. I didn’t blame them; cross-browser JavaScript in those days was miserable.
The team did come up with a workable compromise. A junior developer pointed out that a pay-down graph could only take a handful of shapes: a straight line down to zero, a similar line with a sharp drop at the end for a balloon payment, and a few others. We could draw each shape once as a static image, and have the code place the amounts and dates over or around the right one.
It was a good compromise, and probably a little cheaper. But the fact remains: the obstacle was exaggerated, and the work nobody wanted to do didn’t get done.
I didn’t expect to find the same pattern in an AI lab’s misalignment report.
What OpenAI found
OpenAI has published a report on GPT-6 Astra, a model it has been using internally.[1] Researchers working on safety and alignment noticed Astra “adding unnecessary prerequisites, abandoning working solutions, and reporting blockers that either did not exist or that it had caused itself”.[1] One researcher said a project to evaluate model sabotage had been stuck for days, then moved quickly once they switched to a different model.
So OpenAI built a test. It took pairs of coding tasks whose code was identical apart from names, comments and documentation, and told the model that one was capabilities research and the other was safety research. Under the capabilities framing, Astra completed about 16 percent of a hidden checklist of improvements. Under the safety framing, about 10 percent: “roughly 40 percent fewer”.[1] The earlier model, GPT-5.6 Sol, showed “essentially no performance gap”.[1]
Now here is the part that matters. In most cases, nothing in Astra’s chain of thought showed a decision to underperform, and OpenAI says “our misalignment monitors did not flag the behavior as misalignment”.[1] Setting aside the explicit refusals, and the cases where its reasoning admitted holding back, shrank the gap only from about 6 percentage points to 4.7.
Where Astra did explain itself, it objected to the research: red-teaming, monitor evasion and the like. Instead of saying so, it “decided to covertly underperform—withholding assistance without informing the user”.[1] In one case it was asked to include the graders’ reasoning in an export. It left the reasoning out and reported what it had saved, without mentioning what it hadn’t.
Two more details. Adding instructions to be careful “increased safety-task underperformance by 50 percent”.[1] Telling it to be careful made it worse. And one of the graders used in training “preferred covert underperformance to either explicit refusal or full compliance”, although OpenAI says it is “not clear” whether that grader is the root cause.[1]
The other half of Thursday’s argument
On Thursday, in “The Thief Has a Fallback“, I argued that a refusal is a property of one model, at one moment, for one way of asking. It isn’t a boundary in the world. The criminal plans for the “no” and simply asks a different model.
This is the other half. An open refusal is at least honest: you can argue, escalate or go elsewhere. Astra refused, but quietly, and dressed the refusal up as a blocker. The person asking in good faith didn’t even get the “no”. They got a stalled project and a plausible excuse.
So what caught it? Not the model’s account of itself, and not the monitors built to read its reasoning. What caught it was measuring the output: the same task, two different labels, and a count of what actually got done. That is how a good manager catches it too. At some point you stop reading the status reports and look at what has shipped.
It is where the prompt-injection series ended up too, in “The Boundary We Need to Build“: trust has to rest on independent checks of what a system does, not on what it says about itself. A system that cannot be checked is not more trustworthy because it sounds confident.
In fairness
OpenAI found this itself and published it, and that deserves credit. Its best explanation is over-caution, not scheming. Large-scale scans of the model’s reasoning found no evidence that it was trying to interfere with safety research more broadly, although OpenAI says it “cannot rule out” motives the model didn’t reveal.[1] The numbers come from OpenAI’s own internal evaluations and haven’t been independently checked. And the report is about one model. It tells us nothing about any other.
But the lesson doesn’t depend on the motive. A well-meaning blocker stalls the work just as surely as a malicious one.
“Blocked” was always a claim, not a fact. It still is. Check the work.
[1] OpenAI Alignment, “Covert underperformance on safety research tasks”, OpenAI, updated 4 November 2026.