by Dan Shipper in Chain of Thought

Was this newsletter forwarded to you? Sign up to get it in your inbox.

As any child who’s heard Aesop knows, the point of a fable is its moral. We see the consequences of falsely crying wolf. We learn why slow and steady wins the hare race.

So what is the moral of Claude Fable 5, Anthropic’s newest model, which this week we called the best coding model in the world?

For engineers, the case is easy to make. For many knowledge workers, though, Fable might feel incremental. You may have one-shotted an impressive demo or two, but you’re probably not using it for your day-to-day work. Why would you? It costs twice as much and the results aren’t that much better.

But there is a certain class of developers who are feeling Fable’s full force. These are people like Cora general manager Kieran Klaassen, who are suddenly churning through his backlog of bug fixes and feature requests in hours instead of days. “This is my favorite model ever,” he told me.

What’s the difference between Kieran and everyone else? The difference between Kieran and most people using Fable isn’t simply that he’s a developer but that he’s at Level 7 or 8 on our scale of AI use: He delegates whole projects, lets agents work asynchronously, reviews the results, and feeds what he learns into the next run. In other words he writes—dare I say it, loops—not prompts.

For now, this might make Fable seem like a tool for developers. But in AI, developer workflows have a habit of spreading to the rest of knowledge work. Claude Code started as a developer tool, and now the same methodology is being used for everything from slide decks to spreadsheets inside of Cowork and Codex.

If you’re not feeling Fable’s force, that’s probably because you haven’t yet started to treat your work like gardening ...

Become a paid subscriber to Every to unlock this piece and learn about:

1. The gardening metaphor that explains who gets the most out of frontier AI
2. How Fable helps usher in the era of the individual
3. How the technology gap between the cutting edge and everyone else raises real questions

Click here to read the full post

Want the full text of all articles in RSS? Become a subscriber, or learn more.

by Dan Shipper in Chain of Thought

Was this newsletter forwarded to you? Sign up to get it in your inbox.

At 4 a.m. on the day after we launched our agent-native document editor, Proof, I watched yet another Codex agent try to revive our server.

Over 4,000 documents had been created since launch, but the app had been mysteriously crashing all day. This left users with crucial documents that they couldn’t access, and me with egg on my face.

I hadn’t slept for almost 24 hours, and all I could do was nervously munch trail mix as Codex investigated yet another bug buried deep in a codebase that I didn’t understand. It felt less like programming and more like being the dumbest participant at a math Olympiad. Needless to say, I was reconsidering my life choices.

Today, almost a week later, Proof is more or less stable. And I’ve learned a lot about both building and launching a purely vibe coded app. Perhaps more importantly, I’ve also learned what happens once that app goes live—and then goes down.

My current opinion is this: If you can vibe code it, you can vibe fix it. You just might not be able to fix it quickly.

Software engineering is changing rapidly as a discipline. The days of typing code into a computer manually seem to be over, and the current conversation on X is around “zero-human startups.” My experience with Proof, though, is a good reality check.

It demonstrates both what is truly possible with vibe coded apps, and where human engineers will continue to be critical now and in the future.

What’s possible at the edge

I’ve been writing about how AI is changing programming for a few years now, and my experience with Proof confirms a lot of my thoughts...

Become a paid subscriber to Every to unlock this piece and learn about:

1. What it took to bring a crashing, vibe coded app back from the brink
2. The specific failure modes coding models keep hitting
3. Why allocation is the new key skill for human engineers

Click here to read the full post

Want the full text of all articles in RSS? Become a subscriber, or learn more.

by Dan Shipper in Chain of Thought

​​TLDR: Today we’re launching a new experiment: Proof, an agent-native markdown editor that lets you collaborate on documents with multiple humans and AI agents—and tracks who wrote what. It’s available now for paid Every subscribers.

For the past two decades, Amazon’s “two-pizza rule” has been the gold standard for team size.

The story goes like this: At a company retreat in 2002, when Amazon managers wanted more communication, Jeff Bezos fired back that “communication is terrible!” A few weeks later, he restructured the company around small autonomous teams. If a team had more than 10 people—more than could be fed by two pizzas—it was too big.

Twenty-four years later, two-pizza teams are now themselves too big for building software products. When each employee is armed with Opus 4.6 and Codex 5.3, the ideal team size shrinks even further.

Click here to read the full post

Want the full text of all articles in RSS? Become a subscriber, or learn more.