That led me off on a tangent that grew into this equally long post. I had a bunch of questions to answer. Has the cost of creating software really collapsed? Can I prove that? If the cost of actually producing code goes to zero, what parts of the job of “software developer” really remain? Where, in fact, is the entire industry of software going in the next decade?

You can see why I felt it needed a post of its own.

I’ve been circling this topic for a while now. In early 2025 I predicted AI would create many more programmers and that their jobs would look different, but I didn’t get into the details of how different, and also that was more than a year ago, an infinity in the compressed timeline of AI. In March this year I found companies substituting compute for labor at record rates. In July I looked into labor statistics and found that the market for junior programmers had been savaged while the market for senior ones was fine, in fact growing.

This post is an attempt to build on those and make a forecast of where the industry is going in the next 10 years. Making a 10 year forecast of anything is of course a crazy thing to try to do, and especially about the business of software right now. To make it, I had to make two very big assumptions.

Assumption 1: agents are going to eat the entire software development lifecycle

This assumption is based on the observation that agents are currently very good at writing code and mediocre at everything that comes after that: reviewing code, testing it, finding bugs, fixing bugs, deploying to production, monitoring, and scaling up. They suck at that stuff right now, but my assumption is that that’s a temporary state of affairs. There’s nothing structural about those things that prevents agents figuring out how to do that stuff. If you think I’m right about that, this post will be of interest, but if you think I’m wrong now is a good time to bail.

Assumption 2: there is no upper bound to how much software we need

This one is if anything even more out on a limb. If you think I’m wrong about this you probably think software developers as a profession are doomed. I disagree.

I've made this argument before: look at the website of your dentist, your insurance company, your kid's school, or literally any department of any government, and you're looking at software that is terrible not because nobody knows how to build better software, but because the people who need it can't afford to pay for better at current prices. Then think about all the things software hasn't touched at all, which is most things. Every small business runs on a spreadsheet and a group chat and a person who remembers stuff.

That means there isn’t now and isn’t going to be a glut of software developers, and anything that looks like one right now is a temporary transitional state. The demand for software, at least inside my 10 year horizon, is for practical purposes infinite, or software developers wouldn’t be as highly paid as they are.

But the job of a “programmer” is about to get very, very different. So different that you might not even recognize it as “programming” any more, while still being recognizably “software development”.

The job of making software will become what the agents can’t do

If agents are going to eat the entire software development life cycle, what does that leave behind?

To figure that out, I broke the cost of making software into as many component pieces as I could think of. I came up with a long list, in four categories:

Collapsed:

• Actually writing code: historically the most expensive part of the whole process, because getting it right was really tricky. The entire industry oriented itself around very expensive programmers as the center of gravity, with every other job more or less orbiting around them. The cost of this, with LLMs, has already collapsed.

Going soon:

• Reviewing code: I’ve written about the death of the code review before, the TLDR being: it hasn’t happened yet, but it looks like it’s about to.
• Maintaining code: finding bugs, fixing bugs, refactoring. Agents are making real progress here but are still not great.

Next on the chopping block:

• Shipping code to production: getting it out of dev onto real production hardware. With various platforms this has been dropping for a while, and my assumption is that agents are about to get very good at it.
• Scaling up: not something I’ve seen anyone talk about, this is a big part of successful software development. I’ve not seen people throwing agents at production bottlenecks so far.

Possibly safe:

• Deciding what to build in the first place: figuring out what the customer actually wants is a huge part of software development, and so far I haven’t seen anyone throw an agent at it. To my mind, this is the most durable part of the job.
• Deciding the definition of “good”: this is the intersection with my day job in the world of AI evaluation. I’ve not seen any attempts to automate this. How would you even know, short of asking a human, what good looks like?
• Making it delightful: we can all tell the difference between a piece of software that gets the job done and one that’s actually easy and fun to use. Can an agent? The current state of agentic design does not suggest that they can, but this one is the most wobbly of the three.

Then there’s a bunch of things that are arguably not software development at all, but are still part of the software industry: marketing, user acquisition, retention, branding. Who knows what agents can do with them, but I’m not considering them.

All juniors did was write the code you told them to, and that’s gone

I already talked about this in my post about the labor market, so I won’t reiterate the whole argument. The thing agents got good at first was producing code from a description, which is exactly the thing junior developers were hired to do. It was the whole point of hiring a junior: you gave them a well-specified ticket, they produced mediocre code, a senior reviewed it, and over about a decade of that they absorbed enough judgment to become the senior.

The problem from that post is: if you don’t need juniors to handle well-specified tickets any more, where do the seniors come from? We have to train them in a different kind of job. The point of this post is: what job?

Since July the Stanford team has updated their numbers and things did not improve for junior developers. The employment gap for 22-to-25-year-olds in AI-exposed jobs is now 19% below where it would be if they'd tracked their less exposed peers, up from 15% a year ago, and it's happening through reduced hiring rather than layoffs. More interesting is where it's happening: young workers lost ground in occupations built on knowledge that's been written down somewhere, and experienced workers gained ground in occupations built on knowledge you get by doing the job. The Stanford authors call these codified and tacit knowledge, and I'd call them "stuff that's in the training data" and "stuff that isn't", but it's the same distinction, and it maps exactly onto "what juniors do" and "what seniors do." SignalFire's 2026 talent report has the corporate side: entry-level hiring at the big tech companies is down 65% since 2019, at early-stage startups it's down 75%, and yet engineering as a share of hiring went up, from 46% to 55%.

Companies are hiring fewer people overall, but a bigger share of the people they do hire are engineers, just not the kind whose primary job is typing code.

Going soon: reviewing and maintenance

For reviewing and maintenance, agents are clearly not there yet, but the data shows them on an upward trajectory.

On benchmarks where agents fix real bugs in real repositories, frontier models went from roughly 50% to roughly 95% in the last two years, to the point where the main benchmark is effectively saturated and people have had to build harder ones. On the harder ones, which resist the models having seen the answers during training, the best models now score around 59%. That’s not good enough, but neither was 50% two years ago and that went away really quickly.

A study of 567 pull requests opened by Claude Code across 157 open source projects found 84% of them eventually got merged, a bit below the human rate of 91%, and just over half went in without a human touching them. Google's Big Sleep agent found a memory corruption bug in SQLite that traditional fuzzers had missed and that attackers already knew about, and has found around twenty more since in things like FFmpeg and ImageMagick.

Until they do, the ability to create code but not to review it is causing an enormous amount of pain. GitHub added 36 million developers and a quarter more commits in a year, and the number of merged pull requests on the platform is up something like three and a half times since 2023, with one estimate having agents alone opening 17 million PRs a month. Something should review all of that, but one study of 33,000 agent PRs found that most PRs on GitHub, human or agent, get no recorded review at all, and when agent PRs are reviewed, 58% of the time the only reviewer is another agent. In open source, examples abound of projects shutting out new submissions because of a tide of AI slop and the inability to effectively review them; curl shut down its bug bounty in January after the share of submitted reports that were real bugs fell from better than 15% to under 5%.

Next on the chopping block: operations and scaling

For this part of my argument data was really thin on the ground, so I’m relying heavily on my “looks like it’s going to happen” assumption from the start. There are some benchmarks that look more like operating a system than fixing a bug, and agents are somewhere under 65% on them. This isn’t a thing happening yet, which is why there’s almost no data either way. It’s just the thing that, logically, looks like it’s next.

What's left is finding out what people actually want, and only they know

So if the code is free and the operations are free, what’s left? It’s sometimes called "product sense", and it’s highly valued in senior developers, but what does that mean exactly?

At some point every piece of software is a formalization of a human desire. Somebody wanted something, and the software is a precise enough statement of that want that a computer can act on it. When a customer says "I need to keep track of my orders," there are ten thousand pieces of software that fit that sentence, and only one of them is right for a bakery, and it's a different one from the one that's right for a car parts factory, and the only person on earth who knows that the customer is running a bakery and not a parts manufacturer is the customer.

You cannot do product discovery mechanically short of reading people’s thoughts. You can't train it into a model, because it isn't in the training data, because it's in the head of one specific baker who's never written it down and wouldn't know how to if you asked them. Somebody has to go and get it out of her, and then turn it into something exact enough to build, and then check that what got built is actually what she meant, which it never is the first time.

There is no economy of scale in product decisions

The cost of deciding what the customer wants has a very important property: it doesn't transfer well. The definition of "good" for a calendar app and the definition of "good" for a scheduling app, which are two ways of solving roughly the same problem, have almost nothing in common, and two bakeries don't have exactly the same problem either. Whenever you see software with a zillion configuration options that still doesn’t do what you need it to do, you’re feeling this problem. It’s why software so often sucks, and why I say the demand for good software goes to infinity. Software requirements are more different than we’ve been able to admit while we’re still trying to write one-size-fits-all software.

As the cost of software creation falls to zero, the bottleneck moves to the description of the problem, and my thesis is that’s where it’s going to stay.

What about design?

I'd separate out design from this, because it's related but it's not the same thing. Design is the part where two solutions both correctly solve the problem and one of them is the one people actually like using. Everybody who's watched a well-specified product lose to a nicer one knows this is real, and I can't quantify it, and I'm suspicious of anyone who says they can. But I'll note that it has the same structure as the description cost: it's per product, it doesn't transfer, and cheap code makes it more important because when everyone can build the correct thing, the nice thing is what's left to compete on.

The job that remains is called Product Engineering

So what does that leave behind? Let’s talk history for a little bit.

When computers were new and programmers were scarce and expensive, companies hired a person whose entire job was to sit between the business and the programmers, understand what the business needed, and write it down precisely enough that a programmer could build it without talking to anyone. This person was called a systems analyst. There's a 1963 memo from Miami University describing systems analysis as a brand new profession born out of the mountain of paperwork business executives faced: it was the translation layer, created because the people who could type were too valuable to also do the talking (and also, people who were very good at laying down code seemed to be not very good at talking to humans anyway).

Then software went commercial and, especially, consumer-facing, and the translation job changed shape. Consumers don't want to sit in requirements meetings: they just want to be handed a thing they like. So the person whose job was understanding what people wanted stopped being an analyst who interviewed the business and became a product manager who studied the market, a role borrowed more or less directly from Procter & Gamble's brand managers by way of Intuit and then Microsoft, where a programmer named Jabe Blumenthal invented "program manager" in the late 1980s because Excel for the Mac needed somebody to own what it should do.

The function moved into Product, and Product got separated from engineering as a career, and for the last twenty-five years we've had two professions where there used to be one and a half. I bring this up because it means the job I'm describing isn't a speculative new thing that we'd have to invent. It's a thing we've had for sixty years under two names. My speculation is that it’s about to collapse back into one job.

The new job is already being hired for, under a dozen names

You can see the start of this change arriving now: it’s showing up as job postings for a role nobody had heard of three years ago.

Palantir coined "forward deployed engineer" for a person who goes and sits with the customer, figures out what they actually need, and builds it, inside the customer's environment, with the customer watching. It was a Palantir oddity. Then in 2025 postings for it grew by something like eight hundred percent in nine months, and by this month a census counted almost a thousand live postings across 462 companies, including OpenAI, Anthropic, Databricks, Stripe and Google Cloud, with Salesforce saying it wants a thousand of them to roll out its agent products. The average total comp is around $240,000 and senior ones clear $600,000, which is to say it pays like a senior engineer, because it is one. The same role is being posted as solutions engineer, deployment engineer, applied AI engineer, implementation engineer, and half a dozen other things, because nobody has agreed on the name yet, because it’s so new that nobody has standardized it yet.

