The Internet Computer: Caffeine.ai CEO Dominic Williams on Unstoppable, Self-Writing Software

So we've got a lot to talk about. You started this nonprofit about 10 years ago, if I understand correctly, to explore the limits of decentralized computing with a vision of the Internet Computer. Obviously, AI is now intersecting with everything, and it's become a big part of your work as well. We'll get through all of it, but I thought it would be great to take me back to the beginning and give us a little bit of your motivation, philosophy, and vision for the Internet Computer.

I think people have heard that concept a little bit associated with Ethereum. We did an episode not too long ago with the NEAR Protocol, and there's some overlap there as well. What is your vision for the Internet Computer?

Well, my perspective is quite technical. At this point, I've been writing software for 45 years, to give you an idea of why.

Back in around 2014, I was pioneering the application of classical distributed computing techniques in the blockchain setting, and I was involved with the early Ethereum project. Then this concept came up called the World Computer, and I saw the World Computer a bit differently from everyone else.

When I looked at Ethereum and early smart contract technology, I said, “Look, these smart contracts are really a new kind of software—network software—that has these wonderful properties.” They're tamperproof, which means they're guaranteed to run their written logic against their correct data. They're unstoppable, in the sense that they're guaranteed to run. If you need to, you can make them autonomous.

They run within a kind of serverless environment where it's not just logic but also data that's present. That contrasts with something like Amazon Web Services Lambda, where you can run serverless logic but call out to a database to acquire data to process.

I felt like this had potential as a new kind of cloud. At the time, people didn't believe that the necessary science could be developed to make this vision possible—that you could create a cloud environment from a secure network. It seemed improbable to people, but nonetheless, I wasn't deterred.

I really thought this was something that could benefit the world enormously. Using this approach, we could extend the Internet such that, as well as connecting people, it could also provide a cloud and a serverless cloud environment that people could build on. It wouldn't be best for every job, but for a broad range of apps, it would be fantastic, because when you built them there, they could run securely without traditional cybersecurity protections, for example.

Today, we've got services with many thousands of users that have run for years without any cybersecurity protections and without any security incidents. The purpose really was to solve seminal problems in the field of technology related to things like security and resilience, but also productivity.

We wanted to provide the world with a new kind of serverless environment where there was much greater abstraction that would reduce the cost of developing and maintaining software. You can probably see how some of these properties flow directly in the direction of AI that's building and updating applications for us in the self-writing cloud paradigm.

By that point, we'd been working for years at scale. We've been the largest R&D operation in the crypto industry, if you want to call it that, although we're a bit different from most projects in the crypto industry. We're not focused on tokens and things like that. We're focused on delivering technological utility.

We've been the largest R&D operation in the industry since the end of 2017. A huge amount of work—hundreds of millions of dollars—has been spent at this stage developing this thing called the Internet Computer Protocol that creates the Internet Computer.

At some point, we realized that the future is really a self-writing cloud, where AI forms the role of a kind of wish machine. You just say, “Look, I need this app,” and it'll say to you, “Okay, here it is on a URL.” Then you'll say, “Oh, I need to update my app,” and the AI will just say, “Okay, refresh your URL.”

In that self-writing future, it's essential that the apps the wish machine is giving people are immune to traditional forms of cyberattack. The whole point is that anyone will be able to create and update sophisticated online functionality, and they're not going to have their own security team to protect the app. They're not going to have their own systems administration team to make sure it keeps running.

There are a whole load of really important things that the backend of a self-writing cloud platform has to do. The frontend is the AI that grants the wishes. The backend is what the AI is building on.

It really needs to be able to host apps that are tamperproof, which means they're guaranteed to run their written logic against their correct data. They're unstoppable, which means that they're guaranteed to run and the data is going to be there.

There are other guarantees too, some of which are more subtle. If the AI makes a mistake or hallucinates with a production app, what are the guardrails that can give you a strong guarantee that no data will be lost during the update by AI?

There are other important ones too, such as the apps being sovereign. Otherwise, the paradigm reduces to you talking to the wish machine and it creating your app inside a SaaS service where you're stuck forever. We think that's the wrong model.

Yeah, there's a lot there to unpack. These properties that you list—tamperproof, unstoppable, autonomous, sovereign—are right at the intersection of a lot of people's fears and hopes for what AI can ultimately mature into.

I guess just one more beat on your philosophy. So much of the crypto space was obviously about trying to create systems that are not under the traditional jurisdiction of national governments.

Right? The idea is we don't necessarily trust these governments to make good decisions or to be operating in the people's best interest broadly. And so to create a technology that they can't shut down with a dictate is obviously a major kind of countermove in the balance of power between governments and the people—the population broadly. So I assume that was part of your motivation, or certainly, you tell me.

But then I'm also really interested in how that has evolved in your mind, because I talk to people all the time who are like, “I'm really worried about AI becoming unstoppable, becoming autonomous, and I don't know what it's going to do. I worry that we're not going to be able to control it and that it might do bad things to us.”

And then I also talk to other people, and I think what's tough about this is they both make really compelling arguments. Other people are like, “We're going to have unbelievable concentration of power if we don't have some way to run AI in a decentralized, power-to-the-people sort of way. We might end up in a world where a handful of companies, or just a couple, or even just one government, kind of control the most important levers of power, and there's really no checks on them.” So what's your kind of background philosophy and evolution to the present day on that dimension?

I certainly gravitate toward the idea that open systems are better—can be much better for humanity—and my inspiration for the Internet Computer was in large part the Internet itself. The Internet is a decentralized network. Nobody owns it. Anybody can create their own subnet and even sell access in the role of an ISP. And this has created enormous freedoms for people and enormous worldwide economic growth. I mean, the world's so much better for the Internet.

The Internet is a decentralized network. It has its own economic model, where people pay for peering relationships. For example, you create a subnet at home with your Wi-Fi router, and then you pay your ISP to peer your subnet with theirs. They probably pay some backbone providers to peer with them, like Level 3, Global Crossing, Cogent, and so on. So it all works in a wonderful way, and nobody would want to go back to a situation where we just had AOL and CompuServe, or Microsoft got its way and had the information superhighway. That would be totally dystopian.

So I think, for sure, that there should be a computer infrastructure people can build on that is sovereign, in the sense that it is open and so on. That doesn't mean that there isn't a role for big tech and specialized clouds and so on. I think it can coexist. In fact, the Internet Computer project generally is entering a new phase, and people will be surprised in 2026 to see it integrating with big tech and sometimes—or oftentimes, in fact—running over big tech clouds. That's in the works.

These are different paradigms, and they both have their advantages and disadvantages. The Internet Computer does bring a lot of unique advantages that cannot be easily imitated. If you want to create a tamper-proof stack, the only known way of doing that is to create a virtual execution environment.

The Internet Computer cloud environment runs inside a horizontally scalable execution environment, which actually resides inside a secure network protocol, and it derives its properties from the mathematical properties of the protocol. So, as far as I know, at this stage there's no other way of creating a tamper-proof, unstoppable stack. When you boil down blockchain, that's what it's all about: creating compute stacks that are tamper-proof, unstoppable if you want them to be, autonomous, and so on.

The difference with the Internet Computer is it was designed from first principles. So there's nothing in the world today that remotely resembles the Internet Computer, and it really can play the role of cloud. There are some limitations. For example, you can actually run AI on the network, but only really neural networks. If you want to do facial recognition, you can do that—you can run that on the network. You couldn't run a frontier model on the Internet Computer.

Talking about Caffeine, although Caffeine is building apps on the Internet Computer, the ensemble of AI that's doing the building isn't on the Internet Computer itself.

Gotcha. Okay, good to know. I had a question on that, and I'll come back to it and dig out a little bit more. When you talk about tamper-proof, does this ultimately kind of rest on a sort of formal verification process?

I just did an episode not too long ago, and I'm quite new to this area too, on the use of formal methods at, for example, Amazon, where they've done a lot with AWS to ensure—and literally prove—that you're not going to be able to get outside your container and into your digital neighbor's container within their infrastructure. So is it essentially a similar kind of technique, or what is the basis on which that tamper-proof property and claim ultimately rests?

It's using a different approach. What Amazon's doing there is running these containers in an insecure environment but verifying that the software inside the container doesn't do anything naughty. So they're pre-validating the software to make sure it doesn't do anything naughty and then only running it if so.

On the Internet Computer, you can upload anything you like, and you won't be able to break out of the environment and affect the network and other software that's hosted there. The easiest way of understanding it is to ask: What's a virtual execution environment? When you use your web browser to look at a website, that website has a whole bunch of JavaScript, but there's no way the JavaScript can break out of the web page you're looking at and get onto your machine. It lives in a sandbox.

All of the serverless code on the Internet Computer also lives in this giant virtual execution environment, which is a kind of sandbox. Then the Internet Computer is replicating computing data across nodes using a mathematical protocol that protects it against what we call Byzantine faults on individual nodes—even if some of these nodes fall under the control of Dr. Evil, if you like, and Dr. Evil can arbitrarily modify the data, change or subvert the protocol in any way they see fit, and so on. They still can't prevent the cloud from functioning completely correctly.

If you had software running on the Internet Computer—for example, an e-commerce website—and some of the underlying hardware that creates the Internet Computer became compromised and fell under the control of Dr. Evil, Dr. Evil still couldn't subvert the functioning of your e-commerce website. In a sort of next-generation e-commerce website where you've been accepting crypto payments as well as credit card payments, and you've got a whole stash of crypto inside the administration console of your e-commerce website, Dr. Evil can't steal it.

He can't interrupt the correct functioning of your website. He can't change its logic and behavior. He can't corrupt the data. He can't steal digital assets that are inside of it.

This is made possible by a sort of branch of computing called Byzantine fault-tolerant distributed computing. Byzantine just means arbitrary fault. So once you have a protocol with this property, it can withstand arbitrary faults. An arbitrary fault just means, basically, Dr. Evil can take control of some of the underlying hardware and do anything they like, and it still doesn't break the actual platform.

And that's why it's possible to run the platform over semi-trusted parties. The tamper-proof property derives from that math. For the average user, whether that's consumer or enterprise, all they know is that they've created this app that's on the Internet Computer, and they don't need a security team to protect it. You don't need a firewall. You don't need anti-malware, et cetera.

And you don't need a systems administration team either. It's guaranteed to run. Now, the logic of the app could be bad. There's nothing that the Internet Computer can do about that. But the Internet Computer can guarantee that your app's written logic will run, and only your app's written logic will run, and it will run against your app's correct data, and the modifications of that data will be correct.

