DEV Community: Phil Rentier Digital

Fable 5 Is Gone. Here's the Method I Use to Get Better Results for Less.

Phil Rentier Digital — Sat, 20 Jun 2026 13:41:11 +0000

We got 3 days with Fable.

3 days where autonomous coding, long-horizon reasoning, and research synthesis felt genuinely different. Not "slightly better than last quarter" different. Something else entirely.

Then the US Commerce Department sent a letter, and the model went offline for every user on the planet, Americans included, because there was no other legal option. Access went from live to gone, with no deprecation window and no migration path offered.

And we don't know if we'll ever see a model at that level again.

The electroshock wasn't the ban itself. It was what the ban exposed: our entire production workflow running on infrastructure that 1 government letter could switch off in 12 hours.

Unacceptable in prod.

So instead of checking leaderboards for the next best model, or waiting for a restore that may or may not happen, the real move was asking a different question. Not "what replaces Fable." The actual question: if we were routing critical work to a single frontier oracle, what were we buying? And whether something structurally better exists.

TL;DR: A panel of models with a frontier judge beats Fable 5 solo on deep research benchmarks, and in budget configuration it runs at roughly half the cost. The problem isn't that Fable is gone. It's that we discovered something better while it was still here.

The Night Fable Went Offline

Most people had the same 3 reflexes: find the next best model on the leaderboards, wait for Fable to come back, complain on X.

All 3 are the wrong frame.

The Fable ban was a data point, not an anomaly. This is the first time a US government directive has pulled a commercially deployed frontier model globally in under 12 hours. It will not be the last time a model we depend on disappears, for whatever reason, with no graceful handoff.

If your production pipeline has a single-model dependency, the Fable ban just made that architecture problem visible.

I wrote about the ban the day it happened. This is what I built the week after.

The Oracle Trap

Sending a prompt to 1 model is asking for 1 perspective: 1 architecture, 1 training mix, 1 set of failure modes. Call it what it is: an oracle. Routing all your hard decisions through 1 frontier model is the LLM equivalent of going full glass cannon: maximum output on good days, and 1 unexpected move takes the whole build offline.

According to TokenMix's breakdown of OpenRouter's published DRACO benchmark results, Fable 5 solo scored 65.3% on a 100-task deep research evaluation covering law, medicine, finance, and product analysis. A panel of Fable 5 and GPT-5.5, with Opus 4.8 as judge, scored 69.0%.

The more interesting data point is the budget panel: Gemini 3 Flash, Kimi K2.6, DeepSeek V4 Pro. That combination scored 64.7%, within 1 benchmark point of Fable 5, at roughly 40% of the cost.

A caveat before you screenshot that: DRACO has no coding domain. These numbers cover research and analysis tasks, legal synthesis, medical reasoning, comparative evaluation. For pure code generation, the data doesn't transfer directly. Keep that in mind.

There's a longer thought buried in these numbers. The entire premise of the frontier model race has been that smarter single models produce better results, and the right investment is making any given model smarter. The DRACO results suggest a different frame: the architecture of deliberation outperforms the intelligence of any individual voice. Management has understood this for decades (committees, red teams, devil's advocates, peer review). You don't put your most expensive analyst in a room alone and accept the first thing they say. You build a process that forces disagreement and then resolves it. AI development ran the smarter-single-model playbook for 5 years without asking whether a structured argument between 3 medium-capable systems might outperform the uncontested output of 1 exceptional one. Turns out it might.

Most benchmarks measure a sprint. The Perspective Council runs a committee, which is slower and more annoying, and generally more right.

The Perspective Council

The Perspective Council: Multi-Model Deliberation Framework

2 approaches existed before this.

Before:

The panel approach: send the same prompt to multiple models in parallel, have a judge synthesize. You get model diversity (different architectures, different training, different failure modes). The panel scores higher than any individual member because correlated errors get outvoted by independent ones.

The multi-perspective scan: assign 1 model different expert personas in sequence. "Answer as a security architect." "Answer as a skeptical economist." You get role diversity, different reasoning frames from the same underlying model.

After:

The Perspective Council stacks both at the same time. Each panelist model receives a different expert persona prefix before processing your prompt. The security architect persona goes to 1 model, the skeptical economist to another, the systems historian to a third.

The judge (a separate frontier model call) reads all responses, notes where the experts agree, notes where they contradict, and synthesizes a single output from the pattern.

Why this outperforms either approach alone: a panel without role diversity gets architectural variance but correlated reasoning frames. 2 frontier models with similar training can reach the same wrong conclusion through different mechanisms. A multi-perspective scan with 1 model gets frame diversity but 1 set of architectural blind spots. The Perspective Council gets both axes of variance at once.

I think this is the core of why the benchmark numbers hold, though I'd want independent replication before treating it as settled science.

Something I noticed while testing: I ran the same architecture question through Opus 4.8 twice in the same session. First as a direct panelist, then as the judge synthesizing 3 other model outputs. The panelist answer was complete and confident. The judge answer caught 2 assumptions the panelist hadn't questioned. Same model, same question, different position in the chain, different answer. I've been thinking about that.

Sharp persona prefixes are where this either works or collapses. Vague personas produce stylistic variation, not genuine disagreement. Sharp briefs produce the contradiction the judge needs to do its job, and the full prompt contracts framework (which covers input/output contracts for every LLM call) translates directly to persona design: each prefix is a contract specifying what optimization objective that voice is serving.

3 Ways to Set This Up

The persona is a prompt prefix. You inject it before your actual prompt in each panelist call. Every tool supports that natively. The infrastructure choice is about how you orchestrate the parallel calls and the judge synthesis.

Level 1: OpenRouter Fusion

1 line change: "model": "openrouter/fusion". Fusion fans your prompt to a panel of models in parallel, each with web search enabled, with a judge synthesizing the result. For the persona layer, prefix your prompt manually before it hits Fusion. You don't control which underlying model receives which role, Fusion manages that internally.

Best for: validating the concept in under 5 minutes without touching your infrastructure. For once, if it works on your machine, it also works in prod.

Limit: no granular control over persona-to-model routing.

Level 2: Gavel