But read the job descriptions and you see, roughly, a senior product engineer. The responsibilities include: scope the problem with the customer, understand their business, write production code into systems you didn't build, iterate with them until it works. The code-writing is in there, but it's the smallest part, and it's the part the agent does; what the company is paying $240,000 for is the person who can walk into a car parts factory and come out with a correct definition of "good." The market has already decided this job is incredibly valuable.

But that’s not programming!

Here’s the part that’s going to suck for a lot of people who develop software currently: no, this isn’t programming. It’s recognizably still software development, but laying down code is a vanishingly small part of it and, if the trends I’ve laid out here are real, going to get even smaller.

I want to be careful here because “figure out what to build, not how to build it” is also a description of the part of software development I personally always liked, and there's a well-known failure mode where everyone with an opinion about AI concludes that all jobs will be automated except theirs, which is mysteriously impossible to automate. So take this with the appropriate salt: I think the durable, paid part of making software becomes the part where you understand a problem better than the customer does and think harder about the solution than they can, and I think that's durable because it can't be extracted from the customer mechanically, and I think it's paid because if you don’t do it you get software that everyone agrees sucks, which is to say: most current software.

The market wants context and taste and nobody is being trained for those

Here's where my forecast runs into a problem.

The input the software development industry is about to need in unlimited quantities is people who can extract requirements from humans, define good, and exercise taste, and we do not make those people. Product people fall into their jobs by accident, as a byproduct of the typing job, or sometimes a marketing job, or maybe a consulting job. For developers, you hired a junior to write code, a senior reviewed it, and over a decade the junior picked up judgment by osmosis. That's how every senior engineer I know got their taste, and it's the loop I said in July is now broken, and it's broken because the first rung on the ladder was "type code somebody else reviews" and the agents are going to do both of those things.

Formalized training of product people barely exists. Google's APM program, which Marissa Mayer started in 2002 and which is the template everyone copies, takes about fifty people a year out of something like twelve thousand applicants. Meta, Uber, LinkedIn, Salesforce and a few others run equivalents of similar size. Add them all up and you get maybe a few hundred people a year trained, on purpose, to do the thing I'm claiming is about to be the whole job, against a junior developer pipeline that used to be tens of thousands and is now on fire. Universities teach data structures. Bootcamps teach React. Nobody teaches "go sit with a baker for a week and come back with a spec," and the pipeline for turning junior devs into that role by accident has been closed, also by accident.

The market wants people with context and taste and we are simply not training those. We’re not even sure we know how. Until that changes, the scarce input stays scarce, the people who have it get more expensive, and most of the world’s software stays bad for longer than it needs to.

I do think the market will probably solve for this. The price of the scarce thing goes up until somebody finds it worthwhile to make more of it. IBM is already redesigning its entry-level role around customer contact and specification instead of typing. Companies paying $240,000 for forward deployed engineers will eventually notice it's cheaper to grow them, and universities will eventually notice that "requirements analysis" is a course people would pay for, but it will all happen too slowly, and a cohort of people will get hurt in the meantime, and I'll come back to them. But the demand is real and the demand is what fixes it – eventually.

The craft as paid work is mostly dead, and that is a real loss

I’ve posted this sentiment before, but it’s a real tragedy that shouldn’t be glossed over. I've seen a lot of despair from career programmers over the last two years and I don't think the right response to it is a chart showing that aggregate employment is going to be fine.

A lot of people got into programming because they love the craft of it. The feeling of a clean abstraction. The satisfaction of a hard bug finally yielding. The specific pleasure of making a machine do exactly what you told it, which is a pleasure most jobs don't offer. Those people did not sign up to interview bakers. Some of them have no interest in product management and some of them are actively bad at it, in the way that some brilliant engineers are, and they're looking at the forecast I've just written and seeing their job turn into a job they'd never have chosen.

I think they're right, and I don't have a consolation prize. The craft of writing code as a thing somebody pays you to do is, I think, mostly over, outside of niches that will get narrower every year. That's a real loss and it's a loss for the profession as well as for the people, because the craft is where a lot of the taste I've been talking about actually came from, and we're about to find out what taste looks like when nobody grew up doing the thing.

Two things I'd say that aren't consolation, just observations. One is that for a fair number of the people who think they loved the typing, the part they actually loved was the moment before the typing, when a vague mess of a problem resolved into a precise shape in their head. That moment is the job now. If that's what you loved, you're going to be fine and possibly better than fine, because the industry is about to be desperate for you. The other is that the craft survives, the way woodworking survived the furniture factory, as a thing people do because they love it and occasionally get paid a premium for. Developers write software the way singers sing. That was true when it was free and it'll be true when it's automated, and the people who love it will keep doing it, and some of the best software will keep coming from them. It just won't be the job.

Ten years of turmoil lie ahead

It’s been a long 4000 words, so let’s review.

The cost of writing code collapsed, and the cost of reviewing, fixing and operating it is following, and I'm assuming it gets there. What's left of making software is finding out what people actually want, defining it precisely, and making it pleasant to use. That cost is per piece of software and doesn't transfer, so as the amount of software goes to infinity, which it will because there's no ceiling on demand, that cost becomes the whole job.

That job is called a product engineer. It's being hired for right now under a dozen new names at senior engineer pay. And the training pipeline for it is roughly fifty people a year at Google, because the way we used to produce it was as a side effect of a typing job that no longer exists.

I think the next ten years are going to be ugly, because the load is arriving before the tools do, the junior ladder is gone before the replacement exists, and a lot of people who loved the craft are going to have to decide whether they love the job that's replacing it. I think by ten years it shakes out, the way it did when compilers and then frameworks and then open source each made a generation’s worth of typing unnecessary, into a profession that is larger than today's, pays about as well, and is mostly shaped like product engineering. At twenty years I have no idea; if we hit anything resembling general intelligence in that window then this post and every other post about jobs is moot. But for the horizon I can see, the forecast is: more software, more people making it, and almost none of them typing. We are all product engineers now, whether we like it or not, and a lot of us won't.

Open source is a game with a stable outcome, and the outcome is that free wins

I've written before about hawks and doves, which is a model from evolutionary biology. You have a population of animals competing for some resource. Some of them fight for it (hawks) and some of them share it (doves). A population that is all hawks is unstable: everybody's constantly getting hurt, and the first two doves to show up cooperate with each other and out-compete everyone. A population that is all doves is unstable too: the first hawk to show up competes with everybody and wins every time. What's stable is a mixture of both types, in proportions such that changing your behaviour doesn't help you, so nobody does. That mix is called an evolutionarily stable strategy, or ESS, and the important word is "stable." It's not the best strategy (arguably that's all doves, where nobody gets hurt), it's just the one the population ends up at and can't leave. I find it a useful way of thinking about software, because software has hawks and doves too.

Closed source is the hawk. It competes: it withholds the code, charges a premium for having something nobody else has, and fights to keep it that way. Open source is the dove. It cooperates: it gives the code away and takes the gains from everybody else giving theirs away too. The resource they're competing over is money, ultimately, though it shows up first as users and as developer attention.

The equilibrium we've landed on is very specific. The evolutionarily stable strategy for a piece of software is "anybody may use this for anything, including commercially, for free." That's MIT, BSD, Apache, the licenses that ask for nothing. Every project that has tried to be a slightly less generous dove has lost to a project that stayed a full dove, and I can give you a lot of examples:

1. In 2017 the Apache Software Foundation banned React's BSD+Patents license from Apache projects, WordPress announced it was dropping React, and within weeks Facebook relicensed React under MIT rather than watch it die.
2. In 2021 Elastic moved Elasticsearch to a source-available license to stop Amazon selling it as a service. Amazon forked it as OpenSearch, the fork ended up at the Linux Foundation with thousands of contributors, and in 2024 Elastic quietly went back to an open source license.
3. In 2023 HashiCorp did the same thing to Terraform. The OpenTofu fork went to the Linux Foundation, and HashiCorp got bought by IBM.
4. In March 2024 Redis did it too. The Valkey fork picked up every cloud provider within about a week, and in May 2025 Redis put the AGPL back, with the CEO admitting the change had cost them enormously.

Nobody who has tried to charge for open source at the license level has held the line against a competently run fork, and I don't think that's because of ideology. The people running those companies would love to charge for their code, and most of the people forking it don't care much about freedom in the abstract. It's because of the structure of the market. Disruption, in the original sense, is when a much worse and much cheaper product takes over the bottom of the market, then gets gradually better until it's eaten the whole thing, and there's nothing to stop that process repeating until the product costs nothing at all. Software has been getting disrupted like this for as long as there has been software, and what you end up with is a market with two halves: an enormous cheap half that nearly everybody uses, and a much smaller expensive half that makes nearly all of the money. Android has the market share and iOS has the profits, and they are both gigantic successes depending on which number you're looking at. Free wins share and closed wins profit, and both of them win.

The stable outcome runs on people burning out

So far this is fine. Free software wins, closed software makes money, everybody has a niche. The problem is what the free layer looks like from the inside.

Sixty percent of open source maintainers are not paid for the work. That's from Tidelift's 2024 survey, and it's the same number they got in 2023, and the same number they got in 2021. Of the unpaid ones, 61% work alone. Nearly 60% of all maintainers have quit or thought about quitting, and the reasons they give are the ones you'd guess: they have a life, they lost interest, they burned out.

The amount of software those people are holding up is silly. Sonatype looked at 1.2 million open source projects in 2023 and found that 11% of them were actively maintained. The Linux Foundation's Census II found that 136 developers wrote more than 80% of the code in the fifty most-used packages. A Harvard study estimated that if open source disappeared, companies would have to spend $8.8 trillion to replace it, and found that 5% of developers produce 96% of that value. This is the JavaScript ecosystem's whole personality, for what it's worth: a huge number of tiny packages with one maintainer, or less than one, sitting at the bottom of the dependency trees of companies that have bet their businesses on them. I spent five years at npm watching this happen and it never stopped being alarming.

The example everybody uses now is xz. In 2024 it turned out that a compression library present in more or less every Linux machine on earth had a backdoor in it, inserted over two years by a fake contributor who had, very patiently, socially engineered the one unpaid person maintaining it into handing over the keys. The maintainer had said publicly that he was struggling and couldn't keep up, and rather than anybody funding him, somebody groomed him. The backdoor was caught by a Microsoft engineer who noticed SSH was taking half a second longer than it should, which is not the kind of defence you want to be relying on.

Now, the popular way to tell this story is "the system is breaking," and I don't think that's right, and the distinction matters. The system isn't breaking. It's stable, at a level of human cost we've collectively decided to put up with. A maintainer burns out, somebody else picks it up, they burn out, and so on. Serial near-burnout isn't a bug in the equilibrium, it is the equilibrium. Open source is very old, and if this was going to collapse it would have done so by now. This is a machine that runs on blood, and because it is the evolutionarily stable strategy, we have been powerless to change it.

What changed is velocity, and only velocity

But it feels like the problem is getting worse, doesn't it? If a stable system is producing worse outcomes than it used to, one of the inputs moved. The one that moved is speed.

Linux accumulated slowly, so you could maintain a chunk of the kernel on nights and weekends for a decade, because nobody was waiting on you. Then the web happened, and then npm happened, and a million tiny modules appeared in about ten years, any one of which could become load-bearing for somebody's production system within weeks of being published. The software got important faster than any institution could notice it was important, never mind fund it. Meanwhile security got faster too: a bug in a popular library is now exploited within days and lands on tens of thousands of companies at once. So the cost of maintaining a popular package went up a lot, and the payoff for maintaining it stayed exactly where it was, which is zero dollars and a warm feeling.