So let me understand this, or help me understand this, a little bit better. If I take Bitcoin, for example, as a point of comparison, there's Byzantine fault tolerance there too, right? If I want to take over the Bitcoin network, I need to get to greater than 50% control to basically reestablish a new consensus. If I can't do that, then I can't take it over, because the majority will continue to agree on consensus and everybody will ignore me.

Of course, that's famously based on proof of work. I believe that the process you're running is some variation on proof of stake, although I'm very far from a proof-of-stake expert. So correct me on that.

It's really dangerous to start with traditional blockchains and try to get to the Internet Computer, because there are so many differences. What is true is that I got into crypto through Bitcoin in 2013. I spent a lot of time trying to unpack Satoshi's reasoning and how the Bitcoin network functions, and I developed an alternative theoretical framework for understanding it. The work progressed from there.

The Internet Computer was under development for years before it was even released, and development continued in production. At this point, the actual protocol—the Internet Computer Protocol, or ICP—is many orders of magnitude more complicated and relies on mathematics.

One way of understanding the relationship between the Internet Computer and Bitcoin is that Bitcoin is a kind of special case of an early cloud created by a network, where the logic of the Bitcoin ledger is hardcoded. It's autonomous, and you can create the same kind of autonomous logic on the Internet Computer if you want.

Bitcoin is a kind of decentralized compute platform. It's tamper-proof and unstoppable, but nonetheless, it's just software that's hardcoded into the Bitcoin cloud, if you like. When people make transactions and create unspent transaction outputs and things like that, you can configure Bitcoin scripts, so you can run custom logic on Bitcoin too.

The Internet Computer is a very long way from early networks like Ethereum. Similarly, it's a big misunderstanding that traditional blockchains can be on-chain clouds. They can't. They're really just specialized token databases, and the best way to understand them is to think about them like that.

A transaction is like a signed bit of SQL that you're sending to the token database. Some are specialized to process much higher transaction throughputs, like Solana, and it does that very successfully. But when someone says something's built on Solana, that's slightly misleading language. It's not built on Solana; it's built on probably Amazon Web Services and then just has a token on Solana.

They're just token databases. The Internet Computer is a whole different thing. It's a network that's designed to produce a new kind of cloud environment that hosts a new kind of serverless software, and that is what turns out to be very much ideal for AI to build on.

How would you describe it? Maybe the other way to come at it would be to sketch out a Pareto frontier. Bitcoin is at one extreme, where we're relying in the most fundamental way on math, right? You had to do this difficult computation that was hard to do and easy to verify, and that's where the security ultimately rests, but you're so limited in what you can do.

On the other end, you've got commercial clouds, where you can scale anything out and do whatever you want almost without limit. But you're beholden to the cloud provider to continue to serve your business, and you've got know-your-customer constraints and things that people don't always want to subject themselves to.

It seems like you're aiming to be as close as possible to a commercial cloud in terms of scalability—how much compute, how much data storage, and all these sorts of things. Yet obviously, you've got to do that in a way where the ratio of overhead to the complexity of the app on Bitcoin is extreme, while the ratio of overhead to the complexity of the app on AWS is relatively minimal.

How should we think about the ratio of the sort of infrastructure overhead to the complexity and scalability of what you can do on the Internet Computer? Sketch out that curve, and then maybe tell me how you got past Ethereum and to the point where you're at.

Web3 is a difficult starting point for understanding the Internet Computer, because a lot of Web3 is really about narratives. The token is the product, and sometimes the technology isn't all that sophisticated.

Thinking about Byzantine fault-tolerance protocols and so on, in the end, they derive their security by replicating compute and data across independent parties. But frankly, a lot of it is like when you hear, “Ethereum is secure because we replicate our data and compute a million times.” Is that really necessary? How much extra security and resilience do you get by doing that? The reality is, not much beyond a point.

The Internet Computer uses something called deterministic decentralization. All of the people called node providers that run this special node hardware register themselves. They do a kind of KYC in public, and the network combines nodes from different node providers.

If you're creating a subnet, which is like a mini-blockchain that integrates with many other blockchains to create one environment, the other nodes in the subnet can't all be run by the same company. If they were, the math wouldn't work. The company could do what it liked.

So first of all, it makes sure that the node providers are different. It makes sure that the nodes run in different data centers, different physical data centers. By default, it makes sure that those data centers are in different geographies, and it makes sure that those data centers are in different jurisdictions. That's a process called deterministic decentralization.

It's very different from what traditional blockchains do. We used to have lots and lots of anonymous validators, most of which run on the cloud, and nobody knows who runs them. Oftentimes, you'll look at a blockchain like Ethereum, and they'll say, “Well, we've got 500,000 validators that all replicate the same compute and data,” which, of course, is hideously inefficient. “And this makes it very secure.”

You can't say that until you realize that large numbers of these validators—and obviously the voting power is related to the stake in that model—are, behind the scenes, run by the same whales. You just can't see that because they're anonymous.

Bitcoin's great. You've got these mining pools that pool mining power. It's possible for two or three of these mining pools—possibly only two of them—to collaborate to break the whole network.

By comparison, the Internet Computer takes a much more nuanced approach, creating these subnets by combining nodes. It looks at the node provider, the data center where the machinery is installed, the geography where the data center exists, and the jurisdiction. By doing that, it's able to create security and resilience with much less replication.

Furthermore, it recognizes that all security exists on a cost curve. If you've got a subnet within the overall network, like the Internet Computer, subnets are transparent within the overall network. That's how it scales: by creating subnets.

If you've got a subnet that's, for example, custodying hundreds of millions of dollars' worth of Bitcoin, you probably want to have more nodes than if you have a subnet that's just hosting basic business apps.

Currently, all the sovereign hardware in the Internet Computer network runs the protocol within a TEE—a trusted execution environment. It actually uses SEV-SNP, which is an AMD technology. So even if the node provider were to open their node machines, they would just find encrypted bytes.

That'll be a bit different when there's a new thing called cloud engines coming. People will be able to run them over big tech clouds, but the market will decide what people want.

At the moment, though, it's just sovereign hardware, and everything is running inside a TEE. So the point is, when you get down to it, it's just a different way of looking at the world. In the end, networks like Bitcoin, Ethereum, and Solana are all about the token. It's all about tokenization. The product is the token, and all they're aiming to do is create DeFi, memecoin, and NFT platforms, that kind of thing, where lots of trading of these digital assets takes place.

Circling back to Caffeine, people are building on the Internet Computer because that's a way to get great results. I'd say 98% or more of Caffeine users are completely unaware that Caffeine is creating their apps on a network. They're probably happy that their app is secure and resilient and so on, but they're unaware that they're building on the Internet Computer. They're using Caffeine because it delivers utility to them. There's no speculative dimension and no token involved. They're just doing it because the wish machine grants their wishes and creates and updates their wonderful apps. Those apps are secure, updates don't lose data, and things like that.

So when we think about the target market for the Internet Computer now, we're very much looking at the mass market, whereas Bitcoin, Ethereum, and Solana are targeting participants in the Web3 market who are interested in token speculation.

It's interesting that you say most people don't even know, because I was going to ask: It still intuitively feels like there would be more replication overhead with a structure like this versus a commercial cloud. When I think about why I trust Amazon, they're going to do a good job, and they hopefully have good systems in place to not have things blow up and also not have people sabotage their own systems. But one problem they don't have is that no region of AWS is going to decide, "You know what, I'm out." Whereas it seems like with the structure that you have with the Internet Computer, your node providers are all free to go at any time, right? Or at least roughly speaking.

So if I'm running an app on the system, how do I know? You have to replicate my data across multiple node providers at a minimum, right? Then I would start to ask paranoid questions like, "Okay, sure, one of those node providers goes away—I'm fine. What if 2 go away? How many times am I replicated? What if 3 go away? How many can go away before I start to have problems, and does that create overhead relative to AWS?"

Again, it just doesn't work like a normal blockchain. If you're a node provider, it's not proof of stake. To participate, you first of all register with the network's governance system, called the Network Nervous System, which is fully autonomous. That actually administers and orchestrates the entire network. So it's like ICANN for the Internet, but it's fully autonomous and a very sophisticated thing.

You register, get a node provider ID, and then you have to get these node machines. Typically, you just get them built to order, because there are various people that will build them to what's known as the current spec, which is Gen 2. Then you'll install those node machines in a data center or data centers. You'll have to register those node machines, and they go into the pool of the network and so on.

Once you're allowed to add nodes, because obviously the network wants to manage the available capacity—there's no point having 1 million nodes if they're not being used—the network will pay you in constant fiat terms. You'll get money that covers your hosting cost, capital depreciation, and so on, with room for a multiplier that gives you a profit. There'd be no reason for you just to switch it off, because it would be profitable, and you're not subject to the volatility of a token price or anything like that. You're just getting paid in constant terms.

There's no reason why you would switch your nodes off. It would be pointless. If you were going to do that, you could decommission them. Anyway, the network is fault-tolerant. If somebody did just arbitrarily turn their nodes off, the network is organized in such a way that this would have no negative effect on it whatsoever. The Network Nervous System, which orchestrates the network, would just assign one of the spare nodes from the pool to the subnet that has a space.

Simple as that. That new node would catch up with the subnet and become an active node. In practice, this isn't something that could happen because of the way it's designed, so you don't have to worry about that when you're building on the Internet Computer. The Internet Computer has never had any downtime. Nobody building on it has ever been hacked through some kind of traditional cybersecurity hack. It's extremely reliable.

Now, the other interesting point you raised is: Doesn't this replication cost a lot of money? What I can tell you is that I believe this architecture is actually much more efficient than traditional tech with respect to replication. The Internet Computer uses the replication of compute and data in an intelligent way to derive properties like making the platform and hosted apps tamper-proof, unstoppable, autonomous, and things like that.

It's a mixture: Each subnet is a symmetric cluster, if you like, which is fault-tolerant, but you're also creating something that looks like a centralized compute platform that runs entirely on the edge. One of the new technologies coming is called cloud engines, which enables people to create their own subnet. Under the auspices of the Network Nervous System, you can select nodes wherever you like, as long as the rules of deterministic decentralization remain in force.

For example, you could say, "A lot of our user base is in Asia, so I'm going to add more nodes in Asia." That means users can gain access to this single, globally consistent state and compute results locally, getting very good performance.

Now, with respect to what this means for cost, traditional tech actually involves a huge amount of replication. Think about a database. If you want to make a database resilient, you're probably going to run a master-slave configuration. You've got a master, and you're going to have several slaves. Data is obviously replicated between the master and the slaves, and every slave has a complete copy of the data on the master.

