The future is ClaudeVM but 2026 is like radio plays on television

📺 View the presentation slides

When television was first invented, they filmed people reading radio dramas in front of microphones. People only know how to use a new medium through the analogy of the old one. That's exactly what's happening now.

Software engineers were the first to pick up AI tools, and the first thing they did was generate code they could code review, test deterministically, and ship through familiar pipelines. Cal AI was vibe coded and it tracks your calories, threatening MyFitnessPal's whole business. That's a hint at what's coming — but vibe coding is still coding. It's still radio on television.

Once we actually melt into the medium, the thing that matters is the business case: speed of shipping, capex, cost of development. The code is not the point. No compilation. The specs run directly on ClaudeVM.

When the JVM came out, most COBOL and C engineers kept doing what they were doing — many still do. But there were 10X more Java engineers, and their code swamped the old stuff in businesses. Same pattern with V8 and JavaScript. Engineers today will keep doing what they do and maintain precise infrastructure of a certain kind. Fine.

But we are about to be hit with hundreds of millions of Englishscript engineers writing scripts that swamp all other code in terms of utility and volume — running directly on ClaudeVM, finally fulfilling the end goal of software eating the world. Each script tweaked with a few words from a prior script. Billions of unique programs, each perfectly customized to the user.

So cheap I'm not sure there will be startups so much as blog posts — free as long as you sign up to the mailing list. Custom open-source Englishscript that designs the perfect meal plan: photo detection, flexibility and variety, notifications with exact calories for you, hand-designed in seconds with white-glove human onboarding. And you'd want a phone that can natively run ClaudeVM Englishscripts directly — figure out a payment harness in the OS — none of the heaviness of app compilation, App Store, binaries.

Vibe coding is radio on television. Coding is the wrong word. Even as an intermediary step, coding is dead. It'll just be Englishscript.

Why a VM? Why not compile to binary?

The OODA loop is easier and faster for 100 million Englishscripters. The end user is also live debugging, healing, and adding features in real time. It's like Lisp.

But it's not good code?

The bitcode that V8 generates isn't "good" code either. Not reusable. Often repetitive from loop unrolling. Not DRY. Doesn't matter.

Will we still need C++ engineers?

Sure, there's tons of old stuff not getting changed — COBOL running banks still, decades later. AI isn't touching any of that meaningfully anyway. Value too low, auditing too complex. We'll use limited GPU power on the 10X flexible value creation of new stuff. It doesn't matter if it can't write assembly or COBOL for years.

The analogy is that it's cheaper to set up a whole new solar plant (capex) than to maintain the coal power plants for one more year (opex). In the same way C/C++ still runs all operating systems, we'll still have that infrastructure. I don't think classic engineers will lose their jobs. But a whole slew of apps will have 100X more engineers making 100X more apps and 100X more value, computed inefficiently, the way JavaScript and Electron did. Claude desktop is Electron.

Does this require AGI?

No. Not AGI. Not ASI. Just a fast JIT.

Can you replace the web?

One idea: a new type of browser where clicking View Source shows just the English prompt. The rendered website is generated dynamically from that prompt, with many intermediary throwaway HTML/CSS steps. The World Wide Web, but even more accessible than HTML.

How will Englishscript writers get paid?

Software will become as easy to make as music — and as easy to copy. Piracy rampant. The solution will look like Spotify for software: pay a subscription, and the software writers get a penny per use. Modeling music copyright.

What about MCP?

MCP is tired because it runs code instead of English.

What about tools like CodeSpeak?

The Kotlin creator's new "language": codespeak.dev. Getting close. We will only have Englishscripts and won't need code anymore. No compiling, no vibe coding, no coding.

What is Englishscript really?

It's what you've been doing writing agents using English instead of code. Just extend that all the way to everything — the final endgame. The VM will be something new that Claude will ship around, though right now it's haphazard; people isolate by buying Mac Minis, first sandboxes are coming out but still not fully virtualized.

Aren't Englishscripts less precise than code?

Englishscripts can get as detailed or as zoomed out as you want. They can include literate-program-style snippets of code or pseudocode. But the more code you add, the less flexible, adaptable, forwards-compatible, reusable, and mergeable it becomes.

Doesn't this have to generate code at some point?

Nope. Go learn about how V8 works. It has to make kernel calls but doesn't need any intermediate code you'd ever look at. At best, VM bitcode — not Rust. I'm not even talking about the future at this point. Many of your agents are already English → value, doing things that last year you would have written in code or MCP code. Just go all the way. No code.

Don't you need strictness and repeatability?

Engineers tell me that's the crucial difference. But is repeatability the most important thing about code, or is it just providing the value? Or is the strictness a coincidence — computers used to be unforgiving with outputs for later programs, so we got careful. LLMs can be made deterministic with a seed if you need that. Entropy is just PRNG.

Where does this all end?

LLMs top out the logistic curve as a fast JIT — the "last virtual machine." Not AGI, but useful and world-changing. I haven't seen people analogize LLMs to the V8 VM or JVM. Bitcode is hard and nobody reads it, but it doesn't matter — we're in the slow JIT phase where the code is bad and bloated and slow, and that was also true of Java. Going from slow JIT to fast JIT doesn't require magic or AGI, just lots of optimization by humans. "Skills" or "prompts" or "agents" don't have that viewpoint yet. They should.

Previously: Why Claude Runs on Electron and Not ClaudeVM · Claude is a JIT