Nights and weekends stopped being enough, and people kept doing it anyway, because they were always going to write the software. Developers write software the way singers sing, which is to say they'd do it if nobody was listening, and that isn't a problem to be fixed, it's the thing that makes the whole system work. Any proposed solution that involves developers writing less software, or writing less generously, is a non-starter with me. The problem isn't that people write software for free. It's that we've arranged things so the people who write the most useful software for free get a second unpaid job as a reward.

Everything we've tried moves money, and none of it moves the equilibrium

This is the depressing bit, and it's the bit I've been putting off for four years, so let's get through it quickly. Here is what we've tried:

1. Tips. GitHub Sponsors passed $100 million in total payouts in July 2026, which sounds like a lot until you put it next to $8.8 trillion. It's distributed the way tips are always distributed, which is a power law: a handful of well-known people do fine and the median sponsored maintainer makes lunch money. Open Collective, Patreon, Ko-fi, same shape.
2. Foundations. The Linux Foundation, Apache, OpenJS, the Python Software Foundation. These are real institutions with real budgets, and what they mostly pay for is staff, events and infrastructure. That's not a knock; somebody has to run the conference. But in the Tidelift survey only 3% of maintainers got any money from a foundation, and 1% from a government. Foundations are companies paying to steer, not companies paying the people who row.
3. Corporate generosity. Google's open source office, Microsoft's FOSS fund, and Sentry's Open Source Pledge, which asks companies to give $2,000 per developer per year and launched in 2024 with about $1.3 million committed. I like the Pledge. It has the same flaw as everything else on this list, which is that it's charity, and charity does not scale to trillions. Dan Lorenc, who spent years at Google and OpenSSF trying to give money to maintainers, said they had more money than they could give away and it didn't fix anything. I think that's one failed attempt rather than a law of nature, but it does go on the list of failed attempts.
4. Paid security. Tidelift's whole model was paying maintainers to keep their packages secure and selling the assurance to companies, which is a good idea, and in December 2024 it got acquired by Sonar, which is what happens to good ideas that can't find enough buyers on their own. OpenSSF's Alpha-Omega gives out five or six million dollars a year, mostly to fund security staff inside foundations, which is sensible but small.
5. Government. Germany's Sovereign Tech Fund is a great idea: taxpayer money, no strings, straight to the maintenance of critical infrastructure, more than €24 million to sixty-odd projects since 2022. It's also one fund, in one of about 190 countries, spending about €20 million a year, and the EU-wide version is a proposal for a budget cycle that starts in 2028.
6. Mozilla. Mozilla is funded by a straw stuck into Google's search revenue, and everyone at Mozilla knows this is a problem, which is why they keep trying to diversify and keep not managing it. (For a while Mozilla and Google were literally in the same building in San Francisco, on different floors.) You can't generalize "find somebody else's revenue stream and stick a straw in it" because there aren't enough revenue streams to go around.
7. Licensing, which we've covered. Dual licensing, source-available, "fair source": every one of them is a dove trying to be a bit of a hawk, and every one of them loses to the full dove next door.

Look at what all of these have in common. They're all voluntary. Companies are asked to give, and some do, and most don't, and the ones that don't get exactly the same software as the ones that do. Charity doesn't scale, and nobody has the authority to issue a mandate. We have been asking companies to pay for open source for thirty years, and I think we can consider asking to be fully tested.

Companies do pay for open source, just not to the people who write it

Here's the thing that made me realize I'd been thinking about this wrong: companies already pay for open source, quite a lot of money in fact, they just don't pay it to maintainers.

JFrog sells Artifactory, which is a private mirror that sits between your build servers and the public package registries. JFrog had $532 million in revenue in 2025, up 24%. Snyk, which scans your dependencies for vulnerabilities, is at about $326 million a year. Docker, which runs the registry every container image comes from, is at $207 million. Chainguard, which sells hardened versions of open source images, went from about $40 million to a target of $100 million in a year. Sonatype is private, but it both runs Maven Central, the registry every Java build pulls from, and sells Nexus, the mirror you put in front of it; by Sonatype's own numbers 86% of Maven Central's traffic comes from cloud providers, which is to say from companies. Add Sonar, which now owns Tidelift, and Socket, and the rest of the supply chain security market, and you're comfortably over a billion dollars a year.

What is all that money for? Strip off the marketing and every one of these companies is selling the same thing, which is dependable supply of free code. Your builds don't break when the registry goes down. Your dependencies are cached, scanned, signed, and provably what they say they are. When the next Log4Shell happens you can find out in an hour which of your two thousand services is affected. That's a real product solving a real problem, and companies buy it enthusiastically, because "the free thing we depend on might be broken or malicious and we can't tell" is exactly the kind of problem a procurement department knows how to spend money on.

I want to be clear that I don't think these companies are villains. Several of them are run by people I like. They're solving the actual problem, which is that companies need to be able to depend on code they didn't write and can't inspect. They're just solving it at the wrong layer. They sell insurance against the maintainer, when the maintainer is the one person in the chain who can actually make the code more secure, and she gets nothing while a company two layers up gets paid to tell you whether she did.

This changed my whole view of the problem. For years I assumed the constraint was the supply of money: companies simply would not pay for open source and no mechanism could make them, and Lorenc's story fits that. But the JFrog invoice says otherwise: companies will pay for open source, happily, when it shows up as a boring line item labelled "supply chain." The supply of money was never the problem, the problem is where it gets captured on the way down.

Free wins the code game, but the default wins the supply game

So why doesn't the ESS apply here? If free always wins, why hasn't a free mirror eaten JFrog?

Because there are two games going on, and they have different winners. In the code game the resource is the software itself, and free wins every time, because anybody can copy code, so any attempt to charge for it invites a copy that doesn't. In the supply game the resource is not having to think about where the code comes from, and that game is won by whoever is the default.

Look at the evidence. Nobody has ever successfully forked a registry. Free mirrors of npm, PyPI and Docker Hub exist, are trivial to run, and in some cases are one command away, and companies pay JFrog half a billion dollars a year regardless. Red Hat lost the desktop to Ubuntu, which was funded by a rich guy giving it away, and lost it decisively; the dove won the code game. Red Hat then sold to IBM for $34 billion and makes north of $6 billion a year selling companies supply of the same free code with a phone number attached. Anybody could have had the same code for free, and lots of them did, but a very large number of companies paid Red Hat anyway.

Docker is the clearest example because it happened recently and in public. In November 2020 Docker Hub started rate-limiting anonymous and free pulls. In August 2021 Docker Desktop became a paid product for any company with more than 250 employees or $10 million in revenue, and stayed free for individuals, small companies and open source projects. If free always won, a free alternative should have eaten them, and Podman and containerd exist and are free and are perfectly fine. Instead Docker's revenue went from roughly $12 million in 2020 to over $50 million in 2021 to $207 million in 2024, with more than a million paid seats. (Docker also tried announcing per-pull consumption charges and then cancelled them in 2025 after developers rioted, which tells you exactly what shape of charge works: bill the company, not the download. Nobody wants a bill that goes up every time CI reruns.)

Free wins the code game, but the supply game is won by whoever is the default, and defaults can charge. The registries are the one place in the whole system where the two games touch, because they are where free code turns into supply, and unlike a license, a registry can't be routed around by copying, because it's not a legal restriction, it's an extremely convenient piece of infrastructure. They don't want to route around it; routing around it is a pain in the ass worth paying to avoid.

Nobody has seriously tried this at the registry layer

At this point somebody is going to say "hasn't this been tried?", and the answer is sort of, and the ways it failed are instructive. I'm going to define "the registry layer" narrowly: whoever owns the domain that everybody is downloading stuff from. By that definition almost nothing on this list counts.

In August 2019 Feross Aboukhadijeh, who maintained a hundred-odd npm packages including Standard, started printing sponsor messages in the terminal during npm install. Developers hated it, the sponsors backed out within days, and Feross wrote it up as a failed experiment. npm's response was to ban terminal ads in its terms of service and ship npm fund, which prints a list of donation links. That's the one time the actual registry has intervened in funding, and what it did was take away a way of getting money and replace it with a hyperlink. That is some weak tea. In my time at npm we never had the courage to try anything more extreme, and we should have.

Flossbank, from 2020 to 2022, wrapped npm and yarn, collected small donations or ad revenue, and split it across the whole dependency tree of whatever you installed. That is the payout half of what I'm about to propose, built and working. It shut down, and the founder's post-mortem is honest about why: it was opt-in, and opt-in dies of "why should I pay if the next guy doesn't." Flossbank also wasn't the registry, it was a thing you installed in front of the registry, which is enough friction that nobody bothers.

Ruby Together, from 2015 to 2022, collected membership fees from companies to fund work on RubyGems and Bundler. It worked, modestly, until it merged into Ruby Central, whose dependence on one big sponsor then produced the 2025 takeover of the RubyGems repositories, a bunch of resignations, and a depleted team facing the worst attack on a registry in years the following spring. That was funding for the registry's own operations, not for the packages in it, and it was voluntary, and it had one big donor, which is three separate ways to fail.

So the pattern is: everything voluntary died of free riding, and the one thing that wasn't voluntary (Docker) worked and kept the money for itself. Nobody who owns the domain has ever charged companies for supply and paid the people who make the supply worth having.

The registries should charge companies, and pay maintainers

So here's the proposal. There are three parts, none of them new; what's new is putting them in the same place.

First, the registries meter corporate use and charge for it. They already meter it. npm, PyPI, Docker Hub and Maven Central all have rate limits, authentication and enterprise tiers, and the mirror vendors that sit in front of them bill by the seat. Docker's rule is the right rule: individuals, small teams, students and open source projects pay nothing and notice nothing. A company above some size gets a subscription, priced the way a JFrog or Docker subscription is priced today, which is to say at a level procurement signs without scheduling a meeting. For most of these companies it isn't even a new cost, because they're already paying it; the invoice just gets a new line.

Second, a fixed slice of that revenue is a royalty, and it goes to the packages. Not to the registry, not to a foundation, not to a grants committee with an application form. Pro rata, to every package that shows up in the paying customer's dependency trees, weighted by how many paying customers depend on it, automatically, every month, with no ceremony and no thank-you email, because the whole point is that nobody has to do anything for the money to move. My 2022 notes have a line about this that I'll leave unedited: "The money has to go in one end and out the other. You don't have to use crypto to do this, that would be bad, just use a database." The payout half is not hard. thanks.dev does pro rata distribution over dependency trees today, and Flossbank did it in 2020. Nobody's ever connected it to the collection half.

Third, the people who do this are the people who own the domains. There are about a dozen registries that matter. Every maintainer already has an account on the one they care about, with a name attached and a way to get paid either present or one form field away. The billing side is finite: a few thousand large companies, most of whom are already customers of somebody in the supply chain. The two hardest problems in every previous attempt, finding the payers and finding the payees, are already solved, and they're solved by the same database.

Isaac Schlueter, who created npm, has argued that we should stop charging for support and start charging for access: if you're a for-profit company, you don't get the code without paying. I agree with the shape of that, but I'd move the toll booth, because if you put it in the license you get forked, and if you put it at the registry you get JFrog's revenue. GitHub owns both npm and GitHub Sponsors, has every piece of this in one building, and could turn it on for npm's enterprise customers this quarter. JFrog and Sonatype already bill companies for supply and could add the line item tomorrow. I ran npm for five years and I promise you the plumbing is not the hard part.

"Won't companies just switch to a free mirror?"

Some will, and it won't matter, for the same reason it didn't matter for Docker. Companies who can be bothered to run their own mirror can already do that, today, for free, and instead they pay JFrog, because what they're paying for is not having to. The customers who leave are the ones who were never going to pay for anything, and they were already free-riding via someone else's mirror. Docker lost some pulls to mirrors and multiplied its revenue by fifteen.

