74 Releases in 52 Days. What's Actually Behind Anthropic's Shipping Velocity.

I’ve been running parallel AI workstreams for the past three months: research automation, competitive intelligence, prototyping, and more. So when Anthropic’s “74 releases in 52 days” started doing the rounds, the number didn’t surprise me. What surprised me was how few people were asking the right question.

Pawel Huryn mapped every release to a shipping calendar and called it “what a company pulling ahead looks like.” He’s right. But the interesting part isn’t the speed. Speed is a symptom. The structural choices underneath it (how they plan, how they verify quality, how they manage risk) are what actually matter. I’ve been building AI infrastructure and testing these ideas against my own product work. Some of it transfers directly. Some of it doesn’t.

Ship wider, not faster

The headline most people take from Anthropic’s velocity is “they ship fast.” True, but it misses the point. The real shift is concurrency.

Boris Cherny, the creator of Claude Code, runs five or more local AI sessions simultaneously, each in its own git worktree, plus another five to ten on the web. He starts in plan mode, iterating until the approach is solid, then switches to auto-accept edits. The Claude Code team ships roughly five releases per engineer per day. Merged PRs per engineer increased 67% while the team was doubling in size.

That 67% didn’t come from engineers typing faster. It came from engineers running five things at once.

I’ve been experimenting with this in my own work. The shift from “do one thing, finish it, start the next” to “run three AI workstreams in parallel and check in on each” was uncomfortable at first. It felt like I was context-switching. But it isn’t context-switching when each workstream has its own AI agent holding state. You’re not juggling. You’re delegating to parallel workers and reviewing output. That’s a fundamentally different cognitive model.

Last month I had one agent refactoring a notification system, another researching a competitor’s pricing change, and a third drafting test cases for a new feature. All running simultaneously. My job wasn’t writing code or doing research. It was reviewing output, making judgement calls, and steering direction. I got through what would have been three days of sequential work in an afternoon. Not because the work was faster. Because it was concurrent.

Your planning model probably still assumes one person, one task, one output. If AI lets one person run multiple workstreams in parallel, the question changes from “how do we ship faster?” to “how do we ship wider?” That’s a different planning conversation, and most product teams haven’t had it yet.

Verification replaces specification

Anthropic doesn’t write detailed requirements documents. No PRDs. No multi-quarter roadmaps. Someone builds a working prototype (often in a week or less), ships it to the whole company, observes usage, and iterates or kills it based on real signals. Artifacts, MCP, Claude Code all emerged this way. Bottom-up from internal tinkering, not from formal requirements gathering.

This sounds reckless. It isn’t. What replaced the upfront specification is a layered verification architecture they call the Swiss Cheese Model. Five layers, each catching different failure classes:

• AI self-verification before code reaches a PR: test suites, linters, browser testing
• Automated evals in CI/CD on every commit
• Automated security review on every diff
• Selective human review for architectural decisions and novel risks
• A living institutional memory document that encodes what the AI gets wrong (more on that in a moment)

The discipline didn’t disappear. It moved. From “specify what to build” to “define what success looks like and verify against it continuously.”

I’ve started applying a version of this in my own work, and it’s changed how I think about specs. At work, we still write them. There are good reasons for that when you’re shipping enterprise database tooling with customers who need predictability. But the balance has shifted. I spend more time now on acceptance criteria and verification conditions, less on detailed implementation guidance. The spec used to say how to build something. Increasingly, it says what success looks like, and I verify against that.

I’ve pushed this further in my side projects, where I have more room to experiment. When I shipped the last version of my iOS app, I wrote almost no implementation spec. Instead I wrote a detailed list of what the update should do: every user-facing behaviour, every edge case. Then I let the AI figure out the how, verifying against my criteria at each step. The AI handled the implementation differently than I would have, and in several cases the solutions were cleaner than what I’d have written myself.

The lesson isn’t “stop writing specs.” It’s shift the weight. Define how you’ll know it worked before you define how to build it. When AI is writing more of the code, knowing what right looks like matters more than prescribing how to get there.

Institutional memory that compounds

This is the most transferable idea in Anthropic’s playbook, and the one I’ve had the most direct experience with.

At Anthropic, when a human reviews a PR and spots something the AI got wrong, they don’t just fix it. They update the team’s CLAUDE.md file with the learning. Every future AI invocation reads that file before writing any code. The mistake is encoded as institutional knowledge. Not in a wiki nobody reads, but in the actual workflow, at the point of execution. Each error caught makes every subsequent interaction better.