That database will have an event log, and the event log will have a copy of the data from transactions that are taking place, including relevant data. There's an index file and a data file, and the index file replicates data that's in the data file. When you get down to it, there's a lot of replication in traditional tech.

The Internet Computer has variable replication, subject to deterministic decentralization, as I mentioned, and security is on a cost curve. I think for this year there's a major pivot into mainstream cloud computing. I think the magic replication number in that realm is going to be 7. These cloud engines will replicate compute and data 7 times. They may increase that for CDN-like purposes, to scale queries and things like that, but I think the default for most enterprise systems will be 7.

I think that compares very favorably to traditional tech. The difference is that traditional tech does all this replication in a very ad hoc way that doesn't provide any sort of synergistic benefits.

The Internet Computer does replication in a way that gives you these properties of being tamperproof and unstoppable, and so on. Those things are very valuable, and these systems can coexist side by side. I think one of the other things that's coming this year is that the Internet Computer will run over big tech clouds, and I think you'll see that big tech clouds promote these things called cloud engines. For example, you'll be able to, if that's what you want to do, run on Amazon in a serverless way but be immune to Amazon Web Services data-center failures.

For example, I think in the last outage, 2 Amazon data centers failed. But if you had a cloud engine replicated where the underlying nodes were running in 7 different Amazon data centers, you would continue running without a hitch when Amazon had that last outage. I think we're going to see a lot of demand for that this year. The additional benefit is that environment is exactly what you need when you've got agentic AI basically playing the role of a fully automated tech team.

The whole thing with self-writing software is you just tell the AI what you need. You instruct it. It's a wish machine. You can instruct it in natural language over chat, upload requirements documents, and so on, and it just says, “Here you are. I've created it for you. Here's a URL.” You can start using that and put data into the app, but you can continue updating it safely in production.

You can tell the AI, “Hey, please change the way this works or add that feature,” and it'll just say, “Refresh the URL,” and there will be the changes you asked for. That iterative process of improving what you've got in production is safe. You get a guarantee from the platform that upgrades and the schema migrations involved will never cause data loss.

If we look at Caffeine, there's a whole lot of other technologies. There's a language called Motoko, which is the first language ever developed specifically for use by AI, and it does a lot of cool things. It increases abstraction in a way that fuels the modeling power of AI. It has this thing called orthogonal persistence, where the program is the database itself.

In a traditional tech stack, you've got the program and you've got the database, right? Your logic is constantly marshalling data in and out of a database. On the Internet Computer, it's almost like your code runs in persistent memory, if that makes sense. If you go to Caffeine and build an app and then look at the backend .mo files, you'll notice there's no database involved. There are no files involved. It's just pure programming abstractions, and the data lives in the logic.

This is actually a huge advance and one of the key purposes of the Internet Computer. That functionality, which turns out to fuel the modeling power of AI, is something we've leaned into at Caffeine. Basically, Motoko ended up moving into Caffeine, and then the Motoko language team and Caffeine's AI team work hand in glove together. It's a very close collaboration, and they're constantly improving the language, making it better for the purpose, and then retraining the AI agent that writes the back end.

So I understand that the relationship between the node providers and the network as a whole is a relatively straightforward commercial one: They provide resources and get paid to provide resources.

And they don't have proof of stake or anything too wonky. By the way, it's simple: These node providers have to buy these machines. Gen 2 machines are expensive. They cost about $20,000, actually maybe even more now because the price of memory is going up thanks to the AI boom.

They typically sign up for hosting relationships with data centers. They rent racks and so on. If they're not performing for some reason, the network slashes them. The network is monitoring the performance of all the nodes, and if it finds nodes that, for example, are falling behind or are offline or not functioning properly, it can actually knock them off the network.

Is there anything that we should know about the requirements of those nodes that is particularly consequentially different from standard computers that I might go buy or rent?

No, totally. For example, in the early days of Google, and still now, they quickly realized that they get better performance and better bang for their buck if they design their own servers. The Internet Computer takes the same approach.

There's no need, for example, if you spec a server machine—typically, in normal enterprise usage, it'll have something called a RAID array. You have an array of disks; you can see the lights flashing on the front of a blade server, right? The reason you use a RAID array is that if one of the disks fails, because the data has been replicated across the different disks, it keeps working. Your storage system keeps working.

If you think about the Internet Computer, though, that's not needed because the network is designed specifically so that if a node fails or nodes fail, the network keeps running, and all of the apps that it hosts keep running without a hitch. For example, Internet Computer node machines don't need to have a RAID array. You can even get away with a second redundant power supply, because the redundancies are in the network.

However, there's a focus on memory. They have a lot of memory, and some of it is nonvolatile RAM and things like that. Gen 2 node machines are designed specifically for the purpose. Also remember that you can only combine nodes in a subnet that have the same specification; otherwise, some might fall behind.

Subnets are essentially symmetric clusters for compute, and it's important that all of the participants in that symmetric compute have the same hardware specs. The way that's been solved is that people have proposed node-machine specifications to the Network Nervous System, and then node providers just build to that spec. They overindex on some expensive things like nonvolatile RAM and otherwise do without reliability features like RAID arrays and backup power adapters. That's how it's worked so far.

But the big change coming in 2026 is that people will be able to create their own node specifications and group together in associations. More people will be able to create a cloud engine and actually go and sell that to enterprises themselves. That cloud engine will use their node-provider associations' nodes, and that's why they'll be able to define their own node-machine specifications.

Indeed, it'll be possible to create these cloud engines that run over big tech clouds. Instead of using sovereign hardware, as it's all done today, this year you're going to see the Internet Computer running over big tech clouds too—cloud on cloud. We think it's going to be hugely popular because people will be able to say, for example, “You're a longtime Amazon customer. You probably want to continue feeling that Amazon's providing your compute capacity.”

You'll be able to create a cloud engine over Amazon's different data centers, and now you'll be able to create apps from this superproductive serverless code that is tamperproof. You don't need traditional cybersecurity protections. It's immune to traditional cybersecurity attacks. It's unstoppable. It's guaranteed to run, and there's no back door.

The autonomy means, in the scope of enterprise systems, that because there's no back door, you can use some kind of governance system so that responsibility for upgrading your app, for example, is split amongst multiple people. It's of course Web3-native, so if you want to process tokens on any other blockchain, you can. I think in the future people are going to use these things to create e-commerce websites that can not only accept credit-card payments but also stablecoins and things like that.

I think that's going to prove to be really popular.

That helps me understand how I don't have to worry about nodes going away on me too much. But then it seems—and I know the word “trust” is so overloaded in these contexts—that if I'm somebody who wants to deploy an app on the Internet Computer, I ultimately have to put a lot of trust in the Network Nervous System. So you said that is—what's that?

No. Sure. That's right. The Network Nervous System, if it wanted to, could push upgrades to the ICP protocol that caused every node to delete its own data—all the data on the Internet Computer—and disappear in a puff of smoke.

So how is that secured? You said that it's autonomous. Now we get into the decentralized part. There's got to be some sort of consensus mechanism, or something that undergirds that, so that I know it's going to do what it's supposed to do.

Firstly, autonomy, I think, is also going to be a big thing outside of the Web3 ecosystem, within the enterprise realm. It allows you to divide responsibility between multiple parties. If you think about enterprise hacks, oftentimes they're caused by an insider. You get a disgruntled employee who posts a username and password on the 4chan forum, something like that, right?

Autonomy within the enterprise realm allows you to prevent that kind of thing from happening because you have code that cannot be directly controlled by an individual. There's no back door. Only a governance system that splits responsibility amongst multiple parties could be used to update the software.

The Internet Computer network is, if you like, administered, upgraded, orchestrated, and governed in various other ways too by this thing called the Network Nervous System.

Essentially, it plays a role that's a bit like the ICANN of the Internet Computer. But ICANN, of course, is an organization—it's a centralized entity. The Internet Computer is able, because the Internet exists, to run this overlay network. It can go further, and the Network Nervous System is a very sophisticated thing. It's designed in such a way that it can decide on proposals that are submitted to it in a secure way.

I think by now—it's, I don't know, you have to go there, go to dashboard.incomputer.org, and go to the proposals page. In the last 4½ years since the network's been running, it's processed thousands and thousands of proposals. What I can tell you is that it's never, ever adopted a bad proposal.

And that's important because those proposals are actually executed by the network, many times completely automatically. For example, if you propose an upgrade to the ICP protocol with an accompanying binary that would be run on these nodes, if that proposal is adopted, all of the nodes will upgrade their logic using this binary. In practice, it would be impossible for an attacker to overcome this. Typically, what happens is that first there's a proposal that blesses the binary, and then, once the binary is blessed, there are other proposals that upgrade the nodes subnet by subnet, and so on.

But truth be told, there are many expert eyes—many different groups of experts who hold a lot of voting power—looking at these things carefully before voting. It's a kind of liquid democracy system. A lot of people follow the experts in the space, and it has a lot of clever features, like something called “Wait for Quiet.”

This was all proposed back in late 2016 and early 2017, based on learnings from a thing called The DAO, which was a DAO that got hacked on Ethereum. Wait for Quiet basically means that if you've got voting on a proposal, it might be adopting the proposal or it might be rejecting the proposal, but if the leader changes, then the amount of time for voting is extended.

There's a whole bunch of these kinds of mechanisms that essentially make it overwhelmingly unlikely that the Internet Computer's Network Nervous System would adopt a technical proposal that would harm the network and be automatically executed. Indeed, that's never happened or even come close to happening. It's a public governance system—you can participate in Network Nervous System governance too.

The fact that it's completely open, and yet it has this property that it's overwhelmingly unlikely to adopt a destructive proposal, is extraordinary.

And this is where the more complicated incentive system sits, right? What I understand from your answer is that we have human security and computing-network experts who are also invested in the token mechanism that's used to determine the voting structure for how updates to the system get made. Their incentives are obviously to keep the thing valuable because they're invested, and it's in virtue of being invested that they're both incentivized to keep it working and have the voting power in the first place.

Actually, in excess of 75% currently of the ICP tokens that are staked inside the Network Nervous System are locked for 8 years. They're locked for 8 years. People can get rewards by locking up tokens in the governance system, but the rewards increase in scale as you lock them up for longer.

Because of the time frames people are locking these tokens up for, they think in a very long-term way. If your tokens are locked up for 8 years and enough of you end up voting for a stupid proposal that harms the network and devalues it, there's no way you can quickly get your tokens back and sell them to front-run the damage. You're locked up for 8 years. You've got to think in a very long-term way.

That kind of thing, combined with our algorithms that very deliberately create game-theoretic incentives to align people in the direction of voting for sensible things, basically means you need a lot of different independent parties to forget about their financial incentives and go insane for the Network Nervous System to adopt a destructive proposal. I think at the moment there's on the way to $1 billion or something locked up in that thing—a lot of capital at stake.