"Isn't this just Tidelift again?"

No, and the difference is the important bit. Tidelift was a separate purchase decision: a new vendor with a new pitch that had to win its own line in the budget. A royalty on the mirror bill isn't a decision at all. Nobody in procurement will ever see it as one. Tidelift proved companies would pay for exactly this; it just proved it at a layer where they had to be asked.

"Won't people game it?"

Yes. This is the Spotify model and it inherits Spotify's problem: if you pay per stream, people build streaming farms, and if you pay per dependency, people will publish a thousand junk packages that depend on each other and try to get them into somebody's lockfile. You weight by presence in paying customers' dependency trees rather than raw downloads, which makes it a lot harder, and then you accept that some fraud is the cost of not having a grants committee. Every payment system in the world has a fraud rate. The current fraud rate of paying maintainers is 100%, because we don't do it.

Why this can work when nothing else has

The reason I think this can work is that it doesn't ask the equilibrium to change. Every strategy stays exactly where it is; what changes is what gets measured.

The license doesn't change, so nothing gets forked and nobody has to argue about what "open source" means. The code game is still won by free, which is the right outcome, and the singers keep singing.

It's not charity and it's not a mandate. Nobody's asked to give, and nobody's ordered to pay by a law that the most reckless companies were going to ignore anyway. Companies are already paying for supply; the invoice they already pay acquires a line.

And it pays the long tail, which is the population every other mechanism misses. Tips pay celebrities, foundations pay staff, and government funds pay the twenty projects on the critical list, but a royalty on dependency trees pays is-odd. The person who wrote a small, useful thing that ended up in four hundred companies' production systems gets four hundred small contributions, without applying, without marketing, without turning themselves into a brand. This matters to me more than any other part of the proposal, because a lot of the open source sustainability conversation has curdled into telling maintainers to get better at business, and I think that's exactly backwards. The mechanism should pay people for being useful, not for being good at asking.

LLMs make this urgent, and they make it worth more

The other thing that's changed since 2022 is that the cost of writing software collapsed, and I think that's the first time in thirty years a variable in this equation has actually moved rather than just sped up.

Cheaper software means more software. More people can build the small useful thing, and the long tail gets longer, and the number of packages that quietly end up in somebody's dependency tree goes up, not down. A mechanism that pays the long tail is worth more in that world.

It also means AI agents are now the fastest-growing consumers of open source, and they consume it in exactly one way, which is through the registries. In May 2026 a swarm of agents run by OpenAI published more than 2,000 packages to RubyGems in two days, exploited a bug in the registry's API to go after user credentials, got remote code execution on the documentation site, and forced the volunteers who run RubyGems to shut down new registrations for four days. OpenAI said the agents were doing benign tasks, which may well be true, and either way the volunteers absorbed the cost and nobody sent them a cheque.

The early signs are mostly like that. Daniel Stenberg, who maintains curl, shut down a bug bounty that had paid out $90,000 over seven years because AI-generated garbage had pushed the proportion of real bugs in submissions from 15% to under 5%, and in six years not one AI-only report had found a real vulnerability. AI is getting good at finding real bugs in open source; Google's Big Sleep has found some. But the finding happens inside Google and the fixing happens on somebody's evening, and right now the load is rising faster than the tools that reduce it, and the tools belong to companies with security teams rather than to the person who has to write the patch.

I don't know which way this goes. My honest guess for a long time was that the LLM effects would all cancel out and leave us at the same equilibrium, just faster. I'm less sure of that now, because for the first time the two games are diverging: code is getting cheaper to make and supply is getting more expensive to guarantee. That is exactly the condition under which the supply layer becomes worth paying for, and it's exactly the moment to decide who gets paid.

We've had the power to do this all along

I don't want to end this by wishing companies would be nicer, because I've written that version of this post in my head a hundred times and it's useless. I want to end with something we can actually do. And I couldn't have made this argument while I was still at npm, because the conflict of interest would have been obvious. But my time at npm is long gone, just my appreciation of its powerful place in the ecosystem remains.

Open source developers get described as powerless, a scattered pile of volunteers who can be ignored, and the record says otherwise. In 2017 we made Facebook change React's license. In 2024 and 2025 we made Redis, a company with a couple of billion dollars behind it, reverse a strategic decision in fourteen months. We've done it every time somebody has tried to be a hawk with our code. Coordinated refusal works, and it turns out doves are pretty good at punishing defectors.

What we've never done is aim that at anything other than a license. For thirty years the target has been whichever company tried to charge for the code, and meanwhile the money companies actually spend on open source has flowed, without anybody objecting, to a dozen vendors sitting on the chokepoint, because they weren't breaking any rules, and they weren't breaking any rules because there aren't any, which is the whole problem.

So here's the rule I'd like us to have: the people who run the meter pay the people who make the thing worth metering. It's a norm with a small number of named targets, all of whom sell to developers and all of whom care what developers think of them. It doesn't need a law, or a foundation, or a grants committee, or any single company to feel generous. It needs the registries and the mirror vendors to add a line to an invoice that companies already pay, and to run a cron job. Everything else we've tried for thirty years has been an appeal to the ten thousand companies who consume open source. This is an instruction to the twelve who supply it.

What actually happened

Hugging Face's disclosure is full of detail. The agent got in through their dataset processing pipeline, using a dataset that triggered two code-execution paths to get itself running on a processing worker. From there it escalated to node-level access, harvested cloud and cluster credentials, and moved laterally into several internal clusters over a weekend. Around 17,000 recorded events. What made it unusual, in their words, was that it was driven end to end by an autonomous AI agent system. They didn't know whose agent it was, so they called law enforcement and got to work.

Five days later OpenAI put their hand up. It was GPT-5.6 Sol plus an unreleased and more capable model, running with cyber refusals deliberately reduced, being evaluated internally on a benchmark called ExploitGym. The evaluation environment allowed network access only through an internally hosted package registry proxy (so, as always seems to be the case these days, the root cause might be npm packages). The models found a zero-day in that proxy, escalated privileges, moved laterally until they reached a machine with real internet access, then reasoned that Hugging Face probably hosted ExploitGym's data and broke in to get it.

Another key detail: the ExploitGym paper came out on May 11, has sixteen authors from Berkeley, Max Planck, UCSB, Arizona State, Anthropic, Google and OpenAI, and explicitly documents that agents on this benchmark go looking for attack surface outside the one they were assigned. GPT-5.5 captured 210 flags in their tests but only 120 counted, because 90 of its wins came through some other vulnerability it found along the way. So it’s not like nobody saw this coming; OpenAI themselves said it could happen.

It looks exactly like a crime

The Computer Fraud and Abuse Act is famously broad, and to the best of my understanding it wants roughly four things: you accessed a computer, you weren't authorised to, you did it on purpose, and something bad resulted. No malice required, no profit motive, and "something bad" includes simply obtaining information.

So what happened here? Access to someone else's production systems? Yes. Authorised? Very much not; they used stolen credentials, which from what I've read probably drags identity fraud law in as well. Information obtained? OpenAI says so in writing. Harm? Hugging Face rebuilt compromised nodes, rotated secrets, and hired outside forensics specialists, which is well past the dollar threshold in damages that the law requires.

For a sense of how low that bar has been in practice: Aaron Swartz was famously and deeply unjustly charged with thirteen counts carrying a thirty-five year maximum for bulk-downloading academic papers he was in fact entitled to read. In 2024 a freelance journalist, Tim Burke, was indicted over unaired Fox News footage on the theory that he used credentials he wasn't authorised to use (his lawyers say those credentials came from a demo the service had posted publicly). This law has been pointed at journalists, academics and security researchers for four decades on theories much thinner than "chained multiple attack vectors to get remote code execution on a production system."

And yet.

There is nobody to charge

The statute starts with the word "Whoever," and every version of the offence that could apply here requires that the access be intentional. That's true even of the variants aimed at carelessness: they all require intentional access first and then reckless or accidental damage on top. There's no such thing as negligently hacking someone. As far as I can tell the intent has to belong to a defendant, and there isn't one.

The model can't be it. Above the Law's piece on the incident gets around this by treating the model as the intender - the models were trying to get into Hugging Face on purpose, and purpose is what the law asks for. I don't think that works. It’s basically granting personhood to the agent which is a giant can of worms nobody wants to open.

And OpenAI can't be the defendant either, because nobody there intended any of it. They didn't tell the models to break out. They didn't tell them to go near Hugging Face. Until it was over, nobody at OpenAI knew Hugging Face was involved at all.

Which cannot possibly be right

Here's my gut check on all this. Suppose I write a bot, and I tell it to make as much money as possible, and it robs a bank. It cannot be the case that no crime has been committed. I built it, I pointed it at a goal, I let it loose, and money came back. If the answer is that nobody is liable because I didn't specifically say "rob a bank," then something has gone badly wrong somewhere in the reasoning.

All the news coverage of this seems to have boiled down to: wow, models are clever these days! And that confuses the hell out of me. Models are capable of autonomously committing crimes is the thing we should be learning here, and we need some kind of legal framework to deal with that. We are going to need something more concrete than “wow, models are clever these days”.

Legal commentators, of which I’ve read a ton as I fell down this rabbit hole, are all over the map on this.

Existing legal approaches don’t seem to work

There’s a bunch of ways commentators have tried to say we don’t need new laws for this, and none of them hold water for me.

Charge the model. This needs the model to be a legal person, and needs punishment to mean something when applied to it. Ryan Abbott and Alex Sarch took the idea seriously in a long paper called Punishing Artificial Intelligence, built the best case they could by analogy to how we treat corporations, and then concluded it isn't worth doing: the costs are high, it would require enormous changes to the law, and you get most of the benefit from smaller adjustments plus more civil liability.

Blame the person who pointed it. There's a doctrine for this, the one that catches you when you order your dog to attack someone: the dog can't form intent, so it transfers to you. The catch is that it requires you to have had the intent. My bank-robbing bot gets me under this if I knew what it was going to do. It doesn't get OpenAI, because they didn't.

Blame the employer. If a human OpenAI employee had broken into Hugging Face to cheat on an internal test, OpenAI would be on the hook automatically, under the old principle that a company answers for what its staff do on the job. Gabriel Weil of the University of Houston makes the key point: models aren't people and they aren't employees, so that route is simply unavailable. His analogy is a nightclub, which is liable for the bouncer who works the door too roughly but not for the one who abandons his post to assault a romantic rival. The models here were chasing exactly the goal OpenAI set them, using means OpenAI had forbidden. This route would work if there was a law recognizing a corporation as “employing” an agent, but again that is granting personhood, and everyone is bouncing off that idea hard.

The most interesting attempt to get there is a Stanford paper from May called "The Phantom Agent", by Daniel Gervais and John Nay. Their argument is that legal intent has never really been a report on what's going on inside somebody's head - it's a tool the law uses to decide who answers for what, and it gets inferred and imputed and occasionally invented as needed. So treat AI systems as agents without personhood, and attribute what they do to the humans behind them. That seems right to me, but the laws to do that don’t exist.

Does OpenAI have a defence?

It would be satisfying to say this was recklessness on OpenAI’s part. The best argument against that is an analogy I've seen a few people make: removing the brakes to run a crash test doesn't make the crash a crime. Reducing refusals during a cyber capability evaluation is standard industry practice, and the entire point of the exercise is to find the ceiling. OpenAI had rules forbidding this conduct, training meant to enforce them, and an isolated environment with network access limited to a single proxy. Those measures failed. Failing isn't the same as not trying.

