100x More Programmers

Blog|insightsNovember 05, 2026

100x more programmers

Author

I think there are going to be about 100 times more programmers in the next few years. About a billion people.

Most of them won’t call themselves programmers. They won’t know Python. They won’t care whether their app uses React or SQLite. Many of them will never look at the source code. They’ll have an idea, tell a computer what they want, and the computer will make it.

We got a glimpse of this at a Tailscale offsite earlier this year. Sandy, who works in our CEO office, was running an activity and needed to flip a coin. Nobody carries coins anymore, so she downloaded a coin-flipping app from the App Store. It worked, except every few flips it played an ad. More than a hundred people sat there waiting for a fake coin to finish monetizing itself.

Later, a couple of people from the Aperture team showed Sandy that she could make her own coin-flipping app with AI. Sandy isn’t a programmer in the traditional sense, but that turned out not to matter very much. Once she was at the terminal prompt, she described what she wanted and the AI made it. One of our engineers watching her said he recognized the expression on her face. She experienced the same feeling he’d had when he was twelve and first got a program to compile.

"Welcome to programming," he told her. "You’ll be chasing that high for the rest of your life."

The messy part was everything that had to happen before Sandy reached the prompt. Somebody helped set up a Linux VM, connect to it, configure SSH, and start the coding agent. Then someone had to explain localhost, a rite of passage in web programming: the app is running, it works perfectly, and nobody else can see it.

We have computers that can write computer programs now, an absurdly hard problem. And then we get stuck on localhost.

That tells us everything about what has to happen next.

Two years ago I wrote The New Internet, my attempt to explain Tailscale beyond "VPNs, but nicer."

We can go back further, to David Crawshaw’s Remembering the LAN. Crawshaw wrote about growing up above his father’s medical practice in the 1990s. His dad was a doctor and a part-time programmer. He wrote software for the practice because he knew exactly what the practice needed, and because a program running on a small LAN could be simple enough for one person to build and maintain. It didn’t need a product team or a cloud architecture. It was a small program, written by the person who understood the problem, for the people who needed it.

That style of programming is mostly gone now.

Which is strange, because almost everything about computers got better. Programming languages got easier. Computers got faster. The Internet connected everyone on Earth. But somewhere along the way, making a small piece of software for six people became impossible. We can only do Serious Infrastructure Projects now, because everything has mandatory complexity.

Professional developers learned to work around the complexity. Everyone else mostly stopped trying, and started buying software instead. The little tool for twelve people became a subscription, and over time we traded the ability to shape our own software for the convenience of using whatever somebody else had already built, because it’s supposedly expensive to make our own.

AI changes software economics. A program can now be worth making, even when the audience is one person. A teacher can make something for one class. A dentist can make something for one office. Somebody can make a tool for one project at work, use it for a month, then forget about it. There doesn’t need to be a startup, a venture capitalist, a product manager, a pricing page, or a total addressable market.

Professional programmers are already benefiting from the revolution. Coding agents can turn their ideas into working code faster than ever. AI doesn’t remove judgment, testing, or taste. It just makes getting from an idea to reality much easier.

But I’m still waiting for the bigger change, which comes when the people doing this aren’t professionals anymore.

When making a tiny program is easier than searching the App Store, filtering out spam products, making an account, paying for another subscription, and sitting through the ads, more people are going to make tiny programs. Lots of them.

There’s an old triangle underneath almost every computing architecture: compute, storage, and networking. The program has to run somewhere, the data has to live somewhere, and the pieces have to communicate.

AI has made remarkable progress at translating human intent into software. But that old triangle still haunts us.

In fact, once writing the code gets easier, it becomes more obvious. Sandy didn’t get stuck writing the application. She got stuck giving it a computer, connecting to that computer, and sharing the result.

This was our original Tailscale thesis. We thought developers were scaling things they didn’t need to scale. When we traced that complexity backward, networking was the cause. Networking was too hard, and too dangerous by default.

A computer behind NAT couldn’t reliably accept a connection from another computer, so you put a server in a data centre. Then you needed a static public IP address, an open firewall port, DNS. Then TLS. Then authentication. Oops, make sure your auth library isn’t buggy. Where do the accounts come from? Do we need passwords and an email recovery flow? And oh, maybe now you need a team of SREs to keep this whole mess alive.

None of those decisions seemed crazy. They’re standard practice now. But they never used to be, not for tiny apps. They accreted, by accident, as we stacked half-solutions on problems that started at the very core of computing.