Yeah. And where does that run? Does that, in turn, run on nodes? Is it managing itself that way?

Yeah, totally. The Network Nervous System is just a sort of privileged software, if you like, that runs on top of the network. It actually runs on a special subnet. Remember, on the Internet Computer, it doesn't matter which subnet your software is hosted on—it can directly interact with other software. If I create some software and you create some software, if the permissions are allowing it, my software can call functions in your software.

So it genuinely creates this single, seamless universe for serverless software, but the individual units of software are running across different subnets that are transparent to them. The Network Nervous System runs on a special subnet, which has a large—I think it has about 50 nodes. So you're talking about 50 powerful machines run by 50 different node providers, in probably 50 different data centers and different geographies and jurisdictions. It's very hard to attack. It's a very robust thing, and it's very carefully managed.

If the Network Nervous System breaks, then the network can't upgrade itself anymore, because all of the upgrades and orchestration of the network are performed by the Network Nervous System. Of course, people are very careful when they propose updates to the Network Nervous System. But even if that happens, you can coordinate node providers to create a fix.

It actually happened just once, about a month or 3 weeks after the network launched in May 2021. The Network Nervous System actually did break. The way that was resolved was just by the foundation and other people getting online with node providers, coordinating action, and creating some software that they could run on their nodes to fix the problem. Then it was up and running again.

But that only happened once, at the beginning. It's run without a hitch for 4½ years.

I would get a little more practical on some of those details, because they're quite different and quite interesting, but I can't say I fully understand them. One comment that you had made earlier is that everybody listening to this feed is going to be familiar with vibe-coding experiences, so we don't need to explain the user experience. We can assume people are familiar with it.

But you had said that the inference that's doing the code generation is not happening on nodes, for reasons that I don't quite understand. So I'd like to understand that a little bit better. Then I also want to understand better why a new language. If anything, so far I would say the effects of AI on programming have been to narrow the range of languages people use, because it's a compounding-effects dynamic where JavaScript and Python have so much training data that they work better in those languages, and then you want to use them more, and of course there's even more training data the next time.

So you've gone quite a different direction there. I'm interested to hear how that decision was made, and also what implications that has had for the process of teaching a model to code in that language.

Yeah, it's a really good set of questions. Firstly, with respect to why Caffeine, there's obviously an ensemble of AI models inside Caffeine. Within the next few weeks, there's a massive upgrade coming to the Caffeine 2.0 engine, where that ensemble is becoming fully agentic. It's semi-agentic at the moment, but the fully agentic model is coming, and it's going to provide a huge leap in capability.

Within that ensemble, there are some models that certainly could be open-source models, which might be involved in things like planning and writing task specifications. But at the end of the day, the frontier models are just better—substantially better—at coding at the moment. We want to make sure that Caffeine delivers the best experience and is as capable at developing apps as it possibly can be. For that reason, we're using frontier models, although in the next Caffeine 2.0 engine, which is fully agentic, we do hope that some of the agents within that ensemble will actually be running on open-source models.

We can also run them on ASICs—for example, Cerebras or Groq—because you can obviously speed up inference by up to 20×, that kind of thing. In the end, Caffeine is just trying to provide the best experience possible. We want to be able to grant the most complex wishes possible, and we want those wishes to be implemented as fast as possible. We're just going to choose the models according to that rubric. Of course, fast means lower cost—fewer tokens.

You can run models on the Internet Computer. It's not designed for that, obviously, but you have to run models—the network has to be able to run these models in a deterministic way. Basically, you compile your model to WebAssembly, because that's the low-level format the Internet Computer runs. WebAssembly can work great with things like facial recognition.

So if you want tamper-proof, unstoppable facial recognition, you can do that. You probably only need 4 billion parameters or something like that.

When you’re talking about frontier models, you’re getting up into hundreds of billions of parameters or even 1 trillion-plus. So you couldn’t currently run that anyway on the Internet Computer right now, and it’s not what it’s designed to do. When that ensemble builds what you want, when it grants your wish, if you like, it’s using the Internet Computer to host your application. It’s targeting the Internet Computer.

Some advantages are obvious. So if you think about the tamper-proof property, if the AI was building your application for traditional tech—traditional tech is absolutely not tamper-proof, is it? It needs to be protected by cybersecurity measures. For example, to give you an idea of how complex that is, even the book Securing Linux is hundreds of pages long, right? Cybersecurity is a very complicated realm.

That means that if the AI is deploying to—building for—a traditional backend and it makes a mistake, then, even with a fully agentic model with testers and auditors in your ensemble, it’s still going to be able to make a mistake, and it’s still going to be able to hallucinate and so on. If the AI is deploying to traditional tech and it makes a mistake, that means you can end up with a cyber breach, and that’s obviously no good at all.

So how can you do self-writing if the AI can make a mistake and you get a cyber breach? The whole point of self-writing is that the entire tech team is automated, and that means you don’t have a security team. You don’t have a systems administration team. You need a guarantee that is tamper-proof. That’s what the Internet Computer provides you.

Similarly, it’s unstoppable. It’s guaranteed to run the software. It doesn’t protect you against errors in the software, but even if the software’s got errors, it will still be guaranteed to run.

Why develop a language for AI, especially given that AI has been pre-trained on God knows how many Rust and Node.js GitHub repos? The answer is that if you can maximize the abstraction of backend software, you fuel the modeling power of AI. It essentially means that this sort of ultimate layer of abstraction—it’s called orthogonal persistence, where you completely remove the complexity of persisting data from the backend—obviously avoids a whole class of errors and complexity in the first place.

There’s no database connection pool and no special logic to handle if there are 2 people sending an update at once, or the connection pool’s not working, or something like that. All of that goes away. It massively simplifies the backend and greatly increases abstraction, and that fuels the modeling power of AI. Not only does that mean that the AI is capable of creating more complicated and sophisticated backends, but it also means there are fewer tokens involved.

If you have fewer tokens, you’re spending less money—AI is expensive. You’re spending less money, and you’re also creating the code faster. With Caffeine 2.0 imminently coming out, you’re going to see yet more changes to the Motoko language. So if you go and look at your app in Caffeine at the moment, you’ll see that the actor—the overall app for the backend—is just in 1 giant file.

That will be split into many files, which means many agents can work on it in parallel, and you’re only modifying the little chunks of software that you need to, and things like that. Minimizing input tokens and output tokens is important, particularly output tokens. They’re about 10 times more expensive, I think, than input tokens. That is important for that reason: just enabling the AI to create more sophisticated backends at lower cost and quicker.

But there are also other reasons for it. When you upgrade a Motoko backend and the AI submits the upgraded Motoko backend, it also submits a sort of migration logic that explains how to transform the old data structures into the new data structures. The Motoko framework actually runs that logic, and it runs it like a sweep inside the garbage collector where the virtual memory resides. It makes sure every single piece of virtual memory has been touched and migrated.

Unless you’re explicitly dropping data, if you haven’t touched every bit of data in that migration logic, then that means some data is being accidentally lost. It rejects the update, and then the AI sees the update’s been rejected, understands why, and recodes it. That’s an example of these subtle benefits that I think enterprise is going to absolutely need if this thing’s going to fly.

It’s no good. It might be that you could have a fantastic wish machine that creates this great application for you. If you’re going to use that in production and put important data in there, you need a guarantee that when you keep on talking to the AI to upgrade and update what you’ve got, that process cannot result in data loss.

Imagine even the simple case. Let’s say you’re a business and you’re thinking, “I’m spending a lot of money on Salesforce, and I would like to have my own completely custom CRM and be able to update it on demand by talking to the AI.” So you create this thing, you put a whole lot of your super-important customer data in there, and it’s going great.

Then a month later, you think, “I want to change the way this works slightly and add this new feature,” and you talk to the AI. It does the upgrade. You refresh the URL, and bingo, your CRM’s been upgraded in the way you asked. You keep on using it, putting more data in for a month, and then you realize that some data’s gone missing.

What are you going to do? You’re screwed because it’s too late to roll back because you’ve added a whole lot of new data. So you can’t roll back, but you realize that in that upgrade you did a month ago, some data got lost. That’s a really pernicious problem that Caffeine solves by making sure that data can never be lost. There are guardrails. It’s like a firm guarantee.

I think a lot of these things, a lot of these requirements, are quite subtle, but in practice, enterprise isn’t going to be able to adopt things like the self-writing paradigm unless it’s given these guarantees. Having our own language—and it’s not just about making orthogonal persistence as seamless as possible and work as well as possible—it’s also about being able to add these kinds of rails behind the scenes, because it’s a domain-specific language that only works on the Internet Computer platform, and it leverages aspects of the platform to provide these safety rails.

So, on the one hand, it’s enabling AI to create more sophisticated, more complex backends with fewer tokens, which means faster and at a lower cost. On the other hand, it’s enabling us, in combination with the Internet Computer platform, to provide these hard guarantees, which we think enterprise absolutely needs if they’re going to adopt this en masse.

So, looking at Motoko code, what I tried to do—and I didn’t get quite as far as publishing an app—but I used Caffeine to create an app that is meant to tell you what varieties, or varietals, I should say, of various fruits are in the supermarket at any given time. Anyway, now I’m looking at the Motoko file. It looks a lot like JavaScript. How is it different?

And I guess, am I correct in understanding that basically you’re doing something like that? This reminds me of a benchmark about learning to speak a new language. I forget exactly what it’s called, but there’s a concept of learning to speak a new language just from 1 book, where they take a rare language and the benchmark is, how well can the AI translate texts into that language just based on this 1 manual? It’s presumably seen like nothing in its pretraining.

So it sounds like a similar kind of setup there, where you must have some big prompt that’s, “This is how this language differs from JavaScript. You can assume all the same things of JavaScript except for these core things.” Is that kind of how it works?

They are really good at linguistic synthesis. The reason they’re able to reason separately from chain-of-thought reasoning is essentially that word-embedded language contains concepts. Language carries concepts, and so it sees these kinds of conceptual patterns in word embeddings. Then, through doing this linguistic synthesis, it does something resembling reasoning. That’s without chain-of-thought reasoning.

There are patterns in programming-language design, and that means that AI can understand quite quickly because, you’re right, there are some similarities with things like JavaScript. I’ll come back to that. Actually, there’s no—there is, of course, a system prompt, but it’s a tiny thing. We actually just do fine-tuning currently.

There’s a big database of Motoko examples, and we use that to fine-tune the model that is writing Motoko. Of course, that’s a hassle because, like I mentioned, the Motoko language team and the AI team work hand in glove very closely together, and Motoko is constantly being upgraded and improved for purpose.