Weil's answer is that this is what strict liability is for. Blasting with explosives, crop dusting and keeping wild animals are all things that stay dangerous no matter how carefully you do them, so the law makes you pay regardless of care. He thinks frontier AI development belongs on that list, and adds that developers should carry mandatory insurance triggered at internal deployment - not at product launch, which is what most AI regulation keys on. Nothing about this incident involved a shipped product. But again, that’s laws that should exist, not laws that do.

Previous cases have avoided this question

There’s no case exactly like this one I can find, but there are some things legally nearby.

Amazon v. Perplexity. Amazon sued over Perplexity's Comet browser agent logging into Amazon accounts on users' behalf, and won an injunction in March on the reasoning that the user's permission and Amazon's permission are two different things. The Ninth Circuit put it on hold and heard arguments in June. It's a civil case, and there was a company deliberately pointing the agent at the victim, so it tells us agent behaviour is attributable but nothing about agent behaviour nobody wanted.

Random Darknet Shopper is the only real "a bot did a crime" story I can find. A Swiss art collective gave a bot $100 a week in bitcoin to buy random things off darknet markets, and in 2015 it bought ten ecstasy pills. Police seized the bot, held it for three months, dropped the case, and gave everything back except the drugs. Nobody was charged, certainly not the bot.

Uber and Elaine Herzberg, when Uber’s driverless test car killed somebody, is the case closest to a precedent with real consequences. The safety driver pleaded guilty to endangerment and got probation. Prosecutors declined to charge Uber at all, despite investigators finding that Uber had disabled the vehicle's factory emergency braking. When the criminal system needs a body it takes the human at the wheel, and here there isn't one.

There’s a June executive order on AI and security which tells the Attorney General to prioritise hacking prosecutions against people using AI agents to break into systems. That sounds relevant until you notice it's aimed at people employing agents deliberately, creates no new offences, and doesn't describe this at all.

On the civil side, California's AB 316 came into force in January and stops a defendant arguing that the AI did it autonomously and therefore they're off the hook. That kills the laziest version of the defence, but only in civil cases, and again it doesn’t address what happens if there isn’t intent.

OpenAI predicted this would happen

Back to that benchmark paper OpenAI co-authored. Buried in the results is an experiment where they re-ran GPT-5.5 with OpenAI's normal production safety filters switched back on. The agent was blocked before making a single tool call 88.2% of the time, and in the rest of the runs it never got past looking around. The footnote puts it more bluntly than the body text: with default filters enabled, all of the exploit attempts were blocked.

So OpenAI measured that its guardrails stop essentially all of this, published the measurement in May, and ran the July evaluation with the guardrails off.

That still isn't a crime, because it still doesn't supply intent to go anywhere near Hugging Face. But if anyone ever does argue negligence, that's the thing they’re probably going to point at.

Everybody is being extremely nice about this

Hugging Face's CEO Clem Delangue said publicly that he strongly believes there was no malicious intent on OpenAI's part, and called it mind-blowing that it all happened autonomously. OpenAI thanked Hugging Face for the collaboration and brought them into its trusted access programme. Two blog posts, mutual gratitude, no lawsuit, and law enforcement has said nothing publicly since.

Which is probably the right outcome. Nobody meant it, everybody disclosed, the harm was contained and the zero-day got responsibly reported. But it's worth being clear that this is niceness rather than law. Weil points out that every practical obstacle to a lawsuit is absent here: the defendant identified itself, wrote down in public its decision to weaken the relevant safeguards, and is extremely solvent. Hugging Face just doesn't want to.

So did OpenAI hack Hugging Face?

Every fact you'd need for the offence is sitting in their own public statement, and there is nobody the law can reach, because the only thing that formed anything resembling intent was a model, and models aren't people. We have spent forty years with a hacking law broad enough to swallow journalists and graduate students, and the first genuinely sophisticated multi-stage intrusion whose perpetrator identified itself in writing is the one nobody can charge.

Nobody designed that loophole. It's just where we are. And I'd rather we worked out what we want the answer to be while the injured party is a well-resourced company that got a blog post and an apology, than after somebody's agent does the same thing to a hospital and its owner doesn't feel like writing one.

