Four new cards, two new operators. Three independent lines of argument landed in the first three weeks of June. They don't form a single synthesis, but they describe adjacent pieces of the same shift: model economics are changing shape, organizational readiness decides how much of that change reaches the bottom line, and the best teams are already running their own discipline for navigating new builds fast.
Theme 1, The model substitution flywheel
Tomasz Tunguz published "How AI Inflation Became AI Deflation" on June 7 (Model substitution savings are reinvested in more tokens, not returned to the budget). The argument is empirical. Harvey switched from Claude Opus to Kimi 2.6 for a legal document task: comparable accuracy, 11x cheaper ($84 vs. $954 per 100 tasks). Coinbase kept compute costs flat while token volume grew exponentially. Cursor claimed 10x token efficiency gains. Lindy reported millions in saved API spend.
The finding isn't that AI got cheaper. It's what happens to the savings. Across every case Tunguz examined, the budget freed by substitution was reinvested in more tokens, not returned. Volume grew to absorb the cost reduction. The implication: budget forecasts built on per-token pricing assumptions will miss the actual trajectory. The question to ask isn't "what's our AI cost this quarter?" It's "what do we do with the capacity the cost reduction creates?"
- Tomasz Tunguz, Model substitution savings are reinvested in more tokens, not returned to the budget. Model substitution savings are reinvested in more tokens, not returned to the budget; volume grows to absorb every efficiency gain.
Theme 2, Organizational structure as the AI ceiling
Two operators converged on the same diagnosis in early June. The ceiling on AI velocity isn't model capability. It's organizational structure.
Elena Verna's "Your company needs agency, not agents" (June 5, Organizational bureaucracy, not tool availability, is the binding constraint on AI-driven velocity) makes the structural argument directly. In hierarchical organizations, context travels up and down the reporting chain before anyone acts. Adding AI tools to people at the bottom of that chain doesn't change what they're authorized to know or do. Verna's test: look for teams with high AI adoption rates and flat output metrics. That pattern tells you the bottleneck was never the tool. She draws a clean distinction between agents (deployed) and agency (granted). "The goal is not more agents. It's more agency."
Dan Shipper's "Company-wide AI Implementation in Five Steps" (June 1, The bottleneck for AI adoption has moved from model capability to organizational capability) arrives at the same place from the operator's vantage. He runs Every as a live experiment: 100% AI-written code, five products, seven-figure revenue, small senior headcount. His observation: models are broadly accessible now. The bottleneck is organizational capacity to act on that access. Leaders who haven't used the tools personally can't diagnose what's actually slowing their teams. McKinsey data Shipper cites puts only 6% of organizations in the AI high-performer category with meaningful financial impact. His five-step sequence is designed to build organizational capability first, at each step, before expanding scope.
The two cards reinforce each other without being duplicates. Verna identifies the bureaucratic mechanism. Shipper describes the leadership fluency problem. They converge on the same prescription: the structural and personal work precede the tooling rollout.
- Elena Verna, Organizational bureaucracy, not tool availability, is the binding constraint on AI-driven velocity. Bureaucratic structures that gate information by title block AI velocity regardless of tool access.
- Dan Shipper, The bottleneck for AI adoption has moved from model capability to organizational capability. Leaders without hands-on AI fluency delegate strategy to people who are also guessing; the sequence must start with personal use.
Theme 3, Feedback loops as the core discipline
Thorsten Ball leads the Amp coding agent at Sourcegraph and published "Building Software Is Learning" on June 2 (Minimizing time-to-feedback is the single most valuable practice when building new software). The framing is foundational. When you're building something genuinely new, you can't fully specify requirements upfront. Misalignment between intent and implementation isn't a failure of execution. It's an expected property of novel work.
The implication is structural: the earlier you discover misalignment, the less work gets discarded. Ball names specific compression mechanisms his Amp team uses: one-hour prototypes before committing to full-feature work, written specs before coding, daily incremental shipping, and writing the README or API example before building (which surfaces design flaws that code reviews miss). "The most important thing you can do when you're building something new: reducing the time it takes you to go from 'let me try something' to getting your ass whooped by reality."
This holds for software features, agent prompts, product prototypes, and agentic coding tasks. Anywhere behavior must be discovered through iteration rather than specified upfront.
- Thorsten Ball, Minimizing time-to-feedback is the single most valuable practice when building new software. The single most valuable practice when building new software is minimizing time-to-feedback; discovery replaces specification in genuinely new work.