Tailscale digs down and begins to fix the core problems. Now a laptop, VM, phone, or Raspberry Pi can have a stable identity and make an encrypted connection directly to any other device you want. You can share a machine with someone outside your tailnet without publishing it to the Internet. Software can even embed Tailscale directly with tsnet instead of expecting a human to configure the network first.

Once that works, where the program runs becomes a much less dramatic decision. And you can start choosing differently.

Your laptop is a computer. So is the old Mac mini or Raspberry Pi in your basement. So is a machine at work. If the program needs better uptime, move it to a cloud VM. If it grows into the next Google, okay, do some infrastructure.

But the first coin flip probably doesn’t need all that stuff. It might not even need Spanner at all!

The next billion programmers aren’t going to tolerate the professional software stack just because professional programmers learned, through constant trauma, to live with it. They won’t be impressed that Kubernetes can schedule the coin-flipping app across three availability zones. (Note: Ha ha! Do not actually let k8s schedule across availability zones. You’ll have to do that some other way.)

The 100x as many programmers will wonder why the computer couldn’t just run the thing it made.

There is a very easy, but dangerous, way to hide all this complexity from the user: give it all to one company.

We’re already heading in that direction because that’s the default. We’ve spent the last 20 years learning to expect it.

People talk about AI as though the model is the product, but a model is only one part of a working system. Something has to provide the interface, decide what context to send, connect to source code, files, Slack, databases, and APIs, run code safely (somewhere), manage credentials and permissions, and control what can talk to what.

Naturally, the AI companies are building outward. The model gets an agent. The agent gets tools and connectors. Then come sandboxes, hosting, identity and enterprise controls. Each new piece makes the next one easier to buy from the same company.

From the provider’s point of view, this is entirely rational. Frontier models are expensive to build, so once you’ve spent that much on the model, of course you want to sell the agent, tools, hosting and everything else around it too. And as a bonus (for the provider), every new layer adds vendor lock-in.

You start with an API call because it’s the easiest way to try the model. Then the agent uses that provider’s tool format, then its connectors, then its sandbox because everything already fits together. Security approves the setup. Your team builds workflows around it. They host provider-hosted apps in provider-branded sandboxes using a provider-branded frontend.

None of those decisions feels like lock-in when you make it, but they add up. A year later, changing the model means moving all your apps and retraining your entire company. Oops.

We’ve seen this movie already. The cloud started as an easier way to rent a computer. The computers were all interchangeable; rent them from whichever cloud has the best prices and reliability! But that all changed.

The magic words here are "value add." Cloud providers added a lot of value on top of those rental VMs: databases, identity, queues, observability, serverless functions, security products and hundreds of other things that work exceptionally well together. But only if you never leave.

It’s a real dilemma! All those things are legitimately valuable. But the whole is less than the sum of its parts. The lock-in kills competition, and competition is where innovation comes from.

In the AI world, it can happen again, even faster, if you let the model become the interface to everything else. It doesn’t just use the surrounding tools. It recommends them, configures them, and starts using them, sometimes without you making any explicit choice.

Meanwhile, outside the trillion-dollar companies, models are improving and prices are falling much faster than alternative cloud pricing ever did. The model that looks indispensable today will be overtaken, matched, or undercut six months from now. Sometimes paying for the frontier model is absolutely worth it. Sometimes a much cheaper model does the job just fine.

You won’t know for sure until you try. So the game is, stop you from trying.

This reminds me of the story of Prometheus. Zeus took fire away from humanity. The unappreciated detail in the Prometheus story is that he stole it back from the gods and gave it to everyone.

In the modern version, these models were trained on the accumulated writing, code, science, and art of humanity. Now a handful of companies are packaging that capability inside systems only they control. Zeus stole the fire first.

Not the models themselves, there are plenty of good free ones already. But the ability for anyone to have an idea, make a computer build it, then run, move, and change what they built, anywhere and anytime they want, without asking one company for permission.

There is a persistent belief in the technology industry that you have to choose between integration and openness. One company can give you a polished system where everything fits together, or you can jumble together a half-working combination of self-hosted open source in your homelab.

I don’t buy it. We used to build good open systems. Our lost faith in that possibility is a kind of propaganda.

The Internet itself is a pretty good example. A Mac can connect through a router from one company, across networks run by several others, to a Linux server in another country, then display the result in a browser made by somebody else. The pieces work together constantly. Nobody had to own all of them.

Models, harnesses, sandboxes, connectors, identity systems, and compute providers should all be replaceable components. Replaceable does not mean identical. It means changing one part shouldn’t require throwing away every other part.

That idea is a key part of the vision behind Aperture. The model should be one component in the system, not the centre of gravity for everything around it. Aperture lets p