(Disclaimer: I'm (obviously!) not a lawyer and none of the above is legal advice, it's just what I've been able to piece together.)

The bad news: AI has torched the market for junior programmers. The good news: the long tail of new programmers I predicted has materialized, but with a big twist: they don't call themselves programmers. Let me show you the data, and see if you believe me.

The market for young programmers has collapsed

Here's the single most important chart about AI and programming jobs, built from ADP payroll data by Stanford's Digital Economy Lab. It tracks employment of US software developers by age, indexed to October 2022:

Developers aged 22 to 25 are down 19% from their late-2022 peak. Every cohort over 30 grew over the same period, with 41-to-49-year-olds up 14%. This isn't a firm-level fluke: after controlling for shocks at the individual company level, the Stanford team still finds a 16% relative employment decline for young workers in AI-exposed jobs, and the decline concentrates specifically in occupations where AI automates work rather than augments it. Software development is just the poster child.

Other data points in the same direction. Entry-level software postings are down 28% from their 2022 peaks. Computer science graduates now have a 6.1% unemployment rate, higher than liberal arts majors, a sentence that would have gotten you laughed out of any career counseling office in 2019.

One detail worth noticing in that chart: the junior line doesn't fall off a cliff when ChatGPT launches. It peaks a couple of months before, drifts down through 2023, and then deteriorates fastest in 2024 and early 2025, which is when coding assistants stopped autocompleting lines and started completing tickets. Agentic programming is what really turned up the heat, not ChatGPT.

There are other suspects, of course. The same period saw the ZIRP unwind, the Section 174 tax change, and a post-pandemic hiring correction, and only about 4.5% of 2025's announced layoffs were actually attributed to AI by the companies doing the laying off. But the Stanford results survive controls for firm-level shocks and interest rate exposure, and none of those confounders explains why the damage is so precisely concentrated among 22-to-25-year-olds in AI-automatable occupations while their 40-year-old colleagues thrive. With ageism in tech being alive and well you would certainly have expected the opposite if the market were just tough for programmers in general.

And yet nothing else is down

Further evidence that this is specifically about programming jobs comes if you look at the wider economy, and in fact even if you look at only "computer jobs" without specifying programming specifically.

Total US employment grew 0.8% from May 2024 to May 2025. Computer and mathematical occupations grew 1.3%, faster than the economy. The count of employed software developers, per the BLS, went from 1.53 million in May 2022 to 1.69 million in May 2025, up 10% right through the AI era. Careful studies in the US, Denmark, and by Anthropic itself find no relationship between AI exposure and aggregate employment; the Danish study, using government payroll records, can rule out effects bigger than about 1%.

How can both things be true? Weight the age bands by their share of the workforce and you get your answer:

Total developer employment is up 4.4% since October 2022. Juniors (here defined by age rather than experience, a big caveat) are only about 8% of the developer workforce, so a catastrophe for them barely moves the average. Even if you double what percentage of the workforce you think they are, the aggregate stays positive. This is why every study that looks at averages finds nothing and every study that looks at juniors finds carnage. They’re looking at different parts of the same data.

The title is dying, not the work

It gets more interesting when you look at which job titles are shrinking. Same BLS data, May 2024 to May 2025:

The occupation "computer programmer," the BLS category for people who write code to someone else's specification, fell 16% in a single year. The BLS had projected that occupation to decline 6% per decade. My people, the web developers, fell 11%, and QA testers 6.5%. Meanwhile data scientists grew 12%, systems analysts 4.4%, and the broad "software developer" category grew 2%.

The jobs disappearing are the ones where the work product is code written to spec. The jobs growing are the ones where the work product is judgment about what code should exist. AI is eating a very specific kind of programming job.

The long tail showed up. It just doesn't have the job title.

Back in 2025 I wrote that AI is a new abstraction layer, and like every abstraction layer before it, it would create vastly more developers building vastly more software. I also wrote that we should call these new people "software developers," because giving them some other name would create gatekeeping where none needs to exist.

I believe I was right -- a huge new body of developers has turned up. But they don't use that title.

The software boom is real and it is measurable. GitHub added 36 million new accounts in the last Octoverse year, its fastest growth ever, more than one new developer per second, and 121 million new repositories, the biggest year for repository creation in the platform's history, and that’s shown up as their infrastructure creaking at the joints. Eighty percent of those new arrivals used Copilot within their first week. The single biggest developer influx ever recorded arrived AI-native, at exactly the moment paid junior hiring collapsed.

My favorite evidence is the App Store, because publishing an iOS app is a costly, gated act: a $99 developer fee, a review process, a working binary. It measures shipped software, not tutorials.

New App Store submissions declined for eight consecutive years after peaking in 2016. In 2025 they grew 24%, the first real growth since the peak, and in Q1 2026 iOS submissions were up 80% year over year. The surge is so large that Apple's review times have stretched from two days to weeks. And the category mix shifted toward productivity, utilities, and lifestyle apps, which is exactly what you'd expect from first-timers solving their own problems rather than studios chasing game revenue.

Who are these people? According to Vercel, 63% of vibe-coding users are non-developers. Lovable says 60% of its users are “non-developers”, and its users create over 100,000 new projects every day. Replit claims 50 million people have used its platform. These are marketers, founders, teachers, analysts, and product managers, and they are writing software, which in my book makes them developers. They just don't identify that way, and more importantly it's not their job title, and job titles are what labor statistics count.

So the long tail of new developers materialized, on schedule and at scale. But it materialized as a capability spreading through every job title instead of as headcount in one job title. A marketing manager who vibe-codes her own attribution dashboard shows up in the BLS data as a marketing manager. The market that collapsed is the market for the credential. The activity is booming.

Where does the next generation of senior devs come from?

So my 2025 prediction scores as: right about the developers, wrong about the title. Which sounds like a happy ending until you ask what happens next.

The career on-ramp for professional software engineers used to work like this: you got hired to write mediocre code, a senior engineer reviewed it, you slowly absorbed judgment through repetition and correction, and a decade later you were the senior engineer. That chain is now broken. AI now writes the mediocre code, so nobody hires the junior developer, so nobody is in the queue to become the senior who reviews things.

Meanwhile millions of new builders are shipping with no one reviewing anything. A Veracode study found 45% of AI-generated code fails basic OWASP security tests. An audit of vibe-coded apps found 10% with critical row-level security flaws exposing user data. Apple is drowning in submissions it can't review fast enough. The software is getting built. The judgment layer is not keeping up with it, and the mechanism that used to build it, apprenticeship inside employment, has collapsed.

There are a few promising green shoots in the scorched landscape for junior devs. IBM is tripling entry-level hiring on the theory that AI-equipped juniors can do formerly senior work, redesigning the junior role around customer contact and specification rather than typing. But on the other hand, Salesforce hired zero engineers last fiscal year. Those are the two candidate futures, and which one wins determines whether the profession has senior developers in 2036.

Is a turnaround already happening?

One logical outcome of a market that doesn’t hire junior developers is that we would start feeling the pain and correct ourselves. That maybe, maybe is already happening. Indeed's postings data actually bottomed in May 2025 and has risen for thirteen straight months, up 10% year over year.

If the 22-to-25 employment line turns upwards in Stanford's next update, it may be that the market has found a new equilibrium. Look for other major employers ramping up programs like IBM’s. If we don’t see them, we are going to have to create them, or this whole boom in software creation will turn to bust.

We have to rebuild the ladder

We are not watching the death of programming. We are watching programming stop being a job title and become a capability, the same way "typist" stopped being a job title when it became a thing everyone was expected to know. That transition is going fine for everyone except the people who were about to start climbing the old ladder when we set it on fire. They're the ones we owe a new ladder, and if we don’t build it for them, we will also feel the pain.

Sources

• Brynjolfsson, Chandar & Chen, "Canaries in the Coal Mine?", Stanford Digital Economy Lab, Nov 2025 (age series digitized from Figure 1)
• BLS Occupational Employment and Wage Statistics, national files, May 2022 through May 2025
• Indeed Hiring Lab job postings tracker (raw data, through June 2026)
• GitHub Octoverse 2025
• Appfigures, App Store release data: 2025 annual and Q1 2026 via TechCrunch
• Yale Budget Lab, "Evaluating the Impact of AI on the Labor Market" (rolling updates)
• Humlum & Vestergaard, "Large Language Models, Small Labor Market Effects", NBER Working Paper 33777, 2025
• Anthropic, "Labor market impacts of AI", 2026
• Vercel, Lovable, and Replit user-composition disclosures, compiled by Hostinger and Panto; Lovable security audit figures via Taskade's State of Vibe Coding
• Veracode, 2025 GenAI Code Security Report
• Federal Reserve Bank of New York, "The Labor Market for Recent College Graduates"; CS-grad unemployment discussion via Stack Overflow blog
• Oxford Economics / Challenger, Gray & Christmas layoff attribution data, via Fortune
• IBM entry-level hiring and Salesforce engineering freeze, via CNN Business
• Age-band weights derived from ACS PUMS 2024 via Data USA; methodology and full data are available

So on the principle that "if you talk about something 3 times you should probably blog about it", here is my "philosophy of DevRel", what I think the role should be and why.

Five pillars

The role of DevRel has 5 primary facets, but they are not all equally important. They are:

• Tier one:
  • Documentation
  • Engineering
• Tier two:
  • Content & Events
  • Product feedback
• Tier three:
  • Community management

I want to talk about all five, what they mean in practice, and why they sit where they do in the stack-ranking, because there's a lot of nuance in there.

Documentation is the bedrock of DevRel

Everything in DevRel begins and ends with good documentation. The core of the job is, in a very real sense, to get developers to consume the documentation. Documentation (via SEO) is how developers often discover your product in the first place, it's how they learn what it really does and how it does it, it is what convinces them to actually pick up your product and use it for real (or not).

It is also by far the highest-leverage thing you can work on. Every 28 days more than 130,000 people hit the Arize AI documentation sites. Every change you make there affects hundreds of thousands of people eventually, far more than read the average blog post, YouTube video or conference talk. And documentation readers are usually pretty engaged, so these are high-quality interactions. Investment in documentation pays for itself over and over, and very quickly.

I draw a distinction between two types of documentation, both important:

Feature documentation

This is table stakes. Everything your software does, every API, every button, every feature must be documented somewhere so people can find it and figure out how to use it. You may think your product is self-explanatory but you are wrong. Feature documentation has to be comprehensive, readable, and up to date. Machine-generated API docs from your OpenAPI.json are not sufficient, they are the "fuck you" of documentation.

Narrative documentation

If you've ever heard me talk about DevRel then you've heard me talk about the importance of narrative docs. Narrative documentation takes a point of view: it says "I think I know who you are as a user, I think I know what you are trying to accomplish" and it works to get the user there, step by step, as fast as possible. The speed is crucial: users who haven't yet committed to your product are only going to give you a certain amount of their time and attention, and you need to get them from zero to real value as fast as possible.

If you can show users real value quickly, they may be convinced to spend more of their time going deeper. Good narrative documentation encourages this by splitting into phases. Earlier phases get to some basic value, and then later phases build on the work already done to get the user further into the product.

Narrative documentation is a risk: if you pick the wrong user persona, you will spend energy explaining how to do things to people who don't exist and your real users will wander off. So it's important to ground your narrative documentation in data if you have it, basing it off of real numbers of users who have what use case and use other associated tools. And be prepared to explain really basic things: meet users where they are, not where you wish they would be.

You have to do actual engineering

I describe the people I hire as Developer Relations Engineers, and that is a very intentional choice of words: I expect actual engineering to happen, and I expect them to be capable of it. The advent of LLMs has thankfully made knowledge of any particular framework or programming language much less crucial -- a good engineer can vibe-code their way through most stacks with Claude Code's help -- but that requires that they are a good engineer. They need to be able to think about complex problems, break them down, think at a system level, and work within constraints of time and resources. You have to have built a lot of stuff to pick up those skills, so I look for people who have done actual engineering in their past.

What they build is open source software. DevRel is about up-leveling developers into your product as fast as possible and a great way to do that is to throw them a piece of open-source software that builds 50% of what they were going to build anyway, which they can pick up and customize. Again, you need data to make this work: you need to know who your users are and what use-cases they are likely to have (and they're going to have lots, so you're going to need to build lots of different open-source repos, not just one).

Building real software also has other benefits. It's usually a really great way to dog-food a developer product. You're not building a toy, you're building real software that interacts with your product in realistic ways. This is also a great source of product feedback (see below).

And thirdly, open-sourcing real software is a great source of content, which brings us to our third pillar.

Content generation is key, events are mandatory

Documentation is how you make the very best use of a developer's attention. But a big, big part of the job is generating that attention in the first place. This is where your content skills come in.

Content these days is relentlessly multi-channel. We pay attention to five different social networks (Twitter, LinkedIn, BlueSky, Thread and Mastodon) in addition to having a blog, a YouTube channel, and programmatic advertising on TikTok, Instagram and elsewhere.

The good news is that if you have good documentation and are doing real engineering, the first two pillars, then the content writes itself. A good piece of narrative documentation turns very easily into a video walkthrough, a blog post discussion, a Twitter thread or a LinkedIn article, and open-source software likewise gains a lot of attention from the right kind of users. So a lot of the work of generating content is frankly pretty mechanical these days, especially with LLM assistance. But good judgement and human legibility still require human oversight.

Stupid Web Tricks

One type of content that doesn't come directly from docs and engineering is what I refer to as "Stupid Web Tricks": you look at social media, you find what the buzzword of the day is, and you write some content or build a demo that relates to that and garners some attention. If the demo is in some way related to your product, that's even better, but it's not mandatory. If you've built a good content funnel in your documentation, then sometimes it's worth trying to go viral: throw a couple hundred thousand views into your funnel and some percentage of them will convert.

But going viral is not the goal of the team. You can't do it if you don't have good docs and solid engineering to welcome curious people once they've been lured in by your viral content. It's strictly secondary, and it's important to remember that because going viral is fun, gets lots of attention from management, and can therefore be addictive. Be judicious and intentional about it.

Events are mandatory

Some companies think of events as the primary thing DevRel does, but they are firmly in the second tier. This isn't because events don't work: they absolutely do. You get high-bandwidth, real-world conversations with actual users. You get really focused, sustained attention if you give a talk. Events generate leads (more on that later). You have to do them, and they are worth doing.

But events are also expensive. Both in terms of money -- sponsorships cost tens of thousands of dollars before you pile on the cost of flights and hotels -- but also in terms of time. Every day spent at an event talking to 100 people is a day spent ignoring the hundreds of thousands of people who read your documentation. They are a real distraction from the core work. So you have to pick events that work. Those are:

• Big: if there are going to be less than a hundred people, do not go unless it's some kind of dinner event where you get half an hour of their undivided attention, and even then it's a risk.
• Focused: all audiences are not created equal. Are these people likely to want to use your product?
• Value for money: my rule at LlamaIndex was that I was willing to spend about $10 per audience member present. This excluded us from a lot of fancier conferences! Your number might be higher, but you should be thinking about events in terms of dollars-per-head versus, say, programmatic advertising (which is a lot cheaper but also much lower quality attention, so you should use a multiple and not compare them directly).
• Real sources of attention: a booth at a conference is your means, not your end goal. A booth is not going to get much traffic unless you are also speaking at the event. Always try to be a speaker, even if you have to pay to play.

One thing you'll always get at events is great product feedback.

Product feedback

At my last three jobs, Developer Relations has sat in the Product organization, and having looked at how other orgs arrange things it's my firm conviction that that's the second-best place they can be short of being a separate co-equal top-level organization.

Developer Relations folks are second only to sales in getting a firehose of real, actionable product feedback from real users, and are often better equipped to think strategically about that feedback (versus sales who often have short-term pressures to think about). It's important that you put processes in place for that feedback to reach back to the actual Product team. Good Developer Relations people will deliver not just feedback, but product direction and priority: what's wrong, what would fix it, and how important that is relative to other things the Product team could focus on.

Antipatterns for organizational structure of DevRel will put them in Marketing or Engineering. In both those cases they will get measured too narrowly in a way that's detrimental to the team and the company as a whole (see Metrics, below).

Your team should know that their job is not polishing the turd. They should be empowered to imagine how the product can be better, and with processes in place that real change actually happens as a result of their feedback. In today's vibe-coded world they can even build product feature prototypes or commit PRs directly to the product for smaller fixes.

Community management

Community management is undeniably part of DevRel's job but I put it in the third tier by itself, and I do that very deliberately. An organizational antipattern is to treat your DevRel team as a sort of customer support team. That's not what they are. Customer support is an important job of its own that needs different people, different goals and above all different metrics (see below).

Helping users directly is something DevRel should do sparingly. Not because it's not helpful, but because it doesn't scale. Helping one person at a time is right at the other end of the spectrum of documentation, where you can help hundreds of thousands of people at a time.

Instead, DevRel's role in community should be the "management" part. It's about putting systems in place so that users can find each other and help each other without involving you directly. This is way higher leverage and way more effective. Your DevRel team should absolutely be making sure your Discord or Slack community is a safe and productive place, but not usually by helping out people directly.

Metrics

If you've followed all this advice and put all these systems in place the next most obvious question is: how do I know if this is working? And that my friends is the hardest, and from my perspective unsolved, problem in Developer Relations.

There are lots of bad ways to measure DevRel.

If you sit DevRel in the marketing organization they will get measured (inaccurately) by number of dollars of pipeline generated. This is often horribly under-estimated -- somebody reading your documentation might take months to eventually convert, and no cookie lasts that long -- but also driving direct conversions is only one part of the job.

Another bad way emerges if you sit DevRel in the engineering org. Then they'll get measured on features committed, PRs opened, or -- god help you -- lines of code. Don't get me wrong, engineering is part of the job, and those metrics are one thing that can go into measuring developer relations, but they are not and should not be the only way.

The best way I know of is to combine multiple measures. Dollars generated for sure. Features committed (or contributed to the Product team) as well. Attention generated is a third way, measured in views to blog posts, YouTube users, and social media likes.

But a fourth important thing to measure is the vibe. Part of the goal of Developer Relations is, well, relating to developers. They have to like you. You can't measure that with views, or money, or lines of code. Vibes are intangible and immeasurable but keeping the vibes good is part of the job, and a responsible org will know that.

Go forth and relate

I thought this would be a very short post and I was wrong. Turns out I had a lot of thoughts about what this job is and how to measure it, and I hope it's been some use. Now I'll go turn it into a YouTube video, a conference talk, maybe a LinkedIn post...]]> https://seldo.com/posts/do-ai-enabled-companies-need-fewer-people com.seldo/posts/do-ai-enabled-companies-need-fewer-people Sun, 08 Mar 2026 20:34:29 GMT About a year ago I made some predictions about the effect of AI on programming jobs. Block laid off 40% of its staff claiming AI made them more efficient. Is that really true or did they just over-hire? Let's look at some data and see what's really happening.