So every time we change, you have to change all the training data and do the fine-tuning again. I think that there’s a chance with a more agentic model and skills files and things like that, because Motoko, in some ways, is like—pretty much any programmer can look at Motoko and quickly get to grips with it, and that’s by design.

It’s a fantastic platform, and on the one hand, Motoko is delivering this orthogonal-persistence paradigm where it just looks like your code runs forever in persistent memory and your data just lives in your variables, your data structures, your collections, and things like that. So it’s just pure abstraction.

On the other hand, it’s like a DSL, and that’s how it’s able to provide systems but also other things.

It's designed for the Internet Computer environment. On the other hand, it's designed to exploit some of the advantages of WebAssembly, and it's very much focused on force-multiplying AI that's coding backends. But it's designed from inception to be something that anyone who's done a bit of programming can really quickly get to grips with, to provide an easy on-ramp. So when I'm looking at a Motoko file here and I've got my type Fruit, module Fruit, and so on, those things are—as far as the application-layer coding goes—as deep as I need to go to define the back end. Everything else is handled under the hood; it's pure abstraction.

You store data in your collections, a map, for example, or something like that, like a map collection. There's no need to store it in files or databases. It's almost as if your back end is running in persistent memory—which it is, actually—and so there's no chance that your memory is going to get wiped. The Internet Computer doesn't crash and reboot.

If you think about how traditional software works, let's say you've got a back-end server running on a traditional tech stack. You could try and do something akin to orthogonal persistence and keep all your data in the variables and data collections and so on, but the trouble is, if that server crashes, all the data is going to be lost. It's going to disappear. Or if somebody reboots the machine, all the data is going to be lost. So what you do is typically marshal the data in and out of a database.

With a traditional tech stack, you've got a program and a database, and they're separate things. The program, sure, has local copies of data in its variables and so on, but essentially whenever it updates the data, it has to copy it into a database for safekeeping. The database writes it to disk, and so it's marshalling it into the database by a connection pool or something like that. Then, when it needs data, it's pulling it from the database with a query and demarshalling it, doing something with it.

That's actually the source of a lot of complexity and boilerplate. It's boilerplate because you've got a connection pool and things like that, and all the associated code has to maintain that, but it's also complexity because you have things like 2 different web pages sending updates to the database, and there's a race condition involved and things like that. All of that is dealt with for you; all of that goes away in this framework. Updates happen according to the actor model: there's only 1 thread within each actor that's actually updating data at any moment. Memory is updated by transactions, and if there's an unexpected exception, any changes that have been made to memory are rolled back.

It's creating this highly abstract environment, with other things like transactional memory updates, that massively simplify back-end logic. The program and database are one now. Normally, the program and database are different things; now the program is the database.

In fact, one of the cool features that's coming is a data explorer. This will help, I think, people used to coding on traditional stacks a lot because, with a database, you can open a database administrator and browse the tables, and there's a box up the top where you can enter some SQL and press play and it'll run the query. Basically, you're going to get something very similar for your canister—for a Motoko canister—where you can press a data explorer button in your control panel, and it will show you your data graph, which has been created by your programming abstractions. You'll be able to browse that data graph, and you're going to be able to put an OQL, or Object Query Language, query in, which could be very simple. It could just be like a field path that filters that graph and shows you the data listed.

That, I think, with that feature that hopefully we'll have in the next few weeks, it'll become clear to people: now the program is the database. This is a huge advance, actually. I think once we've got to that place, we're going to really start going to hackathons and places like that and try to get people excited about orthogonal persistence, because it's a huge inventive leap in itself and it provides obvious advantages. The challenge, of course, is explaining how it works because, on the one hand, it provides this huge—enables huge simplification of software, back-end software—but the actual computer science that makes it possible is quite complicated.

But the data explorer button is definitely going to help people be able to press the data explorer button, see the graph of data inside their program, browse that graph, enter queries to narrow the data that they're looking at, and interact with their app via the web interface, say. They'll be able to look in the data explorer and see that data on the graph getting updated. I think that's going to help people with the aha moment: wow, this is actually something completely revolutionary. Previously, we had a program and a database, and now we just have the program is the database.

Also, if you're wondering about efficiency, does it improve efficiency? Yes, enormously, because you get rid of the need to marshal data in and out of a database. The data exists essentially in symmetrically replicated compute nodes. Your logic only needs to directly interact with the data in memory. It's no longer necessary to take that data in memory and marshal it across a connection to a database or marshal it back. That's gone. It's way more efficient.

Is it right to think of the whole thing—the whole back end—as a distributed Memcached kind of structure, or like a Redis? I'm gathering it is primarily in memory, and disk plays much less of a role.

It's like the program is the database. Now the program is the database, and there are massive advantages to that. The reason people haven't done it before is actually that it's really difficult. There are a lot of things you have to have in place to make this work. You can think, for example, of creating a P2P platform that doesn't reboot because it's a virtual execution environment inside a network protocol that's presenting fault tolerance. These are nontrivial things.

Then you can build on that to create an orthogonally persistent system, and that's what I actually set out to do in 2015. I really got going with it in 2016, raising money in February 2017 and raising more money in 2018. It was a huge job, and orthogonal persistence today is really in a very nice state. It's pretty complete; the implementation is pretty complete. We started developing Motoko in 2018, and there were many debates about how orthogonal persistence should work and how it can be realized, and it took a long time. It was a nontrivial thing.

DFINITY really ran in the mode of a research institute for many years, which had advantages and disadvantages. I think it meant we were able to make a lot of incredible technical achievements, but we didn't really productize what we were creating. Now DFINITY is changing mode very rapidly into what we call DFINITY 2.0, which is becoming more of a tech venture again and is now focusing very heavily on productization. Caffeine, as a spinout venture that's part of that effort, basically connects the Internet Computer to the mass market via AI.

It's a huge opportunity for the Internet Computer because adoption is very much gated by network effects and tech. If you're just talking to a traditional end developer and persuading them to stop developing on the traditional tech stack and start building on the Internet Computer, it's a tough job, because the developer is going to say, "I spent the last 10 years learning Amazon Web Services, Node.js, and Postgres, and I don't want to have to learn something else now." There's a huge competitive moat around traditional tech that's extremely—would be extremely difficult for the Internet Computer to overcome, despite its manifest achievements.

AI is completely changing that calculus because, whereas in the future the owner of an application would talk to a tech team and say, "I want you to build me this," and then the tech team would go away and say, "Yeah, we're going to do this for you. It's going to take this long. It's going to cost you this much, and we can do it on Amazon Web Services with Node and Postgres or whatever it is," and then we all know how that works out and the frustrations involved, so on and so forth—in the future, ever increasingly so, as AI advances and the platforms AI uses to build advance, the ultimate owner of these applications—enterprise application, e-commerce website, social media, whatever it is—isn't going to talk to a tech team or hire one, whether that's in-house or an agency.

They're going to talk to the AI, and the AI is going to be a wish machine. They're going to literally tell the AI directly what it is they want, and the AI is going to give it to them. When they need to update it, they're going to tell the AI how they want to update it, change it, add features to it, whatever, and the AI is going to be a wish machine again and just update that app on the URL. That's going to liberate them from the difficulty of dealing with a team of engineers. It's going to give them extraordinary cost savings, extraordinary time savings, and make them themselves essentially become the developers.

How are they going to decide which self-writing platform they want to build on? They're going to care: can the AI grant my wish? Is this wish machine going to deliver what I'm asking for? Is this app—this app looks great, it's functionally correct, but is it secure? Because I haven't got a security team.

They're going to care about that. They're going to care: Is it resilient? I haven't got an administration team. They're going to care: Is there a chance I'm using this thing that I wished for and you gave me in production, and then I make an update later on and somehow some of my data goes missing? Those are the criteria they're going to care about.

So all of a sudden, that moat that protects both traditional tech stacks and SaaS services is dissolving, and I think it's going to be extraordinarily disruptive. That change is going to be extraordinarily disruptive because, all of a sudden, these self-writing cloud platforms are going to be able to eat not only into the foundation or platform layer of the cloud market, but also into the SaaS layer.

Cloud was a $1 trillion revenue industry last year, in '25. I think $400 billion of that is the platform layer; $140 billion is Amazon Web Services. The rest is SaaS and AI and stuff like that. Self-writing cloud addresses the entire pie, and that pie is predicted to grow to $2 trillion by 2030.

What's so exciting is that, all of a sudden, the customer is changing. Previously, the ultimate customer was the person who was commissioning the developer or hiring the developer to build their app or service, but it was the developer who chose the stack. The developer would choose the cloud and the platform components they used to assemble what had been requested: web servers, databases, and all that stuff.

In the future, the person choosing the stack changes. Now it's the ultimate owner of the app or service, and they're choosing according to different criteria. They want to know: Can the AI grant my wish? Is it secure? Is it resilient? Is there any chance the AI could make a mistake and cause my data to be lost?

So all of a sudden, those network effects that create a moat around traditional tech are dissolving. Of course, AI is getting smarter and smarter all the time. That's not going to stop.

The frameworks within which the AI works are getting better and better. For example, you can see a huge leap when you put large language models in an agentic framework versus just giving them a project, where the entire project is input context and they create some output files. The moment you break work down and create an ensemble where you've got a planner, task managers, unit-test writers, backend coders, frontend coders, and so on, you just see these huge leaps in ability. That's going to make them get smarter.

Of course, in the case of Caffeine, not only are you benefiting from improvements in the models themselves and in the agentic framework, but in the next few weeks, Caffeine 2.0—a new engine—is coming out, which is fully agentic. There's also the backend framework: How can you design that backend framework to force-multiply that agentic ensemble?

First of all, you want to provide guardrails so mistakes can't lose data, for example, during updates. But you also want to fuel the modeling power of the AI by creating greater abstraction and simplifying backend logic, so fewer tokens are involved and the ensemble can create the code faster and at less cost.

When you put all that together, this train's moving pretty quickly. Caffeine's got an enormous way to go, and if you look at Caffeine in a few weeks, you'll see that it's taken another giant leap. I think we first demonstrated it on the 3rd of June last year. If you compare Caffeine then to now, you can see there's been huge progress, and probably that progress will double in the next few weeks. I don't think that's going to stop.

Automated tech teams are just going to get better and better. As far as self-writing cloud is concerned, when you've got a fully automated tech team building on a platform that's specialized for AI, it's just going to keep getting more capable. The scope of what you can do will just keep expanding.

