You know the meeting. You have been in it dozens of times.
The slides go up. The roadmap stretches across the quarter. The engineering lead walks through the sprint velocity. Someone asks about the release date. Someone else asks about the backlog. Notes are taken. A follow-up is scheduled.
And somewhere, in a different city, on a different continent, a team is shipping its fourteenth product release of the week.
That is not a metaphor. That is what Anthropic actually did between the 1st of February and the 24th of March 2026. Seventy-four product releases in fifty-two days. Across Claude Code, Cowork, the API, the models, the desktop applications, the enterprise infrastructure. Not one team. Every team. Simultaneously.
The people observing this on LinkedIn and X drew the wrong conclusion. They said Anthropic has the best engineers. They said Claude is a smarter model. They pointed at the talent.
They missed the point entirely.
What you are actually looking at
Anthropic is not shipping faster because its engineers are cleverer.
Anthropic is shipping faster because it changed the physics of the work itself.
The company is building Claude with Claude. Using its own agentic infrastructure. Running autonomous coding cycles internally before any customer sees them. The bottleneck in their engineering organisation is no longer writing code. The bottleneck is now deciding what to build and reviewing the output.
Read that again.
Writing the code is no longer the constraint.
This is not a marginal improvement in efficiency. It is a structural inversion. In every traditional software organisation on earth, the long pole in the tent is getting engineers to write the thing. Planning, estimating, scoping, sprinting, reviewing, iterating. The whole industrial apparatus of modern software development exists because writing code is slow, expensive, and human.
Anthropic just demonstrated that it is not anymore.
The horse and the car
We have been here before. Not with software. With everything.
Every transformative shift in how work gets done produces the same pattern. There is a period when the old method and the new method coexist, and the people still using the old method cannot quite see what is happening to them. The gap feels manageable. It does not feel existential. Until it does.
The typewriter and the word processor. The darkroom and Photoshop. The drawing board and AutoCAD. The travel agent and the internet. In every case, the people defending the old method were not stupid. They were experienced, skilled, and deeply invested. They just could not see how fast the ground was moving.
We are in that moment right now. Most businesses and development teams are still operating on quarterly roadmaps, two-week sprints, and annual planning cycles. Not because they are lazy. Because that is what good engineering looked like until extremely recently.
The problem is that “extremely recently” now means earlier this year.
Siri shipped less in five years than Anthropic shipped in fifty-two days. That is not a criticism of Apple. It is a description of two different worlds operating under completely different rules.
What I see from where I am standing
I build things. Not advise on AI strategy at a comfortable distance. Build. Ship. Iterate. Run AI-first ventures from concept to working product.
And the difference between how we operate now and how the same work would have been done eighteen months ago is not incremental. It is categorical.
Prototypes that would have taken a development agency six weeks and significant budget to produce get built in an afternoon. Not rough sketches. Working products with real logic, real data architecture, real interfaces. Concepts that previously required a full discovery engagement, a technical scoping document, and a multi-week build cycle get validated and prototyped in a day. The same applies to internal tools, client-facing systems, agentic workflows, and operational infrastructure.
I am not describing something exceptional. I am describing what is now available to anyone willing to actually use it.
Claude Code runs agents across a codebase autonomously. Codex operates on parallel threads. The coding platforms, Claude Code, Codex, Gemini, Cursor, and the rest, are not tools that speed up a developer. They are systems that change the ratio of human to machine in the production of software.
When I look at Anthropic shipping seventy-four releases in fifty-two days, I am not surprised. I am watching them do publicly and at scale what we have been experiencing privately and at smaller scale for the past year.
The gap most people cannot see
Here is what worries me.
Most people still experience AI as a chatbot. A better search engine. Something you ask a question and get an answer from. They have integrated it into their workflow as a productivity layer: draft this email, summarise this document, help me think through this problem.
That is not what AI is.
AI is a rocket for building. A completely different substrate for creating products, services, prototypes, and systems. The companies and individuals who have understood this are not just working faster. They are operating in a different dimension of capability.
And the companies that have not understood this are not just slower. They are falling behind at a compounding rate.
Every week that an engineering organisation runs on traditional sprint cycles while a competitor runs on autonomous agentic loops is not a week of linear disadvantage. It is a week of compounding divergence. The gap does not grow arithmetically. It grows the way compound interest does: slowly at first, then all at once.
I work with organisations, agencies, and platforms that are not moving in this direction. Some are actively resistant. Some are curious but cautious. Some are moving fast in the wrong layer, adopting AI tools for communication and summarisation whilst leaving their core build process untouched.
They are not going to like where this ends up.
What this actually requires
The question business leaders ask is: how do we integrate AI into our product?
That is the wrong question. It is the typewriter manufacturer asking how to make a better ribbon.
The right question is: how do we reorganise our entire capability to build around the fact that writing code is no longer the bottleneck?
This is not a tools question. It is an architecture question. It is a culture question. It is a question about what your engineering organisation is actually for when the production of code has been largely delegated to autonomous systems.
The answer, in practice, looks something like this.
Context becomes the most valuable layer you own. The part of the stack that no vendor can replicate is the specific knowledge of your business: your data, your customer relationships, your domain expertise, your accumulated institutional intelligence. Anthropic can ship seventy-four releases in fifty-two days, but it cannot ship your context. That is yours. And in an agentic world, context is the moat.
Architecture decisions become the critical human work. When agents handle the boilerplate, the value of human judgment concentrates at the level of system design. What are we building? Why? How should it fit together? These are decisions that require human understanding. The execution is increasingly not.
Review and direction replace production as the core engineering skill. Teams that have adapted to this shift describe a new rhythm: define, delegate to agents, review, iterate, ship. The human is in the loop for direction and judgment, not for the mechanical act of producing the code itself.
Velocity becomes a compounding asset. Each release creates the conditions for the next one. Context files accumulate learning. Auto-memory holds project patterns across sessions. The feedback loop tightens with every cycle. This is not additive. It is multiplicative.
This is not just for engineers
Here is where I want to push back on how this conversation usually gets framed.
When people see a story about seventy-four software releases, they assume it is a story about engineers. It is not. Or rather, it is not only that.
What has genuinely changed is something much broader. The ability to build software, to create a working solution to a specific problem, has been democratised to an extent we have not fully absorbed yet.
A CEO who needs a dashboard that does not exist yet does not need to commission a development agency. She can describe what she needs to Claude, to Replit, to Lovable, to Bolt, to Perplexity, and have something working in an hour. A project manager who needs a custom tracker for a specific workflow can build it in an afternoon. A doctor’s assistant who needs a simple intake tool, a marketing director who needs a personalised briefing system, a consultant who needs a client-specific analysis framework: all of these are now buildable by the person who needs them, without a single line of hand-written code.
This is not the same as enterprise software deployment. Building a production system used by thousands of users across a company still requires engineering rigour, security architecture, and technical oversight. That complexity does not disappear. But that has always been a fraction of the software that people actually need. Most of what people need is personal, contextual, and temporary. A tool for this project. A system for this client. A solution for this moment.
That class of software is now available to everyone.
Claude Code will interview you about what you are trying to do, understand your context, and build you something real. Not a mockup. Not a prototype that needs a developer to finish it. Something you can use, today, for the specific thing you need.
The platforms, Claude, Replit, Lovable, Bolt, and the growing ecosystem around them, are not just accelerating engineers. They are creating an entirely new population of builders. People who have always had the ideas but never had the means. People who have always understood the problem but could never access the solution.
Anthropic demonstrated what this looks like at industrial scale. Seventy-four releases in fifty-two days, teams running in parallel, agents handling the production, humans steering the direction.
But the same shift, scaled down to the individual, is equally real. And it is happening right now, for anyone willing to sit down and start building.
The objection everyone raises
At this point someone always raises their hand.
“We cannot put our confidential data into these tools. We do not know where it goes. We are worried about training.”
It is a reasonable concern. It is also, in most cases, based on a misunderstanding of how these platforms actually work. And because it is being used as a reason to do nothing, it is worth unpacking properly.
Here is the truth.
The fear applies to consumer accounts. It does not apply to the tools your business should actually be using.
When Anthropic updated its terms of service in September 2025, it changed the default for Claude Free, Pro and Max accounts: conversations could be used to improve the model unless users actively opted out. That generated significant concern, and the concern was legitimate. If your employees are using personal consumer accounts for work, your data is potentially going into training pipelines. That is a real problem.
But here is what the same update also said, and what far fewer people noticed: these changes do not apply to services under commercial terms, including Claude for Work, API use, and access via Amazon Bedrock and Google Cloud’s Vertex AI.
The picture is consistent across every major platform. By default, Anthropic will not use inputs or outputs from commercial products, including Claude for Work and the Anthropic API, to train its models. OpenAI states that by default it does not use data from ChatGPT Enterprise, ChatGPT Business, or the API platform for training or improving its models. Google has confirmed that enterprise data used within Gemini for Workspace and Gemini for Cloud is not used for model training and is not reviewed by humans.
The distinction is not subtle. It is structural. Consumer accounts are designed for individuals exploring capabilities. Business accounts and API access are designed for organisations handling real data. The privacy protections, the contractual commitments, and the data governance frameworks exist precisely at the layer where serious business use happens.
The question is not whether AI tools are safe for business use. Properly configured, under business terms, they are. The question is whether your organisation has formalised that configuration or whether your team is using personal free accounts and hoping for the best.
The latter is the actual risk. And solving it requires a simple decision: move sensitive work onto the appropriate commercial tier, access the models via the API where your data is never logged for training, and establish a clear internal policy on which accounts are approved for which tasks.
That is not a technical challenge. It is a governance decision. And making it is the difference between your organisation having a legitimate reason to move fast and having a legitimate-sounding excuse to stay still.
Note: platform terms evolve. The principles above are accurate as of March 2026 and consistent across Anthropic, OpenAI, and Google’s published documentation. Before committing to a specific configuration, verify the current terms for the platform you are using. The underlying distinction between consumer and commercial tiers has been stable, but the specific details of each tier are subject to change.
The companies starting from scratch today, with an AI-first orientation and no legacy process to defend, are not just more efficient. They are building at a speed and with a capability structure that most established organisations cannot yet match. Not because the tools are unavailable to established organisations. Because the mental models, the processes, the incentive structures, and the cultures inside those organisations are still calibrated to a world where writing code was the hard part.
That world ended.
Every month that passes without a genuine structural response is a month in which the compounding gap widens. The gap does not grow arithmetically. It grows the way compound interest does: slowly at first, then all at once.
Seventy-four releases in fifty-two days is not a boast. It is a proof of concept for an entirely new way of building. And that proof of concept applies just as much to a solo founder building her first product as it does to a frontier AI company running parallel agent teams across four engineering surfaces.
The question is no longer whether this is possible. It has been demonstrated.
The question is simply: what are you waiting for?
If this resonated, subscribe. The next piece goes into the context layer specifically: what it is, why it is the only part of the stack no vendor can take from you, and how to build yours before someone else uses theirs against you.
Craig Hepburn is an AI strategist and builder, Perplexity Fellow, former CDO at Art Basel and UEFA. Works across tech, business and system design shaping how AI operates responsibly.