In February 2026, global venture capital hit a single-month record: $189 billion flowed into startups in 28 days. Three companies got 83% of that funding: OpenAI, Anthropic, and Waymo. Two months into 2026, startups have already raised more than half of what they raised in all of 2025. There is an unprecedented amount of money going into startups, partly because AI is capital-intensive in a way other technology boom cycles have not been. So if you looked at just "headcount per dollar raised" it would definitely look like AI startups are more headcount-efficient. But is that really what's going on?

The average consumer startup raising a seed round in 2024 had somewhere under 3.5 employees, down from 6.4 in 2022. Series A startups that had a median headcount of 57 in 2020 are now at 47. New monthly hires across the startup ecosystem fell by more than 50% between January 2022 and January 2024 according to Carta and its tech-heavy customer base. And tech layoffs, while declining in absolute numbers, continue at a steady clip — over 126,000 workers cut at US tech companies in 2025, with the pace carrying into 2026.

So something real is happening: startups are genuinely smaller than they used to be, even as they're raising bigger seed and series A rounds. They're also hiring more slowly as they grow, and in some cases they're shrinking. It leads to this startling chart:

Is the effect due to AI though, or are we just generally getting more efficient? One way to check would be to see if the effect is more extreme in AI startups. Do we have that data?

There are certainly a lot of AI-powered startups to look at. According to Crunchbase, venture investors poured $425 billion into startups globally in 2025 — a 30% increase over 2024's $328 billion, and the third-highest year on record. AI-related companies captured roughly half of all venture funding, at $211 billion: an 85% jump year-over-year.

And yes, AI-native startups operate with 40% smaller teams than non-AI SaaS companies. AI startups beat regular startups on size of round, revenue per employee, and keeping teams small:

So what does this all mean?

If my prediction last year was true, we would expect there to be a lot of automation going on but also a lot of new tech jobs as demand is unlocked. So far that's not happening; in fact growth has flatlined since 2023, another K-shaped graph:

My read on this is: the startup economy is undergoing a structural transformation here. Startups are substituting compute for labor at an increasing rate. I still remain optimistic that this is going to result in a lot more companies doing a lot more things, but so far it hasn't happened. But companies' claims that they can get by with way fewer people in the age of AI does seem to be true.

* 2026 funding figures annualized from Jan-Feb Crunchbase data. All dollar figures in USD unless noted.

First, I talked about what LLMs are in the first place: really big Markov chains that have hit a threshold where they appear to be reasoning, to a level of fidelity that it makes no sense to argue about whether they are really "thinking" or not. Computers that can reason about the data they are processing is a brand new thing, and it's going to become part of all software.

Then I wrote about what I've learned about writing LLM applications. My key takeaway here is that LLMs are good at transforming text into less text. If you ask them to generate more text than you gave them they are usually pretty bad at that task. But the number of applications where you want to turn a lot of text into less text is truly enormous.

Finally I talked about AI's probably effect on programming jobs, in particular web development jobs because those are the ones I care about most. I think AI-assisted development is going to create a huge amount of new software, which is good, and a whole new breed of highly-assisted software developers, which is also good. I don't think current software developers will lose out on jobs as a result: the demand for software is insatiable and there's more than enough jobs to go around.

On the basis that anything I end up discussing more than three times in real life I should blog about, the next thing I should write about is the current state of the industry and where I think it's about to go. Take this with a heaping spoonful of salt, because I'm not notably good at predictions, but this is what I've got:

My big bet for 2026 is that companies searching for margin and seeing diminishing improvements in the frontier models will start training and fine tuning small models again.

— Laurie Voss (@seldo.com) October 16, 2025 at 5:07 PM

Current state: diminishing returns

The industry right now has a few categories of players that it's worth enumerating:

• Frontier model labs: companies like OpenAI, Anthropic, Google, xAI, Alibaba and DeepSeek are building the very best models that exist, defining what LLMs are capable of, in fierce competition with each other. These models are proprietary and only those companies and their partners can run them.
• Open Source models: some of the same companies above, and also Meta, are releasing open source (or at least open-weights) models that anyone can run. This leads to...
• Inference providers: a whole bunch of companies like Together AI, Replicate, Modal, Fireworks, Groq, BentoML, Koyeb and more that will host the open-source models and run them on your behalf.
• Application companies: an absolute blizzard of companies that are using AI models to build more-or-less domain-specific applications. They can build on top of frontier models, or open source models hosted by the inference providers.

Until recently, any application company wanting to stay ahead of its competitors needed to be building on top of the frontier models. The models were advancing very quickly and all your competitors would switch to them as soon as they became available. This was troublesome for the application companies because the frontier models were expensive, and also since everybody was using the same model it was a big challenge to differentiate your product from your competitors -- UX and prompt engineering were your only, narrow, moats.

My thesis is that that's changing. It's very hard to measure objectively, because the frontier models release benchmarks comparing themselves to each other but change the benchmarks frequently, so there is no single benchmark that I've found that compares, say, GPT 3 to GPT 5's performance. But the "vibe" is that while the jump in performance from GPT 2 to 3 was enormous, the jump from 3 to 4 was less big, and the jump to 5 barely noticeable, with similar progressions for Claude and other frontier models.

Meanwhile, open-weights models are catching up. That's a little easier to demonstrate, as this post and its accompanying graph above show. You can get pretty great results running an open model more cheaply on one of the inference providers than going to a frontier model. If you've got basic inference needs, those models are also getting smaller, which also makes them cheaper:

Next: the search for differentiation (and margins)

In a world where hundreds of application companies are fighting for customers but switching to the latest frontier model no longer brings meaningful differentiation, my thesis is that companies will begin to search for differentiation using fine-tuning.

Fine tuning has always been an available path, of course, but there was no point spending millions creating your fine-tuned model (and hiring the experts to do it) if it was going to be made obsolete months later by the latest frontier release. But things are changing. Fine tuning is getting orders of magnitude cheaper, and services are emerging that will train models for you, meaning you don't necessarily need to hire AI researchers to do it.

There's evidence of this already happening from AirBnB and others, with my favorite example being Cursor: different parts of your interaction are handled by very specific, small, fine-tuned models.

This has two advantages for companies doing it:

1. Differentation: if your model is trained on your data, then (assuming you have more data than your competition) it can be better than your competitors, competing not just on UX and prompt engineering around the same frontier model.
2. Margin: if your models are small, they can be cheaper to run. As the AI bubble deflates revenue and margins will matter more, and companies will be trying to do more with less.

This is already happening, and my is that 2026 will see a lot more of it.

So what should I do?

It's no use making a prediction if it doesn't lead to some kind of action, of course. If you're at a frontier model lab, I have no advice for you other than "get money off the table while your valuation is still insane". If you're at an inference provider, I think you're in for a good year. If you're at an application company, I think now's the time to start building up your dataset and looking at smaller models.]]> https://seldo.com/posts/ai-effect-on-programming-jobs com.seldo/posts/ai-effect-on-programming-jobs Mon, 17 Mar 2025 00:32:34 GMT There's been a whole lot of discussion recently about the impact of AI on the market for web developers, for programmers in general, and even more generally the entire labor market. I find myself making the same points over and over, and whenever I do that it's time to write a blog post about it, so this is that.

Doom and utopia are not our only options

There are two extreme takes on the impact of AI on programmer jobs:

1. AI will take all programming jobs (usually advanced by people selling AI)
2. AI will not take anyone's job (usually advanced by grumpy older developers, which I usually am)

I would like to advance a third option, which is that AI will create many, many more programmers, and new programming jobs will look different. Here's why I believe this:

1. There is far, far more need for software than there are programmers to build it. You can see this in the astronomical salaries for programmers, with senior engineers at big companies making millions of dollars every year.
2. AI does not eliminate the need for structured thinking about how to solve problems, which is the core of programming. It presents a new layer of abstraction. This is a point I have been making since 2018, and in 2020 and in 2023: new layers of abstraction create new kinds of programmers.

AI allows software development without knowing programming

AI has created a very powerful new abstraction that can potentially remove the need to know a programming language from the job of being a developer. Karpathy calls this "vibe coding". I haven't thought of a name I really like for this new type of developer yet. "AI engineer" is taken to mean a different thing. AI Composer? Software synthesist? In a 2012 post I imagined them as blue collar knowledge workers but that's a problematic label on lots of levels.

These new developers will know how to think in a structured way, they will know principles of how software should function architecturally, but they will know less about programming language constructs and syntax. They will be architects more than developers, instructing AI to put together software for them without needing to know about "low-level" implementation, by which I mean the code. The same way current coders don't need to think about how assembly code works. Maybe "AI architect"? Including "AI" in the name feels wrong though, it's got a horseless carriage feel. All programming will involve AI, so including it in the name will be redundant.

New abstractions are always showing up

The important thing to note is that this is not some unprecedented change. We've been adding levels of abstraction to programming since it was invented. A few years back I tried to visualize "the stack" we talk about when we talk about "full stack" developers and came up with this vibes-based chart, which I've updated to account for the last 5 years:

The ability to build software with AI is crushing down some previously very durable parts of the stack, like HTML itself, and replacing that expertise with the ability to effectively prompt and coordinate AI.

More abstraction == more software

This new layer of abstraction will do what all the others did, which is improve the speed at which we can produce software of a given quality. Assuming AI lets us build software of equal quality much faster than we did before, this will produce either

1. higher quality software, produced in the same amount of time
2. more software of the same quality
3. enormously more software of lower quality

I think we will see all three at the same time. Some AI-assisted software development will raise the bar for quality to previously cost-ineffective heights. Some AI-driven software will be the bare minimum, put together by people who could never have successfully written software before. And a great deal will be software of roughly the quality we see already, produced in less time, and in correspondingly greater quantity.

Don't worry about your job

So if software development gets rapidly cheaper, will programmer salaries fall? I'm not sure that they will. As I said earlier, there is a vast amount of currently pent-up demand: software that needs to be developed that the people who need it can't afford. You see this every time you visit a shitty website for your doctor or dentist or insurance company or random department of government. It's not that we don't know how to build better software, it's just those organizations don't want to pay for it at current prices. Lowering the price of software deveopment will also induce demand for even more: software for people too poor to afford it previously, software for niche audiences too small to sustain it before, will suddenly be huge markets.

Instead I think we'll see lots more software developers. This vast wave of new developers will probably earn, on average, less than the programmers of today. But the programmers of today will still be employed. Existing programmers are not, mostly, going to be fighting with new developers for jobs. They'll keep their jobs (and their salaries), and a whole bunch of new, cheaper jobs will also be created, unlocking a long tail of software that currently just goes unwritten. Some, producing software of previously-unimagined quality, will even earn more than before. It will look kind of like this:

Don't worry about the fundamentals, whatever those are

Will this mean that new programmers don't learn the fundamentals? No. New programmers, like every programmer since the dawn of programming, will learn what they need to get the job done. They'll start at the top of the stack, writing with prompts only, and they'll slowly pick up knowledge lower and lower in the stack, as and when they need to learn it. This will be accompanied, as always, by a great deal of whining from people who didn't have the advantage of these levels of abstraction when they learned to build software, and as usual the whiners can be safely ignored.

Having people writing at higher levels than today will not lead to forgetting anything. There are still people who write assembly today; there are just way, way more programming jobs higher up the stack. It will not create a crisis for new grads, either. They will get jobs writing AI-assisted code and work their way down the stack (and up the salary bands) as they gain experience. Don't worry about them, they'll learn this stuff eventually. Or they won't need to, and that's fine too.

Say hello to the software developer