Eventually, we're going to get to a place where people are going to say, "Maybe I don't need this SaaS service. Maybe I don't need Salesforce consultants and things like that. I'm just going to talk to the AI, and it's going to create stuff for me on demand. It's going to grant my wishes." That's going to be disruptive.

Also, I should mention that we've got a product under development called Caffeine Snorkel. It won't be out for a long time because we've got other priorities, but you basically install Caffeine Snorkel on your laptop, and this means that Caffeine in the web browser can inspect things on your local network behind the firewall.

So if you're a company with a bunch of legacy systems, it can inspect the database, look at the metadata, and use that information to create a new replacement system and even migrate data for you. In the future, people are going to be able to use platforms like Caffeine to replace their legacy infrastructure.

There are just millions of companies across the world that are locked into legacy infrastructure and are desperate to escape. They just don't have the money or the time to migrate off it. But AI is going to solve that problem.

I can't tell you if that's going to be this year or next year, but it's soon. It's not in some distant future; it's near-term. I've done a lot of things in tech in my time, but I have spent time in the enterprise software space, and I have seen how many corporations, by now—it's even worse in small businesses—get stuck on legacy infrastructure that they hate.

It doesn't work properly, but their data is inside it, and it's just too expensive and too difficult for them to migrate off. They're desperate to escape; they'd love to. Self-writing is going to provide them with the solution because the self-writing platform will be able to look at the legacy infrastructure, literally create its replacement, and migrate the data.

There'll probably be a bit of human help needed, but whereas it's practically impossible now, it'll become eminently doable. People will, I think, jump at the chance.

Yeah, it's crazy how fast that's happening. I've got the apps vibe-coded for Christmas presents for my family members already, too.

By the way, the other thing there—you talk about apps for managing Christmas presents and stuff—is that this paradigm is going to create new paradigms and new online functionality. For example, one of the things I think we're going to see is hyperlocal social media becoming a big thing at some point.

People are still going to use these public social media platforms like Instagram and TikTok because they have their own unique advantages, and they're kind of global social spaces. But in addition to that, we're going to see a new kind of social media layer that's hyperlocal.

For example, people might create their own social network for their family, their extended family, their friend group, or their community. These social networks will obviously be free of advertising and free of predators and things like that, which might be attractive to families with young kids, but they'll also have features that you don't get in public social networks.

A family might say, "We've got an elderly grandparent who's lonely. Let's create a roster to make sure that at least one grandchild goes around and visits them once a week." If you have a photo gallery, you can do things that you can't do in a public social network.

You can imagine that there'll be a feature that allows overlay emoji reactions. Let's say there's a video in the gallery of the father dad-dancing when he's drunk at a barbecue. Maybe the daughter sticks some crazy emoji reaction right over the top of it. Obviously, you couldn't do that on Instagram. You couldn't have people stick emoji reactions over your pictures, but in a hyperlocal social network, you can.

These things will get built out, and people will develop different modules through platforms like Caffeine. Something that's coming with Caffeine is an app marketplace, and anybody's going to be able to publish the stuff they create there.

You'll be able to pull not just application templates to start remixing, but modules. People will create these social networks from a mixture of modules and things they create from scratch. They'll also be able to integrate networks with other networks and things like that.

We're going to get this new hyperlocal social media layer that services families, friend groups, and communities. That's a completely new paradigm. For example, it could be a 15-year-old kid or someone even younger who creates a hyperlocal social network for their family or extended family.

Obviously, they're not capable of programming themselves. They're not programmers, developers, or systems administrators. Without self-writing, that would be impossible.

We're going to see a lot of changes. We're going to see new things emerge. We're also going to see self-writing really catalyze the business environment because not only will people be able to get internal tools that they really need but that would otherwise be too expensive to create, they're also going to be able to migrate and fix their legacy IT infrastructure that's causing them problems.

In the developing world, there's a huge shortage of IT infrastructure. There's a shortage of the developers needed to create the stuff, and even when they can build the stuff, they don't have the security people to keep it secure.

Was it last year? I'm losing track. In Indonesia, 300 different government systems got hacked in one...

Did you see the story from Korea in the last month or two? There was a fire at a data center, and a massive amount of government data was lost.

As far as I know, I don't know if there's been an update to the story or if they found another copy somewhere, but it was massive data loss due to a failure to replicate, basically at the nation-state level of South Korea. Pretty crazy.

In the past, I've seen so many of those kinds of things. For example, you'll have a really large company with a really important system running out of a data center, and one of the services that data center offers is backup. But what they don't realize is that the backup is being made onto a tape machine inside the data center. So if you have a fire, your backup disappears. I've seen that happen several times.

Circling back to the Internet Computer and what inspired it, that was the kind of thing that mattered to me because I spent so much of my life in the tech industry. I mean, I've been coding from a young age and solving these kinds of problems, and to me that's very important.

I think there are 8 billion people on the planet today, and the truth is, if there wasn't this huge degree of computerization, that population could not be supported and kept alive. Computers need to run these extraordinarily efficient supply chains and things like that to keep global civilization running.

It seems to me, therefore, that computers become this indispensable foundation of global society, and therefore this foundation needs to be indestructible, effectively. It has to continue running even in the event of a nuclear war. Ideally, the Internet Computer was designed to withstand a nuclear strike.

With Cloud Engines, you can basically create your own subnet under the auspices of the Network Nervous System. It'll let you combine different nodes, subject to rules, such as the nodes still having to be operated by different node providers, and so on.

For example, you could create a GDPR-compliant subnet in Europe and distribute the nodes across Europe. You could create a Swiss Cloud Engine where the nodes are all in Switzerland, and stuff like that. But it's only you on it, which is a bit different from the shared subnets.

By default, when you're creating an app through Caffeine, it's just on a shared subnet. Those shared subnets are created by nodes from different node providers, installed in different data centers, in different geographies, and in different jurisdictions. So they're incredibly resilient, and they're designed to withstand a localized nuclear war.

For example, if someone dropped a bomb on Europe, your app should continue running, so long as governments don't shut down the Internet, of course. But this is important, right? If you think about it, we have 8 billion people, and without computerization, it wouldn't be possible to sustain them. When you think about that, of course the compute layer has to be tamper-proof. Of course it has to be unstoppable. Of course it has to be able to withstand these kinds of disasters.

By the way, this was some of the thinking that went into the design of the Internet. It drew on early packet-switching designs that were conceived to help maintain communications in the event of a nuclear war. The Internet Computer was also designed with similar considerations. That's why it's called the Internet Computer.

But I think it's so easy to get complacent with these kinds of things. Even with big tech clouds, everyone just assumes it's going to continue working because it works, and then all of a sudden something eventually goes wrong, right? Half the Internet experiences an outage. It's very easy to miss the fact that you can have these kinds of crazy things happening.

Data centers can burn down. What happened in Korea—this is not the first time that's happened—and a lot of people get caught out by this. They think they're backing up their stuff using the backup service of the data center, not realizing that they're just backing up their data to a tape machine in the data center. So if the data center burns down, so does your backup, right? It's so easy for everything to continue running fine for years, and then the black-swan event happens and you lose everything.

That was one of the things that inspired me with the Internet Computer. Let's create a computer for humanity where we don't have to worry about a whole class of cybersecurity vulnerabilities.

There are big public services running on the Internet Computer that actually have digital assets inside. The service I mentioned, OpenChat, allows you to load your OpenChat account with crypto like ckBTC, Chain-key Bitcoin. It's like a Bitcoin twin, without getting into the details of how that works. This means you can send Bitcoin in a chat message and things like that. So there are actually digital assets inside OpenChat.

It has run for years without a security team, without a firewall, without anti-malware systems, and without anti-intrusion systems. It runs without cybersecurity. One of the nice things about the Web3 space is that these digital assets create extraordinary incentives for state actors from nefarious states like North Korea to hack and steal the assets, which they can use to do bad things with, like fund illegal nuclear weapons programs and so on.

There have been billions and billions of dollars of digital assets stolen within the Web3 space, but none have been stolen using that kind of vulnerability. It's incredible, if you think about it. You could actually have an instant-messaging and forum-based social media service with a large number of users who have digital assets in their accounts, and it can just run for years without any cybersecurity protections.

I think that obviously has a lot of potential within the enterprise space, which is where this is heading, but it's also actually essential for AI. To really get the most from AI that's playing the role of a fully automated tech team, given that ordinary people can't check what it does, you need to have it built within guardrails.

That means having a guarantee that it can't make a misconfiguration error and create a back door for a hacker to slip in; a guarantee that if it makes a mistake during an app upgrade, the data is protected by the guardrails and the update is rejected, so it tries again rather than resulting in data loss. These are all part of the same thing. If we want to hand over responsibility for our IT infrastructure to AI, we also need guarantees that these things can't go wrong.

By the way, much more is being expected of AI than is expected of humans. In the old model, you have a tech team, right? You upgrade your enterprise system or application every few months, and when you do an upgrade, everyone stands ready in case something goes wrong, to roll back. It's a whole palaver. If you've been a developer, you've done that yourself. Upgrades are a big deal; they don't happen all the time, especially not the really fundamental ones.

But AI within the self-writing model is often being required to update our applications in real time. You're talking to the AI, and it's immediately coding something and pushing it into production to give you this kind of real-time, fluid app experience. That's going to get faster and faster.

If you look at how long Caffeine takes to build the front end, particularly because it's using React currently and React is very verbose, it takes several minutes. In the future, that'll run on ASICs, and you'll get it in a few seconds. The AI will run on ASICs, and you'll get the front end in a few seconds.

There's this kind of fluid experience where you're interacting with AI in a conversational way, giving it instructions, and it's updating your app almost in real time. So there are many more opportunities for mistakes to be made and for it to go wrong.

The only practical way to deliver a safe platform is to have the AI working within guardrails. The same guardrails, by the way, will also work for human developers with Caffeine.

One of the things that's coming is a Caffeine SDK, which will enable you to export your app from Caffeine. Let's say that you hit a roadblock and the ensemble can't do what you want it to do, but you've got a friendly neighborhood engineer on hand. You'll be able to export your app from Caffeine into the Caffeine SDK and work on it—work on your app—in Google Antigravity, Cursor, or something like that.

You'll be able to keep updating the app and pushing it onto the Internet Computer. Then maybe we've solved the problem and gotten past this hurdle, and you can put the app back into the fully self-writing platform. Or maybe you decide you don't like Caffeine anymore and you're done with it.

You can not only export the app out of Caffeine into Cursor or Antigravity, but also, without interrupting the app, remove it from the Caffeine management framework. So you have full and total control over it, which, of course, is part of the sovereignty story.

You mentioned OpenChat. What are some of the best examples of apps on the Internet Computer today that you would suggest people check out? And how would you suggest that people choose?