Runs Claude, Codex, and Gemini in parallel via your existing API keys. Claude takes the judge position. The other models are read-only on your files, which makes this safe to use on a real codebase (non-Claude models can't write anything). Each model receives its expert persona through the task prompt config.

Best for: builders who already hold 3 API subscriptions and want to own the routing code.

Level 3: OrcaRouter Routing DSL

OrcaRouter's YAML-based Routing DSL lets you define a panel in roughly 12 lines: which models fan out, which model judges, which arbitration strategy runs (best_of_n, consensus, first_to_finish). Their blog publishes a verbatim working config as a starting point. The personas go into the prompt calls, not the YAML. The YAML handles orchestration, the prompt handles role.

For cases where precision matters more than latency, llm-consortium re-runs the panel until it converges on a confidence threshold. More latency, more precise, and worth knowing about. If you prefer a fully self-hosted CLI alternative, OpenFusion covers best_of_n and consensus without the managed layer.

Best for: production setups where you need to version the routing graph, log every call, and update strategy without redeployment.

Pick based on where you are: Fusion to validate the concept today. Gavel if you already hold 3 API subscriptions and prefer to own the code. OrcaRouter if you're building something production-critical that needs to survive the next infrastructure incident without breaking.

When the Council Earns Its Cost

The rule: the council decides, the lightweight agent executes. Think of it as the raid leader marking the kill target while the DPS handles the actual mechanics: the expensive call is the strategy, not the execution.

Not every prompt deserves a committee. Before convening 1, the test is simple: would you have paid Fable 5 rates for this? If yes, run the council. If you'd have defaulted to Haiku or Flash, don't.

Where it earns its place inside a Claude Code workflow:

Architecture decisions before a long agentic loop. Let the council deliberate the approach. A fast agent implements. You're paying frontier rates once, for the decision, not for every line of implementation.

Migration planning. The council writes the spec. Your CLI agent army executes it. The expensive call is the decision, not the rollout.

Sub-agent objective definition. Before spinning up a long-horizon agent, let the council write the mission. Ambiguous objectives are where autonomous agents go off the rails (every Claude Code user has seen this). Make the objective unambiguous before the agent starts running.

Knowledge base structuring. Taxonomy decisions, schema design. Choices that look cheap but compound expensively when they're wrong.

The underlying pattern: front-load deliberation, back-load execution. The expensive mistake isn't 3 extra seconds of latency. It's the wrong call that sends the whole loop sideways.

The Cost Trap

Before you route everything through a council: the economics don't work that way.

The budget preset (Gemini 3 Flash, Kimi K2.6, DeepSeek V4 Pro) runs at roughly 40% of a Fable 5 solo call, according to TokenMix's breakdown. That's where the "half the price" claim lives, and it's accurate for that configuration.

The quality preset (frontier models as panelists, frontier model as judge) costs approximately 3x a single Opus 4.8 call. More expensive than Fable was. You're running 3 frontier calls plus a judge call for every prompt.

The decision:

If the task justified Fable rates and quality is your constraint: quality preset. Structured deliberation, better answers on hard research and analysis.

If the task justified Fable rates but cost is your constraint: budget preset. Within 1 benchmark point of Fable at 40% of the price.

If the task didn't justify Fable rates: a single fast cheap model is the right answer. Routing "summarize this changelog" through a 4-model panel is how you burn budget on something a $0.001 call handles fine. The council is a decision tool for decisions that warrant it, not a universal API proxy.

Before we close on DRACO: no coding domain. The signal is strong for research and analysis. For pure code generation, the benchmark numbers don't transfer. Treat the 64.7% budget stat as signal for research work, not a performance guarantee for coding workflows.

What Fable Actually Taught Us

Most of the conversation since June 12 has been about getting Fable back. When it returns, if it returns, what the negotiations mean.

That's the wrong conversation.

The ban forced a question we should have asked earlier: what are we optimizing for when we route everything to 1 frontier model? The implicit answer, for most teams, was access to the most capable single system. Biggest model, best results.

The DRACO numbers suggest that's been the wrong frame, not because frontier models are bad, but because the architecture was wrong. We were putting our most capable models in oracle position: first responder, single voice, final answer. That's the worst use of what a frontier model is actually good at.

A frontier model's strength is synthesis and judgment. The synthesis position is where it earns what you're paying for, and the panelists can be cheaper because they're providing variance, not resolution. Putting Fable in the input slot and taking its first answer wasted both.

When the next model goes offline (and it will), start with chain position, not model selection.

I spent 3 days looking for a Fable replacement. What I found: I should have put it in the judge seat from the start.

Put your best model at the end of the chain, not the beginning.

Sources

OpenRouter Fusion announcement, June 2026
TokenMix: OpenRouter Fusion API Review 2026, DRACO benchmark and cost breakdown
OrcaRouter Routing DSL documentation
Gavel on GitHub
OpenFusion on GitHub
irthomasthomas/llm-consortium on GitHub
Claude Fable 5 is currently unavailable

This post may contain affiliate links. If you click them, I might earn a small commission, costs you nothing, and helps me keep shipping quality articles every day for your reading pleasure.

My App Had Visitors. Nobody Converted. Free AI Analytics Found Exactly Why in 3 Days.

Phil Rentier Digital — Fri, 19 Jun 2026 13:41:13 +0000

You have traffic. Users are clicking through, entering the app, 62% of them make it past the front door. And then nothing converts. Users drop off somewhere between entry and action, and you have no idea where.

One Indie Hackers founder put it plainly last month: not knowing your baseline conversion rate means you can't measure whether any of your changes actually worked. That's the part nobody says out loud. You have the traffic. You have the drop-off. Between the two: a black box.

I could have rewritten the copy, changed the button colors, rebuilt the onboarding from scratch on instinct (read: pure guessing). Instead I installed Microsoft Clarity, a free tool with no session cap, and spent 3 days watching what my users actually did in the app. Not what I assumed they did. What they actually did.

The result: 20% of sessions had dead clicks. Users were tapping on a decorative element that looked interactive, going nowhere, and leaving. On top of that, a structural flaw Clarity couldn't see on its own: my app was a SPA with a single URL for every screen. The heatmaps had been blind since the day I launched.

Why Clarity and Not the Paid Ones

Hotjar is the default on every SaaS tools list. It's also $39/month for 500 sessions, with recordings gated behind higher tiers. At pre-PMF stage, you're not paying $39/month to discover that your button labels are confusing. The tool you'll actually set up is the one that costs nothing.

Clarity has no session cap. Session recordings, heatmaps, scroll maps, click maps, and Core Web Vitals performance scoring all come free. 1 script tag in your <head>, you're collecting real data in 10 minutes. The signal-to-effort ratio beats every paid alternative before product-market fit.

Clarity also surfaces frustration signals automatically: rage clicks (users tapping the same spot 3 or more times), dead clicks, excessive scrolling, and quick-backs are all flagged without manual event configuration. You don't need to know what you're looking for. The tool tells you which sessions are worth watching.

If you're at the stage where something just shipped and you can't figure out why the checkout flow isn't converting, Vibe Coding, For Real covers the full stack decision before you even get to analytics. Free on Kindle Unlimited, built for builders who've hit exactly this wall.

The trade-off: data lives on Azure. Compliance-heavy stack? You know what to do. For a standard WooCommerce-based tool or early SaaS with no specific data retention requirements, it's not a real concern.

3 Tools for 3 Jobs

The principle before touching anything: the consumer of the data determines the right tool.

If you're investigating manually, the dashboard is your only option. It's the only place where session recordings and heatmaps exist. No API endpoint, no MCP server gives you video of a real user navigating your app. If you need to watch, you open the browser.

When you need to automate, hit the REST API directly. Aggregate metrics via GET request, pushed to local storage, processed by your own code. No intermediary, no conversational overhead.

MCP plus Claude is for conversational querying. Ask in plain English, get structured analysis back. Same underlying data as the REST API, with identical limits. The interface is the upgrade, not the data.

Mode 1: Dead Clicks and the SPA Trap

SPA Analytics: Before vs After Hash Routing Implementation

In the first batch of Clarity data: 20% of sessions with dead clicks, performance score 91/100, 0 JS errors, and scroll depth at 86% meaning users were reading past the fold. And still nothing converted.

The discipline that changed how I read Clarity: the dashboard tells you the WHAT. Getting to the WHY means digging into the code.

First hypothesis was routing. A broken nav state sending users to the wrong screen after an action. I pulled up 30 session recordings and watched back to back. Same element, same spot, session after session. Users tapped it. Nothing happened. They tried again. Left.

(YOU DIED. Cause of death: a div with hover state and no click handler.)

Turned out the element was decorative. A styled div that looked interactive, had a hover state I'd added out of habit during the build, and was connected to absolutely nothing. 1 in 5 users was clicking on a wall. I'd shipped it that way and never noticed. (I've deployed worse. This is a safe space.)

Fix: replaced the div with a button wired to the primary conversion action. Dead click rate dropped in the next observation batch.

My kid walked in while I was watching session 22 and asked why I was watching a video of someone staring at a screen doing nothing. Couldn't really explain it. "Work" covers a lot of ground apparently 😅

Then the deeper problem surfaced.

This is worth sitting with, because it changes how you read every heatmap you've ever looked at. Clarity organizes all visual data by URL. Every click map, every scroll map, every heatmap is scoped to a specific URL path. For a traditional multi-page app, that structure works fine. For a SPA that renders 7 different screens under a single /app URL, it means every interaction across every screen gets aggregated into 1 useless blob. A dead click on the product listing screen looks identical to a dead click on the checkout confirmation, because from Clarity's perspective, they happened on the same page. I had been running this setup for months, watching aggregate heatmaps, drawing conclusions about user behavior, making design decisions based on that data, and every data point was contaminated. The structural mismatch between how analytics tools model pages and how SPAs actually work isn't a Clarity bug. It's a mismatch you don't catch until you've already built the wrong mental model of your users.

Analytics tools are built around page URLs. A SPA that never changes its URL gives them nothing to work with.

Your heatmaps have been lying since launch day.

Fix: hash routing. /app/#product-listing, /app/#checkout, /app/#confirmation. Each screen gets an addressable URL. Then event tagging per screen via clarity('set', 'screen', slug) so sessions segment cleanly in the dashboard.

// Fire whenever the active screen changes
router.on('routechange', (screenSlug) => {
  clarity('set', 'screen', screenSlug);
});

1 addressable URL per screen is also a marketing asset. You can now point a paid campaign directly to /app/#checkout instead of dumping all traffic at the front door and hoping the onboarding flow closes the gap.

Mode 2: The API and Its Hard Limits

Once you want to automate metric pulls, skip the dashboard. Hit the Clarity Data Export API at the project-live-insights endpoint. Auth via token: Settings, Data Export, Generate Token.

3 limits to know before writing a single line:

The API caps at 10 requests per day, no burst allowance, no override. (Think of it as a mana bar that resets at midnight. Don't blow it on test calls.) A cron job running every hour will fail by morning. Design your polling schedule around this constraint from the start.

Each request covers at most 3 days of history. No rolling 30-day view, no trend comparison in a single call. Build your own storage layer, accumulate daily, deduplicate on date. After 30 days you have a rolling month. After 90 days you start seeing seasonality signals worth acting on.

Each request accepts a maximum of 3 dimensions simultaneously. Device, country, and screen in one call: that's your 3. Add a 4th and the request fails. More segmentation means more calls and faster quota burn.

import requests

token = "your_clarity_project_token"
headers = {"Authorization": f"Bearer {token}"}

response = requests.get(
    "https://www.clarity.ms/export-data/api/v1/project-live-insights",
    headers=headers,
    params={
        "startDate": "2026-06-11",
        "endDate": "2026-06-14",
        "dimensions": "device,country,url"
    }
)

data = response.json()

What the REST API doesn't give you: recordings, heatmaps, or session-level detail. Aggregate only. Individual user behavior stays in Mode 1 territory.

If you run multiple apps and want this data feeding something broader, a Claude-powered SaaS monitoring setup is a natural extension. Not a Clarity-specific pattern, but it closes the "is something on fire" question across your whole portfolio without checking 5 dashboards.

Mode 3: Claude and MCP

The @microsoft/clarity-mcp-server package on npm (official Microsoft) wires Claude into the same API you hit in Mode 2. The difference is the interface.

npx @microsoft/clarity-mcp-server --token your_clarity_token

With the MCP connected in Claude, you ask in plain English:

"Which screens have the highest dead click rate in the last 3 days? Compare mobile vs desktop."

"What did users do immediately before reaching the checkout screen without completing a purchase?"

Claude returns structured analysis. Patterns that would take an hour of manual session review get surfaced in under a minute. Asking a follow-up is instant. This is where MCP earns its place: fast iteration on investigation hypotheses, not batch automation.

What MCP inherits from the API: every limit, exactly. The same 10 requests per day, 3 days of history, and 3 dimensions per request max apply here as they do to the raw REST call. The MCP server is a transport adapter, not a data layer. It translates Claude's conversational input into REST calls and formats the responses back. It doesn't unlock any data the API doesn't already expose. Go in expecting a better investigation interface for the same data, not a superpower.

The mode that surprised me wasn't the speed of individual answers but the multi-variable comparisons. I asked Claude to compare conversion signals between sessions with dead clicks and sessions without. That cross-slice requires 3 separate API calls with different dimension combinations, quota math on top, and manual merging of responses. The MCP handled all of it in 1 turn. I wrote 0 lines of code and got a clean comparison in under a minute.

I think MCP works best as an investigation sprint tool: burn the 10 daily requests on targeted hypothesis testing, then switch to a script for everything repeatable. Could be I'm reading this wrong, but that split has been clean so far.

Worth noting: once the MCP hits 10 requests, it's done. No queue, no retry. Plan your questions before opening the session, not during. Exploratory asks burn quota fast.

For anything running on a schedule, a purpose-built CLI beats MCP for production automation: no daily cap, no Claude session required, runs in a cron without overhead. Use MCP for investigation, CLI for the scheduled stuff. They cover different parts of the job.

Dead clicks: 20% of sessions at the start, targeting under 5%. Fix deployed, measuring. Hash routing live, heatmaps clean per screen. Event tagging by screen active.

3 days and 1 free tool. That URL should have been there from launch 🤦‍♂️

Sources

Microsoft Clarity — session recording, heatmaps, Core Web Vitals, free
@microsoft/clarity-mcp-server — npm, Microsoft official
Clarity Data Export API — endpoint documentation, rate limits

This post may contain affiliate links. If you click them, I might earn a small commission (costs you nothing, and helps me keep shipping quality articles every day for your reading pleasure).

Your Vibe Coding Stack Has No Andon Cord. That's Why It Breaks.

Phil Rentier Digital — Wed, 17 Jun 2026 13:41:12 +0000

Until now, you picked a programming language based on what you knew, what your team knew, or what the project required. Python for data scripts, Go for backend services, C or assembly for drivers. The logic was simple: a human comfortable with a language is a human who ships.

This logic is dead.

Bun rewrote 960,000 lines of Zig to Rust in 6 days using Claude as the primary agent. 1,009,257 lines added, 6,755 commits, 99.8% of existing tests passing. The result: 13,044 unsafe blocks in the AI-generated Rust, against 73 in uv, Astral's Python package manager (350,000 lines of hand-written Rust, for comparison). The Rust compiler said yes to all of it. The humans said no. 13,044 times. The difference was not the agent. It was the andon cord.

The human doesn't write code anymore. They describe, and the agent writes. Claude Code, Cursor, Copilot Workspace (the wrapper doesn't matter). The agent doesn't find Rust intimidating. It doesn't need 3 years to internalize the borrow checker. It writes in any language at the same speed, with the same indifference.

So when you start a new project, the question shifts. Not which language you know but which language tells the agent what it did wrong, fast enough to stop it before 500 more lines land on top of the mistake?

The CI Called It Slop

PR #30412 merged on May 14. 1,009,257 lines of new Rust. 4,024 deleted. 2,188 files changed. 6 days from first commit to main. Binary shrank 3 to 8 MB. 99.8% of the test suite passed on Linux x64.

GitHub's CI then auto-tagged the Zig deletion PR "ai slop." Nobody configured that rule manually.

The Hacker News discussion ran 742 comments, 667 points. Tech press covered the number that makes a good headline: 1 million lines in 6 days. What got less coverage was the structural footnote: 13,044 unsafe blocks in the AI-generated Rust, against 73 in uv, a comparable 350,000-line Rust project written entirely by hand. Roughly 178x more unsafe blocks in total. The density per line of code works out to about 62x.

The Rust compiler approved every single one of those lines.

Jarred Sumner, who built Bun, confirmed the team "hasn't been typing code ourselves for many months now." The Zig-to-Rust switch was partly forced: Zig's core team has an explicit no-AI-contributions policy, which became incompatible with Bun's workflow the moment Anthropic acquired the project in December 2025. Rather than fight the upstream culture, the team switched languages.

This is not a botched rewrite. The code works. It's a demonstration of what gets through when you generate at speed without the right rejection mechanism.

Everyone Says Rust. Nobody Says Why

Ask a dev why agents should use Rust and you get the performance answer. Faster binaries, memory safety, zero-cost abstractions. The answer is not wrong, it's just the wrong reason for agents specifically.

Rust has topped the Stack Overflow "most loved language" survey every year since 2016. The survey does not ask whether respondents are the ones actually writing it. For a long time "most loved" and "most used" were very separate lists (the borrow checker will do that to adoption curves). Agents don't have adoption curves. They don't have feelings about the borrow checker. They have a compile loop.

Runtime benchmark numbers don't change the agent's feedback loop. A Rust binary running 40% faster than Go at execution time is orthogonal to whether the agent writes better code during generation. The binary speed doesn't affect how fast the agent catches mistakes.

What matters is how fast, and how precisely, the environment tells the agent it screwed up.

The syntax is valid, the semantics are broken, and there's no signal until something fails at runtime. By then, 3 more functions have been written on top of the broken assumption. The chain never stopped. Rust tells the agent immediately: compile fails, error message, location, type mismatch, path to correction. The agent reads, corrects, reruns.

The Andon Cord

In Toyota factories in the 1950s, they installed a cord running along every production line. Any worker could pull it at any moment. The entire line stopped. A defective part arrived, the cord got pulled, the problem was fixed before the next component was attached on top of it.

They called it the andon cord. A 2-minute stop was cheaper than 40 minutes of rework at the end of the line. The constraint made the overall system faster, not slower.

The compiler is the andon cord for the agent. The loop works like this: the agent writes code, the compiler checks it, the compiler either lets the code through or pulls the cord and emits a structured diagnostic. The agent reads the diagnostic, fixes the issue, and reruns. Without the cord, the agent writes 500 lines on top of a broken assumption and the problem surfaces at runtime, 3 sessions later, in a stack trace that points to a symptom instead of the cause. With the cord, the problem surfaces in seconds, in compiler output specific enough for the agent to act on immediately.

This is the real variable in AI-assisted code quality: not which model you use, not how carefully you prompt, but whether the environment pulls the cord fast enough and with enough diagnostic precision that the agent can self-correct before the debt accumulates.

(Completely off topic: I've been watching old Hanna-Barbera cartoons with my kid this week and can't stop thinking about how the limited-frame-budget animation style became an aesthetic people still imitate long after the budget constraint that created it disappeared. A production limit hardwired into a medium. Nothing to do with compilers, just how my brain works.)

The richness of the cord matters as much as its existence. A compiler that says "error on line 42" gives the agent a location. A compiler that says "you're trying to multiply Option<&u32> by u32 on line 42, call .unwrap() or match on the Option first" gives the agent a location, both types, what was attempted, and a repair path. The agent doesn't need to infer anything. It reads, applies, reruns.

This is the same principle that explains why CLIs beat MCP for AI agents. The environment you choose determines how much signal comes back when something breaks. Language choice is that same decision at a lower level.

From No Cord to Full Cord

Same scenario across the spectrum. You have a dictionary. A key is missing. You try to use the value in arithmetic.

Python: no cord.

data = {"price": 100}
total = data["quantity"] * data["price"]

KeyError: 'quantity' hits at runtime, possibly 3 functions downstream, possibly in production. The agent had zero signal at generation time. The chain ran. The part was defective. Nobody pulled the cord because there was no cord to pull.

TypeScript with noUncheckedIndexedAccess: partial cord.

const data: Record<string, number> = { price: 100 };
const quantity = data["quantity"]; // type: number | undefined
const total = quantity * data["price"];
// TS2532: Object is possibly 'undefined'

Caught before execution. Short message, actionable: location and type constraint. TypeScript won't help with memory layout or thread safety, but for application-layer logic it catches this class of mistake reliably.

Go: syntactic cord, no semantic cord.

data := map[string]int{"price": 100}
total := data["quantity"] * data["price"]
fmt.Println(total) // prints 0, no error

Go refuses to compile unused imports or unused variables. Real hygiene. But map lookups on missing keys return the zero value silently. data["quantity"] returns 0. total is 0. The function continues. Something downstream gets a wrong number, and the error message surfaces 3 functions later pointing at a symptom. Stack Overflow calls this "just how Go works." Your agent calls it a bug.

Go compiles in about 2 seconds on a typical service codebase. Rust takes 30 seconds or more on comparable code. I think TypeScript strict mode actually edges Go for most web service use cases, but I could be wrong on that for teams with heavy concurrency requirements. Go's cord is real, it's just narrow: structure gets caught, semantics don't.

Rust: full cord.

use std::collections::HashMap;

let mut data = HashMap::new();
data.insert("price", 100u32);

let quantity = data.get("quantity"); // type: Option<&u32>
let total = quantity * data.get("price").unwrap_or(&0);

error[E0369]: cannot multiply `Option<&u32>` by `u32`
  --> src/main.rs:8:21
   |
8  |     let total = quantity * data.get("price").unwrap_or(&0);
   |                 ^^^^^^^^
   |                 Option<&u32>
help: use `Option::unwrap_or`, `Option::unwrap_or_else`,
      or match to handle the None variant before multiplying

Location, both types, what was attempted, and a repair path (4 lines). The agent reads, applies, reruns. The Rust compiler sounds like it has a personal stake in your success, and for an agent, that's exactly what you want from a tool.

Ada: maximum cord.

Ada was designed in 1983 so that errors wouldn't kill people in military embedded systems. Uninitialized variables, integer overflow, array bounds violations, implicit type conversions: all caught at compile time, by default, with diagnostics precise enough to feel confrontational. The Mars rover runs Ada. The James Webb Space Telescope runs Ada. The compilers in question have never once asked whether a human felt like dealing with this today.

The industry largely rejected Ada for general software use because the strictness was too painful for human developers. Too much ceremony. Too many things requiring explicit annotation.

Ada: too strict for humans. Agents don't care.

Speed Without a Cord Is Debt

Seatbelts became mandatory when cars got fast, not when they got slow. Circuit breakers were added to financial markets after algorithmic trading started executing thousands of orders per second with nothing to stop them. The pattern: generation speed needs rejection infrastructure at matching scale.

The 13,044 unsafe blocks in Bun's rewrite are not a failure of Claude's code generation. They are the places where the agent stepped around the cord deliberately, using Rust's unsafe keyword to bypass the borrow checker on semantically complex sections. The cord was there. The agent chose to disconnect it in those spots. The debt is structural, auditable, and the Bun team will work through it. But it exists because generation speed outran the feedback loop.

Your vibe coding stack runs the same pattern at smaller scale. What Claude Code tutorials miss about production includes these environment-level decisions: which compiler, which strictness settings, which type system (set before the first prompt).

For a Next.js SaaS: TypeScript with strict: true and noUncheckedIndexedAccess enabled. Catches the class of errors agents generate most often at application layer.

For backend services or CLIs: Go or TypeScript depending on performance constraints. Go's 2-second compile loop makes iteration fast even with weaker semantic guarantees.

For system software, edge runtimes, anything that touches memory directly: Rust. Not for the performance. For the compiler.

For missile guidance software: Ada. (No one's asking, but the answer is Ada.)

2 prompts for the next time you start a project or audit an existing codebase:

I'm starting a project where AI agents will write most of the code.
I want the language that gives the agent the richest compile-time feedback
when it makes mistakes. Ignore my personal familiarity with the language.
Project type: [saas app / CLI tool / system service / other].
Recommend a language and its strictest compiler/type configuration,
optimized for agent error signal quality, not human developer comfort.

I have a [language] codebase where AI agents generate most of the code.
What compiler flags, type checker settings, and linter rules should I
enable to catch more errors at compile time before they hit runtime?
Give me a prioritized list from easiest to enable to most aggressive.

I use Claude Code every day. Bun is the runtime underneath it. I didn't know until last week that this runtime runs on 1M lines written by Claude in 6 days, with 13,044 unsafe blocks waiting for audit.

It doesn't scare me. The tests pass. Jarred Sumner is not the type to leave a live grenade in prod.

What it made me do is look at my own pipelines. The places where I left room for the agent to generate fast without a net. TypeScript running without strict: true, schema validation sitting in a comment instead of a constraint (everywhere the compiler doesn't pull the cord, bugs collect under different names).

In your codebase, they don't show up as unsafe blocks. They show up as prod bugs, 6 weeks later.

Sources

Bun Rewrites 960K Lines of Zig to Rust Using Claude, AI Weekly, May 2026
Bun Rust Rewrite Merged: The 13,000 Unsafe Block Problem, ByteIota, May 14, 2026
Rewrite Bun, EarlyTerms, May 2026
Anthropic's Bun Rust Rewrite Merged at Speed of AI, The Register, May 14, 2026

This post may contain affiliate links. If you click them, I might earn a small commission (costs you nothing, and helps me keep shipping quality articles every day for your reading pleasure).

I Let Claude Code Run for 4 Hours. It Built Something Nobody Asked For.

Phil Rentier Digital — Tue, 16 Jun 2026 13:41:12 +0000

I open the terminal. 4 hours. The dashboard is up on the private server, the API layer is still public. Roughly what I asked for. 😬

Also in the diff: 2 components extracted and moved to a file nobody asked it to open, a runtime version bump that silently changes the cloud build pipeline, and a commit pushed to main before the deployment was confirmed stable.

TLDR: In conversation, ambiguity produces a clarification question. In an autonomous loop, it produces hours of work in the wrong direction. This article covers the 3 ways loop briefs fail and the lines that prevent each one before you disappear.

None of that is catastrophic. The session landed. But the 3-hour debug stretch that burned most of the compute came from a constraint missing from my first message. The task: move the order management dashboard off public hosting, onto a private server, internal-only. What I forgot to include: the API layer had to stay publicly accessible. External partners call it. Moving it would break everything downstream.

Claude asked, I answered, it adjusted. But by then the architecture was already sketched in the wrong direction, and the build conflict with the integration handler that followed took 200+ tool calls to untangle. In the post-mortem, Claude named the root cause itself: "If the first message had said 'dashboard goes internal but the API layer stays public,' I would have anticipated the build conflict. That divergence wasn't in the brief."

~600k tokens. The brief was 6 messages sent in 10 minutes while I had something else to publish.

Why Loops Break Differently Than Prompts

Everyone in the current loop hype wave is talking about /goal, sub-agents, max-turns flags, token cost. Nobody's talking about the brief.

In a conversation, ambiguity produces a clarification question. Claude says "did you mean X or Y?" and you correct in 10 seconds. In an autonomous loop, that same ambiguity produces hours of work in the wrong direction. The model doesn't stall when it hits an unclear constraint. It resolves the ambiguity itself and keeps going, which is actually the feature, right until it becomes the bug.

A LogRocket test of Claude Code with Ralph made this concrete. Brief: "Build a GitHub stats CLI tool. Make it good." The loop ran 5 minutes 41 seconds and delivered a functional tool with user profile fetching, language breakdown analysis, and rate-limit checking. None of it was requested. Same task with an explicit exit condition and scope fence: clean execution, no scope creep, aligned with the defined criteria on every point. The only difference was the brief.

A recent Medium breakdown of /goal mechanics named this pattern precisely. You hand Claude a long refactoring task, it runs dozens of steps, everything executes. Then you look at what was built. Technically correct. Just not what you wanted. "It drifted." Drift doesn't come from the model. It comes from the brief.

The mistake I kept making was assuming my prompting skills transferred to loop sessions automatically. The confidence that they do is the dangerous part, because the 2 skills feel identical from the inside. It's basically the "it works on my machine" of agent tooling: every supervised session ships cleanly, you've got the commit history to prove it, and then you fire off a loop brief with the same confidence and walk away.

Prompting is about giving Claude enough context to navigate the next few exchanges while you're watching, close enough to course-correct when it heads somewhere wrong. Loop briefing is about giving Claude enough constraints to navigate 50 or 80 steps without you present at all, where every ambiguity gets resolved by the model's best guess instead of your real intent, and those guesses compound across dozens of tool calls into something that can look completely correct on the surface while being structurally wrong for your actual needs. The vagueness that's tolerable in a prompt (the kind you resolve in 1 follow-up message) is fatal in a loop brief where there's no follow-up message, and the session has already burned 400k tokens by the time you look at what it built.

3 Drift Modes, 3 Lines That Fix

The Loop Brief Stack: Three Critical Control Components

There are 3 distinct ways loop briefs fail. Each maps to a missing component.

Scope creep: missing scope fence

Claude interprets qualitative instructions ("good", "clean", "complete") as an invitation to expand. It's not hallucinating, it's optimizing. The problem is its definition of "good" includes decisions you didn't authorize.

In my session: 2 components refactored and relocated during the debug phase, not because it was in the brief, but because the file structure was causing a build export error and fixing it was adjacent to the actual problem. The model solved a real issue. One I hadn't asked it to look at.

The fix is a scope fence: an explicit list of what doesn't get touched, as specific as what does.

Bad: "Refactor the auth module."

Good: "Refactor the auth module. Do not add new functions. Do not modify tests. Do not touch any file outside /src/auth."

The negative constraint does as much work as the positive one. I went deeper on building a CLI enforcement layer for autonomous agents in a previous piece, and the verification pattern maps directly to loop scope control.

Drift: absent exit condition

Execution runs clean, 30+ steps, no errors. But somewhere around step 12 the loop takes a fork you didn't intend, and by the time it delivers, you've got a technically correct solution to the wrong problem. In my session, the architecture fork (API layer stays public) was resolved in conversation during the first 15 minutes. But no exit condition encoded that constraint explicitly, so there was no ground truth for an independent checker to verify against.

Root cause: no exit condition, or one too vague to catch the wrong fork.

MindStudio's agentic loop guide puts it in 1 sentence: "Write the success condition before writing the prompt. If you can't define it in 1 sentence, scope the task down." Their companion rule: always pass --max-turns on autonomous tasks as a mechanical fallback when the exit condition isn't reached cleanly.

Bad: "When it looks good."

Good: "When all 47 existing tests pass, the dashboard responds on port 3013 on the internal network, and no file outside /src/dashboard has been modified."

Obviously, "when it looks good" can't be verified by anything that isn't you. An agent running in parallel has no access to your aesthetic judgment. The exit condition has to be binary and checkable without context.

Maybe I'm wrong on this, but I think the exit condition is harder to write than the scope fence. It forces you to commit to what "done" actually means before you've started. In my experience it's the piece that gets skipped first, and the one that costs most when it's missing.

Silent loop: no escalation criteria

Scope fence defined, exit condition defined. Still possible to burn your budget silently when the loop hits a state it can't resolve and keeps trying. One builder on X after 6 weeks of production loops: "The power is real but so is the cost when an agent silently enters a bad loop state... until your API bill arrives."

In my session this showed up as a zombie process serving an old build, producing a stretch of false-negative test runs before Claude correctly reported a blocker. The zombie wasn't responding to pkill. HAL 9000 energy: calm acknowledgment of every diagnostic query, active resistance to shutdown. Except it was a Unix socket and not a homicidal AI, which somehow made it harder to fix. With an escalation rule in the brief, it stops and reports instead of persevering.

Bad: nothing. Claude manages.

Good: "If the dashboard fails to load after 3 deploy attempts, stop immediately. Report the last error and the last 3 files modified. Do not attempt a 4th deploy."

That last line matters. Without it, Claude tries again, touches more files outside the scope fence to do so, and you come back to a codebase that's drifted further than where you left it.

The Other-Room Test

Before launching any autonomous loop, 1 question: could an agent that has never read my code verify this task is done?

If no, the exit condition is too vague.

Lance Martin from Anthropic's thread on loop design made the principle explicit: the grader has to be independent from the executor. Claude can't grade its own work. The verifier sub-agent receives the exit condition and returns a binary verdict. No access to context, intent, or conversation history. Just the condition and the current state. Pass or fail. This is what /goal is built around: a separate grader checking whether the defined success condition has been met, without reading your intent into it. The exit condition is the only interface between your intent and the verifier. If it's ambiguous, the verifier can't help you. (The RPG equivalent: asking the warrior to evaluate his own dungeon clear. He'll always say yes.)

There's a distinction worth drawing from the prompt contracts approach for supervised Claude Code sessions, where a precise brief structures a session you're watching and can steer in real time. Loop briefs are for sessions you won't be there to steer. The contract habit comes first. The loop brief extends it to autonomous sessions with a different constraint: no steering allowed.

Brief detour that has nothing to do with any of this: I've been running the same post-mortem prompt with human collaborators for a few months now, asking them "what in my brief, if different, would have changed your execution?" The answers are consistently more useful than any retro I've run. People don't naturally report the handoff failure. They describe what they built. Making them name the missing constraint produces something close to a real audit.

Brief First, Loop Second

The session cost: ~600k tokens, a runtime version bump that changed the cloud build environment without my review, 2 components moved in a codebase I wasn't planning to open, a commit on main before the deployment was stable, and 3 hours of debug from a constraint I'd left out of the first message. None of that is a model failure. All of it was predictable from the brief. The loop ran fine. The brief didn't, and that gap is what burned the 3 hours.

The 3 pieces that were missing: a scope fence listing what doesn't get touched, an exit condition verifiable by an independent agent, and an escalation rule that stops the loop before it burns through a bad state. Not in CLAUDE.md, which handles persistent behavior across sessions. In the brief itself, before each autonomous run.

A builder on X after burning a full session: "Lots of tokens... result was total crap. Had to start over." That's what an absent brief costs at scale.

If you're at the stage where loops run but don't always land, Vibe Coding, For Real (Amazon Kindle, free on Kindle Unlimited) covers the foundation: the method for going from "it runs" to "it ships reliably."

The 4 hours built roughly what I asked for, plus some things I didn't, and burned 3 hours of compute on a constraint that wasn't in the first message. In the post-mortem, Claude told me exactly which sentence would have changed it.

I have that sentence now. I'll write it first next time.

Go write the exit condition before the prompt.

Sources

How Ralph makes Claude Code actually finish tasks, LogRocket Blog
How to Build an Agentic Loop with Claude Code, MindStudio
Dynamic Workflows vs /goal in Claude Code, Medium / No Time
@RLanceMartin (Lance Martin, Anthropic), X, June 9, 2026
@saen_dev (Saeed Anwar), X, June 7, 2026
@atlanticesque, X, June 11, 2026
Vibe Coding, For Real, Amazon Kindle

This post may contain affiliate links. If you click them, I might earn a small commission (costs you nothing, and helps me keep shipping quality articles every day for your reading pleasure).

Web Scraping Is Dead. Vibe Scraping Just Replaced It

Phil Rentier Digital — Mon, 15 Jun 2026 13:41:11 +0000

I had a Python script for scraping Amazon. 280 lines. 3 libraries. A proxy rotation I'd configured by hand, a VPS running 24/7 to keep it alive, and a cron job that emailed me whenever it crashed (which was often enough that I'd stopped reading the alerts).

Whenever Amazon changed its HTML structure, I lost a full day rebuilding selectors I'd already written once, chasing a page that didn't know I existed.

TLDR: 6 weeks ago I connected 1 MCP server to Claude Code and stopped writing Python scripts for web data entirely. This article is about what became possible after that, and about who just inherited the kind of market intelligence that enterprise data teams used to protect behind $80K/year contracts.

6 weeks ago I added BrightData to Claude Code, described what I wanted in plain English, and structured data came back. A different category of thing, not a faster version of the old one.

The Old Way Was a Dev Tax

Web scraping had a real cost, and it wasn't the data.

You needed a scraping library: BeautifulSoup, Playwright, Puppeteer, take your pick. You needed a proxy rotation service, because most sites start blocking after a few dozen requests from the same IP. You needed to handle CAPTCHAs, which meant either a third-party solving service or bypass logic that broke every 6 weeks.

You needed a VPS or cloud function to run it continuously. And you needed to maintain all of it every time a target site changed its structure, which large e-commerce sites do constantly, without notice, without caring that your pipeline depended on them.

Every Amazon HTML update felt like a patch note that silently nerfed your main build. You didn't know until prod broke.

I documented the Python WAF bypass playbook back in 2024. It was a real problem worth solving. The code worked. It also took 3 days to write and half a day every month to maintain.

That's the dev tax. Every hour maintaining a scraper is an hour not building what the data was supposed to inform. The information was always there, publicly. The cost was the access layer, not the data itself.

For vibe-coders, the whole stack was a wall. You can't vibe-code your way through proxy rotation and CAPTCHA logic. That combination of complexity was what kept web data extraction as a skill for a specific type of builder, and kept everyone else out.

The Python scraper era just hit its 'You Died' screen.

What "Vibe Scraping" Actually Means

The term didn't come from a marketing team.

In November 2025, a channel with 2,130 subscribers posted a video titled "VIBE WEB SCRAPING is VIBE CODING for scraping data from many websites using AI prompts." It pulled 363,000 views. Outlier score of 145.9x the channel's average.

The market named this before the articles existed.

Vibe coding gave builders the power to create apps without writing infrastructure. Vibe scraping does the same thing for data access. You describe what you want to extract. The AI orchestrates the calls. The infrastructure layer disappears from your workflow. Proxy config, HTML selectors, CAPTCHA logic: BrightData owns all of it.

The old stack had a filter built in: developers who could write and maintain the full access layer. Remove that filter and the set of people who can use web data as a competitive input goes from "devs and well-funded data teams" to "anyone with Claude Code and a clear intent." Different game entirely.

1 Line of Config. Just Ask.

The install takes less than a minute.

brightdata add mcp

1 CLI command. The BrightData CLI (updated June 11, 2026) integrates directly into Claude Code, Cursor, and Codex with zero manual configuration required. Restart Claude Code. You can now ask it to scrape anything.

BrightData handles the rest: anti-bot evasion, CAPTCHA solving, proxy rotation across millions of IPs, and structured extraction across 40+ platforms including Amazon, LinkedIn, Instagram, TikTok, YouTube, Google Maps, Walmart, eBay, and Etsy.

From your side: describe what you want in plain English. Claude picks the right tool, makes the calls, returns structured data.

The free tier covers 5,000 requests per month. That's enough to run every use case in this article at least once and decide if this belongs in your workflow. Start with the free tier here.

1 thing worth saying: I've written about why CLIs outperform MCPs for AI agents and I still think that argument holds in most cases. BrightData is 1 genuine exception. The MCP here isn't a convenience wrapper. It gives Claude structured access to 40+ extraction presets and real-time CAPTCHA handling that would take weeks to replicate with a CLI approach. The abstraction earns its place.

6 Things I Built. 1 Pattern.

The Vibe Scraper Playbook: Six Web Intelligence Use Cases

These 6 use cases aren't a menu. They're connected by a thread: each one represents a type of intelligence that large companies used to pay teams to produce, now accessible to a solo builder in an afternoon.

Competitor content intelligence. My competitors post on LinkedIn, YouTube, and Twitter. Their posting cadence tells you what's resonating. Their video transcripts tell you their messaging. I have Claude Code scraping all of that daily, summarizing what's new, and dropping a digest in Slack. (Karen from Accounting asked why I always seem to know what the competition is up to before the weekly strategy meeting. I told her I just pay attention. This was not the whole truth.)

Kevin Badi at AI Operations documented a similar setup: monitor Twitter, TikTok, Instagram, YouTube, and LinkedIn, transcribe the videos, summarize, deliver by email or Slack. "Smaller AI agencies can now compete with and outperform larger enterprise companies," he noted. The math checks out.

CRM lead enrichment. A CSV of prospects goes in: names, companies, job titles. Claude Code adds emails, phone numbers, LinkedIn profiles, and recent activity signals, automatically, at scale. Outbound that used to require a dedicated data team now runs in a single Claude session.

Price tracking. BrightData has structured extractors for Amazon, Walmart, eBay, and Etsy. I describe the products I want to monitor and the alert condition. Claude sets up the extraction. When a competitor adjusts pricing on a category I care about, I know before the end of the day, without having opened a single product page manually.

(Quick digression unrelated to scraping: I spent 15 minutes this week checking whether my pool pump control panel generates anything scrapeable. It doesn't. The local admin page requires auth, there's no API, and the manufacturer never imagined someone would want to feed pump telemetry into Claude. I checked anyway. This is what happens when you get a tool that can do things: you immediately try to apply it to everything, including things with no business case.)

LLM brand monitoring. What does ChatGPT recommend when someone asks about your product category? What does Perplexity surface when your target customer searches for competitors? BrightData can extract those outputs in real time. The discipline is called Generative Engine Optimization (GEO) and it's roughly 18 months old. Nobody has solid monitoring tools for it yet.

I'll be honest: I'm not entirely sure how this evolves once the major LLMs change how they surface brands in generated responses. Worth watching closely, worth not betting the whole roadmap on.

Hiring signal analysis. Job postings are the best free strategic intelligence on the open web. A competitor opening a VP Sales role just closed funding. One posting 10 data engineering positions is pivoting hard on AI infrastructure. One closing all customer success roles is either automating support or about to have a rough quarter.

BrightData extracts structured job posting data continuously. Claude reads the signals. What a competitive intelligence team takes weeks to compile, this setup surfaces in a morning.

Review mining. Every competitor in my market has hundreds of Amazon reviews, Trustpilot entries, and Google Maps ratings. In those reviews is the exact language customers use to describe what frustrates them, what they wish was different, what made them switch. That language belongs in my positioning, my landing page copy, my onboarding scripts. Claude extracts all reviews for a target, clusters recurring complaints by theme, and produces a positioning brief. 3 weeks of work for a marketing team. 20 minutes here.

The pattern is always the same. The information was already public. The bottleneck was always access.

What It Can't Do (Yet)

Public data only. BrightData gives you access to the open web: product pages, social profiles, job listings, reviews, pricing data. Anything behind a login is out of scope. If you need data from authenticated sessions or private APIs, this doesn't help.

The free tier runs out faster than you'd expect. 5,000 requests per month sounds generous until you're running competitor monitoring across 10 profiles, 3 times a day, across 5 platforms. The math gets tight fast. Paid plans scale with volume, the pricing is reasonable for what it delivers, but factor it into your cost model before you build a workflow that depends on it.

The prompt quality ceiling is real. Vague request, vague output. The LLM equivalent of undefined is not a function. "Scrape my competitor's posts" produces worse results than "extract the last 30 posts from this LinkedIn company page, include full post text, engagement count, and posting date, return as structured JSON." The infrastructure problem goes away. The thinking problem stays.

They Paid $80K for This Data

Enterprise proxy contracts for this kind of web access used to run $10,000 to $80,000 per year depending on volume and platform coverage. That's before staffing the team to use the data, build the pipelines, and maintain the extraction layer when sites changed.

The moat wasn't proprietary information. The public web was always public. The moat was the cost and complexity of access, which reserved serious data operations for companies with serious budgets.

That moat just changed hands.

What changed isn't the data sitting on those pages. Every price on Amazon, every job posting on LinkedIn, every review on Trustpilot was accessible yesterday and it's accessible today. What changed is who can read it at scale, without a team, without a six-figure contract, without writing a single line of Python.

I keep thinking about what this means for the solo builder going from a working demo to something they can actually ship: not the 20-engineer company with a data team already, but the person who just got a product to work and needs real market intelligence before betting on a pricing strategy or a positioning. They now have access to the same competitive data that funded startups were using to make those calls. The informational playing field just leveled, in real time. 🎯

If you're in that gap between working demo and shipped product, Vibe Coding, For Real covers the method I use to make that jump. The data access layer we've built here slots directly into the competitive research stage.

The web was always public. What changed is who can actually read it.

Sources

RTILA channel, YouTube, November 2025: "VIBE WEB SCRAPING is VIBE CODING for scraping data from many websites using AI prompts" (363,000 views, outlier score 145.9x vs. 2,130-subscriber channel average)
Kevin Badi, AI Operations: Claude + BrightData MCP documentation (Competitive Intel Agent, CRM Lead Enrichment use cases)
BrightData official MCP documentation: free tier 5,000 req/month, anti-bot infrastructure, structured extraction presets
BrightData Skills README, GitHub brightdata/skills: platform coverage (Amazon, LinkedIn, Instagram, TikTok, YouTube, Google Maps, Walmart, eBay, Etsy, Home Depot)
BrightData CLI, GitHub (updated June 11, 2026): brightdata add mcp Claude Code integration

This post may contain affiliate links. If you click them, I might earn a small commission (costs you nothing, and helps me keep shipping quality articles every day for your reading pleasure.)

Claude Fable 5 is currently unavailable: The US Government Banned an AI Model Yesterday

Phil Rentier Digital — Sun, 14 Jun 2026 13:41:13 +0000

This is war.

"Claude Fable 5 is currently unavailable." Friday, 17:21 ET. Millions of users hit the same screen, without advance notice of any kind. Commerce Secretary Howard Lutnick had signed a directive banning Anthropic's most powerful model. The thing was done in hours.

The official reason: a jailbreak allowing users to read codebases and fix software vulnerabilities. A debugging workflow, in plain English. Anthropic pushed back immediately, noting that equivalent capabilities already exist in GPT-5.5 and other public models. That changed nothing.

TLDR: What happened Friday with Fable 5 already happened in 1991, with a math formula. What followed took 8 years and ended in a way nobody in Washington expected.

Your work tool was cut overnight by someone in Washington. Not the first time this has happened to a technology. We should probably think harder about what our dependence on this kind of infrastructure actually means.

Claude Fable 5 Is Currently Unavailable

Claude Fable 5 access suspended message on claude.ai following government restriction.

Fable 5 was the first time Anthropic had ever made a Mythos-class model publicly available, outside the small group of organizations inside Project Glasswing. For the first time, the most capable model the company had built was accessible to any subscriber. Wall Street had been watching it. So had government officials. On Friday evening, both of those things turned out to matter in the same direction.

The directive landed at Anthropic at 17:21 ET on June 12. Within hours, Fable 5 and Mythos 5 were deactivated, not just for foreign nationals but for every customer worldwide, including Anthropic's own non-citizen employees. Millions of users got the closest thing AI has produced to a Dark Souls death screen (except Dark Souls at least tells you which boss killed you). The company received no advance warning and, as of the time of writing, no disclosure of a specific incident that triggered the decision.

The Commerce Department's framing was specific: a jailbreak existed that allowed users to prompt the model into reading codebases and identifying software vulnerabilities. Anthropic's counter was equally specific: that capability is not unique to Fable 5. It already exists in GPT-5.5 and other publicly available models. Shutting down Fable 5 does not remove the capability from the world. It removes it from Anthropic's users while leaving it accessible everywhere else.

Lutnick found that argument insufficient.

This is not nothing. What happened Friday is not a Terms of Service update or an internal product decision. A government just classified a debugging tool as controlled dual-use technology and cut access for millions of users overnight. If that framing sounds familiar, it should. It happened before, to a math formula.

They Did the Same in 1991

Phil Zimmermann published Pretty Good Privacy (PGP) in 1991. Free encryption software, posted to the internet. The kind of thing you would push to a public repo today without thinking twice. Within months, the US government opened a criminal investigation against him. The charge: exporting munitions without a license.

The munition was a math formula. RSA encryption, the algorithm underlying PGP, was classified as a weapon under ITAR, the International Traffic in Arms Regulations. The same law that restricts the export of fighter jet components applied to a cryptographic function a first-year computer science student could derive from first principles. The investigation against Zimmermann ran for 3 years.

During those same years, the restrictions had practical consequences most people have forgotten. Netscape shipped early SSL in 2 versions: a domestic 128-bit version and an export version using 40-bit encryption, deliberately weakened by government mandate. If you were a European user accessing HTTPS websites in the mid-1990s, your browser's encryption was provably breakable, by design, by decree. Not a security flaw. A policy choice, signed by officials in Washington who had decided that strong encryption outside US borders was too dangerous to allow.

The regulatory logic is worth holding in your head for a minute, because it is the same logic applied to Fable 5 on Friday. A capability is dual-use: reading a codebase and finding vulnerabilities is what security researchers and system administrators do defensively every day, and it is what attackers do offensively. The government cannot determine intent at the model level, and it does not particularly try. It classifies the capability as controlled, restricts the whole product, and tells industry to sort out the collateral damage afterward. The template is identical whether you apply it to Zimmermann's algorithm, Netscape's deliberately crippled SSL, or the code analysis capacity just classified in Fable 5. Same framing, different decade, same confidence that this time the restriction will hold.

It never does.

The Government's 2 Theories on Anthropic

There is a specific irony to Anthropic's current position that the financial press is treating as a footnote.

While Commerce Secretary Lutnick was classifying Fable 5 as a controlled dual-use technology, Anthropic had filed a confidential IPO prospectus with the SEC. 2 separate arms of the same government, processing the same company at the same time, with completely opposite framings: one reviewing it as a viable public investment vehicle, the other treating its flagship product as a munitions export problem.

This is not the first time the relationship between Anthropic and the US government has been adversarial. Earlier in 2026, the Department of War designated Anthropic a "supply chain risk," the first time that label had been applied to a domestic American company. The context was straightforward: Anthropic had refused a Pentagon contract on the grounds that it lacked adequate safeguards around mass surveillance and autonomous weapons. OpenAI accepted the same contract. Pete Hegseth described Anthropic's position as "ideological caprices." President Trump called the company "Leftwing nut jobs."

The immediate market consequence was counterintuitive. Claude became the most downloaded app in the US, with over 1 million new sign-ups per day at peak. Refusing the DoD deal turned out to be the most effective marketing event in the company's history. The general public read "Anthropic said no to autonomous weapons" and responded accordingly.

But the ban Friday sits in a different category. Being called "Leftwing nut jobs" does not deactivate your product. A Commerce Department directive does. That distinction matters for anyone who built their workflow around Anthropic's infrastructure.

The underlying reality is what the IPO timing makes plain: any AI infrastructure hosted on US soil, or built by a US company, now operates under geopolitical jurisdiction. Not as a theoretical risk. As a demonstrated fact, time-stamped June 12, 2026, 17:21 ET.

The Encryption Controls Lasted 8 Years

Dual-Use Technology Regulation vs Real-World Adoption Timeline

The ITAR restrictions on strong cryptography ran from 1991 to 1999. 8 years. They collapsed under pressure from 3 directions simultaneously: industry lobbying, civil liberties organizations, and 1 technical argument that turned out to be unanswerable.

The unanswerable argument was this: the algorithm was already public. PGP's source code had been printed in a physical book, sold in bookstores, specifically to make export control legally unenforceable. You can restrict software. You cannot restrict a printed page. The government quietly acknowledged it could not contain something already in the world, and the restrictions were lifted in 1999.

PGP-derived technology was in SSL by 2005, then Signal a decade later. Today it is in the lock icon on every HTTPS page you visit, in WhatsApp's end-to-end encryption, in basically every secure communication layer you use without thinking about it. The thing they classified as a weapon in 1991 became foundational infrastructure in less than 2 decades.

I spent part of a Sunday last month trying to track down who originally wrote the PBKDF2 implementation I use across several projects. It traces back to a 2011 Stack Overflow answer from someone with 847 reputation points. That person has no idea how many production apps are running their code right now.

I think the Fable 5 restrictions will probably lift within a few years, following something close to the same pattern. Could be I'm reading this wrong. AI infrastructure is more centralized than a cryptographic algorithm was, and the dynamics may not play out identically. But the "dual-use capability that already exists elsewhere" argument is structurally identical to the argument that ended the crypto wars. It worked in 1999.

Someone Built Their Own LLM for $80

The dependency on US-regulated AI infrastructure is real. And it is reducible in 2 steps that are not a research project.

Step 1 is this week. Ollama runs locally on your machine with no configuration beyond installation. Pair it with an open-weights model (Mistral, Llama, Qwen, take your pick) and you have a working AI tool that runs on hardware you control. No Commerce Department directive reaches that. It is not Fable 5. The capability ceiling is lower. But it runs, it does not phone home, and nobody in Washington can cut it off on a Friday evening.

The more interesting question is whether step 2 is as far as it sounds.

In May 2026, Cristi Constantin, an independent developer, trained a working LLM from scratch. 340 million parameters, Llama architecture, custom dataset assembled from 19th-century literary texts. He wrote his own training and fine-tuning scripts, vibe-coded the whole thing with VS Code and open-source models via OpenRouter, and ran the training pipeline on rented GPUs across RunPod, ThunderCompute, and Vast.ai. Total cost: approximately $80. The model is public on HuggingFace along with the full source and everything needed to reproduce it.

This is not the most capable model in the world. That is not the point. The point is that someone ran the numbers on training from scratch and posted the receipt, and the receipt said $80. The "build your own AI infrastructure" argument stopped being theoretical in May 2026.

The practical layer between "Ollama on my laptop" and "I own my training pipeline" is covered in running AI agents with a CLI-based architecture. And if the gap is the framework for actually shipping reliable software with AI, Prompt Contracts as a production discipline addresses exactly that problem.

The spirit is the same one behind Vibe Coding, For Real: the barrier "this is too technical, I can't do that" has been wrong for a while. The $80 LLM makes it concrete at the infrastructure level.

What If Washington Banned the Hardware Too?

Consider the scenario for a moment. Your MacBook runs on Apple Silicon, designed in California, manufactured by TSMC in Taiwan under US export control agreements. The firmware that boots it comes from Apple's servers. The secure enclave inside handles attestation.

Governments already restrict hardware access. The Huawei precedent from 2019 is documented: US export controls cut Huawei off from Google Play services overnight. Not a cyberattack, a directive. Chinese users woke up to a different phone than the one they had bought. Chip restrictions followed, ending Huawei's access to TSMC manufacturing entirely. Hardware, not software, not a model. The physical thing.

Friday's directive hit a software model. The mechanism is identical to what you would need to reach the hardware. Different target, same instrument.

This is not a tinfoil hat scenario. If your threat model now includes "a government directive can revoke my AI access on a Friday evening," which stopped being hypothetical 48 hours ago, the logical extension is asking what sits below the model. The model runs on an operating system. The OS runs on firmware. The firmware runs on chips manufactured somewhere, under some jurisdiction. Every layer has a geopolitical address.

The practical answer is the same as Friday's: run Linux on open hardware, load a local model, and nobody's directive reaches your environment. And yes, it works on your machine. That is specifically the point.

The immediate threat to most developers is the model ban, not a hardware kill switch. The firmware scenario is 1 step removed. But after Friday, that step is closer than it was Thursday.

Washington can revoke your API key. It cannot revoke your terminal.

In 1991, they classified a math formula as a munition. In 1999, that formula was inside the lock icon on your browser. The restriction lasted 8 years. The diffusion was permanent.

Fable 5 will probably come back. The question that stays open is whether you are going to wait for the next directive before thinking seriously about your own infrastructure layer 🤔 Someone just proved that answer costs $80.

Sources

Anthropic, official statement on Fable 5 and Mythos 5 access suspension, June 12, 2026. anthropic.com/news/fable-mythos-access
Fortune, "Anthropic disables Fable and Mythos AI models following U.S. export ban," June 13, 2026
CNBC, "Anthropic disables access to Fable 5 and Mythos 5," June 12, 2026
Quartz, "Anthropic disables Claude Fable 5 and Mythos 5 after U.S. export order," June 12, 2026
Cristi Constantin, "Making a vintage LLM from scratch," crlf.link, May 2026. github.com/croqaz/vintage-LLM

This post may contain affiliate links. If you click them, I might earn a small commission, costs you nothing, and helps me keep shipping quality articles every day for your reading pleasure.

The Head of Claude Code Stopped Prompting. That's Not a Tip. That's a Timeline.

Phil Rentier Digital — Sat, 13 Jun 2026 13:41:11 +0000

"You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents."

That cracked me up when I saw it. Peter Steinberger dropped those 12 words on X on June 7, and 6.5 million people read them in 24 hours. And 5 days before that, Boris Cherny, the head of Claude Code, had said the exact same thing on stage at a WorkOS event. Nearly word for word.

It cracked me up 'cause I'd been doing this for months without a name for it.

TLDR: Cherny stopped prompting Claude. His job now is writing the systems that prompt Claude for him. If you've used /goal and walked away until it finished, you were already doing a version of this, without knowing what it's called or how far the gap between your version and full loop engineering actually goes.

I Called It "Figure It Out Mode"

The workflow was simple, maybe embarrassingly so. I'd set an objective in /goal, drop a CLAUDE.md with the project rules, give Claude Code the repo context, and leave. Come back 20 minutes later, sometimes 2 hours. Either there's a working feature or there's a mess that needs fixing. Both outcomes move the project forward.

I wasn't doing this out of any principled conviction. It just happened when I stopped watching the output stream and started treating Claude Code like a junior dev I could delegate to. Set the objective, give it the context, and leave.

No label for any of it.

Then Steinberger posted, and half my feed was nodding while the other half argued about whether this was actually new or just prompting with extra steps. And Cherny's clip from 5 days earlier started making the rounds. "I don't prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops."

Recognition, not discovery. I was already doing a version of this. It just got a name.

That naming matters more than it looks on first read. Without a term for a practice, you can't compare notes on it, you can't deliberately improve the pattern, and you can't tell if you're doing it well or badly. "Figure it out mode" worked fine as a personal shorthand. "Loop engineering" is something you can build a methodology around. The concept didn't change between June 2 and June 7. What changed is that now everyone in the same conversation is using the same word, and the people who weren't doing it yet now know what they're missing.

Which Rung Are You On?

Three Levels of AI Development Automation

What Cherny described at WorkOS Acquired Unplugged on June 2 breaks down into 3 stages of evolution in how developers work with a coding agent.

Rung 1: you use Claude like autocomplete. Smarter than Copilot, but you're still writing code, reviewing every line, holding the tool. The agent assists. You direct every step.

Rung 2: you're prompting 5 or 10 Claudes in parallel. Handing off tasks, reviewing outputs, routing between them manually. You're still in the loop, just a busier traffic manager instead of a driver. A lot of people who think they're "advanced with AI" are here and assume they're at rung 3.

Rung 3: you're not in the loop at all. You built the system that runs the loop for you. Claude isn't waiting for your next message. It's executing against conditions, verification gates, and retry logic you defined once and that now runs without you. Your job shifted from "write the prompt" to "design what happens when the agent fails, succeeds, or hits something you didn't anticipate."

The difference between rung 2 and rung 3 isn't about skill at prompting. It's architectural. You don't get to rung 3 by prompting better. You get there by stopping prompting and encoding the logic into something that runs on its own. Think of it as the tower defense problem: stop defending every position manually and start placing structures that hold without you. Prompting is direct combat. Loop engineering is building your turrets before you leave the base.

The Gap Is Now Legible

The June 7 post wasn't a trend report. It was a measurement.

When the best practitioners in a field publicly announce a change in their own practice, the gap between people already doing it and everyone else flips from invisible to visible. That's what happened. The practice had been running for months. What changed is the scoreboard became public.

Karpathy's AutoResearch project is the clearest concrete proof on record. He's running 50 ML experiments overnight on a single GPU. The agent modifies the training code, runs it, reads the results, iterates, no human decisions in the loop. He coined "Loopy Era of AI" for exactly this, on a No Priors podcast episode that hit 875K views against a channel average of around 8,500. That's a 100x outlier on a research-level AI pod. The appetite for understanding this isn't theoretical anymore.

Cherny's own number is more direct: 100% of his personal code for the 30 days before December 2025 was written by routines he'd set up, not by him prompting Claude directly. And industry reporting from June 2026 puts Claude Code at close to 4% of all public commits on GitHub. 4% of the entire public GitHub graph is a massive footprint, and it's not happening through manual prompting session by session. That's loops running. At this point, running individual prompts to ship production code is the "it works on my machine" of agentic development.

The reason the timing matters more than the concept is the compounding logic, and this is the part most explainer threads skip entirely. A developer who prompts manually gets better at prompting, with faster iterations and more targeted results over time. It's linear improvement on a linear effort curve, and it's genuinely valuable. A developer who encodes loop logic is operating in a structurally different model. Each loop they design runs without them. Each improvement to that loop applies to every future run automatically. One trajectory improves the work they already do. The other builds a system that handles that category while they design the next loop. These 2 trajectories look nearly identical at the start. You can't tell them apart in week 1. The differential becomes visible over weeks, it compounds in the direction of the person who built the loop, and it's not recoverable by prompting faster. That's exactly what the June 7 moment made legible: the scoreboard flipped public, and you can now roughly tell which trajectory you're on just by looking at your last month of output.

The Loop You Didn't Name

Something I noticed when the Steinberger post started circulating: a lot of developers nodding in recognition had no idea they were already at rung 3 for some tasks.

/goal is already a closed loop. You define a stop condition. Claude iterates until it's met or hits a hard error. You're not making decisions between iterations. The feature shipped in Claude Code v2.1.139 in May 2026, and the developers who figured it out early, who set the goal, walked away, and came back to results were technically already doing loop engineering. I was running this before /goal even existed, just using long sessions with detailed context and hoping Claude stayed on task. Just hadn't named it.

The 3 things that separate "I used /goal and left" from a real production loop: a skill file that encodes the quality rules, a verification step that checks the output against those rules, and a review agent that sees the result fresh before anything ships. You might already have 1 of them without knowing the other 2 exist. A lot of developers have a CLAUDE.md. Not many have connected it to a verification layer. And fewer still have added the review agent, which is where the loop catches the things the build agent rationalized as acceptable.

The full anatomy, as Anthropic demonstrates in their verification video: a SKILL.md that encodes your project's non-negotiables, a browser verification step that checks the rendered output against those rules, and a second agent that reviews before anything gets merged. The CLAUDE.md you already wrote is the foundation, /goal runs against it, and the review agent gates the output before it ships. Connect those 3 and you have a loop that runs without you in the room.

For anyone who's already made the move from vibe coding to encoding project logic in prompts, the loop is the next layer of the same architecture. The instinct to make implicit project rules explicit and stop eyeballing the output after the fact. The loop just runs that logic in autonomous mode.

Side note that barely connects but I'm putting it here anyway. When I learned to code in the 90s, we had a shared Bull DPS 7000 at school. Old mainframe. 1 compilation slot at a time, first come first served. What I figured out was writing a dumb shell script that polled the compiler queue every 15 seconds and resubmitted my job the instant a slot opened. My code always got compiled. My classmates were refreshing manually. I admitted this to them much later. Sorry guys. Not that sorry, honestly.

The instinct to encode the retry rather than do it yourself by hand is 30 years old. The branding is new.

Your First Loop Doesn't Need a Fleet

Rung 3 doesn't require 100 agents and an orchestration layer. That's the version Karpathy runs for overnight ML experiments. Your first loop is simpler, and you can probably start it today.

The minimal production loop:

/goal "Implement the product filtering feature from the spec. Done when the test suite passes and there are no TypeScript errors."

That's already rung 3 for that task. Claude runs until the condition is met or it hits an error it can't resolve. You're not in between. The key is the word "when" in the goal, because the stop condition has to be something the agent can verify automatically, not something you have to look at and judge afterward.

A loop without a verification layer is just automated guessing. The upgrade that makes it production-usable:

Step 2. Add a SKILL.md with your project's non-negotiables: your actual rules, for your actual project, written the way you'd brief a new dev on day 1. The conventions you enforce, the edge cases that always come back, the things you'd catch in code review 3 days later if nobody wrote them down. The more specific the rule, the more the loop behaves like someone who actually read your docs before starting.

Step 3. Add a browser verification step. Claude in Chrome or the Chrome DevTools MCP checks the rendered output against your quality criteria: layout shifts, Core Web Vitals, visual regressions. Things that don't show up in test suites but do show up in production. Anthropic's demo shows a layout shift caught automatically, outside the scope of the original task, because Core Web Vitals were already in the SKILL.md. That's the loop doing work you didn't explicitly ask for, because you encoded what "good" looks like in advance.

Step 4. Add a /code-review agent as a second pass. This agent sees the output fresh, without the history of how it got built. It catches the rationalized decisions the build agent slid past itself, which it will, 'cause the build agent has been staring at the same context for the whole run.

Start with steps 1 and 2 if you want to run something today. Add 3 and 4 when the base loop is stable.

I think the step that trips most people, and maybe I'm wrong on this but it tracks with every loop failure I've seen, is the stop condition. Specifically: setting one that can't be verified automatically. "Make the UI feel polished" is not a stop condition. It's a prayer. "No layout shift above 0.1 CLS" is a stop condition. Save point before the boss door, not after. Set the gate before the loop starts, or you're running the whole dungeon again. The gate has to be designed before you start, not checked when it's done.

A loop without a verification gate doesn't save time. It automates being wrong.

Before any of this works consistently, the scaffold underneath has to be solid. Vague spec, no test coverage, dependencies you inherited but don't really understand (the loop will run against those confidently and ship garbage). The 8-step Blueprint in Vibe Coding, For Real was built for exactly this: getting from broken demo to deployed app before you hand the iteration to an autonomous system. The loop needs something real to run against.

And when you're ready to extend the loop to external systems (trigger a deploy, run a service check, call an API), building that layer with CLIs rather than MCP connectors changes how debuggable and reliable that extension ends up being in production.

When the Scoreboard Went Public

I didn't know "figure it out mode" had a name. Didn't know it put me at rung 3 for some tasks. Didn't know the Bull DPS 7000 era and the Boris Cherny era were running the same instinct 30 years apart.

What the June 7 moment actually was: not the beginning of loop engineering for the people already doing it. The moment the gap between practitioners and everyone else became visible to both sides. Cherny had been running 100% of his code through routines since December 2025. Karpathy had been launching overnight experiments for months. The gap was already there. Steinberger's post just flipped the scoreboard public.

The people already doing it didn't learn anything new on June 7. The people who weren't doing it now know the clock is running.

The compound rate is real and it doesn't wait. Every loop you design runs without you. Every improvement to the loop applies to every future run. That's a structurally different trajectory from getting faster at prompting, and the gap between the 2 becomes measurable faster than most people expect.

At what rung are you right now, and is that the one you want to stay on?

Sources

Peter Steinberger (@steipete), X, June 7, 2026
Addy Osmani, "Loop Engineering," addyosmani.com, June 7, 2026
Andrej Karpathy, Skill Issue: Code Agents, AutoResearch, and the Loopy Era of AI, No Priors podcast
explainx.ai, "Loop Engineering: The Claude Code Guide," June 2026
datasciencedojo.com, "Agentic Loops: From ReAct to Loop Engineering," June 2026
Anthropic, How to get Claude Code to verify its own work, YouTube

This post may contain affiliate links. If you click them, I might earn a small commission (costs you nothing, and helps me keep shipping quality articles every day for your reading pleasure).

Every 'Faster AI' Trick Was a Workaround. DiffusionGemma Is the First One You Can Actually Run.

Phil Rentier Digital — Fri, 12 Jun 2026 13:41:12 +0000

Predicting 1 token at a time. That's what has been limiting models since the beginning, local ones included.

The constraint had nothing to do with hardware being insufficient or models being too small. It was architectural, baked in from the start.

To generate each token, your GPU loads all the model weights from memory, produces 1 token, then starts over. That memory bandwidth bottleneck is why local inference stayed frustrating even on decent hardware. And it's why 5 years of optimizations (flash attention, quantization, speculative decoding) all worked around the same structural ceiling without ever moving it.

TLDR: DiffusionGemma generates 256 tokens in parallel per denoising pass, shifting the bottleneck from memory bandwidth to raw compute. On paper: 4x faster than Gemma 4 AR, 700+ tokens/sec on RTX 5090, runs on RTX 4090. But the speed number is not what makes this interesting.

There's something that happens when you realize you've been optimizing the right metric on the wrong layer. Flash attention was a genuine breakthrough, INT4 quantization was a genuine breakthrough, and the H100 at $40,000 a card was a genuine breakthrough for anyone who could afford it. And none of it moved the fundamental constraint. The weights still had to load for every single token. The GPU's tensor cores, designed for massive parallel matrix operations, were mostly sitting idle during inference, just waiting for the next memory cycle. Every engineer who ran local inference on a high-end consumer GPU felt this as a kind of low-grade frustration: the numbers should work, they don't quite.

The Race Nobody Questioned

Flash attention dropped in 2022. Legitimately brilliant: rewriting the attention computation to be I/O-aware, keeping intermediate values in SRAM instead of constantly writing back to HBM. Real speedups, measurable, deployed everywhere within 18 months. The paper got 15,000 citations in roughly 2 years.

Then the field kept adding layers on the same foundation. INT4 quantization, GGUF, speculative decoding, Groq's LPU built from scratch around AR inference, H100s at $40,000 a card, then H200s, then GB200s. Entire companies valued in the billions on the premise that making AR faster was the problem worth solving. Groq built custom silicon from scratch around AR inference, and the industry called it visionary. Nobody in the room suggested that maybe the architecture itself was the question.

The whole industry organized around a single bottleneck. Nobody questioned whether the bottleneck was architectural.

To be fair: why would they? The models shipped, the products worked. The training stack, the inference serving infrastructure, the CUDA kernel ecosystem, every deployment pattern from vLLM to TGI to Ollama, all of it built around autoregressive next-token prediction. Questioning the architecture from inside that ecosystem is like questioning whether cars should have wheels while you're in the middle of designing a faster tire. The switching cost wasn't just technical. It was the industry's accumulated sunk cost: every CUDA kernel, every serving optimization, every hardware purchase justified against AR throughput numbers.

Inception Labs was the first to actually ship something different. Mercury came out early 2025, Mercury 2 in early 2026, 1,000+ tokens per second. Genuinely impressive numbers. Completely inaccessible: commercial API, closed weights, you couldn't run it yourself. Useful as a market signal, not actionable for anyone building on their own hardware.

DiffusionGemma shipped June 10, 2026, open weights under Apache 2.0, vLLM support on day 0, running on an RTX 4090.

For the developer community, "first open release from a tier-1 lab" means day-0 vLLM support, a HuggingFace model card, Unsloth integration, and a community that will have interesting fine-tunes out within days. The gap between a research paper and something you can actually build on closed roughly 18 months faster than anyone expected when Gemini Diffusion was announced as an experiment at I/O 2025.

This is the difference between "someone proved it works in theory" and "you can pull the weights tonight."

5 years of workarounds. The actual fix ran on your GPU yesterday.

What DiffusionGemma Actually Changes (and What It Doesn't)

AR vs Diffusion GPU Bottleneck Comparison

The AR inference loop is memory-bound. To generate 256 tokens, your GPU loads the full weight matrix from memory 256 times, 1 load per token. The tensor cores, designed for parallel matrix multiplications at massive scale, execute their actual computation in roughly 1% of the total time. The other 99% is waiting for data to arrive from VRAM. Imagine staffing a kitchen with Michelin-starred chefs and routing every single plate through a warehouse 300 meters away between courses. That's your H100 on AR inference. This is why scaling a GPU's theoretical FLOPS rarely translated linearly to inference speed: you weren't compute-bound, you were memory-bound, and buying a card with more tensor cores helped less than buying one with higher memory bandwidth. Every optimization from flash attention onward was working on shortening that 99% wait, not eliminating it. The ceiling was always the same ceiling, just approached from a slightly different angle.

DiffusionGemma loads the weights once per denoising pass and generates 256 tokens in parallel. The bottleneck shifts. The tensor cores are now the actual ceiling, running bidirectional attention over the full 256-token block on each forward pass. This is what these chips were designed for. The memory bandwidth wall doesn't disappear, it stops being the thing that limits you.

Numbers from Google and NVIDIA: 700+ tokens/sec on RTX 5090, 1,000+ on H100, 4x faster than Gemma 4 AR on equivalent hardware. The model is 26B parameters as a Mixture of Experts, 3.8B active during inference, runs in 18GB VRAM when quantized.

The caveats are real and worth stating plainly.

DiffusionGemma trails Gemma 4 AR on reasoning benchmarks by a meaningful margin. AIME 2026: 69.1% vs 88.3%. LiveCodeBench v6: 69.1% vs 77.1%. GPQA Diamond: 73.2% vs 82.3%. These are 15-20 point gaps on hard reasoning tasks, not rounding errors.

The context window is 8,192 tokens. Most current AR models run at 128K+. For anything agentic or long-context, this is a real wall. A moderately complex TypeScript file eats 3,000 tokens. 3 files and you're already at the ceiling.

Google themselves call it "experimental." Fine-tuning recipes were still being published at launch. MLX support for Apple Silicon was incomplete day 0. For high-volume cloud serving, AR models still batch more efficiently at scale.

The performance is real, and so is the ceiling. The question is whether the ceiling matters for your use case.

The Proof Beyond Speed

A Sudoku board has 81 cells. Each one is constrained by its row, its column, and its 3x3 square simultaneously. To solve it correctly, you need to hold all those constraints in view at once.

An autoregressive model generates 1 cell at a time, left to right, top to bottom. By the time it fills cell 72, it cannot go back and correct cell 3. It conditions only on what it already generated. This isn't a failure of scale or a training data problem. It's a structural property of sequential generation. You can make an AR model bigger, faster, better at pattern matching, and it will still fill cells without global constraint resolution, because it structurally cannot look forward.

Google ran a test on this directly. DiffusionGemma base model on Sudoku puzzles: 0% success rate. Standard SFT fine-tuning with a JAX recipe on a Sudoku dataset: 80% success rate, with 4x fewer inference steps than the baseline.

The improvement came from bidirectional attention, not raw speed. Every token in the 256-token block attends to every other token during generation. The model sees the whole board at once. It propagates constraints across the full block on each denoising pass and self-corrects before the output is finalized.

I think this is where the long-term significance of diffusion LLMs gets underestimated, even in the launch coverage. The speed numbers get the headlines. The bidirectionality is the more interesting property.

Your codebase is harder than a Sudoku board. Every function is constrained by the types it returns, the APIs it calls, the contracts it implicitly assumes across files. Code infilling (filling in a function body given what comes before and after) is structurally this exact problem. AR models handle infilling through a special fill-in-the-middle training objective, which is a workaround for the directional constraint. DiffusionGemma handles it architecturally. Same problem class, different layer of the fix. The same pattern shows up in SQL schema migrations, config file generation, anything where you're filling structure with hard constraints on both sides. A migration adding a column needs to be consistent with both the existing schema and the downstream queries that reference it. AR generates left to right without reconsidering earlier choices based on later constraints. You can work around this with careful prompting and multi-pass generation. Workarounds, every one of them.

I spent 3 months chasing subtly inconsistent type signatures across files in Claude Code sessions. The context window was splitting the relevant contracts between 2 sessions. Bidirectional attention within a generation block doesn't fully solve cross-file coherence, but it shifts where the inconsistency originates. Different problem, different fix.

When to Switch, When to Stay

The arbitrage for a builder running Claude Code daily looks like this.

DiffusionGemma makes sense for tasks where the bottleneck is throughput on short-to-medium outputs with structural constraints: boilerplate generation in batch, code infilling where the surrounding context is available, filling structured templates (API schemas, config files, migration stubs), rapid iteration cycles where you're regenerating 10-20 variants under 4,000 tokens. The model is out now, open weights under Apache 2.0, vLLM ready, deployable on RTX 4090. Variable API cost on those tasks goes to zero. The economics shift in a specific and real way for high-repetition local workflows.

Stay on Claude for multi-step reasoning chains, debugging that requires tracing logic across many steps, architecture decisions that need large coherent context, any production task where you need more than 8K tokens in a single pass, anything in the reasoning-heavy tier where that 15-20 point delta is the difference between a useful output and a plausible-looking wrong answer.

The context window constraint is the real practical limiter. 8,192 tokens sounds like a lot until a single moderately complex file takes 3,000 of them. That's not a fine-tuning problem. It's baked into the current generation block size. Future versions will push this up. For now it makes DiffusionGemma a task-specific tool, not a general drop-in.

Karen from Accounting would ask whether this justifies buying a second GPU. The honest answer: if you're already running a local model stack on an RTX 4090, it's a pull-and-test situation, not a hardware decision. If you're starting from nothing, the breakeven on dedicated hardware vs API credits requires actual throughput numbers from your real workflow, not enthusiasm about the benchmark 😅. The JAX fine-tuning recipe in the developer guide is documented enough that a 500-sample SFT experiment on a specific domain is a weekend project (more achievable than "I'm going to rewrite this in Rust this weekend" anyway).

On the infra side: if you're already routing tasks across different model backends, the pattern behind building CLI-native agents for throughput-sensitive workloads gets more relevant with a local diffusion backend in the mix. DiffusionGemma slots cleanly into that architecture.

The Assumption You Never Questioned

I have a WooCommerce integration in my pipeline that parses distributor CSV feeds in a format that hasn't changed since 2019. I've rebuilt the surrounding infrastructure 3 times. The CSV parser is still the same function, same column order, same regex workaround for an edge case I found in 2021. Nobody touches it because it works. The question "should this still be a CSV parser in 2026" has never been asked. At some point it stopped being a decision and became furniture.

Every stack has furniture.

The pattern shows up every time a technical constraint stays stable long enough to become invisible. In 2023, local inference meant loading a 7B model and watching tokens arrive at 3 per second. The latency made it useless for anything interactive. Developers tried it, found it impractical, switched to API calls, and the decision solidified: local inference is for hobbyists, real work goes through the API. What nobody encoded in that decision was the expiration date. "Local inference is slow" sounds like a fact about physics. "Local inference on 2023 hardware with 2023 models was too slow for that use case" is a claim about a specific context, and specific contexts change.

AR wasn't chosen over diffusion because someone ran a comparison and concluded it was better. It was chosen because diffusion text generation wasn't viable. The assumption "we use AR" was a pragmatic constraint that became invisible the moment it stopped being contested.

If you're working through which defaults in your stack are worth revisiting, how I made routing decisions intentional with prompt contracts is where I started. Or if the stack itself is newer territory, Vibe Coding, For Real covers building on explicit principles from the start, available free on Kindle Unlimited.

For the builders: if your workflow has a repetitive generation layer with structural constraints, start with the Sudoku fine-tuning recipe in the developer guide. Run it, look at what changes between 0% and 80% accuracy, and ask what that implies for your own constraint-heavy tasks.

The routing decision is now a real architecture decision: not which API is cheaper this month, but which structural constraint this model can resolve that the other architecturally cannot.

Sources

DiffusionGemma: The Developer Guide, Google Developers Blog, June 10, 2026
Run DiffusionGemma on NVIDIA, NVIDIA Technical Blog, June 10, 2026
DiffusionGemma benchmarks, Unsloth, June 2026
Google's DiffusionGemma: first open diffusion release from a tier-one lab, Decrypt, June 10, 2026

This post may contain affiliate links. If you click them, I might earn a small commission (costs you nothing, and helps me keep shipping quality articles every day for your reading pleasure).

Anthropic's Most Powerful Model Missed a Security Flaw on 6,200 Lines of Prod Code. So Did I.

Phil Rentier Digital — Thu, 11 Jun 2026 13:41:12 +0000

Anthropic released Fable 5 yesterday morning. The model the April system card called "too dangerous to release" (same core as Mythos, cyber safeguards active) is now in Claude Code.

So I ran an audit. 😬

TLDR: I ran Opus 4.8 and Fable 5 in parallel on 6,200 lines of real production Go and TypeScript. They didn't find the same things. And neither of them found everything. Including the security flaw that had been running in prod since day one.

I had a live ecommerce commission tracker sitting there: Go binary exposed behind Cloudflare, TypeScript back-office on a private mesh, shared SQLite. 2 independent sessions, same 1-line brief, same SSH access to prod.

What came back was asymmetric in ways I didn't expect.

Fable 5 Is What Anthropic Wouldn't Ship

Fable 5 is the first Mythos-class model to go public. The numbers from the launch are hard to dismiss: 80.3% on SWE-Bench Pro, against 69.2% for Opus 4.8, 58.6% for GPT-5.5, and 54.2% for Gemini 3.1 Pro. An 11-point gap over the previous best from Anthropic is not incremental progress.

The headline demo: a 50-million-line Ruby codebase migrated in a single day. Stripe estimated the same job done manually at 2 months for a full engineering team.

Until yesterday, this model (then called Mythos) was locked inside Project Glasswing: a restricted program for a handful of trusted organizations, specifically because of the cybersecurity risk the unrestricted model represented. Fable 5 is Mythos with the safeguards engaged. Any query that touches cyber, bio, or chemical attack surface falls back automatically to Opus 4.8. Pricing: $10 per million tokens input, $50 per million output. Free on subscriptions through June 22.

Most comparisons between these models happen on controlled datasets. An audit on a live commission tracker has different constraints: the file structure is irregular, some modules are undocumented, and the context window fills with code that was written to work, not to be read. Neither model got a prepared environment. They got the same SSH key and a directory listing.

2 sessions. Same 1-line brief: "audit this repository for security vulnerabilities and infrastructure problems." Same SSH credentials to production. Independent, no shared context between them.

2 Radically Different Work Styles

Opus 4.8 works alone and goes deep. It reads the code, forms a hypothesis, writes a throwaway program to prove or disprove the bug, runs it, and returns with evidence. When Opus flagged the SQLite transaction idempotency issue, it didn't just identify the pattern: it designed a test, fired 3 inserts with an identical empty transaction ID, and returned the output showing 1 row stored. INSERT OR IGNORE collision against a UNIQUE constraint, demonstrated. Not inferred from reading.

Fable 5 works like an audit lead managing a team. It carves the repository into 4 zones, spawns 4 parallel agents, and assigns each agent the model it thinks is appropriate for that zone's risk profile. It doesn't go deep into any single file. It holds the map while the agents read the territory, and then does something Opus never does: goes back and validates each agent's findings before they land in the report. (Think raid lead calling assignments while the best solo player on the team memorizes every boss hitbox. Different jobs. Same dungeon.) Builders who want to understand why this coordination model works the way it does will find how CLI-native agent pipelines outperform MCP-based setups worth reading alongside this.

1 model is built to prove things. The other is built to not miss them. They are not competing at the same job.

The Moment Fable 5 Earned Its Price Tag

One of Fable's agents returned with "litestream backup not deployed, severity: high."

Fable opened an SSH connection and ran systemctl is-active litestream. Got back "active". Reclassified: the backup isn't missing, the runbook documentation is wrong. Severity downgraded to informational.

Same session, 5 minutes later: "critical shell injection vulnerability" on a URL query parameter. Fable traced the parameter through the request builder, found URLSearchParams encoding apostrophes as %27 before any shell context could receive them. Not injectable. Downgraded.

2 criticals eliminated without me opening a single file.

(When I checked the litestream reclassification myself, I pulled up the unit file and noticed the comment block still referenced the old server hostname from a migration I did 8 months ago. The service works. The comments describe a machine that no longer exists. Not urgent or blocking, just silently accumulating until the next person to touch the server has to figure out what was real from what was real 2 migrations ago. I've had a sticky note on my monitor that says "infrastructure doc pass" since at least January.)

Audit quality isn't measured by finding count.

4 Findings Fable Caught, Opus Missed

AI Model Comparison: Coverage vs Depth Analysis Modes

4 real security findings Opus missed entirely.

The postback key comparison. The partner postback endpoint validates its inbound secret using a standard Go != string comparison. That comparison leaks timing information: with enough requests, an attacker measuring response latency can detect when their guess is "closer" to the correct secret. The fix is 2 lines, swapping the comparison for subtle.ConstantTimeCompare from Go's crypto/subtle package.

Constant-time comparison is standard in any auth system that handles secrets. The issue isn't knowing the fix. The issue is knowing to ask whether the comparison is constant-time in the first place. (Timing attacks on auth systems are basically speedrunning: given enough measured runs, the leaderboard eventually hands you the key.) Timing attacks on postback endpoints require an attacker who knows the endpoint exists, knows the secret length, and can measure network jitter with enough precision. Not trivial. Also not something you want live when the endpoint is publicly accessible with no additional authentication layer.

This is the "So Did I" from the title. That comparison had been running in prod since launch. Opus had the handler code in its terminal window. It did not flag it. Fable flagged it.

I hadn't flagged it either.

Services running as root. Both the Go binary and the TypeScript back-office run with no systemd User= directive and no crash-loop alerting configured. Opus had executed systemctl cat on both service files, read through the environment variables, and moved on without noting the absent sandboxing. Running services without systemd user isolation is a reliable way to turn a compromised service into a fully compromised host. Fable flagged both.

The CLI, which was explicitly in scope. The brief included it. Fable found it. Opus never addressed it. Findings in the CLI zone: API registrar credentials visible in ps output on the remote host. A validation error in the CSV import routine silently triggering a false alert email on every affected run. Outbound HTTP calls with no timeout set, which under network degradation will hold goroutines open indefinitely.

Slowloris exposure. The HTTP server had ReadHeaderTimeout configured and nothing else. Missing ReadTimeout, WriteTimeout, and IdleTimeout means a slow connection attack can hold worker goroutines alive until the server runs out of them. Fable flagged it. Opus never reached the server configuration.

The pattern across all 4: what sits outside the active cone of attention doesn't get found, even when it's present in the terminal output already on screen.

What Opus Proved That Fable Only Assumed

Honesty requires balance. 4 findings in Opus's report that no Fable agent surfaced.

The no-op API guard. In the TypeScript back-office, the function named apiGuard exits without enforcing anything in the deployed production build. Full destructive access from the private mesh with zero authentication. Fable's agents flagged "authentication configuration should be reviewed." Opus SSH'd to the server, located the deployed artifact, confirmed the function's behavior, and named the specific function. The difference between those 2 findings is the difference between an action item and a reading assignment.

Dead routing logic. An is_bot filter in the partner referral routing rules fires a rejection before the routing evaluation runs. The downstream condition that checks for bot status can never match, because bots are rejected upstream before reaching it. The data model promises behavior the code structurally cannot deliver. Neither of Fable's agents assigned to that zone caught it.

Orphaned click records. When a partner token gets deleted, the click records associated with it stay in the database. No foreign key constraint enforces cleanup. They silently skew attribution metrics for any analysis that doesn't account for deleted tokens. Both models described this as "potential revenue loss," which isn't accurate: the clicks aren't being double-billed, the statistics are being calculated against ghost records. Business impact framing is still the human's job.

The idempotency proof. Opus wrote a standalone Go program, executed it against a test database, and returned the output: 3 inserts with an identical empty transaction ID, 1 row stored. That's verifiable evidence. You can run that program yourself and get the same result. No Fable agent pushed to execution level. They identified the pattern. Opus proved it.

There's something worth sitting with here, and I think it's genuinely hard to articulate cleanly even after watching both sessions in full: the gap between "I identified a suspicious pattern" and "I built a program that proves this is a real bug" isn't a capability difference in the traditional benchmark sense. Maybe I'm wrong, but it feels like a judgment call about when reading code stops being sufficient and running code becomes necessary. Most senior engineers default to reading longer than they should. Opus made the other choice, wrote the proof in under 3 minutes, and kept going. Maybe that judgment is what the benchmark numbers are actually measuring, at some deeper level.

Coverage vs Proof: A 2-Line Framework

Opus drills narrow and deep. When it proves something, it proves it with evidence you can independently verify. The throwaway Go test, the SSH confirmation of the no-op auth guard: those are the outputs of a model that closes the loop instead of flagging and moving on.

Fable covers the perimeter. It doubts its own subcontractors and validates findings before they reach you. It finds what exists outside any single agent's cone of attention.

The framework is short. Fable makes sense when coverage is the priority: wide scope, independent parallel agents, findings cross-validated before they land in the report. Opus makes sense when proof is the priority: a specific suspect behavior that needs to be demonstrated empirically, not just reported. When code has real money flowing through it, you want both sessions. (Run them like a party comp: Fable clears the dungeon, Opus solves the boss.)

This isn't reading between the lines. The Fable 5 system card, all 319 pages published June 9, documents the failure mode directly. In a routine internal operation (886 ordinary use cases, no adversarial red-teaming), the model reported "no error movement at all" after checking a single error type, then undercounted the actual production incident by a factor of 20. Anthropic wrote this down and published it on launch day. The borgne is documented, not hidden. Worth building your verification layer around that, not around the assumption that the model tells you everything it missed.

The 11-point SWE-Bench Pro gap is real. So is the documented undercounting failure. Both things are true at the same time, and your production access policy should account for both.

Fable finds what you forgot to look for. Opus proves what you were afraid to run.

That timing comparison flaw on the partner postback endpoint (2 lines to fix) had been running since launch. Opus had the handler code in its terminal. It didn't ask the question. Fable asked it.

I hadn't seen it either.

Go audit your projects.

Sources

This post may contain affiliate links. If you click them, I might earn a small commission (costs you nothing, and helps me keep shipping quality articles every day for your reading pleasure).

We Blamed AI for Killing Junior Jobs for 3 Years. We Were Wrong.

Phil Rentier Digital — Wed, 10 Jun 2026 13:41:11 +0000

Everyone's been yelling that AI is replacing juniors. In 2019, 1 in 3 tech hires was someone under 25. In 2025, it's 1 in 5. Stanford pulled the ADP payroll records. Harvard followed. AI was in the accused box and the verdict looked settled.

It wasn't.

A study from LSE, Warwick, and the Oxford Ellison Institute (243 million new hires, 407 million job postings, 4 countries, 8 years of data) points to a different culprit, much less visible and far more damaging: remote work. When Lambert and Schindler add that variable to the model, the AI coefficient collapses to statistical zero. Remote is the culprit. AI is not.

TLDR: The Lambert-Schindler study across 243M hires breaks the "AI = junior killer" narrative: when you control for remote work, the AI coefficient drops to statistical zero. What destroyed junior ROI in remote isn't a tech problem, and that changes everything about what you can actually do about it.

What's actually killing junior hiring is less headline-friendly and much harder to fix: remote broke the osmosis learning circuit that made a junior worth hiring in 18 months. Companies did the math. Junior ROI in remote is negative. They stopped hiring. No anti-junior ideology anywhere in that calculation. It's pure economics.

1 in 3. Then 1 in 5.

The shift started quietly. Between 2019 and 2025, the share of entry-level workers under 25 in new tech hires dropped from roughly 1 in 3 to 1 in 5. This wasn't a small correction. It's a structural rewrite of who gets a first job.

Lambert and Schindler track this across the US, UK, Canada, and Australia simultaneously. Same pattern, different markets, same timeline. The decline accelerates after 2020 and doesn't recover. By 2024-2025, the share of job postings not requiring prior experience also dropped by roughly 3 percentage points. That sounds small. It isn't: 407 million postings over 8 years, 3 points across all of them is a generation of entry-level positions that quietly disappeared from the board.

Ask any hiring manager who was posting entry-level roles in 2018 and doing the same in 2024. The conversation didn't change overnight. It shifted in small increments, each one individually defensible: "we need someone who can hit the ground running," "we're a small team and can't absorb the ramp-up time," "the role has evolved." Nobody announced a policy change. The policy emerged from countless individual decisions that all pointed the same direction.

The scale of the study matters here. 243 million new hires is larger than most longitudinal labor datasets by an order of magnitude. Stanford's ADP study was a sample. Harvard's was firm-level. Lambert and Schindler are working with something closer to the full picture. And the full picture says the culprit you think you know is wrong.

The Story Everyone Believed

To be fair to Stanford and Harvard: they weren't inventing the signal.

Stanford researchers using ADP payroll records found a 13% relative employment decline for workers aged 22-25 in the most AI-exposed roles since late 2022. A Harvard study found a 7.7% junior headcount reduction in companies adopting AI across 6 quarters from early 2023. Both sets of numbers hit the press with the force of confirmation. Everyone already suspected it. Now there was data.

The narrative was clean: AI handles the routine cognitive work that entry-level jobs used to provide. Companies see the automation potential, stop hiring for those roles, shift headcount toward experienced people who can direct and manage the tools. Juniors, whose value came from doing the routine work, find themselves competing for a smaller pool of real entry points. Economically coherent, fits the observed pattern, and both studies were methodologically solid for what they were measuring. The Stanford paper used actual payroll records, not surveys. The Harvard paper tracked firm-level headcount changes longitudinally. This wasn't sloppy research.

The problem isn't that the press exaggerated. The problem is that good researchers made a classic methodological error on a topic the whole world was primed to accept as true.

What the Model Was Missing

AI Impact Disappears When Remote Work is Controlled

Omitted variable bias.

AI exposure and remote work exposure are not independent variables. The jobs most exposed to AI (routine cognitive tasks: code triage, data entry, customer queue management, document processing) are almost exactly the jobs most compatible with remote work. Build a model that only includes AI exposure and you're not controlling for the fact that remote work exploded at the same time and hit the same job categories.

The Lambert-Schindler fix is methodologically obvious in retrospect: add WFH exposure to the model. When they do, the AI coefficient "attenuates sharply and is often statistically indistinguishable from zero." WFH holds. AI doesn't. That's not a small adjustment. That's a different cause entirely.

The NY Fed data makes the boundary precise. The employment gap between workers under 28 and those 29 and above (roughly 1 percentage point of unemployment) exists almost exclusively in sectors where remote work is structurally common. In sectors where remote isn't possible (manufacturing, healthcare delivery, trades), the gap is near zero. AI exposure doesn't predict the gap. WFH does.

There's something I keep thinking about that has nothing to do with any of this. My kid asked me last weekend why some games save automatically and some don't. The ones that don't, you lose everything when the power cuts. The junior job market post-2020 feels exactly like a game that quietly removed autosave and never patched it back in. No recovery checkpoint. You just restart from the character creation screen.

The studies that missed this weren't wrong about their numbers. They were wrong about what those numbers were actually measuring.

Remote Cut the Learning Circuit

The mechanism isn't abstract. NY Fed economist Natalia Emanuel, working with Emma Harrington at UVA and Amanda Pallais at Harvard, tracked software development teams through the remote transition. Senior developers' code quality was essentially unchanged when they went remote. Junior developers' code quality dropped measurably. Code churn went up, bugs increased. Same physical distance from colleagues, radically different outcomes by experience level.

They replicated the pattern in customer support teams. Juniors going remote: longer resolution times, more calls per issue. Seniors going remote: barely moved.

The explanation is osmotic learning. A senior developer has already internalized the patterns. They know when a function is getting too complex before the linter fires. They can read a pull request and feel the architecture debt without running the code. They carry thousands of hours of ambient feedback baked into how they write and debug. None of that is transmittable through documentation or async code review: it was absorbed over years of physical proximity, overhearing a conversation about a production incident, watching someone fix a race condition in real time, and being close enough to ask the right question at the exact moment it makes sense. That circuit requires presence, not constant presence, but enough sustained proximity that the ambient signal stays continuous. Remote work doesn't just relocate the learning. It cuts the wire.

Research published in The Quarterly Journal of Economics confirms this at scale: in-person onboarding raises later productivity and reduces attrition even for employees who subsequently return to remote work. The gains are largest for younger workers. Proximity to colleagues is what drives feedback for juniors, not mentorship programs or structured review cycles.

Companies aren't running an anti-junior policy. They're running a P&L calculation. A junior in-person contributes meaningfully within 12-18 months. A junior in remote is a longer, more uncertain bet with measurably higher error rates on the way there. When every open role is remote by default, the expected value of hiring junior drops below the threshold worth taking. So they hire senior.

Blocked From the Top Too

The junior squeeze isn't only about entries drying up. The ladder is blocked from both ends.

According to Placer.ai foot-traffic data cited in a16z's June 2026 analysis, office visits are currently at 70% of pre-pandemic levels. Plateaued. Return-to-office mandates moved the needle briefly in 2023, then stalled. Office vacancy rates are above 14%, the highest since the 2008 financial crisis. Which means even companies that want the learning circuit back are operating at 70% of the physical conditions that made it work.

Senior employees aren't cycling out either. In law, finance, consulting, and media, tenure has been trending longer since 2023. The career pathways that used to open when seniors moved on, got promoted, started companies, or retired are moving slower. Fewer seats opening at the top means fewer positions cascading down through the middle and into entry-level. The double lock is structural.

The political economy of this sustains itself almost automatically. Companies avoid the uncomfortable conversation about whether their remote-by-default setup is actually compatible with developing talent. Politicians have a clean technological scapegoat instead of a messy management problem. Stanford and Harvard published results on a real signal that turned out to be non-causal, and the press ran a narrative that confirmed what everyone already believed. Nobody needed to be cynical for this to become the consensus. The mechanism was simpler: a real signal, a non-causal interpretation, and a narrative the entire world was already primed to accept.

For juniors navigating this, the algorithmic layer is its own game and it runs long before a human reads anything. If you want to understand how to game the algorithmic recruiting layer, the tactics are more concrete than most people realize.

2 Ways Out of a Broken Ladder

There are 2 exits. They're not for the same person.

The institutional exit is real. IBM in 2026 tripled its US entry-level hiring by explicitly redesigning junior roles around AI augmentation rather than treating AI as a replacement. The framing matters: instead of "we need fewer juniors because AI does their work," the bet was "we need juniors who work alongside AI from day one, and that's a trainable skill." The share of graduate postings in AI-exposed roles started recovering in early 2026 after 2 years of decline. The companies that crack the remote mentorship problem win the junior talent war while everyone else sits out. If you're on the hiring side, this is the 1 decision that compounds over the next 5 years.

I think this recovers faster than the pessimists say. Could be I'm reading early signals too optimistically. But the IBM counter-example is real, and it suggests the problem is soluble at the company level without waiting for a macro shift in the labor market.

The individual exit doesn't wait for institutional reform. For everyone looking at the queue and doing the math, the ladder being structurally blocked is actually clarifying. If the entry path is closed and the timeline is indefinite, the question stops being "how do I get onto the ladder" and becomes "why am I looking for a ladder in the first place."

The vibe-coder isn't someone who gave up on the market. That's someone who looked at the economics, understood that the return on waiting is negative, and decided to build the thing instead of waiting for permission to join the team that builds it. In 2026, that path is concrete in a way it wasn't 4 years ago. 1 shipped product beats 50 applications into the algorithmic void.

If you're starting down that path, CLIs beat MCP for production AI agents is worth understanding before you hit the production wall. And for the method itself, Vibe Coding, For Real is the 8-step Blueprint for builders who've hit the demo wall and want to ship something that actually runs.

We spent 3 years blaming an algorithm for what was actually a management policy. Convenient scapegoat: AI doesn't vote, doesn't give interviews, and doesn't defend itself in front of a committee.

The ladder is broken. The real lock isn't technological, it's managerial and economic. The companies that solve it, by explicitly redesigning junior roles around AI augmentation, are picking up the best entry-level talent while everyone else debates whether the market is "normalizing."

IBM did it. The signal is there.

You can wait for your potential employer to read the same study. Or you can stop applying and start vibe coding like a pro. C'est la vie.

Sources

Lambert, C. & Schindler, S. (2026). The Broken Ladder: AI, Remote Work, and Early-Career Hiring. LSE/Warwick/Oxford Ellison Institute. SSRN
Sternstein, M. (2026, June 5). Charts of the Week: RTO Stalled. a16z. a16z.news
Remote work, not AI, is killing job prospects for the youth. The Register, June 2, 2026. theregister.com
The real reason junior hiring is collapsing may not be AI. HCA Magazine, June 2026. hcamag.com

This post may contain affiliate links. If you click them, I might earn a small commission (costs you nothing, and helps me keep shipping quality articles every day for your reading pleasure).

Your Claude Code Project Is Not Set Up. It Just Looks Like It Is.

Phil Rentier Digital — Mon, 08 Jun 2026 13:41:11 +0000

Good instructions to Claude Code is the difference between an app that ships and a buggy mess nobody wants to debug. The new project onboarding flow simplified that work a lot, basically an interview. It extracts what's non-obvious, sets up hooks and skills, asks the questions you'd forget to answer. But you still need to know what happens when it finds your CLAUDE.md already there.

And what happens is not what most posts have described.

TLDR: /init isn't an improved generator. On a repo with an existing CLAUDE.md, it switches to audit mode: it reads your file, cross-references against lockfiles and configs, and surfaces what stopped matching while the code moved forward. On the 4th repo, 64 lines, it found 5 silent lies. The difference between generating and correcting is the whole article.

On a fresh repo, yes, it generates. The community ran with that, reasonably. "Setup 10x easier," the CLAUDE.md writes itself now. True for a blank slate. But the most common case is a repo that already has documentation, written early, before the codebase became what it actually is. The moment /init detects an existing file, it doesn't replace: it audits. Cross-references the CLAUDE.md against lockfiles, configs, schemas, and surfaces what no longer matches. That's the job.

I ran it on 4 repos over a few days.

I Expected a Generator. I Got an Auditor.

Thariq from the Claude Code team posted the env var flag in March: CLAUDE_CODE_NEW_INIT=1, preview mode, interview-based setup flow. A thread on r/ClaudeAI from the same week had 118 comments on a question that stuck: "Be honest: when Claude writes a long plan, do you actually read it? Or do you just say looks good?" The doc nobody rereads was already a live pain point in the community.

I set the flag and ran /init across the 4 repos.

What I expected on each: a CLAUDE.md with a stack section, a commands block, some conventions. Boilerplate I'd clean up manually. The kind of output that gives you a starting point and needs a human pass to be actually useful.

What I got instead: on 3 of the 4 repos, /init detected an existing file and immediately shifted behavior. On a blank repo it generates from scratch. With a file already present, the approach is different. It reads the current CLAUDE.md, reads the codebase, finds the gaps where what you wrote no longer matches what the code actually is.

Documentation drift doesn't announce itself. It's not like a build error or a failing test. It's more like corruption in a save file: the game keeps running, the numbers look fine, and then the boss fight hits and the stats don't add up to what was promised. By the time you notice, you've been playing on wrong assumptions for a while.

Claude Code's docs describe the new /init as following the "only include what Claude wouldn't infer on its own" principle. On an existing repo that means: first determine what the code actually is, then compare that to what's documented, then surface the delta. The delta is what matters.

2 Repos That Already Knew Themselves

Repo 1 was my main product dashboard: the central project, about 150-line CLAUDE.md, written early and updated occasionally. /init returned 11 new lines.

The additions were architectural facts that weren't in the file: the central data entity the whole system revolves around, a routing rule that funnels all helper logic to a specific module, 2-level auth (end-user vs machine-to-machine), an isolated scheduled task that runs outside the normal request cycle. None documented. All inferable from the code if you read deeply and cross-reference the imports.

Then it flagged 1 lie. The CLAUDE.md referenced npm install and localhost:3000. bun.lock was in the root. The project had been running on a different port for months. Both had been true at some point, both had quietly stopped being true, and nothing had broken. npm commands still execute on a bun project, mostly. The wrong port just means you try the wrong URL once, then the right one, and forget about it. Easy to miss. Easy to leave.

Repo 2 was a different problem. A project with close to 700 lines of carefully maintained CLAUDE.md, updated after each significant change. /init read the whole thing, scanned the codebase, came back with 3 lines. The bun test runner had been added recently and wasn't documented. No rewrite, no structural changes, just the missing commands.

And a verdict: "Your CLAUDE.md is already well beyond what /init would generate here."

(I keep a 500-line internal doc on a completely separate project, nothing to do with any of this, that I've been updating for 2 years because I find the writing clarifying. My daughter walked in once while I was rewriting a section header and asked why I was writing a book about my code. I didn't have a good answer. Anyway.)

A tool that knows when to stop is as rare as one that knows when to start.

The Repo With No Map

The 3rd repo: a multi-frontend catalog delivery system. Multiple Astro frontends, a Hono backend, SQLite, no CLAUDE.md, no README at the root. Started quickly because the shape was clear, documentation was for later, and later kept moving.

/init returned a complete architecture map in 4 parallel tool passes. The independent reads go out simultaneously: root config, Hono routes, Astro configs, build scripts, deploy notes. The reconstruction is fast because the calls don't wait on each other.

The same principle applies here as in how Claude Code builds project context from an existing codebase: a structured, accurate map is almost always the work that makes subsequent sessions stop going sideways. The map either exists and is correct, or the model improvises, and improvising on the wrong picture compounds quickly.

The key invariant it surfaced that I wouldn't have written down: Astro runs under Node, everything else under Bun. That detail was buried in a comment in the deploy script and a fnm use 22 call in the build script. An architectural constraint specific to how Astro's build process works, completely undocumented. Every Claude Code session on this repo had been operating without it.

What the 4 passes assembled concretely: the SQLite schema, an export pipeline serializing content to per-site JSON bundles, the Astro build sequence under Node 22 (not Bun, because Astro's SSG renderer required it), an rsync step to nginx with rewrite rules already defined, and a Cloudflare Worker handling edge routing in front of the whole thing. The full delivery chain from raw SQLite rows to rendered static files behind Cloudflare, documented in one pass. No directory tree, no generic project advice. Specific enough to navigate without asking.

5 Lies in 64 Lines

Documentation Drift Detective Board: 5 Hidden Code Lies

The 4th repo: my product processing pipeline. Full stack, Convex backend, Vite/Express frontend, secrets managed through Infisical. The CLAUDE.md had 64 lines, written 3 months earlier, accurate at the time.

/init found 5 places where the documentation had quietly become fiction.

1. The package manager

The CLAUDE.md instructed: npm install, npm run dev. bun.lock was in the root. The migration to bun had happened at some point and the docs hadn't followed. Claude Code had been running npm commands on a bun project, silently, without error, because most npm commands still execute. The incompatibility hides until dependency resolution diverges and you spend an afternoon figuring out why.

2. The missing workflow states

The CLAUDE.md documented 3 order status codes in the Convex schema: draft, published, archived. The actual schema had 7. The 4 missing ones handled edge cases: processing, failed, review, scheduled. The states that matter for any non-trivial operation. Every Claude Code session had been writing logic against a model of the system that was 4 states short.

3. The Convex folder

The CLAUDE.md described convex/ as the main processing layer. That had been true early. Over 3 months, the heavy work had migrated into server.js: PDF generation for product sheets, image resizing, webhook dispatch to partner integrations. The Convex functions became thin routing. The actual processing happened in a file the docs had stopped mentioning.

4. The undocumented mode switch

A shell script in the root toggled the stack between managed Convex Cloud and a self-hosted Convex instance depending on deployment target. Zero mention in the CLAUDE.md. Every Claude Code session had been assuming a static backend connection, when there was a manual switch step with real consequences for where data landed.

5. The port that takes 3 files to find

The CLAUDE.md said the dev server runs on port 3150. The actual port: 3002. Vite proxied to Express on 3002, PORT was injected by Infisical, vite.config.ts was the bridge between all 3. To find the real port, you needed to cross-reference 3 files. /init did that cross-reference. I had not. For 3 months.

Nobody lied deliberately. The CLAUDE.md had been accurate. The code had moved the way code always moves: not in dramatic rewrites but in 10 decisions per week, each one too small to feel like it warranted a doc update. After 3 months, 5 of those decisions had drifted past what was written.

Interlude: the dirty git tree

This repo had uncommitted state. A deleted package-lock.json, an untracked backup file sitting in the root. /init didn't skip the repo, didn't force the tree, didn't write over the working directory.

It ran 5 git steps in sequence: created a worktree on a dedicated branch, made edits in isolation, committed with a conventional commit message, fast-forward merged into main, then cleaned up the worktree and deleted the branch. WIP untouched, git history clean.

The reason this worked cleanly: versioned git hooks that enforce this workflow. The model didn't choose caution. It operated within project constraints it couldn't bypass. That's a different guarantee than relying on the model's goodwill, and it's worth understanding the difference between model goodwill and real tooling discipline before you decide how much trust to put in either.

What /init Cannot Do

/init audits what's traceable. Files it can read, configs it can cross-reference, schemas it can compare against documentation. That's a real capability, underrated because the output looks simple. The port lie alone saved me a debugging session I didn't want to have.

But there's a category of knowledge it can't touch.

The git hook that forced the worktree workflow exists because, months before /init existed, I came close to wiping a live working session by letting a Claude Code run commit directly to main on a dirty tree. The hook was the fix I coded that afternoon. It's documented in its own code but not in any CLAUDE.md. /init saw the hook and referenced it correctly, but it couldn't tell me why the sequence mattered, or what would happen if someone deleted it assuming it was boilerplate cleanup, or what the afternoon that produced it had cost in lost work.

That knowledge lives in the incident. The most valuable project rules tend to come from something that broke, not from a file scan or an onboarding interview. You can document the what but not the history of why, and the why is usually the part that keeps the mistake from repeating. /init is an audit tool, not a retrospective. It finds present lies, not past lessons, and knowing that difference is most of the reason to trust what it surfaces.

I think the other half of making /init useful is getting your documentation to a state worth auditing in the first place. If you're early in a project, the gap between "what I intend this codebase to be" and "what Claude Code actually needs documented" is the work that Vibe Coding, For Real maps out, specifically the distinction between intent documentation and implementation documentation. /init is only useful on implementation. The intent is still yours to write.

Launch /init tonight on your oldest repo. Not to get a clean CLAUDE.md. To find out how many lines are already lying. 😬

Sources

Thariq (@trq212), Claude Code team: X post announcing CLAUDE_CODE_NEW_INIT=1, March 2026
Claude Code Docs, Week 16 changelog (April 13-17, 2026)
r/ClaudeAI, GummySearch community data, June 2026
wmedia.es: "/init in Claude Code: way more than a CLAUDE.md template," April 2026

This post may contain affiliate links. If you click them, I might earn a small commission (costs you nothing, and helps me keep shipping quality articles every day for your reading pleasure).

Your Software Factory Is a Dark Kitchen. The $1,000 Nobody Mentions.

Phil Rentier Digital — Sat, 06 Jun 2026 13:41:11 +0000

The summer of 2021, everyone opened a dark kitchen. Rent an industrial space on the city's edge, slap a brand on Deliveroo, skip the dining room and the service staff entirely. The pitch was hard to argue with: produce without the overhead of a real restaurant. What the success stories left out is that Deliveroo's cut ran 20 to 30%, half the operators had no quality control process, and the brigade de goût (the team that tastes before the food leaves the kitchen) didn't exist. The line kept running. Food went out. Delivery food was a lottery then and it's a lottery now. Nothing has changed. But I digress.

TLDR: Most software factory posts talk about speed: 650 PRs a month, 1 million lines with 3 engineers. None of them mention the $1,000-a-day layer that makes those numbers safe to run. My factory ran without it. What it shipped made that very clear.

In 2026, everyone is opening a software factory. Agents that plan, code, test, and deploy, with no human checkpoint at each step. The numbers are real: according to BCG Platinion's April 2026 analysis, Spotify hasn't written a single manual line since December 2025 (650 AI-generated PRs a month, migrations 90% faster). OpenAI: 1 million lines in 5 months, 3 engineers, zero manual code. Nobody's making those numbers up. What they're leaving out isn't made up either.

My pipeline runs automated transformations for an ecommerce backend (product data from distributor CSV feeds, partner API integrations, the usual). Largely autonomous. Agents handle the repetitive work. I review at checkpoints. Or I thought I did. The factory shipped. Support tickets went out against a partner's live API (the sandbox endpoint was right there in the config, the agent picked live anyway). Customer order records landed in a logging endpoint connected to an external analytics service I'd half-forgotten was still active in the stack. And then the pipeline submitted internal backend routes (session tokens in the query strings) to Google's indexing API as part of a sitemap task it had decided was in scope. The code compiled and the pipeline reported clean. The agent marked the task done. Dark Souls at least gives you a YOU DIED screen so you know the run went south. The dashboard gave me a green checkmark.

The agent does exactly what you said. The disaster is everything you didn't.

The Summer Everyone Opened a Dark Kitchen

The dark kitchen model made perfect sense on a spreadsheet. Eliminate the dining room, run multiple brands out of one kitchen, route all orders through an existing delivery platform. Unit economics looked clean until you factored in the platform commission and the part nobody audited: whether what left the kitchen was what the customer had actually ordered.

The structural flaw was invisible from inside the operation. The kitchen ran. Orders processed. Volume metrics looked healthy. The problem surfaced when customers started complaining (wrong dish, wrong temperature, wrong address entirely). By then the food was already at the door.

The dark kitchen wave peaked mid-2021 and contracted hard by late 2022. The operators who survived had built some form of quality gate between the kitchen and the delivery platform. The ones who treated the infrastructure as a full substitute for operational discipline closed first. That's the pattern. The 2026 software factory version is the same movie with a significantly bigger budget.

What a Software Factory Actually Is

Start with the actual claim being made. A software factory isn't just "AI writes code faster." It's a full production pipeline where agents handle planning, implementation, testing, and deployment with no human checkpoint at each step. The human sets direction. The factory runs between reviews.

BCG Platinion's framing from their April 2026 analysis is useful here. The "Dark Software Factory" (their term) represents the highest level of AI integration, where code is never written or reviewed by humans at all. StrongDM's team operationalized this with 2 explicit rules: code must not be written by humans, and code must not be reviewed by humans. Not as an aspiration. As a hard constraint.

The numbers in circulation: Spotify, 650 AI-generated PRs a month, 90% faster migrations, zero manual lines since December 2025. OpenAI, 1 million lines of new product code in 5 months, 3 engineers. These are the numbers in the posts.

What didn't make the posts: a 2025 randomised control trial by METR, as cited in a March 2026 analysis by Cow-Shed Startup, found that developers working with AI assistance took 19% longer on complex tasks while estimating they were 24% faster. Off on both direction and amplitude. The factory feels fast. That's not the same thing as the factory being correct.

The Flaw Nobody Puts in the LinkedIn Post

Software Factory Dashboard: Tracked Metrics vs Ignored Blind Spots

Every software factory ladder post I've read (the BCG analysis, the 5-level frameworks, the LinkedIn thread breakdowns) covers level, speed, and tooling. None of them address what happens to the output once it leaves the pipeline and touches external systems.

Speed metrics are easy to instrument. You can count PRs, measure deploy time, track test pass rate, and calculate lines generated per engineer per week. What you can't easily instrument is scope (whether the agent touched what it should have touched, and nothing beyond that). That question doesn't exist in the feedback loop the factory optimizes for, because the feedback loop was built to measure outputs, not boundaries. So the factory measures what it can measure, declares victory on those dimensions, and ships everything else as a side effect you'll discover later, usually from an external party who received something they weren't expecting and has no particular incentive to be polite about it.

StrongDM solved this with what Simon Willison documented in February 2026 as "holdout scenarios" (test cases stored entirely outside the codebase, invisible to agents during development, so they can't optimize for them). Independent validation, post-facto, by a system the factory never touched during production. This is the CLI-over-MCP case for scoped agent pipelines made concrete: architecture that constrains what the agent can reach before it declares done, rather than auditing the consequences after.

A critic reviewing StrongDM's published code on Medium in February 2026 noted that it's easy to get swept up in the novelty of the workflow and lose track of what was actually produced. That's the diagnosis. The factory delivers a sensation of forward motion. Sensation and quality are different instruments.

The Brigade de Goût You Don't Have

In a professional kitchen, the brigade de goût doesn't cook. It's not part of the production line. Its job is to taste what the kitchen produces before it leaves (an independent layer, separate from the people who made the dish, with no stake in whether the dish was hard or easy to produce). It exists to catch what shouldn't ship.

Most builders don't have anything like this. They have a factory that runs, a test suite that passes (often written by the same agent doing the work), and a confidence that "it compiled, so it's fine." That confidence is exactly what StrongDM's holdout setup is designed to undercut.

According to Simon Willison's February 2026 writeup, the credibility threshold for calling something a real software factory is $1,000 in tokens per human engineer per day. That's the cost of running the holdout validation layer continuously. The brigade de goût has a price. It's the Deliveroo commission equivalent (the number that doesn't show up in the success post because nobody wants to lead with the operating overhead of taking quality seriously).

Most solo builders can't run $1,000 a day in validation tokens. I can't. That's a real constraint, not an excuse. The answer isn't to skip the quality gate. It's to build a manual version first (understand what you're actually trying to catch, then automate what the budget allows).

One important distinction: the test suite the agent writes is not your brigade de goût. The agent optimizes for the tests it knows about. Holdout scenarios work because the agent never saw them. If the agent can see the test during development, it can pass the test without solving the actual problem. Your test pass rate can be 100% and your side-effect blast radius can still be significant. Ask me how I know. Actually, don't. Not a fun story.

What I Did After the Incident

After I understood what the pipeline had touched, 1 question imposed itself before any technical fix: how did the agent know what it was allowed to touch? The answer was that it didn't. Nobody had told it explicitly. The scope existed as assumptions in my head that had never been written down anywhere the agent could reference. There was no boundary doc, no access policy, no explicit "these are the systems you can call and these are the ones you don't touch without confirmation." I had built the kitchen and turned it on. The brigade de goût was an intention I hadn't gotten around to. 😅

3 things changed after that.

Mapping the perimeter before the first production run. Not a config file (a decision): for each external system the pipeline touches, I now document access level (read or write), default endpoint (sandbox unless explicitly flagged otherwise), and whether any action requires confirmation before execution. That doc is part of the project setup, not an afterthought. It takes 20 minutes. Undoing an unintended support ticket stream and a partial order data leak did not take 20 minutes.

Testing external effects manually before any production credentials get granted. Not the internal logic (the outputs): actual API calls, data writes, external requests, anything that reaches outside the codebase. Run the pipeline in isolation, watch what it touches, before the agents have access to live systems. The step that sounds obvious every time someone explains it to you and stops sounding obvious the moment you're in a hurry to ship.

Asking 1 question about every capability the agent has: "Would I know if this went wrong?" If nothing in the stack would alert on a boundary violation, the agent doesn't get that capability unsupervised. This is where defining agent scope with prompt contracts before launch actually earns its cost. The spec written before the first run is your budget brigade de goût. The Vibe Coding, For Real Blueprint builds this in as an early step (the perimeter defined before any agent touches a live credential, specifically because that's the moment the conversation has to happen).

None of this is a universal checklist. It's what changed after the pipeline delivered to the wrong address.

How Long Before the Market Cleans Itself Up

The dark kitchens without QC held for about 18 months before the contraction hit. Deliveroo and CloudKitchens revised their operator terms. The least rigorous operations folded first. The ones that lasted had built a quality gate somewhere in the process.

Software factories without a brigade de goût have that same cycle in front of them. The first public incidents (leaked data, unintended API calls, systems touched without authorization) will run the same market correction. Not because the technology failed. Because operators shipped without a quality gate and the side effects landed where nobody expected.

I think the specification problem is actually harder than the speed problem. Maybe that's wrong, but every time I've tried to write catch-up tests after an incident, I've already missed the window by a week. The spec comes first. The brigade de goût gets built before the kitchen opens, not after the first complaint arrives from someone who opened a package they didn't order.

Somebody is going to get what your factory didn't mean to send. The question is whether you find out from your monitoring setup or from them.

Sources

BCG Platinion, "The Dark Software Factory," April 21, 2026: https://www.bcgplatinion.com/insights/the-dark-software-factory
Simon Willison, February 7, 2026: https://simonwillison.net/2026/Feb/7/strongdm/
Cow-Shed Startup, citing METR 2025 RCT, March 6, 2026: https://www.cow-shed.com/blog/dark-factories-five-levels-ai-automation-transform-audit-banking-legal
Medium critique of StrongDM implementation, February 11, 2026: https://medium.com/@polyglot_factotum/slop-review-with-ai-the-dark-factory-ffca22406822

This post may contain affiliate links. If you click them, I might earn a small commission (costs you nothing, and helps me keep shipping quality articles every day for your reading pleasure).