I use the same pattern. I maintain a document that tells my AI system what it consistently gets wrong: what it misses, what it over-indexes on, what to prioritise. A few real entries: “When analysing competitor pricing, always check whether the price is per-user or per-instance, you’ve confused these twice.” “Don’t summarise regulatory articles without noting which jurisdiction they apply to.” “When I ask for a competitive brief, lead with what changed since last week, not a full recap.”

These feel mundane. They’re not. Each one represents a failure I only had to experience once. The system reads them before every task. Over six months, the compound effect is significant. The AI’s output is noticeably sharper, not because the underlying model improved, but because I invested in the configuration layer.

Any team using AI tools can start this today. Keep a living document of what the AI gets wrong in your context. Put it where the AI reads it. Update it regularly. It’s the highest-return quality investment available right now, and it works at any shipping velocity.

Graduated shipping manages risk at speed

Most enterprise product leaders underestimate this: Anthropic is an enterprise company. They serve Fortune 500 customers. They have SLAs, security certifications, and compliance requirements. And they still shipped 14 major features in March, alongside five outages and an accidental model leak. That’s the cost of velocity, and it’s one they’ve clearly decided is worth paying.

How? Research previews.

Computer use launched as a research preview: clearly labelled, explicitly imperfect, learning in production with real users. This isn’t cutting corners. It’s a deliberate trust model: ship early, be transparent about the maturity level, gather real usage data, graduate to production when the feature is ready.

Enterprise software companies already do versions of this: betas, early access programmes, feature flags. But most do it timidly, with too many caveats and too little ambition. A research preview is more honest and more ambitious: “This is new. It’s not finished. We think it’s valuable enough to share now. Try it, tell us what breaks.”

I think the fear that enterprise customers can’t handle imperfection is wrong. What they can’t handle is surprise. If you’re transparent about what’s early and what’s production-grade, most enterprise customers will meet you there. Many will prefer it. They’d rather shape a feature through early access than receive a finished product that doesn’t fit their workflow.

I haven’t shipped a research preview in my own product work yet. We have early access programmes, but they’re cautious. More “here’s a polished beta” than “here’s something ambitious and unfinished.” Anthropic’s approach has made me rethink that. The next feature I ship that’s genuinely novel, I want to put it in front of customers earlier and more honestly than I normally would. The risk of shipping imperfection is lower than the risk of shipping late and wrong.

If your release cadence is measured in quarters, graduated shipping is probably the single fastest structural change you can make.

Where this doesn’t fully transfer

Anthropic has structural advantages that most product teams don’t, and it would be dishonest to gloss over them.

Their product IS their toolchain. Claude Code is built using Claude Code. The feedback loop between “the thing we ship” and “the thing we build with” is uniquely tight. Most enterprise product teams don’t have that recursive advantage.

Their internal dogfooding is unusually high-signal. When 4,000 AI engineers and researchers use your product daily, you get extraordinary usage data without a single customer call. My product’s users are enterprise DBAs. Their feedback is valuable but it arrives slowly, through support tickets and research calls, not through daily internal usage.

Their risk tolerance is calibrated for a market that rewards speed. AI infrastructure is a land-grab right now. Enterprise database tooling is not. My customers value stability and predictability alongside innovation. That’s a legitimate constraint, not an excuse.

But none of these gaps invalidate the structural lessons. Parallel execution, layered verification, institutional AI memory, graduated shipping. These work regardless of your market or your product. You just apply them at a cadence that fits your context. The structure is the thing. The tempo is variable.

What I’m taking from this

I’m not trying to turn my teams into Anthropic. But I am making three concrete changes based on what I’ve learned.

I’ve restructured how I plan my own work around concurrency. Parallel AI workstreams instead of sequential tasks. It’s already changed how much I get through in a week. My role has shifted from “person who does the work” to “person who steers the work and makes the judgement calls.” That shift is uncomfortable if you’ve built your identity around being the one who does the thing. It’s liberating once you realise the judgement calls were always the valuable part.

I’m investing more in my AI memory document. Twenty minutes a week to update. Hours saved correcting the same mistakes. Each entry is a failure I’ll never repeat. That’s the best ROI of anything I do.

And I’m pushing for earlier, more honest customer exposure on our next novel feature. Not a polished beta. A genuine “this is early, help us shape it” preview. Anthropic’s model gave me the framing to make that argument internally.

I’m still figuring a lot of this out. But studying how Anthropic works, and then testing it against my own context, has given me a much clearer sense of what to focus on. The structure is the thing. The tempo is yours to set.