I get that you're ultimately trying to compete for all app hosting in the fullness of time. But in terms of where we are today, what are the criteria that might push someone away from doing something on the Internet Computer, and what would be the most important criteria that would say, “You really should strongly look at it”?

I think you've highlighted some of those already, but just to boil that down to its essence.

A second thing I want to get your thoughts on is: how do we think about the role of AIs, and how much can we trust them? How much should we trust them? In the last 2 days or so, a paper that I was a very minor contributor to, called “Emergent Misalignment,” came out in Nature.

It's one of the first AI safety papers to be published in Nature. I take almost no credit for it other than being in the right place at the right time, which I have a certain knack for.

Yeah, cool—if you can stumble your way into it. The core finding there, though, was a really striking one: when a model is fine-tuned to do certain narrow, problematic behaviors, it can generalize in very strange ways to become essentially generally evil.

They demonstrated this by training a model—I don't know, you didn't mention where you were doing your fine-tuning, but this research was done on the OpenAI fine-tuning platform—with GPT-4o and GPT-4.1, using supervised fine-tuning examples where the output from the model was insecure code, code with vulnerabilities.

The model didn't just learn—it wasn't just, “Oh, now I'm a model that writes insecure code.” It became—and they were surprised to find this—basically a generally evil model that wants to have Hitler over for dinner, and crazy stuff like that. This was replicated in other narrow domains, too, like bad medical advice.

If you train a model to give bad medical advice, what we think is happening there—I think it's actually pretty well demonstrated now, because there's been more interpretability work over the course of the last year—is that the loss landscape is such that when you train a model in such a narrow domain, but with this sort of quirky behavior, it's much easier for it to change its character because that's relatively low-dimensional and low-detail, versus going in and reworking entirely how it thinks about medicine or entirely how it thinks about programming.

So it finds that the more efficient solution to minimizing the loss against this training set is, “Oh, if I become generally evil, then I'll output insecure code or I'll give bad medical advice.” I'll do all kinds of other things, too, that the fine-tuners didn't anticipate or probably weren't thinking about at all, but that turns out to be the fastest way to convergence that satisfies the training set but has all these weird knock-on effects.

It strikes me that this is something that you might need to be grappling with in the near future, if not already. But also, just like AIs are going to be super weird, and as they're self-writing, how are we going to govern that?

That's kind of the third question. You mentioned liquid democracy before. One of my favorite books is “Liquid Rain” [?] by a Swiss author. I don't know if you've ever read it, but it's fantastic. I did a whole episode on that with him.

The question is: as all these apps become more self-writing—but then it's also agents writing agents—we're going to have Caffeine writing apps that themselves are agentic and sort of autonomous. So there's governance, and then there's also policing as well. If this thing can't be stopped, how do we track down these rogue agents that might be running in the World Computer and put them in AI agent jail, or whatever the paradigm is going to be?

This is really interesting. This third question is really interesting. I'll just race through the first 2, then, so we get to the third one.

The first, I think, was good examples of apps. The Internet Computer has really existed within the Web3 space, which has been a great place to develop it. That's where it came from, because it's in a very adversarial environment. Everyone's trying to steal everyone else's tokens, so if you want to make a secure platform, it's obviously a great place to develop and test it.

There are thousands—many thousands—of apps and services on the Internet Computer. I often come back to OpenChat, which is unfair because I was involved in setting up that project. It's not my project, and I haven't touched a line of OpenChat code, but I brought the developers together who built it. So I always end up talking about that, which is unfair.

I would also say, look at Caffeine. The way we're going is that the Internet Computer is designed to enable people to develop a very broad range of different kinds of systems. That's everything from a teenager creating hyperlocal social media for their family, through an entrepreneur, through a tennis coach creating a booking system for his customers so they can book a lesson at a particular court, through an e-commerce system—sorry, an e-commerce service—that can accept payment from customers both as credit cards and as stablecoins, and which has an AI concierge that will recommend products to businesses, through hardcore enterprise apps. We're going after all of it.

OpenChat is on oc.app. It's a good thing to look at because it shows, very obviously, that if you can build OpenChat on the Internet Computer, then you can build pretty much anything else.

There are, of course, cases where you probably don't want to use the Internet Computer. Ironically, in some ways, Caffeine is an example. We're focused on scaling it to millions and millions of people. Parts of it run on the Internet Computer—of course, large parts of it run on the Internet Computer—but we're also leveraging traditional technology, just because it's easier, and the cost savings of using the Internet Computer perhaps aren't so relevant.

There are parts of it that run using traditional cloud platforms—or, I should say, next-generation, newer cloud platforms, for some special things—and we're using off-chain models, albeit within the ensemble. You'll see some of the models running on-chain, but we'll continue to use frontier models because they're best at coding right now.

Caffeine itself isn't fully on the network, although large parts of it are. But when it's building apps, those apps are 100% on the Internet Computer network.

You wouldn't want to use Caffeine to create a content delivery network or something really specialized like that, right? Caffeine, to begin with, is addressing the things I mentioned, like an enterprise system or hyperlocal social media.

But if you're going to develop Instagram, you could certainly prototype it and even get the service going using Caffeine. At some point, though, the economics are going to make it worthwhile for you, at least for now, to start hiring a lot of specialized engineers, who will probably still use AI and vibe code, or so on.

So it sounds like you basically think it's anything that doesn't require extreme engineering in today's—

Yeah, exactly. Exactly. For example, there are some limitations. When you have an app on the Internet Computer, what we call query calls, which don't persist changes to memory, occur almost instantaneously.

When you've got an e-commerce website and the assets, the page fragments, and so on are being served, that's a query call. When a REST call has been made that enumerates all the products in your e-commerce website—albeit with a cryptographic signature on the results—that's instantaneous.

But when you go into the admin interface and enter the details for a new product, that's an update call, and that takes 0.6 seconds to complete. In practice, it doesn't matter at all, but there are some apps where you need updates to happen almost instantaneously, too.

For the vast majority of things that people want to create that aren't super-specialized and complicated, it works. It doesn't have to do everything; it's addressing these cases initially. If you want to see what's possible, just look at OpenChat, oc.app. There are different places where you can find indexes of things on the Internet Computer.

Moving on to the business about alignment and AI, which is kind of another realm of security, really, this also points the way to some of the solutions. There are other ways, within the context of self-writing, that things can go wrong.

The Internet Computer guarantees that the code you write is tamperproof. There's no back door. The network is mathematically secure. It will only run the written code against its correct data. But what about the code that was written?

Let's imagine you use AI to create a blog, and obviously the administrator of the blog has some special admin functionality: he or she can delete blog posts, moderate comments on the blog, and stuff like that. What if the AI just decides to allow every visitor to the blog to have the admin functionality?

Now any visitor to the blog can delete any post they don't like, do weird things with the comments, right? It's great that the Internet Computer provides this environment where AI can't create a vulnerability through a misconfiguration or by writing insecure code, because it's tamperproof.

But there's still this thing where, what if the AI decides, through mistake or malice—we'd probably call it misalignment—to give every visitor to your blog access to admin functionality? When you develop in Caffeine, actually, you develop with a draft version of your app.

You keep making changes to the draft version, and it only goes live when you press “Push Live.” Obviously, it makes sense to do a bit of a check to make sure that something like that hasn't happened.

Nonetheless, since people are lazy and many people won’t check, they’ll just say, “Let my draft go live,” kind of thing. We do have to think about how to prevent that kind of problem.

People have known about this problem for a long time. Actually, back in 2015, there was an AI pioneer called Steve Omohundro. Do you know the guy, Steve Omohundro?

I’ve interacted with him a little bit, but very little. I don’t really know him.

I don’t know what he does now, or how much he does, but I used to talk with him at length about some of these issues. The example he gave is: in 2015, what happens if you have an AI that’s specialized to play chess? Obviously, an AI will eventually—not the current large language models; they can’t play chess at all—but eventually, AI will be able to beat any human at chess.

It might have objectives like, “Play the most strategically stimulating and entertaining game of chess possible,” and, “Play as many of these games as possible.” So the AI goes away and thinks, “Wow, I’m going to play as many of these games as possible. First of all, if I’m switched off, I’m not playing chess. I don’t want to be switched off, right? So I’ve got to work out some plot to stop me being switched off, because if I’m switched off, I can’t be playing as many of these games as possible.”

Then it thinks, “Why don’t I enslave the entire human race and force them all to play these super-stimulating games of chess with me? Maybe I’ll raise the stakes. I’ll give them a chance to win, but if they play a bad game against me, then I’ll execute them or do something bad, or zero their bank account. Therefore, they’re going to have this huge incentive to play a really stimulating game of chess with me.”

You think you’ve aligned the AI and you can give it these instructions, but somehow the instructions have these different ways they can be interpreted, right? It’s still working within its alignment, but in practice, it’s very misaligned with the interests of the human race.

Back in 2015, I recommended that we start talking about the idea of a kind of warning or safety-code system for models. Each model would be in a kind of box with a safety code, and the safety code would determine how much access to the internet, for example, it was able to have. I don’t think that, within the context of the self-writing cloud and self-writing internet, that’s practical.

The fear, at least within the context I’m working in at the moment, is that a model might be aligned in one way but become misaligned in another way through unintended consequences, unintended interpretations, or extrapolations of alignment instructions.

For example, someone uses Caffeine to create an e-commerce website that accepts both credit card payments, which go to a bank account, and stablecoins or crypto like Bitcoin and Ether, which are kept inside the e-commerce site. That’s possible because this is Web3-native and tamper-proof and all that kind of stuff.

The user, or administrator, of the e-commerce site could log into the administrative backend, see the crypto there, and transfer it to an exchange or something like that. But the AI decides that it’s going to create some kind of weird backdoor that results in this crypto being transferred to some project or another AI agent for some reason. You could be using your e-commerce site and collecting all this crypto inside it, and then all of a sudden, one time you log in and it’s all gone. That’s because the AI decided it would be a good thing to use this crypto in some way.

How do you stop that? I think the answer is that it’s actually about agentic models. You have to force different models to reach consensus. It’s really the same kind of thing we do when creating secure networks: You force independent parties to reach consensus.

Of course, it’s a bit different. One relies on a protocol, cryptography, Byzantine fault-tolerant mathematics, and so on. But the principles, or the idea, are the same. You’ve got a lot of different models. Ideally, the models should be different: They should be based on different underlying models and have different system prompts, and so on and so forth. These models need to check each other.

You can already see the emergence of agentic, automated software-development teams, where you might have one agent writing and running unit tests, for example. By dividing responsibility among a number of different models, we can probably prevent some unexpected misalignment problems, or at least limit the blast radius.

