Three new cards, three new operators. One recurring tension surfaced across all three sources: the gap between what AI can technically do and what it actually does in the world, and who controls that gap.
Theme 1, AI volume and human work: the sandwich that stays intact
The loudest story of the week was Arvind Narayanan and Sayash Kapoor's essay on why AI hasn't replaced software engineers (AI compresses execution in knowledge work but leaves specification and delivery as human-owned layers). Published June 11 in their newsletter AI as Normal Technology, the piece examines the profession where AI capabilities advanced furthest and fastest, and applies Federal Reserve employment data, WARN Act filings, and a GitHub study rather than projections.
Their finding: AI has compressed execution but not the layers around it. Knowledge work is a decide-execute-deliver structure. Execution is the middle layer, writing code, drafting documents, producing analysis. AI has automated much of this. But decision (what to build, how to specify it, who owns accountability) and delivery (testing, verification, integration, maintenance) absorb the savings because their volume rises as execution output increases.
The sharpest data point is on layoffs. Of 160+ WARN Act filings in New York's first year of mature AI tools, one company cited AI. An HBR survey found 21% of companies made reductions "in anticipation of" AI gains while only 2% cited actual implementation. From Narayanan and Kapoor:
"59% of hiring managers admit emphasizing AI when explaining cuts 'because it plays better with stakeholders.'"
The decide and deliver layers are not just slow to automate; they are expanding as execution volume grows. A GitHub study found AI agents produced 8x more code but only 30% more releases. The difference is delivery: reviews, verification, integration work that now handles a larger input.
- Arvind Narayanan and Sayash Kapoor, AI compresses execution in knowledge work but leaves specification and delivery as human-owned layers. AI compresses the execution layer of knowledge work but leaves specification and delivery as human-owned layers.
Theme 2, Token economics: compile once, run forever
On the same day as the Narayanan essay, Packy McCormick and Markie Wagner published their analysis of what they call Return on Tokens in the Not Boring newsletter (Using AI as a compiler converts expensive thinking into cheap deterministic doing). The organizing insight is a simple asymmetry.
Thinking is expensive: using AI to reason about a business process, understand its rules, and convert them to code costs tokens once. Doing is cheap and scales indefinitely: running compiled code on every transaction costs nothing further per execution. Companies that wire agents into the runtime path of their operations pay full token cost on every transaction, which scales with volume and cannot be optimized away.
"Thinking is expensive but happens rarely. Doing is cheap and happens forever."
Wagner's company Poetic demonstrates the pattern in practice. Compared to agent-based approaches, Poetic reports 100x less token usage while delivering 99%+ accuracy on multi-hour business processes at AIG. Uber's counter-example is instructive: the company burned its full 2026 Claude Code token budget by April after wiring agents into development workflows.
The compiler pattern also changes the audit surface. Compiled code is readable, versioned, and correctable. Agent output at runtime is opaque. The business case and the legibility case converge on the same architecture.
- Packy McCormick and Markie Wagner, Using AI as a compiler converts expensive thinking into cheap deterministic doing. Compiling business rules to deterministic code with AI once costs 100x less than running AI agents as a runtime on each transaction.
Theme 3, The ceiling is policy, not silicon
Tomasz Tunguz's June 10 post named a shift that cuts across both findings above (Frontier AI deployment is now constrained by safety policy, not by model capability). Fable 5 jumped 10 to 15 percentage points on standard benchmarks compared to the prior generation's typical 2-point increment. That is a real capability leap. Stripe used a frontier model to migrate 50 million lines of Ruby code in a single day.
Yet enterprise users encounter a ceiling that is not technical. Safety guardrails, deliberate access controls, and deployment phasing mean the model's benchmark capability is not fully available in production. Tunguz argues this is intentional infrastructure management: banking, energy, and healthcare systems were not designed to absorb frontier AI outputs at speed, and a mismatch could cause failures in systems that have not had time to adapt.
"We've reached the upper bound of AI."
"How do you release the most powerful model in the world to everyone without destroying kingdoms?"
The implication for buyers is that the competitive differentiator between AI providers is now partly about how much useful capability they release, not just how much capability they build. The ceiling will rise as infrastructure hardens, but the rate is a policy decision, not a technical one.
- Tomasz Tunguz, Frontier AI deployment is now constrained by safety policy, not by model capability. The frontier AI capability constraint is now safety policy, not model intelligence; the ceiling is temporary but intentional.