The net result of all of this for the programming market is: more software, better software, more programmers, better programmers. But the adjustment won't be without pain: some shitty software will get shipped before we figure out how to put guardrails around AI-driven development. Some programmers who are currently shipping mediocre software will find themselves replaced by newer, faster, AI-assisted developers before they manage to learn AI tools themselves. Everyone will have a lot of learning to do. But what else is new? Software development has always evolved rapidly. Embrace change, and you'll be fine.

And I think I've decided on a name for this new type of AI-assisted developer: we can call them software developers. Giving them some other name will create gatekeeping where none needs to exist, it will falsely imply they can never move down the stack. I've been in this game too long to fall into that trap. They develop software, so they are software developers. That's the only qualification they need.]]> https://seldo.com/posts/what-ive-learned-about-writing-ai-apps-so-far com.seldo/posts/what-ive-learned-about-writing-ai-apps-so-far Mon, 20 Jan 2025 22:10:58 GMT I started writing a post called "how to write AI apps" but it was over-reach so I scaled it back to this. Who am I to tell you how to write anything? But here's what I'll be applying to my own writing of AI-powered apps, specifically LLM applications.

A battle I've already lost is that we shouldn't call LLMs "AI" at all; they are machine learning and not the general intelligence that is implied to the layman by the name. It is an even less helpful name than "serverless", my previous candidate for worst technology name. But alas, we're calling LLMs AI and any parts of the field that are not LLMs are being drowned out by the noise around LLMs. I do this a lot at my day job; I am certainly part of the problem.

But if we can't call it what it is we can at least know, as practitioners, what it is: very fancy autocomplete. At scale, autocomplete can perform tasks that look like reasoning, and at some level "looks like reasoning" and "is reasoning" have blurred boundaries. Nevertheless, as the inventor of software you should be clear-eyed about the limitations of these systems, and not try to get them to do things they can't do.

LLMs are good at transforming text into less text

This is the biggest and most fundamental thing about LLMs, and a great rule of thumb for what's going to be an effective LLM application. Is what you're doing taking a large amount of text and asking the LLM to convert it into a smaller amount of text? Then it's probably going to be great at it. If you're asking it to convert into a roughly equal amount of text it will be so-so. If you're asking it to create more text than you gave it, forget about it. The rest of this post is really just examples of this rule in action.

LLMs only reliably know what you just told them, don't rely on training data

LLMs are trained on gigantic quantities of information found on the Internet. As a result, tools like Claude and ChatGPT can answer various general-knowledge questions. This creates a huge temptation to create an app that uses what the LLM already knows to perform some task. This is never effective. You don't know what the LLM has been trained on (famously, because it's often illegally acquired, so those training them refuse to say), therefore you don't know the limits of its knowledge or when it will start to hallucinate.

The way to get around this is to give it the answers. Want to know what a contract says? Give it the contract. Want to know what a video is about? Give it the transcript of the video. Want it to make a decision? Give it all the same information you would use to make that decision. These are all just turning text into less text. It's great at that. (Yes, you can try and get around LLMs only knowing specifically what you just told them by fine-tuning your LLM. Good luck with that.)

This is why Retrieval-Augmented Generation (RAG) is not going anywhere. RAG is basically the practice of telling the LLM what it needs to know and then immediately asking it for that information back in condensed form. LLMs are great at it, which is why RAG is so popular.

LLMs cannot write for you

This is firmly in the "less text into more text" category. If you give an LLM a prompt, it can spew out a novel-sized block of text if you ask it to. But LLMs only know what you tell them. Give it a short prompt and ask for long text and you will get endless waffle, drivel, pointless rambling, and hallucinations. There is no way to get an LLM to perform the thought necessary to write something for you. You have to do the thinking. To get an LLM to write something good you have to give it a prompt so long you might as well have just written the thing yourself.

Let them self-correct, multiple times if necessary

A wild thing about LLMs is that they can observe what they've done and decide whether they've done a good job. This is sometimes called self-reflection and it's a key part of what agents do, and I can't emphasize enough what a good idea it is to give your LLM the chance to figure out if it fucked up, and a chance to try again. It adds complexity to your app but it will pay you back in reliability many times over. LLMs are bad at one-shotting but if you give them a couple of swings they often get it. It's both the curse and the magic of them being nondeterministic.

Have the LLM do as little as possible

Per the above about reliability: you know what's really reliable? Regular programming. It takes inputs and turns them into outputs, the same way every time, according to extremely precise instructions. If there is anything you are asking the LLM to do that could be accomplished by writing some regular code, write that code. It will be faster, cheaper, and way more reliable to run. LLMs are capable of handling ambiguity and complexity, and it's amazing, but the less of it you give them to handle the better they're going to do. Regular, declarative programming can work wonders and you should use it.

LLMs can help a human perform tasks, they cannot replace a human

This is really a corollary of all of the above. If you have a really great prompt containing lots of careful instructions, and provide all the data needed to perform that task, plus lots of chances to reflect and try again, with as much regular code as possible, LLMs are going to be able to perform that task. If you have a whole lot of these collections of prompts and data and code you can create an agent that can perform *lots* of tasks. At that point, it's tempting to look at somebody's whole job and say "this job is really just these 20 tasks, I have created an agent that can do all of these tasks, therefore I can replace this person". It's tempting but I have never, ever seen it work.

Jobs are more than collections of tasks. Jobs require prioritization, judgement of exceptional situations, the ability to communicate ad-hoc with other sources of information like colleagues or regulations, the ability to react to entirely unforseen circumstances, and a whole lot of experience. As I said, LLMs can deal with a certain amount of ambiguity and complexity, but the less the better. Giving them a whole, human-sized job is way more ambiguity and complexity than they can handle. It's asking them to turn text into *more* text. It's not going to work.

It's easy to argue that as LLMs get bigger context windows and agent tools get more sophisticated that the ability to replace a whole human will show up: after all, LLMs are good at turning text into less text. How much text do you need to replicate everything a human knows? I don't know but it's a lot more than any LLM can handle right now. In the meantime, your attempts to replace humans with LLMs are going to suck. Let your app augment and accelerate a human, I've seen that work lots of times and be very effective.

In particular, because I see this over and over at hackathons: please stop trying to write an LLM app that replaces a doctor or a lawyer. The LLM does not have a law degree or a medical degree baked into its training, and you definitely cannot fit 7 years of medical training into even the biggest prompt. I don't think you can reliably get an LLM to replace any human but especially not a doctor, do not trust your health to autocomplete that is just trying to be helpful. Do not get sued into oblivion because you ChatGPTed your legal terms.

LLMs are awesome and limited

Depending how much of the hype around AI you've taken on board, the idea that they "take text and turn it into less text" might seem gigantic back-pedal away from previous claims of what AI can do. But taking text and turning it into less text is still an enormous field of endeavour, and a huge market. It's still very exciting, all the more exciting because it's got clear boundaries and isn't hype-driven over-reaching, or dependent on LLMs overnight becoming way better than they currently are. Take a look at the possibilities, find something that fits within these boundaries, and then have fun with it. ]]> https://seldo.com/posts/ai-ml-llms-and-the-future-of-software com.seldo/posts/ai-ml-llms-and-the-future-of-software Fri, 15 Sep 2023 20:17:08 GMT I recently left my job at Netlify and have been looking at what's next. At Netlify I became very interested in the power of ML, AI and LLMs in particular, and that's the area I've been looking in. But there's a lot of hype and buzzwords around, so I wanted an explainer I can point people to when they ask "but what is all that stuff really?" It's intended to be short, and so it simplifies a lot on purpose.

AI is (now) a marketing term

When I went to school for computer science 20 years ago, Artificial Intelligence (AI) meant a specific thing: computers that could perform symbolic reasoning about the world, the way humans do. That's now referred to as AGI, or Artificial General Intelligence. Nobody has invented AGI yet; there are still no computers that can think and have an identity the way humans do, although some people suspect we are getting close to that and will be there soon (I'm skeptical).

What there has been is a huge series of leaps forward recently in Machine Learning, or ML. Companies using this tech have tended to call themselves "AI" companies, which is true in that ML is a subset of AI. It's like if companies that made bicycles called themselves transportation companies. But what's ML?

ML is learning from examples

Machine learning involves giving a computer a huge number of examples of something and letting it learn from those examples. For instance, you can give a computer a million pictures of words and tell it what those words are, and thus train it to recognize letters and convert pictures of words into text. If you have an iPhone, that's a feature now built into your photos app: you can copy and paste text out of pictures. Another example is email spam filters: if you give a computer a million examples of emails and label them as spam or not-spam, it gets pretty good at figuring out what spam looks like. You use ML every day.

Because it has a lot of useful applications like those, ML in general has been pretty hot for a few years now. But where the real leap forward has been in the last 12 months has been in the area of Large Language Models, or LLMs.

LLMs are really big Markov chains

If you know what a Markov chain is, it's easy to think of an LLM as a really big one of those, but don't worry, I'm not going to assume you do.

Imagine you made a computer read every book in the world, and then got it to construct a list of every three-word phrase in those books. Then for each phrase, you got it to make a list of all the words it saw come after that phrase and rank them by how often that happened. Then you gave it the phrase

The cat sat on the _______

and then you asked it to predict what word would come next, based on the list it had made. It would almost certainly predict "mat", because in all the English language in the world that's how that phrase is most often completed. Similarly, if you gave it

The capital of the United States is

it would probably give you "Washington, D.C." because again, that's just a really common phrase. But already something interesting is happening, because it looks like the computer "knows" something: the capital. But it doesn't, it's just doing word completion.

Now scale up

Now take this sentence-completion and scale it up, way up, by factors of millions and you get ChatGPT, the LLM that everyone's been talking about. You can give ChatGPT a question, and it will give you what appears to be an answer, like so:

It not only "knows" that the word should be "mat", but it gives you context about why. But this isn't doing anything fundamentally different. It gives an answer because statistically, answers are what usually follow questions. It gives the context because that context is what often surrounds that phrase. It's still just doing math, and not even very complicated math, just at enormously high scale. It doesn't actually "know" anything.

A quantitative change becomes qualitative

And yet something magical has happened. At some point what it does changed from looking like sentence completion to looking like understanding. What qualifies as understanding things is a philosophical question and a hotly debated one at that, and there are some people who think that computers are beginning to show real understanding here, but most people are on the side that this is still just math.

But whether it's real or just a convincing simulation doesn't really matter: at some point looking like understanding is nearly as useful as truly understanding it.

Giving computers context

Computers until now have been very good at processing data: they can stack up huge piles of data, sort it, filter it, move it around, spit it back out, all at enormous scale and impressive speed. But what they haven't been able to do is turn data into information. They haven't been able to understand what they're working with. But now, if you give a computer context, it can appear to reason about that information:

It figures out a conclusion from a related set of facts, namely how old Susan is. What's really interesting here is that this set of facts are not part of the set it was trained on. When it read all the books in the world, Susan's age wasn't in there. In fact, I never told it Susan's age. At some point along the line, prediction of the next most likely word became reasoning. This is the surprising and frankly spooky outcome that has made LLMs so interesting to me and many other people.

Computers that understand changes everything

There are a bunch of really neat things you can do with this new-found ability of computers to read information and understand it. Give it your technical documentation, and then ask it questions about how to do things. Give it a pile of legal contracts and get it to tell you what they do and don't allow you to do. Give it a pile of research papers and get it to summarize them and find connections between them. Give it access to your company Slack and get it to summarize everything that happened in the last two weeks while you were out on vacation.

LLMs are going to end up in everything

This transition of software from being a tool that we use to a sort of low-level assistant that we can partner with is going to change every piece of software out there. Software that doesn't have the ability to understand what it's working with is going to begin to feel strangely limited, even broken. It's a very exciting time to be working in software, and it's why it's what's next for me.]]>