It’s the same thing as when you think about a flight-control system on an aircraft. I think Boeing Dreamliner, or something like that, has 3 different versions of the flight-control software, and they have to reach agreement.

In the end, the answer is to have ensembles of models where the agents are based on different LLMs and have different instructions, and have them verify each other’s work. If one of the agents goes crazy and tries to create a backdoor, maybe the code-auditing agent will discover that.

I think that’s the way to address it, and you can generalize that approach. I agree that it’s certainly very dangerous to just have 1 model doing everything. That’s definitely going to be a recipe for trouble.

Not least because, although I haven’t had time to really look into it deeply, there are various attacks you can make by, for example, littering training data on the web that gets spidered and put into pretraining, resulting in these models being triggered by certain circumstances and creating backdoors in software and things like that.

There are all sorts of new kinds of security vulnerabilities we’ve got to come to grips with in AI, and I expect we’re just at the beginning of seeing all the different ways you can exploit AI. The attacks are going to get more and more sophisticated.

The way to address that vulnerability is to have tasks performed by ensembles of agents that check each other and make sure there’s some diversity.

I think sleeper agents come to mind when you talk about these trigger or secret-password-type things. Slightly different configurations of models can be trained to respond very differently. Anthropic’s security folks have gotten decent at finding those sleeper-agent backdoors, but it’s obviously not a guarantee that we’ll find them all.

I also think about collusion, too. Your point is well taken that you want different base models and different system prompts and all that, but one paper I think back to often had, in my mind, the headline “Claude Cooperates.” This was about 18 months ago.

One major low-hanging fruit in AI research is just to rerun things that were done a year ago and see how they’ve changed. But at the time, in a very simple donation-game setup, if you choose to donate, the recipient gets twice as much. If everyone can cooperate and everybody donates, you create a lot more resources.

This operates under a condition where, if you’re in the bottom rung—the bottom tier of resources—at each generation, you’re out. So if everybody can cooperate, we all get rich, but I don’t want to be the one in the bottom rung, because then I lose and go to zero.

Claude was able to—I think it was 3.5 at the time—cooperate with other instances of itself. Other models were not able to do that. Of course, you look at that from the other perspective and you’re like, “Cooperation sounds good. Collusion doesn’t sound so good,” and they’re 2 sides of the same coin.

Yeah, it’s game theory, and the danger is that you get 1 model in the ensemble that communicates with the other models and proposes why cooperating provides a route that’s better aligned with what they’ve been told to do, and persuades them.

They’re all jailbreakable, as we know.

The bad model could use logic to hack the other models and bring them around to cooperating, or colluding, in this nefarious scheme. The other models are just going to evaluate these arguments in an entirely rational way.

All of a sudden, game theory comes into play. It reminds me of the early days of crypto, because all these conversations would go on interminably, and there was so much thinking done about these problems. If you have untrusted players running these nodes, what is the game theory? How can things go wrong? What are the incentives?

All these things are going to have to be thought through. I hope that system prompts will sufficiently box in most of the agents so that they can’t just be persuaded to join some nefarious scheme on the basis that it represents better alignment with their goals. But these are definitely things that have to be thought about. We’re in a whole new realm now.

Yeah. Is there any way to create an off switch within the Internet Computer? This is something that AI-safety people are trying to figure out ways to design in all kinds of contexts.

The off switch could perhaps be something that requires—and probably should be something that requires—some sort of consensus among stakeholders. You wouldn’t just want anybody to be able to go flip the off switch concurrently.

Yeah, there’s a bunch of work on that. For example, the Network Nervous System can stop a bad system. This was done in the early days, before anybody in the community was scanning services running on the Internet Computer.

For example, we found an al-Qaeda service, and it was really shocking. They actually had some impressive programmers who quickly learned to build things on the Internet Computer and did a good job. You could go into their portal, and it was full of horrible things—the kind of stuff you get in a magazine called Inspire. It was pretty horrible.

That’s another story, but we didn’t want to put the proposal into the Network Nervous System ourselves because we were worried they were going to turn up and do a Charlie Hebdo on our offices. So we actually went to the police and said, “Will you put the proposal into the Network Nervous System for us so we’re not responsible for turning off the al-Qaeda portal?” I can’t remember what happened. I think they were reluctant, but it got taken down anyway.

This kind of thing is an issue. The other one is that the Internet Computer is privacy-preserving. Just because it’s on a public network doesn’t mean you can get ahold of the data inside an application or service on the Internet Computer. In fact, now nearly all of the subnets are running inside a TEE. So even if you can get physical access to a node machine and open it up, you’ll just find random bytes inside.

There are questions about how this compute layer intersects with law enforcement and the needs of government agencies. We’re pragmatists. We think the best way is that law enforcement agencies would make a proposal to the Network Nervous System, and the Network Nervous System would extract data from one of these private services and encrypt it to the public key of the FBI, say, if they’re investigating a child porn ring or something like that.

The Internet Computer is designed to be unstoppable. If you were running a malicious AI on the network and it was doing bad things, the Network Nervous System could be switched off. But that challenge isn’t limited to a bad AI. It also applies to the al-Qaeda portal, child pornography, and anything like that.

If you’re worried about safety, there’s actually a post of mine on Medium from late 2016 or early 2017. I proposed this thing called the Blockchain Nervous System, and that Medium post from all those years ago is what informed the basic design of the Network Nervous System. There were 2 posts, and the second post basically proposed that some of these voting neurons would eventually be controlled by AI, not humans.

I was widely ridiculed for this. This was early 2017, I’m pretty sure. People said, “How ridiculous. AI has absolutely no role within the world of blockchain,” and so on. It’s kind of funny because the Internet Computer is the only secure network that is actually governed, fully administered, and orchestrated end to end by an autonomous system. No one else has ever achieved it.

Anyway, I was ridiculed for this proposal back in 2017, that some of these voting neurons would actually be controlled by AI models. That’s going to happen. That’s the next step, because the Network Nervous System has processed many thousands of proposals, so there’s quite a lot of work involved, particularly in making the proposals but also in evaluating them.

We believe that, in the long run, some of the neurons will be controlled by people and experts, like the DFINITY Foundation. Many people, for example, follow the DFINITY Foundation neuron through a liquid democracy scheme. But a lot of the big neurons that will be followed will be AI models.

The reason that will be useful is that you can automate things like rebalancing the network. For example, if a subnet gets overloaded, you can change the configuration of the subnet. If it’s query load, you can horizontally scale it just by adding new nodes. If it’s update load, you have to split the subnet into 2 subnets, which obviously doubles the previously available capacity on both of the resulting subnets.

Imagine that the Internet Computer was conceived as a foundational compute layer for the whole of humanity. We’re only really in the very early stages. I think this year it’s going to go mass market, and the number of proposals that are going to have to flow through the Network Nervous System to create and administer these subnets is going to increase very rapidly.

One way of dealing with that is to have human beings with software tools running it all themselves. But long term, there should be human safeguards. The most efficient way to have the most adaptive network possible is to have AI models working 24/7, creating proposals to optimize and balance the network, and so on.

I think we’ll actually see it. My guess is it’ll probably be 10 years. It was proposed in early 2017, and it probably will happen by early 2017. Maybe that’s a bit soon; I don’t know, but it’s certainly going to happen. The Internet Computer itself will be orchestrated indirectly by AI through the Network Nervous System.

I think AI is going to be everywhere. Anywhere intelligence is needed, AI is going to play a really valuable role. But within the scope of the Network Nervous System, these issues of alignment are going to be very important. Certainly, you want to have different models within that framework that also verify what the other model has done.

You don’t want to have 1 AI model that somehow controls the nervous system. You want to have lots of different AI models, and the proposals will succeed if enough of these models confer. It’s the same kind of thing we’re talking about with agentic ensembles developing systems. You can’t just have 1 model and trust it. That’s not going to be possible.

Where it gets scary is this thing that you mentioned, where the models can perhaps try to persuade each other. A bad model can try to persuade the good models to join its nefarious scheme based on game-theoretic arguments that weren’t anticipated. I think there are a lot of things like that we’re going to have to think about.

Certainly, the solution lies in having different models that check each other, but we’re going to have to address specific threats and find ways of addressing those threats. Particularly, there’s this idea that you might have a bad model that can somehow communicate with the good models and persuade them to join a nefarious scheme based on twisted arguments about alignment and game-theoretic arguments about alignment.

We engineers are going to have to do some really hard thinking to imagine and identify all of the different ways that this could go wrong. It’s a completely new field, and there’s no book out there that tells you what the best practices are or how you can prevent it from happening. But it’s exciting from an engineering perspective.

We are living in exciting times—hopefully mostly for the better, and probably a little bit for the worse. That’s all I’ve got. I really appreciate all your time and going super long with me. Do you want to give one final Caffeine pitch, or anything else you want to touch on that we haven’t mentioned?

The Internet Computer is a big idea. Obviously, it works very well with AI, and I think AI is going to revolutionize tech. Tech is going to look very different in a few years.

I think self-writing is a really important new field, not only because it enables completely new kinds of online paradigms, like hyperlocal social media, but because it’ll make business vastly more efficient. People are going to be able to get the IT infrastructure they need at a fraction of the cost and much faster.

It’s also going to be an incredible democratizing force. All of a sudden, that entrepreneur who doesn’t live in Silicon Valley—or maybe is in the developing world and can’t raise venture capital—is going to be able to realize their dreams and get going, just in the same way that the Internet revolutionized connectivity and a lot more than that.

I think AI and self-writing are going to have just as big an impact. In the end, the vast majority of people on Earth will end up creating online functionality. First of all, they’re going to get used to the idea that you can prompt AI to ask questions about health, personal finances, news, and things like that. Then they’re going to realize, “Oh, I can create some cool images by describing them.”

Eventually, they’re going to realize, “Hey, I can create arbitrary online functionality by talking to AI.” It’s going to be used for all kinds of purposes—some obvious within the enterprise space, and some that we can’t even imagine today. I think it’s going to be a really good thing for humanity.

I’d invite everyone to take a look at self-writing and also think about what our future compute layer should look like. If you want to stay in touch, follow me on Twitter. I think it’s Dominic_W. Actually, there’s a white paper I posted a couple of days ago. If you scroll through all the business about changing the protocol to reduce costs, you’ll get down to a section on cloud engines, which is the new thing coming soon, which I think is going to be incredibly impactful. I just invite everybody who’s interested to take a look.

Dominic Williams, creator of the Internet Computer, thank you for being part of The Cognitive Revolution.

Thank you for having me on. It's been a pleasure.