A few weeks ago Mitchell Hashimoto posted his daily schedule.

I remember two lines:

600 review nightly agents, start new

and at the other end of the day,

2000 hang with wife, start new nightly agents

He’d set himself “always have an agent running” as a goal in early 2026 (and admitted he’d mostly failed at it initially). By August though — at least two agents running constantly, many of them through the night.

So I thought I’d like to test this shape of a workday. I felt intuitively that my loops were too short. And I am fortunate enough to spend some time with folks who keep agents working on their own for hours, on useful work.

For about fourteen days now I’ve been running my own version: sessions of eight to sixteen hours, agents working without a pause, one overnight run clearing thirty-something tasks by breakfast. What follows is a field note.

Four things I’m fairly sure of, and one I’m stuck on.

The afternoon is the job

Fourteen days went into drawing graphs: which tasks depend on which, what can run side by side, where the results have to meet. The models mostly wrote the code. I mostly wrote the graph (although it is really a conversation). If prompt engineering was ever a discipline, it’s dead; the craft moved up a level, from the words in one prompt to the edges between thirty of them.

People have started calling this graph engineering. You can watch Andrew Ng — a guy who likely trained half the world’s ML engineers before LLMs were even a thing — describe it in his two-hour course. In short: a node is one unit of work, an edge is a real dependency between them. Boris Cherny of Claude Code reportedly said: “You’re not supposed to write code anymore. You’re supposed to build a graph that writes itself.” And I’m starting to think there is some substance to it.

So my day has a shape. Two to three hours of graph in the afternoon, which is really a conversation about trade-offs and scope. One to two hours of review in the morning. The machines in between. In three such days I get through what would have taken several weeks at the start of 2025, with the caveat that some of it I would never have done at all (thus it is an infinite ROI, or at least “hire someone else” territory).

Worth noting: nobody in this setup is really watching twenty terminals at once at this stage. The afternoon is one long conversation, with occasional forks, about one big chunk of work, the night runs it, the morning reads it. People who try agents and report exhaustion are usually describing something else: babysitting several of them live, switching context every few minutes. My intuition now is this: if many parallel flows leave you exhausted, you may still be doing prompt engineering. Planning the graph up front removes the switching, and the switching is most of what people mean by tired.

This is mostly design work now (and it is hard!).

Multi-agent moat was wrong

Three or four months ago I’d have bet against all of this, and for a specific reason. I assumed the frontier labs would each build a harness around their own agent, and that the hard gap, the one a product could live in, would be between agents: one lab’s model handing work to another’s, adversarial review across vendors, worktrees and changesets managed between them. In short, the classic multi-cloud play from the cloud-native era.

That gap closed without anyone announcing it (or I didn’t care to notice). Claude Code manages Codex: hands it a changeset, sets up a worktree for review, picks the model tier, exchanges messages, reads the verdict back. Codex will talk to Gemini. No framework sits in the middle, and it works surprisingly well. The models’ raw coding ability, as far as I can tell, has barely moved in that time (irrespective of what AI pundits claim). What moved is their ability to coordinate, but oh boy — is it a hell of a difference!

The harness moat is eroding too

Once they coordinate, something odd happens to the harness: agents running without one start producing better work than agents running inside a custom one. Robert Martin — Uncle Bob — spent several weeks building a harness: gates, tests, tools, protocols, all constraining the agents to work his way. When he came up for air the agents had improved enough that “the need for my harness was obviated. Indeed, the need for any but the most liberal of harnesses may be obviated.”

The next morning, in a bathrobe rant, he went a step further: with the harness off, the work came out better than it had inside it. The unharnessed agent beat the harnessed one.

This is truly surprising.

But it matches my results closely. What I run instead now is really dull. A few skills tuned to how I actually work, a handful rather than a hundred. A few models, so one can review another (this is key). Cheap remote machines, because fourteen hours is a long time to keep a laptop lid open (and besides if you truly want to have at least some agents working at any given point in time — this is really a must).

But there is more. Take mutation testing. Three months ago I spent real time working out how to poke holes in agent-written tests with deterministic mutation testing: a harness step, wired by hand, because the agents would happily write tests that passed and proved nothing. Today they run mutation testing on their own work unprompted. For free (kind of).

Wow.

Review becomes shape

Adversarial review by a second frontier model catches real things. One round finds most of them, a second round a few more, and my ceiling of four exists for my own comfort; typically past two, the reviewers start inventing objections. That said, I have had runs where the worst defects surfaced in the third or fourth round, so the ceiling is still an experiment.

The morning has changed. Two machines have already argued over the lines, so I read the shape of what came back: which files were created and where; what each file is responsible for, so the division of labour is legible; which tests exist, at the level of “what does this protect”; which parts of the system were touched, and whether those are the parts that got tested.

Review always had a price, paid during authorship. Human authors used to arrive at review already understanding the code they’d written. With agents, that understanding no longer comes bundled with the implementation. Someone has to acquire it afterwards. What you can do is stop reviewing lines and start reviewing structure, which is where intent and taste still live and where the diff says nothing (or at least is too fine-grained, and it’s easy to miss the forest for the trees).

My bet: review gets reinvented within a year. It has to; the old ceremony is mostly inefficient and partly useless.

The part I’m stuck on

It’s slow. The coding is quick; adversarial review and mutation testing eat the hours, and a graph only lets you parallelise the edges that are genuinely independent. A lot of it still runs one after the other. At three or four parallel lanes on a subscription you sometimes hit the API throttle. And the industry numbers point the other way for now: Faros AI telemetry across ten thousand developers, reported in a May 2026 paper, found pull requests up 98% and review time up 91% with delivery flat, which is what happens when the review moves nowhere. On metered pricing, working the way I work now, I’d burn eight to ten thousand dollars a month (in API-based pricing costs; realistically I use a bunch of subscriptions and rotate them so it is effectively way cheaper). Which still buys, overnight, what two or three weeks of developer time cost in 2024 money.

Tokens will get cheaper; they always have (at least for the last few years). And if capitalism is good at anything, it is driving the cost of technology down. The accounting problem is still here, though. Cost per unit of work has collapsed, visible spend per unit of time has spiked, and the visible number is the one that lands on a credit-card statement in real time.

I discussed this phenomenon with my friend recently. Either the return is real and hard to attribute, and the visible cost wins the meeting. Or maybe the development bottleneck was hiding a harder truth: some of the lower-priority work never had a convincing business case. We could leave it in the backlog without confronting that. Now each task comes with a visible token bill, and that makes it painfully obvious.

Either way, the work moved. From writing code to drawing the graph, and from reading code to reading its shape. A year from now, reading the diff line by line will feel like reading the assembly your compiler emitted: possible, occasionally necessary, and no longer where the judgment lives.

Want to make a bet?

Recently I bought my son a pair of Nikes. They cost around three hundred złoty ($80 or so at today’s rate). I remember buying my first pair somewhere in the mid-nineties, in primary school, and it was a big deal — I had to travel to a different city and save money for months. The funny thing is the price was about the same — three hundred, give or take. One could say that the price tag for regular Nikes pretty much froze for 30 years.

Which is weird, when you think about it, because nothing else around it froze. Polish CPI rose about fourfold between 1995 and 2025. Wages rose roughly tenfold. Polish footwear prices fell about thirty percent in nominal terms over the same period. The regular price of Nikes in 1995 might have cost roughly the equivalent of ⅓ of an average Polish salary, while in 2026 it is more like 3% — a tenfold change.

Part of it is of course a remarkable growth of the Polish economy — from a country struggling after leaving the iron curtain to the 21st largest economy in the world (by GDP numbers). The other way of looking at it is less remarkable, but still interesting — Nike brand deflation. Nike stopped being a premium brand and became regular footwear.

Shoe Dog

One explanation is that manufactured goods deflated everywhere relative to services: containers, trade liberalisation, Chinese capacity. US footwear prices are up about 22% since January 1996 while the overall basket more than doubled. Sneakers didn’t get cheap so much as everything else got expensive around them. You’ve probably already seen Mark Perry’s much-circulated chart elsewhere anyway, so you might know what I am talking about.

But there’s a second question underneath, and it isn’t that much about price. It’s about what a single pair still means, and who gets to keep that. Which is where Shoe Dog turns out to be useful.

Picture this: 1962, Kobe. Phil Knight walks into Onitsuka with no company at all, introduces himself as an American shoe distributor, invents the name Blue Ribbon Sports on the spot, and walks out with distribution rights for the western United States. First year: 1,300 pairs, $8,000 gross. About six dollars a pair — for a shoe someone else designed, someone else made, and someone else owned the name of.

Nike did eventually own factories briefly, in New Hampshire and Maine, and closed them at a write-off of about $10m — in a year when total profit was $15m. It hasn’t made a finished shoe since 1985. The scarcity was never in the factory — Japan had good factories, which is precisely why he went there. It was getting the shoe onto the feet of American runners whose opinion travelled, with a track coach’s design and endorsement attached.

The memoir is charming, as founder memoirs typically are, but it also carries some interesting insights into Nike’s business model. Knight built a distribution and credibility company, and rented the shoe production.

All this brings me to software.

App Store avalanche

I stumbled upon a statistic recently. New app releases on the App Store grew about 30% in 2025, to roughly 600,000. Then 560,000 arrived in the first half of 2026 alone — roughly double the prior-year half. Downloads over the same period grew 2%, to 17.6 billion. Downloads per new app roughly halved in twelve months.

The same shift shows up on the supply side. App Store publishers went from ~780k in February 2025 to ~1.1 million by August 2026, while apps per publisher fell from 2.42 to 2.33. Interestingly, it isn’t incumbents shipping more (so where exactly is AI building software for them?). It’s a lot more people shipping their first thing.

Mobile games give the cleanest read on quality: releases up 77%, games earning over $20,000 up 14%, and 96.7% of releases stuck under a thousand downloads. It got to the point where Apple began blocking Replit and Vibecode updates under Guideline 2.5.2 in March.

Marginal cost was never the point (so far…)

The tempting read is that software is repeating the sneaker story. Sneakers got cheap because the marginal cost of production fell (offshoring, containers, scale).

But cheap to make was never Nike’s problem. Nike’s problem is that owning a pair stopped meaning anything — it flooded its own icons, drifted off performance, and the premium walked. What it cost to make the shoe had nothing to do with it.

Software’s marginal cost was already zero, and had been for decades. Shapiro and Varian wrote it down in 1998: information is costly to produce and cheap to reproduce, high fixed cost and negligible marginal cost, and therefore “cost-based pricing just doesn’t work: a 10 or 20 percent markup on unit cost makes no sense when unit cost is zero”.

What AI collapsed is first-copy cost — the price of getting version one to exist at all. Building the first copy used to mean an agency and a five-figure invoice, $5,000 to $50,000 for something simple and six figures for anything real. It now means a $200 subscription and a few weekends. Two orders of magnitude off the price of existing at all.

(Side note: actually AI has an interesting effect on the marginal cost of software, as tokens spent by users are a very tangible cost; but that’s another story)

And the first-copy cost was doing two jobs. It filtered — shipping anything took enough effort that not everything got shipped. And it protected the margin, because catching up with whoever shipped first meant paying that effort all over again. Difficulty was the moat. Remove the moat, and we get 560,000 apps chasing 2% more attention.

Where the scarcity goes

It doesn’t disappear. That’s what “software is dead” gets wrong. Christensen wrote the correction two decades ago: commoditization at one layer sets off “a reciprocal process of decommoditization at the next level of value added” (yeah, it’s a mouthful). Asked directly whether profits vanish or merely change hands, he was firmly on “change hands”.

Technology rarely eliminates scarcity; it moves it somewhere else in the system.

Generic software gets cheaper, more abundant, more competitive. Producing it has stopped being a moat — the barrier to building something functional has collapsed, and writing the code buys you less every quarter. What’s left is the relationship: owning the channel, or sitting close enough to the business to know what’s worth building. Knight had both, without needing the theory. He had the shelves and he had Bowerman’s runners, and he rented the shoe from a company that only had a factory.

Except Nike eventually lost that relationship. It surrendered running to Hoka and On while sliding from performance into lifestyle (Hill’s first act as CEO was to announce he was “putting sport back at the center of everything that we’re doing” — a sentence you only say once it has moved off the centre).

Which leaves one difference between the two halves of this story.

When Nike diluted its own icons it had a lever. It could make fewer Dunks — painful, expensive, but available. Supply was something Nike controlled, so restraint was a strategy.

Nobody controls the supply of software. There is no franchise management for the App Store, no decision anyone can take to ship less (and thank God). Apple can reject slop at the gate, and does, but a gate is not a factory — and the App Store is about as tightly guarded as centralised marketplaces get. The abundance is the condition.

So the sneaker playbook — make less, charge more, restore the premium — isn’t available in software. Only the other half is: move to where the scarcity went, and get there before anyone else.

Three hundred złoty for a pair of Nikes is a bargain, and it took sixty years and a global supply chain to make it one. My guess is that generic software gets there way faster.

Mid-2026, and we seem to be in an interesting situation. On one hand we have people claiming to run hundreds of agents single-handedly and produce millions of lines of code in a short span of time. On the other hand, we have people using their terminals with tabs named 1-2-3 to keep track of their AI agents, scratching their heads about how you would run 10+ agents in parallel and maintain your sanity at the same time. Naturally, most of the former claims come from LinkedIn influencers who haven’t built shit and are selling courses or paid services. It is important not to dismiss that side of the story entirely though — there are also genuine builders in that camp shipping production-grade stuff, and some of them have discovered genuinely useful tools and practices along the way.

Speaking about the tools and practices — there is a class of tools that has been popping up wherever you look since 2025. For the lack of a better term I’d call them a Parallel Agentic Environment (or Parallel Agentic Coding tool). They are not the remedy for all the pains of agentic development — but I do believe they could easily raise the limit from managing a handful of agents to tens of them, and still being in control.

What’s a parallel agentic environment

Before we start, let’s cover the definition. What is a Parallel Agentic Environment? This is a tricky question, because as is usually the case with emerging categories it depends who you ask — especially with a hefty dose of current AI hype and money flowing in, it is sometimes difficult to separate marketing from reality. Additionally, it is a moving target — it evolves as the market matures, and naturally the tools will likely capture a wider feature surface over time.

For the sake of this article I’ll define it as: a Parallel Agentic Environment is a tool that lets one developer run multiple AI coding agents at the same time, even on the same codebase, without them tripping over each other (or over you), usually through some sort of app / IDE run locally. This is necessarily a broad definition, but we’ll get into what it means on a more tangible level.

It is a surprisingly rich category. The most popular products and the most clear-cut for this category are:

• Superset

• Orca

• Conductor

• DevSwarm

In fact there are many more that are somewhat similar but have a unique angle to it. Let’s just name a few that definitely feel different, and yet have some undeniable overlap:

• Nimbalyst (previously Crystal) — an interesting take on the visual integration (charts and flows)

• cmux — technically multiplexing terminal, but coincidentally could be used as a basic multi-coding agent tool. Side note: multiplexing terminals are an interesting beast on their own — recently we’ve heard about Mitchel Hashimoto himself founding a new company in that space

• Superconductor — a step toward team development, and way closer to Software Factory category (which I’ll mention later)

• Cursor — even Cursor over time started to adopt many of the features outlined in this group (not to mention, that you can use Cursor Agent within Parallel Agentic Environments).

I’ve likely missed some — I focused predominantly on the ones I had some hands-on experience with. Tens of different tools in that space already exist, both open source and commercial (which, by the way, is a very clear signal of how crowded the category is).

Surprisingly the typical Parallel Agentic Environment all landed independently on the very similar set of primitives. In practice these are four broad groups of capabilities:

• Parallelism: each agent works in its own isolated copy of the repo — a git worktree seems to be the standard — so their changes never collide on disk.

• Grouping: there’s a single surface where you can see what all of them are doing, review their diffs, and steer them with clearly segregated agents, terminal windows, logs and be notified with notifications when agents finish work or require user feedback.

• Integration: the environment handles the boring plumbing that makes parallelism work effectively and provides context for running agents: setup and teardown scripts which allow to run multiple workspaces in a conflict-free way, and the connection between an agent’s work and a ticket, a PR, or a CI run.

• Programmability: where the environment exposes some sort of programmatic surface (e.g. MCP) so you can drive the whole thing from code, as opposed to human UI interaction exclusively. In fact to be more precise: it is more about your agent to be able to drive the thing. I’ll come back to why that matters.

Note I didn’t include here more complex combines that approach it from organization/team perspective and usually cover the entire SDLC process in a more orchestrated way. These kinds of tools feel like different beasts, an emerging category that I would colloquially call “software factories”. The typical examples in this category are: Factory.ai (the one that pretty much defined the term), 8090.ai, overcut.ai or visdom (full disclosure: this one is being built by my colleagues at VirtusLab). This category in my mind is a distinct area — even though there is an overlap, which I expect will only grow as mentioned tools will try to capture a large portion of the market — and as such I won’t be describing them here (perhaps worth another write-up).

What these environments actually do

Strip away the marketing and every one of these tools does roughly the same eight things. Some do more of them, some do them better, but here they are:

Worktree isolation. The market converged on worktrees as the means of work isolation. Each agent gets its own checkout, so their edits don’t collide. Every serious tool in this space uses it now — Superset, Conductor, Orca, DevSwarm all do it (and so does Cursor since 2.0+).

This capability allows you to almost instantaneously create a separate worktree (clone of your repo on a separate branch) so you can work on it without interrupting your other work on the same project.

Superset has a neat 1:50 video that describes this concept.

Side note: It is almost funny that the AI wave dug out an obscure and almost forgotten git feature from a decade ago — git worktrees were originally introduced around 2015. “Almost,” because if you think about it, this is a recurring pattern in technology: for instance cgroups and LXC existed for years with very limited usage and only became ultra-popular after Docker combined them into one convenient package.

Agent grouping and console management. Since you’d be switching contexts you need to have some sort of segregation. Workspaces allow you to work on several aspects of a single project (or repo) at the same time. You can also have several projects/repos, each of them having multiple worktrees.

But it is not only that — you typically want to see some terminal, maybe have several agents (e.g. design with Fable, implement with Opus and review with Codex) on the same project. So you want to have all these grouped together, and neatly segregated across your projects and workspaces. Once you’re running five or ten workspaces, you need somewhere to see them all. A single pane of glass, or at minimum a shell multiplexer that is tmux with better fonts, and gives you reasonable grouping.

Here is a pretty good 5 min overview with Orca from their docs.

And interestingly enough — continuing the re-discovery of old primitives — tmux itself was a pretty niche tool until the last few years, when we suddenly needed a way to multiplex parallel coding agents. Additionally, we typically get a visual distinction / sound notification when any of the agents finished its work or requires your interaction.

Programmatic steering. CLI, MCP, whatever — in other words: means to drive the thing by the agent (or you via code — although that’s a secondary effect). Things like: spawn a worktree from a script. Send a prompt into a session. Read the diff back out. Once you have that, you can build things on top: hooks, scheduled automations, or your own mini-orchestrator that spawns ten worktrees with scoped agents. Some tools expose more of this than others.

Setup / run / teardown hooks. If every worktree wants to run the app locally, you are likely to have some problems — the first one being: they all want port 3000 when you start up your app locally (or whatever your app framework uses). So the tool needs to give each worktree its own port range and handle the boring stuff: bring up the DB, run migrations, seed, start the app, kill it all when the agent finishes. Without this you’re not really running in parallel, you’re just running sequentially with extra tabs.

This is more powerful than it seems (even though it’s a trivial concept at its core). With a simple combo of setup.sh / run.sh / teardown.sh scripts and some predefined environment variables you can do a lot of useful stuff. Some are:

• Automatically copy your dotenv files from your main workspace

• Tackle port collisions

• Or even automatically reusing database across different workspaces of the same repo (or leveraging a single Postgres container; with on-the-fly creation of test databases with pre-seeded data on different workspaces)

Ticketing/PR integration. GitHub, Linear, Jira. An agent that opens PRs now could have a pretty good context of what it’s working on. An environment that reads a Linear ticket, assigns it to a worktree, spawns the agent with the right context, and closes the ticket on merge starts to be a neat productivity tool. For a certain class of tickets, you can pretty much have one click from a Linear ticket to your favorite agent solving it and opening a PR back to GitHub.

Code review and diff experience. Parallel agents produce parallel diffs, and someone may still want to read them (e.g. me, even if sometimes cursorily). The tools differ meaningfully here: Conductor makes each workspace into a proto-PR you can review before it hits GitHub; Superset lets you scrub diffs inline in the terminal and stage hunks per-agent; Orca leans on GitHub’s native review UI plus its Chromium Design Mode for UI-level diffing.

Remote environments. Run the fleet somewhere outside of your laptop — a beefy VPS, a shared dev cluster — and steer from a laptop, or a phone (e.g. Orca has this in preview as of mid 2026). Transparent server nodes seamlessly integrated into your local environment are quite useful — you can finally close your laptop, and the work still continues. These days, you can even easily open remote dev environments in your Cursor / VScode setup — so this is not limited to your Parallel Agentic Environment. (Side note: I think with the current trajectory, it is likely we are on the verge of rediscovering remote development environments on a larger scale).

Automations. Hooks and scheduled workflows. In practice today, most “automations” in these tools mean scheduled work — flows you set on a cron-like schedule (”every morning at 8am, spawn an agent that syncs the tracking issues and drafts the standup“). Superset explicitly ships scheduled automations, and both Conductor and DevSwarm expose their equivalents. You can also build more interesting stuff — e.g scan GitHub issues on a regular basis, find issues with “low-hanging-fruit” label, create a workspace (perhaps on your remote machine), implement the changes and push them back to the repo as a PR for you to review when you wake up.

Event-driven hooks exist but are still shallow: mostly “agent finished, notify me,” occasionally “agent finished, run tests.” The richer reactive loops you’d want (”PR review comments received → hand them back to the agent with the diff”; “CI failed on main → spawn a debugging agent”) are more aspiration than shipped feature in mid-2026.

But this is where the environments stop being cockpits and start becoming workflow engines. It’s also where the flat, hierarchical, and software-factory bets visibly diverge: the flat cockpit tools give you scheduled hooks and let you wire your own reactions on top; DevSwarm bakes the wiring into HiveControl patterns; the software-factory tools treat the workflow itself as the product.

There are also features that exist in one or two tools but haven’t converged into a baseline yet. Orca has a mobile view — you can approve diffs and steer agents from a phone while walking somewhere (ties neatly with remote workspaces too). DevSwarm and Superset both expose enough hooks that you could build lightweight workflow triggers on top — things like “when this agent finishes, spawn a follow-up on the merged branch” — though almost nobody ships this as a first-class UI-level trigger yet. A handful of tools are experimenting with voice steering and push notifications on agent completion. None of these are yet at the point where a buyer would pick a tool on their strength, but they hint at what the next capability tier looks like.

Divergence, up close

Superset is the one I use the most. Desktop app, agent-agnostic (you can run whatever you want: Claude Code, Codex, Cursor Agent, OpenCode, Copilot, and so on). Their own honest admission tells you where they actually are: Superset itself claims five to seven reliably today (well, the article is from February), with a roadmap to one hundred by the end of 2026. My own experience runs closer to low 10s.

Their roadmap post is refreshingly explicit about what breaks between here and there: “Scale the agents all you want — it’s the humans that don’t scale.“ Even at low 10s we’re already well beyond the 2–3 you get by renaming tabs in the terminal. The gap between the marketing “100+” and the engineering “low tens” is the story worth watching, and I’m curious to see how they’ll attempt to pull it off. Their roadmap talk is worth watching for how they envision tackling this.

The mental model is flat. N agents, one human coordinator — you. Superset builds the cockpit and — at least for now — doesn’t pretend the agents can coordinate themselves.

Orca is the maximalist. Its makers refuse to call it an IDE at all; they’ve coined ADE — Agent Development Environment — on the theory that IDEs were built for you, and an ADE is built for you and your agents. It picked up somewhere north of 15,000 GitHub stars in months. It has an embedded Chromium browser with a “Design Mode” — click any UI element and it ships the HTML, CSS, and a screenshot straight into your agent’s prompt. It has remote worktrees over SSH, so you can run the fleet on your VPS box and steer from a laptop.

DevSwarm takes the bet the others don’t. It’s a full VS Code IDE. A little too heavy for me, but they have a genuinely different headline feature — HiveControl: a lead agent in one workspace can plan a piece of work, spin up sub-workspaces, delegate scoped tasks to them, exchange messages, and stitch the results back together — all branch-isolated, all reviewable. Their own tagline is refreshingly on-point: “Running parallel agents is solved. Coordinating them is the next challenge.“

The unusual bit is that HiveControl is built around a handful of patterns that keep showing up in practice. Their team names some of them: the Plan-Do Pattern (one workspace understands the problem and creates an execution plan; others handle implementation) and the Review Stack Pattern (large changes get broken into smaller, focused PRs that stack into a review chain). (There is also a third one: Release Stack Pattern).

Instead of making you the coordinator, DevSwarm tries to make an agent the coordinator — with a shared orchestration tree, real GitHub and Jira integration, port networking per worktree, and now multi-repo workspaces for polyrepo shops. So we have: human-directed, agent-coordinated, and workspace-native. This is the hierarchical bet — a manager agent with reports.

The coordination bandwidth problem

The scarce resource in parallel agentic development is not agents, and is not compute. It’s coordination bandwidth — the ability of one human to keep N streams of machine-generated work coherent enough to merge, ship, and not regret it a week later. That’s a fixed, human quantity. It doesn’t scale with your GPU or token budget.

None of the tools from this category managed to effectively break that ceiling. They have a pretty similar approach to the problem (mostly flat structure with project/workspace layout, with human coordination). The notable exception is perhaps DevSwarm which is trying and says: raise the ceiling by promoting an agent to coordinator. The software-factory tools take a different route entirely — they template the common shapes at the org level, so most of the coordination happens without a human in the loop at all, with humans reserved for judgement calls at defined checkpoints.

If you build software for a living, and are not using any of these (or something similar, there are many others) — picking one is great bang for the buck (especially so, as some of them are free, within limits). The pricing model is a simple one anyway — which is reasonable, as you plug in your existing subscription-based (or API-based) AI models into it.

You are the coordinator now. I’m not yet convinced a lead agent can be trusted to merge its reports’ work entirely without a human reading at least some pieces of the code, but that’s a bet worth watching. There are certainly people who have found some success in the opposite approach (i.e. skipping human review entirely), so I wouldn’t discard this approach.

Either way, the tab-renaming era is over. What comes next is not a single winner but a real market: plenty of rather serious tools, two coordination models on the laptop and a third at the org level, and — at least so far — one obvious bottleneck. Worth paying attention to which one bends first.

I stumbled on a McKinsey piece from a few years ago the other day — a 2022 report on low-code and no-code, the last time we told non-technical people they could build software. Buried in it was this term: phantom couplings. A shadow app quietly consumes an IT system’s data, the IT team changes something reasonable, and the shadow app breaks in a way nobody traces back for weeks. Read it in 2026 and it doesn’t feel like history. If anything, it feels more relevant than ever.

Consider these two examples. One is about the nine seconds it took an AI agent to delete a production database this month. Operator-level access, one irreversible command, no human in the loop. Some called it a “backup verification gap.” That’s one way to put it. And it isn’t only startups. The Financial Times reported that AWS let its own coding agent, Kiro, fix a bug in production last December; the agent reportedly decided the cleanest fix was to delete and recreate the environment, taking AWS Cost Explorer down for thirteen hours. Amazon disputes the framing — it was, they said, “user error — specifically misconfigured access controls — not AI.” Hold onto that phrase. It turns out to be essential for what’s to come.

I wrote a piece a few weeks ago called Everyone Is a Builder Now. Non-technical people are shipping automations that hit Jira, post to Slack, write to prod APIs. That’s the fun and optimistic version. The other side of the same coin is: those automations are a live, messy dependency graph — and you can’t see it, let alone govern it. And it’s going to grow exponentially.

This is the part that’s genuinely new. For decades, software inside a company came from one place: engineering. That’s over. Increasingly the apps aren’t built by engineers at all — they’re spun up and adapted by finance, ops, marketing, the teams closest to the problem. Engineering is no longer the sole source of software, and the org has to cope with that whether it planned to or not.

Two dangers, one cut leash

Different dangers hide in here, and they’re worth pulling apart — because they’re related but not the same. One is invisibility: you don’t know the code exists, so you can’t trace it, can’t govern it, and it breaks something in a way nobody connects back for weeks. That’s the phantom-coupling problem. The other is blast radius: you may know exactly what the thing is, but it’s been handed the keys to do real, irreversible damage. It’s also where the security and compliance nightmares live. That’s the nine-seconds problem. One is that you can’t see it; the other is that what you can’t see can do anything.

The old world had both dangers too, but leashed. Low-code apps were active — a zap fired on a trigger, wrote to Salesforce, moved money without anyone opening a file. But they were bounded and deterministic: they ran only through the platform’s connectors, on surfaces the platform could see, and they did exactly what you wired, nothing more. Even the dumbest failures stayed inside their box — Public Health England quietly dropped sixteen thousand COVID cases when an automated export hit an .xls row cap in 2020. Bad, but bounded: one broken step in one predictable pipeline, doing exactly the wrong thing it was wired to do. The AI version is unbounded and autonomous. It reaches any API, and it decides what to do on its own. Same two dangers — invisibility and blast radius — just with the leash cut.

Pave it (or pretend)

So what do we do about it?

The reflex is to lock it down. Approval workflow, security review, mandatory catalog. Every place I’ve watched try this has produced some version of the same result — the vibe collapses. And the vibe is the whole point. Non-technical teams build their own tools to scratch an itch that central IT would take weeks or months to reach, because in the grand scheme of priorities it never rises to the top. But let’s be honest — part of it is also just fun. The fun of building something shaped exactly for you and the handful of people you work with. Tell those people to route around a security screening, file a verification request, and wait for approval, and you don’t get safer software. You get no software.

And that would be a real loss. Modern organizations run on software, so people building the tools they need isn’t a hobby — it’s a spark worth protecting, not a thousand small liabilities to stamp out. The tension between untamed creativity and ungoverned mess is real. I feel it too.

Back to McKinsey. Their prescription back then was sensible — don’t ban the citizen builders, give them a path with guardrails. Give them a platform, a catalog, and — above all — a promotion path. Here’s what’s changed, and it’s the point of the story. Low-code had a platform. It was a walled garden — a bounded surface where every app was at least visible to the people who ran it. Vibe coding tore the walls down. The automations now run anywhere, call any API, touch live systems, and appear in no catalog at all. AI didn’t kill low-code. It killed the one thing that made low-code governable. The phantom couplings McKinsey worried about were manageable when you could at least see the apps. Multiply them by a thousand invisible ones and you have what most large organizations are struggling with right now.

So the right frame is the one platform engineering figured out a decade ago. A paved road. You publish the opinionated, supported path, you make it fast, and you accept that people can go off-road when they need to — off-road just means they carry the full weight themselves. And above all: not everything should be promoted. A private filter someone built for their own dashboard should stay a private filter forever. A workflow three teams now depend on has to graduate — get reviewed, get an owner, get real error handling — before the whole company is quietly standing on it. And the thing that decides which tier you’re in was never how the app was built. It’s blast radius: what it can touch, and who bleeds when it breaks.

So the old question “who’s allowed to build?” is no longer relevant. In 2026 the answer has to be everyone, whether you allow it or not. The question that matters now is: who’s on the hook when it breaks?

The sales rep’s Zapier can lie to them. Fine. The billing automation your finance team vibe-coded can lie to a customer. Not fine. The agent your engineering team gave production credentials to can delete a database in nine seconds. Definitely not fine. Same tools, three different tiers — and the thing that sorted them was blast radius. Which, you’ll remember, is what Amazon called “misconfigured access controls.”

We already built the hairball. That’s not the problem. The problem is telling ourselves we can put off paving the road — right up until something deletes the database in nine seconds.

Once upon a time, in a remote kingdom — you remember it, or you’ve heard the stories — a developer could show up at three consecutive daily standups and say, with a straight face, “still moving the button.” Or “still debuggin’.” Or “still setting up the environment.”

Not designing anything. Not deciding anything. Moving the button. Or figuring out why the library that worked yesterday now throws on line 40. Reading a Stack Overflow thread from 2014 where the accepted answer is wrong and the third comment is right. Fighting the build. Guessing at an undocumented flag. Three days of this, and nobody blinked, because that was just… the job.

We’ve decided to be sad about losing that.

My take is — fuck that shit.

Sure, part of it was that the industry had normalized it. Around 2021, some software engineers lived a little like nobility — two or three hours of actual work wedged between table-football matches, Xbox sessions, and fruit Thursdays.

But that was only part of it.

So today, one camp is convinced AI is coming for software engineering — the jobs, the salaries, the whole profession. Gone. The other camp is busy insisting AI can’t actually code: Look at this hallucinated function! Look at this security hole! It’ll never really do the work! Well — AI does generate a lot of code. It also generates a lot of garbage in some cases. Both are true. But it’s the wrong argument.

We’ve quietly convinced ourselves that the interesting part of software engineering was typing. That the craft lived in the keystrokes. This prolonged grind of vertically centering the div or figuring out why the library misbehaves this time.

The interesting part was never writing the code.

It was deciding what to build and why.

It was the whiteboard sessions where the team fought two irreconcilable requirements into a truce.

It was the architecture — where the seams go, what talks to what, which decision you’ll regret in eighteen months.

It was pinning down requirements from a stakeholder who doesn’t know what they want until they see what they don’t want.

It was tying it all together: this system, that constraint, this team, that deadline, the thing that has to still be true when traffic is 10x.

That’s the work. That was always the work.

The three days lost to a misbehaving dependency? That was never the work. That was friction — an artifact of a tooling ecosystem we tolerated because we had no choice, dressed up over time as craftsmanship. We got so good at surviving the friction that we started mistaking the friction for the profession. For some, debugging the button became a personality.

Good times make for strange romances. When headcount is cheap and deadlines are soft, “I spent three days on a library quirk” is a perfectly acceptable sentence. Then the money got expensive, and it stopped being acceptable. And that’s roughly where we are.

So let the typing go. Genuinely — good riddance! If a machine can grind through the boilerplate, wire up the CRUD, chase the dependency hell, and hand me something that compiles, that is not the death of my job. That is the removal of the part of my job I never should have been romanticizing in the first place. Because everything that made software actually hard is still hard. Harder, if anything. When generating code is nearly free, the scarce skill isn’t producing it — it’s knowing what’s worth producing, how it should fit together, and whether it’ll survive contact with reality. The volume goes up; the need for judgment goes up faster. Someone still has to hold the whole system in their head and decide. That someone is an engineer. That was always what an engineer was — we just let the tooling convince us otherwise.

The doomers are mourning a profession that isn’t dying. The deniers are defending a task that deserves to. But software engineering isn’t going anywhere. At least, not for this reason, and not for now. What’s going away is the pretending — the three-day button-push, the friction-as-identity, the quiet fiction that typing was ever the point.

I’ll miss it about as much as I miss dialing a modem. The craft is still here. It just finally has to be about the craft.

Last week I wrote about the enormous bill — the European Commission puts grid investment alone at around €584 billion this decade — that EU energy supply and the grid in general has to bear if we are to dream of long-term AI sovereignty.

On the one hand the investments needed are mind-blowing, on the other there is a whole industry already rubbing its hands at the business this inevitably brings. Yin-yang.

Naturally, there are sceptical voices, and they typically take one of two forms. The first says AI — in its current incarnation i.e. LLMs — is a bubble, and a bubble sooner or later pops; when it does, all these investments come to naught, and the problem pops along with it. The second says efficiency will outrun demand: the current architecture — transformers and the hardware under them — will be optimized so aggressively that the mountain of surplus compute we’re racing to build simply won’t be needed.

Personally, I have issues with both lines of argument. On the first: the fact that a bubble pops doesn’t mean the demand shrinks — the dot-com crash bankrupted companies, but demand for the internet grew many times over in the years that followed. On the second: Jevons. We have seen it recently with token costs — they have fallen at least fourfold over the last two years (you could easily make an argument they fell between 10-100x if you take into account fixed capability), and yet we typically pay more than we used to, not less. I wrote about that here.

But let’s put this aside. I am willing to admit that I can’t predict the future with high precision. Time will tell.

And yet, there is another factor that makes both of these lines of thinking likely inaccurate. And the reason has almost nothing to do with AI. More than that — AI is only part of the reason demand is growing at all. Electrifying transport, swapping gas boilers for heat pumps, and reindustrializing the continent each add new load on a scale comparable to data centers. AI just happens to be the fastest-climbing line on the chart.

Let’s get to a different angle. The current explosion in energy demand is just an overcurrent - and the European grid infrastructure, as it is, requires a decade-long investment either way. Even if AI demand gets slashed by half tomorrow.

Let’s walk through five forces reshaping the European grid right now. Only one of them is about AI. The other four would be tearing at the system even if every frontier lab folded tomorrow.

But first, let’s look at the frame that makes the whole thing click.

In general there are two different things we sloppily lump together as “the grid problem.” One is rebuilding — changing what kind of power spins, when energy arrives, and how we store it.

The other is growing — adding raw load. These are not the same engineering project, they don’t run on the same timeline, and crucially, they don’t have the same cause.

The rebuild is forced by the energy transition itself. The growth is forced by electrification — electric cars, heat pumps, reindustrialization, and yes, data centers. AI lives almost entirely in that second bucket. It is a volume driver, and it barely touches the first.

Which is the whole point. If you pop the AI bubble, you remove a chunk of the growth. You don't remove a single gram of the rebuild. And the rebuild is hard, slow, and expensive. Hold that distinction — we'll come back to it.

OK, let’s now get into the five forces I’ve mentioned earlier.

1. The grid forgot how to stay up

Start with the most uncomfortable fact, the one we tend to avoid because it lives in a part of engineering we could have conveniently ignored for years.

On April 28, 2025, at 12:33 in the afternoon, the Iberian grid lost roughly 15 GW of generation in about five seconds — close to 60% of everything that was online at that moment. Voltage surged out of control, and within seconds Spain and Portugal separated from the rest of continental Europe and the lights went out for tens of millions of people. The bill was real: roughly 500 flights cancelled, factories like Volkswagen’s Navarra plant idled, and economic-loss estimates as high as €4.5 billion (more likely though between €1-2 billion).

Here’s the key part. At the moment it failed, the Iberian system was running on over 70% solar and wind through inverters. Even though the eventual root cause was voltage control, not the renewables share, the inverter question still matters — and here is why: inverters don't spin.

A gas, coal, nuclear, or hydro plant runs on an enormous lump of metal rotating at grid frequency — spinning in lockstep at the grid’s 50 hertz, synchronized across the whole European network. That spinning mass is not only a side effect — it’s also a shock absorber. When supply suddenly drops, all that rotational inertia keeps turning and buys the operators a few seconds of physics before frequency collapses. Those seconds are the safety margin: they are the window for fast frequency response from batteries (which can react in well under two seconds) and for governors on the remaining spinning plants to ramp up. Run out of that window and the grid’s last-ditch defense kicks in — automatic under-frequency load shedding, which simply disconnects whole blocks of customers to save the rest of the system.

Solar panels and wind turbines give you none of that for free. (And yes, a wind turbine does have a spinning rotor — but it is connected through power electronics that electrically decouple it from grid frequency, so the system can’t lean on that mass the way it leans on a directly-coupled generator.) Grid-forming inverters — the newer kind, programmed to actively imitate a spinning machine and inject power the instant frequency dips — can synthesize a version of it, but they are a rounding error in today’s deployment.

So you end up with a grid that is cleaner, cheaper to run on a sunny afternoon — and structurally twitchier than the one it replaced. Lower inertia means less margin for error. That fragility is not the whole story of the April blackout — the official inquiries trace the collapse to a cascade of overvoltage and failed voltage control, with low inertia and weak interconnection as aggravating conditions rather than the single trigger. But it is the structural backdrop against which any such cascade now plays out. (Side note: the report quoted here is a genuinely fascinating read — worth at least a cursory look.)

This has nothing to do with AI. It is a property of the energy transition itself. We are swapping spinning mass for silicon faster than we are building the things that compensate for it.

2. We are paying people to take the electricity away

The second force shows up in the price.

In 2025, Poland recorded over 300 hours of negative day-ahead electricity prices — more than double Great Britain’s 149, and on a clear upward march year over year. And remember: Poland is a renewables laggard by EU standards — about 29% of its power came from renewables in 2024, against an EU average near 47%. If a country this far behind the curve is already paying people to take its midday solar, that tells you the imbalance is structural. April alone saw a record run, with roughly 27% of the country’s solar output exposed to prices at or below zero — up from 5% a year earlier.

A negative price means exactly what it sounds like. There is so much power on the grid at midday that producers pay buyers to absorb it. In Poland the tax authorities have actually had to rule on how to charge VAT on the transaction — because someone is rendering a service by taking your electricity off your hands.

This is the duck curve — plot net demand (total load minus solar and wind) across a sunny day and the line sags into a deep belly at midday, when solar floods in, then rears up into a steep neck in the early evening as the sun drops and everyone gets home. And it is not a victory lap for solar, mind you. We have built enormous quantities of generation that all arrives at the same hour, in a system that still can’t move energy across time. So the Polish operator curtails — in one week before Easter 2025, PSE is reported to have cut around 77.5 GWh of wind and solar — on the order of what the country curtailed in all of 2023. The April picture is starker still: Pexapark puts non-market curtailment at roughly 400 GWh in the first four months of 2025.

Negative prices and curtailment are the grid telling you, in the bluntest language it has, that the system is unbalanced. No AI required so far.

3. Europe is spending billions on batteries

Which is why the third force is the most telling — just follow the money.

In 2025 the EU deployed a record 27.1 GWh of battery storage, up 45% on the year, taking the installed fleet to nearly 80 GWh. Developers are bolting BESS onto existing solar portfolios as fast as they can finance it. And the queue behind that is staggering: by mid-2026, roughly 455 GW of battery projects and 375 GW of generation were stuck in distribution-grid connection queues across eight European markets — around €100 billion of clean assets sitting in a line.

Nobody is putting up tens of billions of euros in storage to power a chatbot. They are doing it because the problem in forces one and two is structural — too much variable generation, not enough inertia, not enough ways to shift energy from the sunny hour to the dark one. Storage is the market’s answer to a physics problem, and the size of the bet tells you how real the operators think that problem is.

4. The geopolitics were here before the GPUs

The fourth force is the one Europe has spent the decade learning the hard way.

Gas dependency. Uranium and fuel sourcing. The critical minerals inside every battery and every transformer. The Baltic states only finished cutting themselves off from the Russian-controlled BRELL network in February 2025, and that single act reshaped storage economics across the region overnight.

So energy security is not a 2026 invention. It is the thing that has been driving European policy since at least February 2022, through a winter of Liquefied Natural Gas (LNG) terminals and price caps and uncomfortable conversations about who controls the molecules. And AI didn’t create that exposure – it just gave us a fashionable new reason to talk about it.

And yet, the dependency didn’t disappear so much as move: the US supplied about 58% of the EU’s LNG imports in 2025 and is on track toward two-thirds in 2026, and Europe has its AI chips, its cloud, and increasingly its molecules sourced from the same single ally — which is its own kind of exposure. Especially in the shifting geopolitical climate.

5. AI is the accelerant, not the fire

So where does AI actually fit?

On top. It lands on a system that was already strained by the first four forces and presses on the timeline. The honest framing is that AI is one input among several, and not even the largest. In other words — it’s the accelerant, not the cause.

Look at the actual numbers and the panic deflates a little (well, AI-induced panic; as some sense of urgency is still truly warranted). Data centers are about 3% of EU electricity today, heading for roughly 4.5% by 2030. AI is only a slice of that — the IEA put AI at around 15% of data-center demand in 2024. So in absolute terms, AI is a low-single-digit percentage of total European load.

The dynamics are more interesting, though. Estimates of how much of the EU’s new electricity demand to 2030 belongs to data centers vary enormously — from around 10% in the IEA’s stated-policy scenario to 20–28% in industry projections. That’s a big share of the growth — but it isn’t even alone there. The electrified industry adds about 80 TWh of demand growth by 2030, electric vehicles around 67 TWh, and data centers around 72 TWh. AI is the fastest-climbing slice of the growth, not the entirety of it.

And for anyone who still thinks EVs are a fad worth discounting: in 2024 pure battery-electric cars alone outsold diesel in the EU — 13.6% of new registrations against diesel’s 11.9% — and in December 2025 they outsold petrol cars in a single month for the first time ever. The fleet is electrifying, whether one likes it or not.

Let’s now bring back the rebuild-versus-grow frame. AI is a growth force. It is responsible for expanding the grid — and it shares even that job with cars, heat pumps, and factories. It is responsible for almost none of the rebuilding — the inertia, the duck curve, the storage scramble. Those came from the energy transition, and they are the slow, expensive, decade-long part.

That distinction is exactly what survives the bubble. If AI demand evaporates, you remove a chunk of the growth pressure — and you don’t get your stable, boring 2019 grid back, because the entire rebuild is untouched. You’d still be low on inertia, still drowning in midday solar, still short of storage, still geopolitically exposed. Same structural crisis, minus one accelerant, with the deadlines nudged out by a few years.

So what does this all mean?

Back to software. None of this is AI’s fault — but all of it is AI’s problem.

Software people carry an instinct that compute scales like software. Need more capacity, spin up more instances, raise another round. But sovereign AI in Europe is no longer gated only by how many GPUs you can buy. It is gated by interconnection queues, inertia limits, and curtailment — a decade-long physical rebuild you cannot accelerate with a term sheet or VC your way through.

That reframes where the hard problems live. If midday solar is free-to-negative and energy storage is scarce, then when and where you run a workload stops being an infrastructure footnote and becomes an optimization problem. Training and inference want to chase the curtailed megawatt-hour — the energy nobody else can absorb — and that is a scheduling problem, a siting problem. In short — a software problem.

OK. So compute doesn’t get to escape the grid. It has to become grid-aware. My take is that we’ll also see some companies specializing in carbon- and price-aware scheduling — deciding which data center wakes up when the wind blows in the right country. By the way this isn’t hypothetical: Google has been running exactly this kind of carbon-intelligent scheduler since 2020.

Full circle, then — to the real connection to sovereignty. The power bill itself was part of the problem. The grid that issues the bill is being rebuilt for reasons that predate the first transformer block — and anyone who wants to build sovereign AI on top of it inherits that rebuild whether they like it or not.

Last but not least — even if every AI lab folded tomorrow, Europe’s energy story would still be the dominant infrastructure story of the decade. Sovereignty isn’t optional.

It just gets a hell of a lot more headlines when we frame it as an AI problem.

In April 2025, the European Commission announced it would mobilise €200 billion to make Europe an “AI continent” — €20 billion of it earmarked for up to five AI gigafactories, each a cathedral of a hundred thousand processors.

The phrase “AI continent” might make our American friends smile — the indulgent smile you give your grandpa when he announces he’s finally getting on Facebook. It’s a big aspiration from a place that doesn’t yet own a single layer of the stack. But the money is real, the ambition is serious, and you wouldn’t be wrong to read it as Europe finally getting its shit together. Or at least trying to.

As always, there’s another angle to it.

That same Europe needs €584 billion of grid investment by 2030 just to keep the lights on as electricity demand climbs — a bill it has not figured out how to pay. We are writing cheques in Brussels for the compute, and quietly hoping the wires magically show up on their own.

They will not. Well, not magically at least.

The queue outlasts the model

In the last article I argued that sovereignty isn’t blocked by software, or even by chips. It’s blocked by electrons. Let me show you exactly where the block lives.

As I’ve mentioned — a single modern AI cluster draws as much electricity as a quarter-million homes. Anthropic expects that developing a single frontier model will need a 5-gigawatt data center by 2028 (equivalent to the output of roughly five nuclear reactors). In 2026, that’s roughly 6% of Poland’s entire installed generating capacity (75 gigawatts), ~4% of the UK’s (about 115), and ~3% of France’s (roughly 156).

A hyperscale data center can be built in eighteen to twenty-four months. Getting it connected to the grid in one of Europe’s five big data-center hubs — Frankfurt, London, Amsterdam, Paris, Dublin — takes seven to ten years. In some cases thirteen. At the same time a frontier model is superseded in twelve to eighteen months (Opus 3.x released in Mar 4, 2024, and Opus 4.x first released in May 22, 2025).

As of January 2025, more than 11,900 businesses were queued for a grid connection in the Netherlands alone, and operators have started openly rationing power. West London has connection quotes stretching into the 2030s, with the transmission upgrades that would relieve it not due until 2037.

And this isn’t for lack of a plan. The €584 billion figure comes from the EU’s 2023 Action Plan for Grids — a document that correctly diagnosed every problem above. Two and a half years on, the verdict is in: the ambition went up, but the wires didn’t. Roughly 1,700 gigawatts of renewable and hybrid projects now sit in connection queues across 16 countries — more than triple what’s needed for 2030, and about double the EU’s entire installed renewable fleet. In 2024 alone, €7.2 billion of clean power was thrown away across just seven countries because the grid couldn’t carry it. The plan’s voluntary tools were so clearly not enough that in December 2025 Brussels had to come back with a binding Grids Package — and a price tag that had ballooned to €1.2 trillion by 2040.

The chip was a chokepoint US controlled. The wire is a chokepoint Europe built for itself.

Ireland’s example

If you want to see where this ends, look at Ireland. Ireland did everything right by the old playbook. It courted every hyperscaler on Earth, built the Silicon Docks, became the data-center capital of Europe.

It had consequences, though.

In 2024, Irish data centers consumed 22% of the country’s entire electricity — up from 5% a decade earlier, and more than every urban home in the country combined. The IEA says no other country carries a heavier load, and forecasts put it near a third within a few years.

So Ireland froze new connections. And when it finally lifted the freeze at the end of 2025, it replaced it with a sharp solution: large new data centers now have to bring their own dispatchable power — onsite generation or storage matching what they draw. In short — build your own electrons, or don’t build at all.

I don’t think that’s an Irish quirk. It’s more of a preview.

But renewables!

Yeah, yeah, yeah. Europe is crushing it on clean power. I know. And it’s true — in 2024, renewables hit 47.5% of EU gross electricity consumption, up from 15.9% in 2004. By 2025, solar and wind were outgenerating fossil fuels altogether, with over 70% of EU electricity coming from low-carbon sources. Genuinely a triumph.

Hold the applause for one paragraph.

The headline hides the gap. Take my own country. Poland crossed 50% renewables by installed capacity in 2025 — a great press release. By electricity actually generated in 2024, renewables were about 29%, and coal still supplied 57%, the highest share in the EU (which won’t surprise anyone who knows the country’s history, where coal was less a fuel than a national institution, the same industrial heartlands that, alongside the Gdańsk shipyards, gave us Solidarność). The distance between what you’ve installed and what you can dispatch at 3 a.m. is the whole problem in one statistic.

A renewable grid is optimised for the average megawatt. An AI cluster needs the instantaneous gigawatt — at three in the morning, in February, with the wind down and the panels dark. And the two failure modes are different. A long training run that loses power doesn’t dim the lights; it loses everything since the last checkpoint. Serving the model to users is the opposite problem: it has to be on essentially always — what data centers are built around. Alas, this is neither how the wind nor the sun works.

Which is why the most striking line in European energy policy last year came not from a utility but from Ursula von der Leyen, who told the 2025 State of the Union that Europe needs “more homegrown renewables — with nuclear as a baseload.“

And batteries don’t close the gap. Europe’s fleet is growing fast — 40 GW by the end of 2025 — but today’s batteries average just 1.5 to 2 hours of duration. They’re brilliant at shifting cheap midday solar into the evening peak, and no help on the third still, grey day of a February high-pressure system. Storage makes a renewable grid smarter; it doesn’t make it always-on. For that you still need firm capacity underneath — long-duration storage, and the dreaded N-word, nuclear.

Read von der Leyen’s line, then, as the Commission quietly conceding that “just build more wind” is not, on its own, an AI energy strategy. You also need the boring, dispatchable, always-on megawatts — and that’s exactly where Europe’s clock runs slowest.

France’s first new EPR2 reactor won’t switch on until 2038. Britain’s Sizewell C took its final investment decision in 2025 and faces nine-to-twelve years of construction. Poland’s first reactor: somewhere between 2036 and 2040.

For comparison, the United States is bringing the mothballed Three Mile Island reactor back online by 2028 under a Microsoft power deal — about four years from announcement to switch-on. America is restarting old reactors faster than Europe can build new ones.

The race

Let’s get a little uncomfortable by seeing where we are in comparison.

In 2024, China added 429 gigawatts of new generating capacity in a single year — a 21% jump, the most any country has ever added. Of that, 356 GW was wind and solar: roughly four and a half times the EU’s additions, and close to the entire installed wind-and-solar base of the United States. It also waved through 54 GW of new fossil capacity, because when you’re building baseload you take it where you can get it.

On the other side of the race, the American private sector. OpenAI’s Stargate project planned nearly 7 GW of AI capacity across new sites in nine months, more than $400 billion committed, ahead of schedule. To put that 7 GW in European terms: it’s larger than the entire peak electricity demand of Ireland, which peaks at roughly 5–6 GW. One company, one project, secured more power for AI than a mid-sized European country uses for everything.

Europe’s answer, the gigafactory programme, won’t break ground until 2027.

The €200 billion compute cheque and the €584 billion grid gap aren’t two separate stories. They’re the same story. The first is what Europe wants. The second is what Europe is standing on. If you ask me, right now the foot is going through the floor.

The bypass?

Now, the industry is not waiting around for the wire. It never does. The good thing about capitalism is that wherever there’s money to be made, someone will find a way.

If the public grid quotes you a decade, you build your own. Across Europe, data-center operators are putting up gas turbines, co-locating with dedicated wind and solar, turning their backup batteries into grid assets — anything to skip the queue. One estimate puts the AI-dedicated data-center buildout in Europe at around €176 billion through 2031, much of it now routed around the public grid. In the US, a single turbine-maker’s order book has hit 100 GW, sold out past 2028.

Clever. And for any individual operator, completely rational.

But notice what just happened. We started the last article worried that a foreign government could flip a switch on our models. The escape route depends entirely on who owns the turbine. A European operator powering a European data center with European gas? That’s real sovereignty — exactly the point. But increasingly the builder and the owner are the same American hyperscaler. In that case the private plant doesn’t shorten anyone else’s queue, doesn’t relieve the national grid, and answers to no European energy plan. It’s dimensioned for one data center and switchable by one owner — and that owner isn’t European. You haven’t escaped the foreign switch. You’ve poured concrete around it.

The one chokepoint you can actually build

So here’s where I land, and it’s less bleak than it may sound.

Of all the layers in the AI stack, the grid is the only one Europe can fully own. The lithography machines are Dutch but singular (and US controlled). The best open weights are American. The chips are American and Taiwanese. But a transmission line through Lower Silesia, a battery park in Iberia, a reactor on the Baltic coast — those can be ours, end to end, no foreign letter required to keep them running.

Can be — with one asterisk. A grid wired with Chinese transformers and battery cells just swaps dependence on Nvidia for dependence on someone else. The rule is the same one we keep relearning: own the layer and its supply chain. The difference is that here, unusually, Europe isn’t starting from behind — in transformers, HVDC links and cabling it has real champions (Siemens Energy, Nexans, Prysmian). It has no such thing for frontier chips or models.

That’s the inversion worth sitting with. The thing everyone treats as the boring, capital-intensive afterthought — the wires, the firm megawatts, the storage — is the one rung of the ladder no one can switch off from abroad. Europe spent a decade chasing model sovereignty and chip sovereignty, the two things it can least control. The sovereignty it can build was sitting in the substation the whole time.

It is unglamorous. It is a permitting fight, a financing fight, a fight with everyone who’d rather not have a pylon in their sightline. €584 billion of fight. But it’s a fight with a known answer — pour the concrete, string the wire, sign the nuclear offtake, stop treating the grid as plumbing and start treating it as the strategic asset it has quietly become.

So it’s not so much that sovereignty is blocked by electrons. It’s not blocked. It’s just unbuilt.

And unbuilt is the one problem on this list that money and a decade of nerve can actually solve. The question isn’t whether Europe can build the grid. It’s whether it starts pouring concrete now — or finishes paying the power bill in someone else’s currency.

As you’ve probably heard already, last week on Friday evening, June 12th, at 5:21 PM Eastern, a letter arrived at Anthropic from the US Commerce Department. By the early hours, two of the most capable (allegedly!) models on the planet — Claude Fable 5 and Mythos 5, released barely days earlier — were dark. Neither throttled nor rate-limited — just cleanly disabled. For everyone, everywhere.

The reason, on paper, was national security. The actual mechanism is worth sitting with for a second, because it’s the kind of detail that sounds made up. We’ll get into that later — though it’s not the part of the story that matters most to me.

Here is the thing: the order didn’t ban the models in a country. It banned them for foreign nationals — a nationality test, not a geography test. The geography test as it is, is already a difficult thing to enforce (VPNs and all). A nationality test is roughly impossible to enforce with a scalpel. You can’t reliably serve one model to an American in Seattle and withhold it from a French engineer sitting at the next desk, or from Anthropic’s own foreign-born staff.

And so Anthropic did the only thing the order left it room to do. It pulled the plug globally. I guess you wouldn’t be wrong to read this as a story about Anthropic getting unlucky. I mean one could argue they’ve brought it upon themselves — for months Anthropic talked up Mythos as so dangerous it couldn’t be released publicly, and that drumbeat is precisely what drew the government’s eye.

That’s the obvious frame, and it’s not entirely false. There’s another angle to it, though.

The jailbreak or a regular feature

Here is what the government was apparently worried about, in Anthropic’s own telling. The dangerous “jailbreak” at the heart of the order “essentially consists of asking the model to read a specific codebase and fix any software flaws.”

Read that again. The catastrophic national-security capability is: the model finds bugs in code.

…

Well, one cannot help but think there is something else to that story (a quid pro quo, maybe?). The feud between Dario Amodei and the administration has been simmering for months — the Pentagon even branded Anthropic a supply-chain risk. Anthropic, understandably, pushed back hard. They noted the same capability is “widely available from other models (including OpenAI’s GPT-5.5), and is used every day by the defenders who keep systems safe”. They noted the government acted on “only verbal evidence of a potential narrow, non-universal jailbreak.” And they pointed out — this is the part that should make any frontier lab’s blood run cold — that if this standard were applied consistently, “it would essentially halt all new model deployments for all frontier model providers.”

A government reached in and switched off two commercial frontier models — globally, for everyone — on the strength of a verbal claim about a capability that amounts to reading source code. These two happened to be days old. The next one it reaches for might be the model your bank, your hospital, or your government already runs on.

The point isn’t whether this particular order was wise or even survivable — Anthropic is challenging it, dozens of cybersecurity veterans have signed an open letter against it, and these two models will likely be back. The point is that we just watched the switch get flipped. We now know it exists, where it sits, and whose hand is on it.

We’ve run this experiment before

Here’s the part where the tech industry’s famously short memory kicks in, so let me get ahead of it.

For years, the way a government controlled access to advanced computing was through chips. We built an extraordinarily long, extraordinarily fragile chokepoint stack and then acted surprised that someone might use it.

Start at the bottom: the machines that make the chips. Extreme ultraviolet lithography is a global monopoly held by a single Dutch company, ASML — effectively one building in Veldhoven, with no alternative supplier on Earth. One rung up: the chips themselves. Since 2022, successive US export controls — the BIS rules, then the “AI Diffusion” framework that sorted the entire world into tiers of chip access — turned Nvidia silicon into an instrument of foreign policy. The H20 saga, the country tiers, and the whole apparatus. (The Diffusion Rule itself was later rescinded before it ever took effect — a reminder that these levers get pulled and reversed at will).

Fabs, then chips. And now, with Anthropic, the third rung: the trained model itself.

So, it is not a novelty. It’s more of a pattern reaching its logical conclusion. Political scientists Henry Farrell and Abraham Newman gave it a name — weaponized interdependence — the idea that whoever sits on a chokepoint in a shared network can quietly switch the rest of us off. The US already controlled who gets the machines and who gets the chips — and the way it does that is itself a small lesson in how this game is played. ASML is Dutch, not American, yet Washington still dictates who it can sell to. The lever is the Foreign Direct Product Rule: because roughly a tenth of an EUV machine’s value is US-origin technology (down to the laser unit, made by Cymer, a US subsidiary ASML bought in 2013), the US claims jurisdiction over the entire machine — wherever it is built and whoever buys it. A ten percent stake, a hundred percent veto. The Dutch have spent years quietly trying to claw that control back.

Controlling who gets the model was always the next move. We just hadn’t seen it happen to a live one before.

“It’s just 1999 again”

Now, the steel-man, because we deserve one.

The contrarian case is that none of this is new and everyone needs to calm down — this is overreaction, export bans happen, the models will be cleared faster than most, the tech industry just has short memories.

And the history is real. In the summer of 1999, the United States classified the PowerMac G4 as a munition — a weapon — for crossing the one-gigaflop threshold, and banned its export to some fifty countries. Apple turned the absurdity into an ad: “For the first time in history a personal computer has been classified as a weapon by the US government.”

Go back a little further and strong crypto was literally classed as a weapon under US export law too — Netscape’s “International” build shipped a deliberately crippled 40-bit cipher that researchers cracked in days. Export controls on computing power are not new. They land, they make headlines, and they usually pass.

And on the narrow question — will these two models come back? — the contrarians are probably right. They likely will.

But the analogy quietly smuggles in an assumption. In 1999, a US export control landed on a continent that trusted the United States. It was an ally’s bureaucratic hiccup — annoying, temporary, fodder for a clever ad. The context made it small.

Sadly — and I am saying this as a European — that context is gone.

The number that matters more than the ban

Two days before the Anthropic block, the European Council on Foreign Relations published a poll across fifteen countries. Only 11% of Europeans now describe the United States as an “ally” — down from 22% in late 2024. In every country surveyed, majorities doubt the US would actually defend them if attacked.

If you have to ask why, you’ve spent the last year or so under a rock. It’s the backdrop of an 18-month rupture. “Liberation Day” tariffs that pushed the headline US rate on European goods to 20% — part of a salvo that lifted America’s average tariff to its highest level in over a century. A fragile 15% truce the European Parliament could only ratify by bolting on a sunset clause — because it didn’t trust Washington to honor the deal. Over $7 billion in EU fines on US Big Tech, answered by US visa bans on the European officials who wrote the digital rules. An $800 billion European rearmament plan. US troops coming home from Germany. Ursula von der Leyen, a year ago, calling it “a very strong wake-up call”; by Davos, calling for “a new form of European independence.”

A perfect storm.

So no, this is not 1999. In 1999 the switch belonged to a friend. The mechanism is identical; the meaning is quite different. The novelty was not the ban. It’s that the hand on the switch is no longer one Europe is sure it can trust.

The contrarians are right that export bans aren’t new. They’re wrong that this one is just another. The context has changed — the US is no longer an ally Europe can count on.

The sovereignty hair-trigger reflex

Europe’s response was immediate and predictable: build our own. The day the switch flipped, the Polish open-weight model Bielik — an Apache-licensed project built by volunteers at the SpeakLeash foundation and the Cyfronet supercomputing center in Kraków — quote-tweeted Anthropic’s own shutdown announcement with a single line: “Do you need a clearer argument for developing sovereign AI models?”

It is a good line.

And I believe the sovereignty reflex is the right instinct. But here’s where I want to slow down, because the reflex hides a trap that the cloud era didn’t have.

Think back to ten years ago, when the worry was cloud lock-in. If you got nervous about AWS or Azure owning your destiny, you had a real escape hatch: on-premise. Bring it back in-house. Buy your own servers, run your own racks. The migration was miserable, expensive, slow — but it was possible, and at the end of it you genuinely owned the alternative. Sovereignty was a purchase order away.

What’s the equivalent for a frontier model today?

The good news is better than you’d expect. Open-weight models — Llama, Mistral, DeepSeek, Qwen (and Bielik) — are now genuinely competitive: Qwen-family systems post SWE-bench Verified scores in the high seventies on real GitHub issue resolution. Closed Anthropic systems still top many public trackers — so the case for open models isn’t that they clearly lead, but that they’re becoming good enough for a growing share of enterprise work.

And increasingly, the thing that matters isn’t the raw weights at all — it’s the harness wrapped around them: the agent loop, the tool calls, the scaffolding that turns a model into something that actually does work. Claude Code is the obvious commercial example of the pattern; open-source harnesses are increasingly replicating it — replicable, and improving fast, which quietly tilts the math even further toward the open alternative. You can rent European GPUs, deploy the weights, and run the whole thing yourself. Open-source agent harnesses increasingly speak the same APIs as the commercial tools, so in principle you can run the entire loop locally — your code never leaving the building.

So we’re fine, right? We just self-host.

Not quite. Look at what you’re actually standing on. The open weights you’d fall back to are American (Llama) or Chinese (DeepSeek, Qwen). And whichever you pick, it runs on Nvidia GPUs — the very silicon that sits behind the chip export controls we just walked through. The fallback to escape US AI dependence is built on US AI hardware. No European AI accelerator exists on any credible timeline before 2030; the one new advanced fab on the continent, TSMC in Dresden, makes chips for cars, not for training runs.

With cloud, you could buy your way to sovereignty. With AI, you can only buy your way to less dependence.

The wall

Fine, says the optimist. Less dependent is still better. Build the European stack anyway — the models, the data centers, the whole sovereign rig. Throw money at it.

And this is where the story stops being about software, or even about chips, and becomes about something far more stubborn.

Because a sovereign AI is not only about software. It’s a physical thing that has to sit somewhere — in a building, drawing power, on a grid. The weights are portable. The machine that runs them is emphatically not. And the moment Europe tries to actually own that machine at scale, it runs headfirst into a constraint that no amount of capital or political will can conjure away on the relevant timeline.

Sovereignty, it turns out, isn’t blocked by software. It isn’t even, ultimately, blocked by chips.

It’s blocked by electrons.

Here’s what that means in practice. A data center can be built in twelve to eighteen months. Getting it connected to the electrical grid — the cables, substations, and permits that actually deliver the power — now takes seven to ten years across Europe’s major hubs. That gap is the real wall. You can pour concrete and rack GPUs at the speed of capital; you cannot conjure a high-voltage connection on the same timeline, no matter how much money or political will you throw at it.

And the load is not small. A single modern AI cluster draws as much electricity as a quarter-million homes. Anthropic expects one frontier training run to need five gigawatts by 2028 — the output of roughly five nuclear reactors, for a single model. To put that in perspective: Poland’s entire installed generating capacity is around 75 gigawatts, the UK’s about 115, France’s roughly 156. One training run is already a few percent of a mid-sized European country’s entire power system — and a serious sovereign-AI buildout means many of them running at once. In Ireland, data centers already eat more than a fifth of the entire country’s electricity, heading for nearly a third; official plans put future data-center demand at roughly the nation’s all-time peak. In the Netherlands, the grid is so congested that some new connections are being quoted waits into the mid-2030s. The grid is full, and the line is years long.

So the real race for AI independence in Europe is, underneath everything, a fight over power. The electrical kind.

And that’s a whole different story. A story that deserves another write up.

Last year (!) Brian Armstrong told the world that ~40% of daily code at Coinbase is AI-generated — and that he wanted it past 50%. I bet many people read it as a layoff memo with a future tense. Truth be told, the story seemed to write itself: AI gets good at code, engineers get cheap, then optional, then gone.

And you wouldn’t be wrong — the layoffs happened, just a few months later.

There’s another angle to it. Look at what Armstrong actually does on weekends. He builds little web apps. By his own account, “it’s not really coding — I just observe, communicate, execute, and copy-paste, and it usually works.”

It’s interesting because he is by no means alone. Garry Tan runs Y Combinator and still ships ten to twenty thousand lines of code a day on the side — cheered by some as proof of what’s possible, dismissed by others as throwaway slop. At least it’s entertaining.

I have personally had many conversations mirroring this sentiment.

The point is — people further from the codebase keep climbing back into it. Not to replace the engineers, but rather because — among other things — it turned out to be fun. Hell, it is!

That’s the part where I start to question the ongoing replace-or-augment debate.

Essentially, we were sold two futures. In one, AI makes engineers faster (which it does), and demand for them explodes. In the other, it makes them unnecessary. In other words, one assumes that the demand will expand (due to cost going down) and the other assumes that it is fixed (or at least growing way slower than supply).

What if the pile was bottomless, though? Or what if it’s at least way deeper than we think? So deep in fact, that due to the entry barrier falling through the floor, the cohort of engineers, even if it grows, will be dwarfed by an even larger cohort of non-engineers building software?

Brian Armstrong even said as much in his layoff Twitter/X post:

“Second, AI is changing how we work. Over the past year, I’ve watched engineers use AI to ship in days what used to take a team weeks. Non-technical teams are now shipping production code and many of our workflows are being automated. The pace of what’s possible with a small, focused team has changed dramatically, and it’s accelerating every day.”

I just happen to work with an institutional investment office — analysts and portfolio people. Most not being software engineers by training. In the old days they were supposed to be the consumers of software the tech team builds for them.

Instead they became the catalyst. They build their own workbenches now. They manipulate data, stand up small applications that crunch a dataset and render a dashboard, ship things that are genuinely useful. People who hadn’t written a line in fifteen years, or ever, are suddenly in the code. And you can see it on their faces — they are enjoying it!

If you think about that, we’ve run this experiment before, every time the entry barriers to programming dropped. Assembly to Fortran and C let scientists write their own simulations instead of begging the systems team (not mentioning what the introduction of Python did!).

The spreadsheet turned millions of accountants and analysts into programmers who would never accept the title.

No-code/low-code did it again (albeit never at the scale we were promised).

Each wave, the prediction was the same — this abstraction will reduce the need for programmers — and each time the population of people who build software went up, not down, because the barrier to entry fell and a new cohort walked in.

LLMs are just the steepest drop yet. The barrier used to be syntax, setup, and the years it takes to stop being dangerous. The barrier is now a clearly stated intent. So of course the CEO is back. So is the analyst, the PM, the designer, the ops lead who spent a decade routing around IT with increasingly cursed spreadsheets.

Yeah, yeah, yeah. Jevons Paradox. We heard it before.

But hear me out: the cheaper code gets, the more of it the organization wants, and the more of your non-engineers quietly become part-time builders.

That’s not a threat to your engineering function! It’s a vastly larger surface area of software, created by people who don’t report to it, don’t follow its conventions, and don’t know what they don’t know. Give it a second thought, because this has significant implications for tech organizations (or rather — any kind of organization).

Which is exactly what happened the last time. The spreadsheet didn’t just make accountants into programmers — it made them into programmers nobody supervised, and the unsupervised work turned out to run real things. A copy-paste slip in a risk spreadsheet helped JPMorgan misjudge the exposure behind a multi-billion-dollar loss. An Excel error in a single Reinhart-Rogoff paper propped up austerity policy across actual governments. Audits have long found that the overwhelming majority of consequential spreadsheets contain errors. So within a decade an entire industry existed to govern the result: version it, audit it, lock down what data it could touch, and stop a fat-fingered cell from quietly restating earnings.

And a vibe-coded app is the spreadsheet’s far more dangerous descendant. A spreadsheet sits in a file; an app reaches into the production database, calls live APIs, moves money, holds the PII. And yes, I have seen the blasphemous contraptions people already build in Excel. Still, a spreadsheet error pretty much stays in its cells; an app error is a breach, a leak, or a 3 a.m. page.

In essence though — the builders came first. The rails came after — retroactively — because the rails turned out to be where the real problem, and the real market, lived.

So here’s the thought.

Everyone is busy building the tools that help amateurs produce the first working version. Others are building AI SDLC pipelines for engineers.

Almost no one is building the part that makes the thousandth version last — the pipelines, the guardrails, the paved road that lets a portfolio analyst’s Saturday app run on Monday without an engineer babysitting it.

And any technology leader with visibility into budgeting knows — the majority of costs of software development are spent on maintenance.

The market for helping non-engineers build things (not prototypes!) that last is under-explored. The on-ramp is crowded (prototype). The highway is crowded (SDLC pipelines). Nobody is paving the regular road.

If the prototype is now free, the durable thing around it is the scarce one. That’s not the small market. It might even be the bigger one, as more and more people become builders.

We’ll see what happens. One thing is certain — the bugs caused by incorrectly filled Excel spreadsheets will be overshadowed by the problems that will come from the new wave of apps being built.

Fasten your seatbelts, because it’s going to be a hell of a ride.

Next week I’m heading to New York for Tech Week. I always look forward to the trip — partly for the events, partly because New York is just a great city to land in. If you’ve never been, MoMA is one of those places worth carving out half a day for. Starry Night, the Rothkos, the Picassos, and so on.

MoMA is also home to a funny story.

In October 1961, the museum opened a new exhibition: The Last Works of Matisse: Large Cut Gouaches. Among the pieces was Matisse’s Le Bateau — a sailboat and its reflection. It hung in the gallery for 47 days before a visitor, a stockbroker named Genevieve Habert, pointed out that it was upside down. The reflection was on top. The boat was on the bottom. Tens of thousands of people had walked past it, and no one else noticed.

The software industry runs on a similar trick.

There’s a pattern in tech that’s so reliable you could almost set a watch by it. Someone has a good idea. The idea spreads and turns into practice. Within one cycle, the industry has implemented something that is, on close inspection, pretty much the opposite of what the practice was supposed to be. And yet, we keep the original name.

Agile is the obvious one. The original manifesto is 25 years old. It’s eight bullet points long, and almost militantly anti-process. “Individuals and interactions over processes and tools.” “Responding to change over following a plan.” What we built on top of it is two-week deadline cycles dressed up as sprints, and Jira workflows with more states than the periodic table. The retrospective — the one ritual whose entire job was to change something — became the meeting everyone skips (or has lost hope that it can meaningfully improve anything). We took a document arguing against process and turned it into a process-heavy way to ship software. Hell, we've even built an entire certification industry on top of it — over a million SAFe-certified professionals, another 1.5 million through Scrum Alliance!

DevOps had a simpler fate. The whole point was to tear down the wall between development and operations. Shared ownership. No handoffs. Engineering teams responsible for what they shipped. So we built a new wall, painted “DevOps” on it, and hired a team to stand behind it. The job posting reads: “DevOps Engineer — own the CI pipeline so the developers don’t have to.” The wall is taller now, and it has a Jira queue.

Microservices were supposed to give teams independent deployability. Small services, clear contracts, deploy on your own schedule. What most companies actually built is a distributed monolith — every service depending on every other service, except now the dependencies travel over a network with retries and timeouts and a 40-page runbook. We didn’t decouple the system. We decoupled the deployments and coupled everything else harder. The reward for splitting your monolith is that now your monolith has latency.

And — the part that got me thinking about all this from my previous article — the Product Trio. Cagan’s point was that PM, design, and engineering should sit so close together that the seams disappear. One team, three skills, one outcome. What we built instead is three sub-organizations with separate VPs, separate roadmaps, and a shared Confluence space. The trio became a triad became a tax.

So why does this keep happening? My working theory is dull.

Good ideas in our industry arrive as practices, and orgs metabolize practices the only way they know how — by assigning them a manager, a budget line, and a team name. The practice dies on contact with the org chart. The main aspect that survives is the name.

With the AI revolution, we are about to have new ideas. Ideas that will improve how we build software at scale. The next big idea may be about how product disciplines collapse into each other, with AI as the connective tissue.

And yet — give it a cycle. I suspect it will have a separate vertical in the org chart and a VP before the cycle ends.

In a recent client engagement, I’ve been working with investment analysts. A small tech team works alongside the business. The analysts themselves are building their own POCs — not through a PM, not through a backlog, not through a request-for-proposal that turns into a Jira epic six weeks later. They prototype directly. And they do it with Claude Code. The small tech team (us) picks up where the business’s prototype runs out of road, expands it, and productizes what survives.

Five years ago, this engagement would have been a delivery team of six+ on the vendor side — PM, designer, frontend, backend, devops, you name it — handing off to a passive business sponsor on the client side.

So, what happened?

The seats that have disappeared are the seats that existed to translate between the business and the engineering.

That is the article in one anecdote. What used to flow through a chain of specialists — each translating the work for the next — now flows directly. The seats that survive on both sides are smaller, more senior, and more shaped.

In the previous essay, I described what I think is happening to the composition of the software engineering workforce. This is the companion question:

What shape does the surviving organization actually take?

I believe there are three threads to this.

The Triad was a coordination structure

For about fifteen years, the canonical tech org had three sub-organizations. Engineering. Product. Design. The “EPD triad” — popularised by Marty Cagan / SVPG (Inspired, 2008):

In modern teams, we tackle these risks prior to deciding to build anything. These risks include value risk (whether customers will buy it) [Product], usability risk (whether users can figure out how to use it) [Design], feasibility risk (whether our engineers can build what we need with the time, skills, and technology we have) [Engineering], and business viability risk (whether this solution also works for the various aspects of our business—sales, marketing, finance, legal, etc.) [Product].

Inspired: How to Create Tech Products Customers Love (Chapter 7)
by Marty Cagan / SVPG (annotations mine)

It roughly maps to a “three risks” frame:

• Product = value/viability

• Design = usability

• Engineering = feasibility

The triad existed because specialists couldn’t easily understand each other’s work. PMs translated business intent into requirements engineers could execute. Designers translated user needs into visuals PMs could approve. Engineers translated requirements into a working system, and then translated the system’s constraints back into something PMs could communicate to the business.

Cagan’s work became part of the intellectual foundation for product people. By the mid-2010s, it was an industry-wide convention, and organizational structures grew to mimic the frame.

Instead of tight collaboration, we drew organizational boundaries along these dividing lines. (This might have been a distortion of Cagan’s thinking, by the way.)

Every translation now carried a tax — a meeting, a Jira ticket, a Figma handoff, a spec doc, a Slack thread, a manager whose entire job was to enforce the protocol. The tax was the price of having specialists who couldn’t do each other’s jobs.

The cracks start to appear in the facade of this tax, though.

Sahil Lavingia, Gumroad’s CEO, predicted it in a walkthrough of his own workflow back in January 2025. I highly recommend watching it — it has aged remarkably well, in times when material from last month is often already outdated. His estimate of the speed gain, in certain cases, is around 40x — a number that sounds absurd until you notice it is mostly the translation time between specialist teams that has been removed, not the time spent doing the underlying work.

A PM who prototypes in Cursor no longer needs an entire engineering team to validate feasibility — the prototype itself is the validation. Sure, it might need proper guardrails and scaffolds, and maybe someone to productionize the output. But that is very different from throwing a ticket over the wall.

Likewise, a designer who can ship their own React doesn’t wait in a queue for engineers (though they might need a code review).

Shopify now includes vibe coding in PM interviews. Think about that. Oh, and Shopify is not the only one. Google, Netflix, and Stripe followed. There is an expectation that a PM can ship a working prototype in 2026.

Maryam Ashoori, leading WatsonX product at IBM, mentions that the traditional 1 PM to 8 engineers ratio is being replaced by 1 PM to 0.5 engineers.

Heck, Marty Cagan himself predicted last year that within 3–10 years we should expect product teams to compress to 3 people.

Joel Lewenstein, the Chief Design Officer at Anthropic, calls it a Venn diagram coming closer together — heavy role collapse upstream in ideation and prototyping, with clearer swim lanes still re-emerging downstream at scale (this is productionization).

The triad is shrinking because the protocol between the three organizations was the expensive part. And a large chunk of that protocol got eaten by AI.

Layers go with it

Some management layers existed to manage the translation. When the translation goes away, these layers have nothing left to manage.

GitLab announced Act 2 on May 11. “Eight layers is too deep for a company our size, and management layers are slowing us down.” They are removing up to three layers in some functions and reorganizing R&D into ~60 smaller teams with end-to-end ownership — nearly doubling the count of independent units. CEO Bill Staples explicitly framed it as “rewiring internal processes with AI agents, automating reviews, approvals and handoffs.”

Meta’s Applied AI engineering team is now running at a 50:1 employee-to-manager ratio. The industry “outer limit” for span of control is 25:1. The research-determined optimum, depending on whose textbook you use, sits around 7. Jensen Huang is notorious for running Nvidia with 60 direct reports and no one-on-ones. But this sentiment is spreading across the industry. Andy Jassy mandated a 15% increase in the IC-to-manager ratio at Amazon at the end of 2024 and doubled down on it in his 2026 shareholder letter. Microsoft cut 7,000 middle managers in May 2025 — without even using the word “AI” in the announcement.

There is a fresh quote from Brian Chesky noticing the same thing: “I don’t think people managers will have any value in the future. When I mean people managers, I mean people that only manage people. (…) You can’t just be these managers where you’re people’s therapists, doing meetings, doing one-on-ones.” The direction is the “manager IC” — every manager has to manage through the work, not around it.

The pure-coordination role — the manager whose job was to be a load-balancer or translator between specialists — is being deleted at the same time the specialists themselves are being merged.

The shaped generalist comes back

If specialist teams merge and translator managers go, what shape is left? There’s a third thread. The people who survive look different from the people who got the company here.

The 2010–2022 era of hyper-specialisation — backend engineer, frontend engineer, infra engineer, ML engineer, data engineer, mobile engineer, QA engineer, SRE, DevEx, four flavours of designer, three flavours of PM — was a function of two things. Cheap capital, which let companies hire one of everything. And the limits of any one human’s ability to hold the whole stack in their head.

Both of those constraints have softened. Capital is no longer free. And the assistant you sit next to can hold whatever part of the stack you forgot.

What comes back is the T-shaped generalist. An engineer who can write the spec, ship the prototype, validate with users, instrument the metric, and own the operational tail. A product person who can prototype the thing they used to brief. A designer who ships their own UI to production. The early-stage founder profile, basically — but as the default shape of a senior contributor at scale, not just at seed.

YC’s Requests for Startups for 2026 names this explicitly: “For the first time a 2–3 person team can ship something a Fortune 10 can find useful before the ink is dry on their incorporation docs.” Tobi Lütke’s Shopify memo made AI usage a basic expectation, and made managers prove AI couldn’t do the job before approving headcount.

Small teams of shaped generalists, with no coordination tax between them, can now do work that used to require the organizational triad plus three layers of management above it.

Where this breaks

It’s worth being honest about where the collapse stops.

Late-stage product work still has swim lanes. Lewenstein’s nuance is the right one — collapse upstream, clearer specialisation downstream as you scale and harden. So it works up to a point. Still, the feasible range is increasing.

Regulated and safety-critical domains — financial services, healthcare, defence, anything with an audit perimeter — still reward people who own a narrow column deeply.

And the span-of-control numbers at the extreme end are going to break some managers. One Wall Street Journal-quoted manager with 36 direct reports described a “constant state of inadequacy”. I can tell you I’ve already had multiple conversations like that. No one said the transition was going to be easy.

And yet, my take is that removing the layers without redefining how the role gets spread out will produce false efficiency. We’re going to find out soon enough.

The optimistic version of this article is that coordination between the organizational triad was a tax, and the tax is being repealed. The honest version adds: that doesn’t mean the underlying functions disappear. It means they get redistributed across fewer, more capable people — and the people who used to do them as full-time specialist roles need to become something else.

What now?

Play It Again, Sam described the substitution happening at the engineering level — routine work absorbed into a tooled layer, strategic work concentrated and repriced upward.

This is the same mechanism viewed from inside the org chart.

The Triad coordination was a tax.
The layer of managers above the triad was a tax.
The translation between roles was a tax.

What survives is smaller, flatter, and more shaped.

The function persists. The tools change. The people who change with the tools keep their seat.

I keep hearing two competing narratives — in real life, and in their extreme forms on social media.

One is: AI will eliminate software engineering (mostly hands-off CEOs, VCs, social media influencers). The other is: AI is a passing fad, and we are at the peak of the inflated expectations cycle (mostly skeptical hands-on engineers).

My bet: neither is right, and both miss the point of a technology transformation we have seen many times before.

Backdrop: Economic climate

Let’s zoom out a little.

It is sad to notice, but the 2026 tech layoff count is climbing, and we are dangerously close to being one of — if not the — worst years since the pandemic. Take that in for a moment.

By the first week of May, the TrueUp full-year projection sits near a staggering 361,000. Trackers disagree on the exact tally (Layoffs.fyi: ~103,000; Trueup: ~132,000) because they count differently, but they agree on the shape: 2026 will pass 2025’s ~246,000 US tech layoffs, with months to spare. Kalshi and Polymarket prediction markets have it at 91–93% odds.

(Disclaimer: if you look those numbers up, they are unlikely to be exactly the same — the data flows in continuously, and even while I was writing this essay they were, sadly, increasing)

The Q1 names are unambiguous.

• Oracle: ~20,000–30,000 cuts in March, tied to a $2.1B restructuring charge, explicitly funding AI data centers.

• Intel: 25,000+ between 2025 and 2026, headcount now under 100,000.

• Amazon: ~30,000 (and counting).

• Meta: 8,000 in Q1 (Zuckerberg said the cuts were structured as headcount reduction in service of AI infrastructure) on top of a quarter where revenue grew 33% and net income grew 61%.

• Cloudflare cut 20% of its workforce while growing revenue 34%.

• Coinbase cut 14% in a quarter where revenue fell 31%.

• PayPal: up to 20% of headcount over two to three years under a new CEO.

And yet, the coin has another side.

FRED’s Indeed Hiring Lab index for US software development job postings — IHLIDXUSTPSOFTDEVE for the curious — sits at 72.15 as of May 14, 2026. Pre-pandemic baseline is 100. So postings are still well below their 2022 peak. But they have been climbing since early 2025, and as of February US software-development postings were up 10% year-over-year while total US job postings declined 5.8%. The pattern I noted in March — that openings had been growing since the bottom of the dip in early 2025 — has continued and accelerated.

This is the article in two numbers: layoffs accelerating to a record; openings climbing back at a 10% YoY pace. Both are true at the same time.

How can that be?

The same six companies cutting headcount in Q1 had thousands of open engineering positions on their own careers pages on the same days the layoffs were announced — and a few of them are revealing. Meta: heavy on AI Research Scientists and ML Engineers. PayPal: Lead Product Manager, Agentic Commerce. Coinbase: Principal Machine Learning Engineer. Same for Cloudflare and GitLab.

Two CEOs

Two CEO statements from the last sixty days frame the whole story.

GitLab’s Bill Staples described his restructuring — three management layers removed, R&D reorganized into ~60 smaller teams — as “not an AI optimization or cost cutting exercise.” He said it in the same statement in which he also said “software will be built by machines, directed by people” and that agents will “plan, code, review, deploy and repair software.”

Wipro — yes, the Indian 200k+-employee behemoth — said the interesting bit out loud as early as 2024! When the company began cutting hundreds of mid-level onsite roles, an internal source described the doctrine as “Left-Shift”: “The work of a level 3 employee is shifted to a level 2 employee, who is given appropriate tools. A level 1 employee does the level 2 work, and the idea is that the work of a level 1 employee is automated.” That is the substitution mechanism stated cleanly. Wipro has continued — recruiters describe TCS, Infosys, and Wipro as having quietly cut around 50,000 jobs across 2025 under the label “performance management” or “skill mismatch,” while Wipro itself simultaneously hired 7,500 freshers in FY26 and now lists no fewer than 10,000 open positions (which you can check here).

The Wipro doctrine is the article. Push the work down the seniority ladder, give it tools, automate what is left at the bottom. Every other company is doing some version of it. Not everyone will say so on the record. Wipro said so two years ago.

The market is now discounting the AI-restructuring story even when CEOs deliver it cleanly. Cloudflare fell 24% on its AI announcement. PayPal fell 8%. Marc Andreessen — who has every incentive to talk AI up — called it a “silver bullet excuse.”

So what is happening?

We’ve seen this movie before

In 2008, every company of meaningful size had a Database Administrator. They patched, backed up, tuned, provisioned. By 2018, the title was rare. The popular reading: cloud killed DBAs.

The Bureau of Labor Statistics tells a different story. Database Administrators and Architects is projected to grow 4% from 2024 to 2034 (worth noting — the average growth rate across all professions is 3%), ~7,800 openings a year, median wage $104,620. Yet it would be dishonest to pretend nothing changed. You don’t meet DBAs at conferences anymore.

But that’s not even the whole story! True, AWS RDS and its peers absorbed the routine 70% of what a DBA used to do. The remaining 30% — schema design, query optimization, security posture, capacity, reliability — got more valuable, got renamed, and got absorbed into other roles. The vanilla Software Engineer got some of it on their plate, but new roles also emerged — Database Reliability Engineer, Data Platform Engineer, Data Engineer. New titles. Often paid better, by the way.

The function evolved and expanded. The vocabulary changed. But the people who refused to evolve got sorted out.

But let’s push the lens back.

The typical argument I keep hearing is: “But Pawel, cars really did kill horse-drawn carriages.”

But did they?

Yeah, it turns out they did. Between 1870 and 1900, in ten major US cities, the number of teamsters — carriage and wagon drivers — grew 328%, while the population grew only 105%. The horse-drawn era was expanding employment in the transport function right up to the moment cars arrived. Motor cabs reached London in 1897, outnumbered horse cabs by 1910, and the last horse-drawn hackney license was relinquished in 1947 — half a century of overlap. So yes — cars killed the carriages.

But…

The drivers didn’t disappear. The function — moving people and goods for a fare — exploded! Today’s combined population of taxi, rideshare, and delivery drivers dwarfs the teamster cohort of 1900.

The tool changed completely. The function persisted, and grew.

The narrative we remember is cars replaced carriages. The data says the function survived a tool transition and got much bigger.

If you ask me, those are two completely different stories.

From inside the seat

My personal experience is this. 60–70% of what an engineer used to spend their day on — boilerplate, scaffolding, glue code, test setup, first-pass documentation, routine refactors, the long tail of “Stack Overflow for an hour” tasks — is being absorbed by tooling.

Not eliminated. Absorbed.

It still gets done, in a tenth of the time, by a person plus a model. The remaining 30–40% — system design, ambiguous problem framing, integration across messy boundaries, judgment about what not to build — has become more valuable.

This is the Wipro Left-Shift in microcosm. Routine work absorbed into a managed layer. Strategic work concentrated and repriced upward. The engineers who lean into the new tooling are roughly two to three times more productive than they were in 2023. The engineers who don’t are visible from across the room. They are the people the layoff lists are quietly built around — at the same time the company is opening req after req for AI engineers, platform engineers, and AI product managers.

This is not replacement. This is sorting. The headcount may not change much. Which people fill those seats will.

Act accordingly

A workforce restructuring is in progress with multiple drivers — 2020–22 overhiring, the long-postponed cleanup of teams built in an era of free capital, the higher interest rate environment, and a genuine productivity shift from AI tooling. AI is the one clean future-facing word that wraps all of them into a single acceptable public sentence. But it is not the whole story.

The composition is what is actually shifting. Roles that were a large share of headcount in 2020 — high-volume support, low-leverage operations, manual QA, boilerplate-heavy backend, parts of middle management whose job was coordination overhead — are getting compressed. Roles that barely existed in 2020 — AI product managers, ML platform engineers, AI compliance, agent integration, AI-augmented sales engineering, prompt-driven analysts — are being hired at higher salary bands than what was cut. PayPal’s Agentic Commerce PM is not an anomaly. It is just the data point of the substitution.

So what does this all mean to you?

If you build software: the people who will not learn the new tooling will be sorted out. Not because AI replaced their job — because the job changed underneath them and they did not move with it. The DBAs who learned cloud became platform engineers and got paid more. The DBAs who did not, you stopped meeting at conferences. There is a version of this article being written in 2034 about software engineers. You can choose which side you want to be quoted on.

If you run a company: the “AI made me do it” framing has lost its credibility with the market, your employees, and increasingly the press. The honest framing — we overhired, we are right-sizing, and we are shifting the composition of the workforce toward roles that work with AI — is harder to deliver but holds up. Wipro stated the doctrine clearly in 2024 and is hiring 10,000 people while doing it.

The carriages went away. The drivers stayed, learned a new machine, and grew 10x over a century. The DBAs got renamed. The work got more valuable. The function persists. The tools change.

The people who change with the tools keep their seat.

AI coding tools make developers faster. Agents can take on chunks of implementation, testing, refactoring, and migration. Cloud platforms and APIs make infrastructure easier to assemble. Heck, every other software services company is trying to turn its SDLC into an AI-powered delivery platform.

On the one hand, we are entering the age of personal software: small tools, workflows, and systems built for one person, one team, one company, or one weird local problem.

Tomasz Karwatka described reviving his contact database by extracting context from notes, PDFs, Obsidian, LinkedIn exports, phonebook data, and Gmail, then building a simple local app around it. Tyler Jewell, CEO of Akka, spent a week mostly inside Claude while rethinking how his company should operate in an AI-human workflow.

CEOs are literally building. This is not just good ol’ “everyone becomes a programmer”. It is something more interesting: more thinkers, tinkerers, and operators can turn their mental models into working tools.

And it is truly amazing.

There is another side to this story, though. On the surface, this sounds like it should make software success easier. More people can try. More startups can launch. More teams can digitize workflows previously trapped in spreadsheets and meetings.

But a lower entry barrier does not reduce competition. It increases it.

The market gets flooded with more products, more demos, more internal tools, more AI wrappers, more vertical apps, more weekend prototypes, more software houses claiming proprietary delivery platforms, and more SaaS companies repositioning themselves as agentic workflow platforms.

Alas, not everyone becomes a successful software company.

We’ve seen it before.

Social media made everyone a creator. Well, not literally everyone, but close enough to change the market. You no longer needed a studio, a publisher, a TV network, or a record label to reach people.

We called it democratization.

And it was. More people could publish. More people could be seen. More people could build an audience without asking permission.

But it did not make everyone influential.

The creator economy became a power-law market, with a high concentration of engagement among the top roughly 0.5% of creators. Millions created. A few earned. A tiny fraction dominated.

That is the lesson worth remembering.

When the barrier to entry falls, markets usually become more competitive. More participants enter. More substitutes appear. The market does not usually hand everyone higher profits. It attracts competitors until excess returns are competed away.

The gains move to whatever remains scarce.

In Taleb’s language, this is a move toward Extremistan: the domain where one observation can dominate the aggregate, and where scalable work creates extreme outcomes. A creator does not need to be 1,000 times better to get 1,000 times the attention. Distribution, compounding, and visibility do the work.

Software is not suddenly easy. That would be the wrong claim.

Production systems, security, integrations, reliability, maintenance, design, and customer understanding still matter. Good software is still hard.

But the relative cost of getting some working software is falling.

The customer is no longer comparing you only to another vendor with a large engineering team. They are comparing you to an internal tool. To a software house with an AI platform. To a feature from an incumbent. To a generated prototype. To doing nothing. To a good-enough workflow assembled by someone inside the company.

For a long time, “we can build it” was a meaningful claim. It implied access to scarce talent, process, and execution capacity.

Outside of extreme or niche cases, my bet is that “we can build it” becomes table stakes.

The harder question is: Why would the customer choose you?

I wrote before that the moat many software service companies sell is disappearing. General technical execution is becoming less scarce. The old pitch, “we can build this for you,” is losing power as AI makes building more accessible.

Obviously, that does not mean all moats disappear. It means the moat moves.

If software is cheaper to produce, customers will not pay a premium because you can produce it. They will pay because you can operate in an environment others cannot. Because you understand a niche better than generic competitors. Because you are close enough to the business to know what should be built in the first place.

They choose you because you understand the workflow. The edge cases. The politics. The handoffs. The exceptions. The stupid details that never fit into the product requirements document.

They choose you because they trust you. Because if the system breaks, someone is accountable. Because security, compliance, uptime, and support are not afterthoughts.

That is the part cheap software does not solve.

AI lowers the cost of software creation. It does not lower the cost of being chosen. In fact, if the social media parallel is any good, it elevates the cost of being chosen!

This is where many companies will get confused. They will ship more, demo more, prototype more, and generate more. They will mistake activity for advantage.

But the market does not reward software for existing. It rewards software for mattering.

The creator economy already ran this experiment. Making creation easier made attention, trust, taste, and distribution more valuable.

Software is next.

AI may make software cheaper to create. But software success was never just about creation. And it’s going to be even less so.

On April 21, Anthropic quietly pulled Claude Code from its $20 Pro plan. No prior announcement. They’ve just placed a red X on the pricing page and a rewritten support document — long story short, Claude Code temporarily ceased to be available on the Pro plan and became only available on the Max subscription.

When people noticed, Anthropic’s head of growth said it was a small test affecting about 2% of new signups. Maybe. I’m not interested in conspiracy theories. Whether it stays or is reverted is irrelevant. This still looks to me like them testing the waters for a policy change already underway.

And it’s not just Anthropic. One day earlier, on April 20, GitHub announced it was pausing new signups for Copilot Pro, Pro+, and Student plans, tightening usage limits, and removing Opus models from the Pro tier. Their stated rationale: “agentic workflows have fundamentally changed Copilot’s compute demands... it’s now common for a handful of requests to incur costs that exceed the plan price.”

The fact is, your $20 a month was never really $20. Ditto for the $200 Max version. For two years, AI labs have been selling flat-rate subscriptions at prices far below the actual compute they consume. As Ed Zitron wrote: “Anthropic’s subscription plans charge far less than the book value of tokens consumed, sometimes by a factor of ten or more.”

That means: you paid $20, but you really burned through compute that cost them $50, $100, sometimes more. The difference was financed by venture capital. The bet is: grab the market now, figure out margins later.

You could argue it’s a typical Silicon Valley playbook. We’ve seen it before with Amazon, we’ve seen it with Uber, and plenty of other companies. All with Peter Thiel's acolytes chanting in the background: Competition is for losers, monopoly is the goal.

And we have historical proof that it works.

Or does it?

The curve ahead

Even as labs subsidize subscriptions, the underlying cost of generating a token has been falling at an impressive rate.

GPT-4 launched in March 2023 at $30 per million input tokens and $60 per million output tokens. Today, GPT-5.4 delivers vastly better performance at $2.50 and $15, respectively. That's roughly a 12x reduction in input costs and 4x in output costs in three years at the flagship tier — and far more if you compare on fixed capability.

Claude Opus 4.6, priced at $5/$25, costs a third of what Claude 3 Opus did two years ago ($15/$75).

Gemini 2.0 Flash hit $0.10/$0.40 in late 2024 — prices that would have sounded absurd even eighteen months earlier. The curve bends everywhere you look (for comparison: GPT 3.5 — $0.50/$1.50 — being inferior to Gemini 2 Flash overall, even in pure text use cases).

The reductions aren’t just coming from better hardware, though. Andrej Karpathy recently retrained a GPT-2 grade model for $73 — the same model that cost OpenAI around $43,000 to train in 2019. That’s a 600x reduction in seven years, falling roughly 2.5x every single year. Part of it is hardware (H100s beat TPU v3s). Part of it is software (FlashAttention, fp8 training, better optimizers). But a huge part is just algorithmic progress — we’ve figured out how to do the same thing with far less compute.

“Past performance does not guarantee future results.” Got it.

This is nonetheless reminiscent of other historical price curves. Take the lithium-ion battery cost chart. The inflation-adjusted drop in the costs of lithium-ion batteries over the last 3 decades is mindblowing — ~99% over that period of time. A drop - mind you! - that enabled reinvention and mass production of electric vehicles and the growth of what is estimated to be a $1.6 trillion industry. (And I’ll completely ignore the far bigger impact it had on the consumer electronics industry at large.)

If this is not a textbook example of Jevons Paradox, I don’t know what is.

The unit economics

The Silicon Valley playbook mentioned earlier is not a clean parallel, though. Amazon was unprofitable for nine years and didn’t generate meaningful profits for closer to twenty. But Amazon sold books at roughly cost plus margin. Its losses came from warehouses, logistics, infrastructure — fixed costs that paid off once they were built. When Amazon got more popular, its unit economics improved.

What are the unit economics here?

Every token you generate costs the lab money, today, in electricity and GPU time. When more people use Claude, Anthropic bleeds faster. The subsidy isn’t a one-time investment that pays dividends later. It’s a tap. Actually, more of a firehose. Turning it off is the only way to stop the bleeding.

And the labs are starting to turn it off. Here are some examples:

• In February, Anthropic introduced Fast Mode — 2.5x faster inference at 6x the standard rate. Same model, same capabilities, you’re paying a premium to skip the queue.

• In March, they started throttling peak-hour usage across subscription tiers.

• OpenAI runs its own version with “flex processing” — cheaper if you’re willing to wait.

These are pricing tweaks, not new features. Compute is scarce, and subsidies end. The price you pay will depend on when you use it, how fast you need it, and how much leverage the lab still has.

Here’s the twist. Even as the price of a token keeps collapsing, the bill is going up. How so? Well, ask yourself - with all these token prices falling so rapidly — are you paying less for AI subscriptions today than 2 years ago?

Enterprise LLM spend doubled in six months last year while per-token costs plummeted (did I mention Jevons Paradox already?). Agentic workflows burn 5 to 30 times more tokens per task than a simple chatbot (tool calls, multi-step reasoning, orchestrations, and so on). That’s why unit cost falls while at the same time the total cost explodes.

What comes next

Eventually, the underlying cost of a token will drop to a level where no subsidy is necessary. Depending on the source, the token costs fall at a rate between 2.5x (Karpathy example) and 10x (Epoch AI) per year.

Nvidia’s near-monopoly will also erode as AMD, Google’s TPUs, and Amazon’s Trainium chips take share at the infrastructure layer. The margins that Nvidia has today are just too outrageous to ignore. Competition at every layer will push prices toward the real cost of electricity and silicon, not the VC-subsidized numbers we’re seeing today.

This is, not coincidentally, what Sam Altman told the US Senate in May 2025:
”Eventually the cost of intelligence, the cost of AI will converge to the cost of energy and it’ll be how much you can have. The abundance of it will be limited by the abundance of energy.”

But between now and then, there’s a bill to be paid. The labs spent hundreds of billions acquiring users at a loss. They have to make that back. And the people paying it — whether through removed features, peak surcharges, or tiered pricing — are you.

So what does this mean if you’re building on any of this?

The price you see today is not the real economic price. It is whatever the lab currently wants you to believe the product costs. It will change, probably not in your favor, probably sooner than you think. Per-token pricing, peak surcharges, and tiered inference are the future. Anyone betting on labs absorbing the difference between subscription prices and real compute costs might be heading toward a nasty wake-up call in the short-term future.

I am ultimately an optimist. And few things show such predictable and consistent price drops as technology entering the mass market. But first, it’s going to get worse before it gets better.

Brace yourself.

I’ve overheard it in a meeting. Two people disagreed on a strategic direction, you could feel the temperature creeping up, and one of them eventually responded to the disagreement with: “It’s just semantics.” As in — “this is not worth arguing about, let’s move on.”

I’ve been thinking about that phrase ever since. Not the first time, though. I’ve realized I’ve heard it repeatedly over the years. “It’s just semantics.”

I cannot help but think: what is there in a conversation besides semantics?

A lot, actually — tone, body language, emotion, context. But in organizations, especially when we discuss strategic matters, it is critical that we are all on the same page — everyone involved understands exactly and in the same way what we are discussing and what we are about to do.

Locally — in any given room — there are a lot of factors that matter. Outside of the room, as the mission and vision spread through the organization, the thing that survives the journey is the words. The meaning they carry. Semantics is the part that scales.

In that sense, semantics isn’t a distraction from strategy, nor a tangent to it. It IS the strategy. Every strategic decision is ultimately a question of “what do we mean when we say X?” What does “customer-first” mean when you have to choose between two customers? What does “quality” mean when the deadline is tomorrow? What does “aggressive” mean when half the room thinks it means pricing and the other half thinks it means litigation?

When someone says “we need to move fast,” what do they mean? Ship in two weeks? Hire three people by Friday? Skip the compliance review? Everyone in the room nods. Nobody is agreeing on the same thing. “Move fast.” “Be aggressive.” “Think long-term.” “Stay lean.” These are words that feel like decisions or directions but aren’t — because nobody defined them. The meeting ends with alignment that doesn’t exist.

So here’s how I think about this today. When we wave away the definitional question with “it’s just semantics,” it’s not really avoiding a pointless argument. Two people walk out of the room thinking they agreed. They didn’t. They agreed on a word. They never agreed on what it means.

We’re locking in a misunderstanding and voluntarily giving it time to compound. And compound it will.

Some understood this. Jeff Bezos banned PowerPoint at Amazon and required six-page narrative memos instead. Slides let people hide behind vague language. A bullet point like “improve customer experience” survives a meeting unchallenged. You can hide a lot behind hand gestures and a confident delivery while giving a presentation, too.

Try writing that as a full paragraph, and you're immediately forced to explain what you actually mean. And if you don't, whoever reads it will force you to. Bezos insisted on plain English because he understood how critical semantics is.

We can disagree on the meaning of the message. It’s OK to disagree. It’s OK to be confused. Nobody knows. But we can figure it out. As long, that is, as we all recognize we haven’t reached agreement — or at least understanding — yet.

Semantics is literally the study of meaning. Dismissing it is dismissing whether you mean what you say. And the meaning of what you say sounds like a damn important thing to me.

The best engineers might be today 40% more productive with AI coding tools. At least that’s what this study says. Given it was published in October 2025 — in today’s timeline, roughly a decade ago — it is already outdated. My assessment would be that it is more than that, at least for the best performers and a certain range of software products. (Now, how much of an individual productivity gain translates to the organization is an entirely different story!)

This creates an interesting dynamic for software service companies — companies that build custom software for their clients.

Right now, companies that adopt AI aggressively feel like they have an edge. And they do — today. But this is a transitory advantage. Whether it takes one, two, or five years, the market will eventually catch up. AI proficiency will become the new baseline, not a differentiator.

An opportunity and a threat

Software service companies are living through this transition in two very different ways.

Some see it as an existential threat — and not without reason. Customers can now create way more software themselves — software that they used to subcontract to vendors. The barrier to entry for building a functional application has collapsed. If your client’s PM with one engineering colleague can spin up a working prototype over a few days, they are starting to question whether they need an external partner at all.

Sure, doing a limited POC and a real, production project, with real load, security constraints, and ongoing maintenance, are two very, very different things. Many of these ad-hoc in-house products will eventually fail to deliver the promised value.

And yet, it would be dishonest not to notice that building relatively typical software has become way more accessible. And let’s be straight — not every custom-built product was a complex, multi-year endeavor. You can check it out, for instance, on Clutch by browsing the typical price ranges for past projects. There are plenty of companies living off $10-100k contracts.

Others see it as a tremendous opportunity. With outstanding productivity gains, they can harvest disproportionate margins — doing more with less, delivering faster, and capturing the spread between the old cost structure and the new one.

Here is the problem, though. Your client knows this. They don’t need to master AI or even use it effectively themselves. The mere existence of AI-augmented development gives them leverage to push for lower prices. A recent CIO analysis found that enterprise customers are already demanding their share of AI productivity gains. The logic is straightforward: if developers complete tasks 40% faster, someone is capturing that surplus. The client wants to know why it isn’t them. And the traditional saying goes: the customer is always right…

A question of price

Where does this put software service companies that typically operated in a time-and-materials manner? On the one hand, customers expect faster delivery (fewer man-days). On the other hand, the agency that truly masters AI-augmented software delivery cannot reap the efficiency benefits (as they charge per day).

The first instinct is to move to fixed pricing. You capture the efficiency, the client gets a predictable cost, everybody wins. Except the prices will fall down too - in the same way that expected man-days for a project would fall down (though arguably the price arbitrage will be there for a limited time, and companies that are ahead-of-the-curve should be able to capture part of it while it lasts).

The forward-looking companies are moving further along the spectrum — from time-and-materials through fixed price to value-based pricing.

What is value-based pricing? At its essence, you charge for what it’s worth to the buyer, not what it costs you to produce. It might be capturing a fraction of the savings that delivering specific software produces for the customer. Or it might be a price set based on new opportunities uncovered for the customer. There is also a closely related term of outcome-based pricing. Technically, outcome-based ≠ value-based — an outcome doesn’t have to translate to value. In practice, the two are close enough to treat as the same thing.

McKinsey already generates 25% of its global fees from outcomes-based arrangements. You may be skeptical about McKinsey. I am not surprised. One thing is certain, though - they know how to make money, whether we like it or not. And when they overhaul how they charge, it is at least prudent to pay attention.

To quote Business Insider: “The result is a renewed industry focus on implementation and value over mere activity.” Part of me shouts: At long fucking last!

Unfortunately, value-based pricing is an entirely different and complicated game. And on top of that, moving to value-based pricing for a general software vendor is going to be even harder. Except for very specific, narrow technical cases (e.g., cloud cost optimization), a lot of value is entangled in the customer’s business. It is going to be very difficult to move towards that pricing for software service companies that operate exclusively at the technology layer.

Whichever way you go, the same pressure applies — building general-purpose software has become more accessible, and software service companies will face pressure.

Where does the moat go?

Forbes predicts that within three to five years, a software development productivity boost will exceed 80%, meaning half the labor currently needed will suffice. Now, I am very much on the side of Jevons Paradox: a software Cambrian explosion will drive the cost down, which will in turn drive the demand up.

However, there is an intermediate problem. Most enterprise customers won’t be ready to absorb a radically higher volume of delivered software. They grew their processes in a reality where building software was the bottleneck. Now, the bottleneck has shifted, and many enterprises are just not ready for consuming software at a faster pace.

Whether the demand explodes or not (and when!), the immediate reality is the same. An industry built on billing for labor will feel every point of upcoming compression. The agencies that thrive won’t be the ones that just write the most code.

The work won’t disappear — but the margins for general software-service companies will. And who wants to end up on a commodity-price treadmill?

So what’s defensible? Three things, as far as I can tell.

First, go where the barriers are structural. Regulated industries — finance, healthcare, defence. Hardware integration. Environments where certification, compliance, and safety aren’t nice-to-haves but legal requirements. AI can write the code, but it can’t navigate a regulatory audit, own a liability, or sign off on a medical device. At least — not yet.

Second, go deep into a niche. Not necessarily a regulated one — but one where accumulated expertise takes years to build. Narrow but deep technology expertise. Real-time trading systems. Logistics optimization. Developer’s efficiency. The agency that has spent a decade understanding how a specific domain actually works will beat the one with better engineers every time. This was always a good bet. AI makes it even more relevant because when the code price tag collapses, the only thing left to charge for is knowing what the code should do better than your customer.

Third — and this is where I think the real shift happens — close the gap between software and business. The “code monkey” role — take a spec, produce code — is the one most directly displaced by AI. Outside of highly specialized areas like critical infrastructure or security, the direction is convergence. Software engineering stops being a separate discipline and becomes part of how business operates. The agency of the future doesn’t just build what you spec. It helps you figure out what to build. At an extreme, that’s not a software agency anymore. It’s a industry specific consulting firm that happens to ship code. Coincidentally, value-based pricing is way more achievable for vendors being closer to the business (or even better — closer to an actual P&L).

Tectonic industry shifts are uncomfortable by definition. But they also reshuffle the deck. The reshuffling threatens some, but it also creates disproportionate openings for others. One thing seems to be certain though - the days of straightforward selling of pure, general technical experience are gone.

The room was asked to place a dot where they actually are in their day-to-day coding. The dots clustered around the 25% mark from the left. Actually, the 25% might be a charitable interpretation. Take a look at it yourself.

This is a room full of software engineers. People who write code for a living. And when asked honestly where they stand on the AI continuum, the majority of answers were: still mostly doing it by hand. Truth be told, my suspicion is that the Rust community might be a little more biased toward organic coding — I’ll give you that.

Even so, that photo has been stuck in my head for days now, because it captures something the industry conversation keeps getting wrong.

In March 2025, Dario Amodei told the Council on Foreign Relations that AI would be writing 90% of code within three-to-six months. Essentially all of it within a year. Obviously, the internet did what the internet does — half the people called him delusional, the other half declared software engineering dead. And naturally, the further detached they are from software engineering, the louder they get.

So here we are, a year later. And the conclusion is… mixed.

On one hand, John Crickett ran his own informal survey and found that maybe 5% of developers are heavy AI users. Around 20% use agents, mostly for tests. Many are still on autocomplete or nothing at all. That maps almost perfectly onto the Rustikon whiteboard.

On the other hand, Linear reports that coding agents now operate in 75% of enterprise workspaces, with 25% of issues handled by agents. Not a rounding error anymore — more of a structural adoption.

Here is a funny thing, though — both of these are true at the same time, and that’s the part most commentary misses.

I can clearly see this firsthand. At VirtusLab, I work with some great, capable engineers who essentially don’t write any code by hand at all anymore. They direct AI, review its output, and focus on architecture and coordination. The same is true across many companies I talk with. At The-5 — a community of entrepreneurs founded by — we have a group exchanging AI practices. For many, the vibe is close to 100% automation. Move anywhere near Silicon Valley startups, and it's even more so.

And yet. None of these people has stopped doing software engineering. (Though it’s worth pointing out — some of the people making the boldest claims about its death never actually started in the first place.)

That’s the distinction most people miss when they quote Dario. “AI will write all the code” is not the same as “AI will do all the software-engineering.” These are completely different claims. The gap between them is enormous.

AI today is genuinely capable of typing the code. Give it a well-scoped task — a function, a test, a migration, or even a relatively well-defined feature — and it will produce working output faster than any human. That part of the prediction is largely correct, even if adoption is uneven.

However, leave it unsupervised, without any guardrails and engineering discipline, and over time, the castle in the sand starts to crumble.

This is already visible. The code that is being generated is already straining the system, and the quality is going down. Rob Zuber at CircleCI published data showing that PR sizes increase by more than 150% when teams adopt AI coding tools. Across 28 million workflows, main branch success rates fell to 70.8% this year — the lowest in five years. The industry has become very good at producing change and strikingly bad at absorbing it.

The bottom line is: software engineering isn’t about code generation. It’s figuring out what to build. It’s understanding constraints that live in people’s heads, not in the codebase. It’s navigating organizational politics, legacy systems, and tradeoffs that don’t show up in any spec. It’s directing the architecture. This might be many years away. Or it might be tomorrow. No one knows. It is clearly not here today.

The best evidence that writing code and engineering software are different things is the current tech job market. The number of software engineering openings in the US has been growing since the bottom of the dip in early 2025.

And last but not least: Anthropic — the company behind arguably the most capable AI coding tool available — is hiring over 100 software engineers. Boris Cherny, the creator of Claude Code, was asked why and that was his answer:

The company closest to making software engineers obsolete is hiring them as fast as it can. Because even when AI writes every line, someone still has to engineer the software.

Say what you want. Dario might have been wrong about AI writing all the code by now. But he was pretty much spot on about AI being able to write all the code. This does not change the fact that engineering is still needed. And it’s not going anywhere.

A friend recently recommended I re-read Neuromancer. I guess it’s fair then to close this with:

“The future is already here – it's just not evenly distributed.”

In 2024, Google ran an Olympics ad called “Dear Sydney”. A father uses Gemini to help his daughter write a fan letter to her favorite athlete.

The internet was… not exactly impressed.

Google pulled the ad. The backlash wasn’t about the quality of the letter — it was that a child’s genuine effort to express admiration had been outsourced to a machine.

The content might have been fine. The act was hollow.

Walk into any organization today, and you’ll find the same dynamic playing out on a smaller, quieter scale. Emails that are clearly AI-generated, sent to people who will clearly barely skim them. The lucky ones, that is. Most will have the title read and be instantly archived (and the rest will just die in the inbox).

And then we have Slack messages with that unmistakable ChatGPT cadence — slightly too polished, slightly too structured, slightly too long (and with way too many emojis).

Performance reviews that read like they were written by a thoughtful manager but feel like they were assembled by a machine. Which they were.

AI-polished documents that — and here is the thing - no one asked to be polished.

There’s an asymmetry here that bothers me. AI has made it trivially cheap to produce content — 30 seconds, and you have a polished update. But it hasn’t made it any cheaper to consume content. Reading a two-page document still takes the reader 15 minutes. Before AI, the effort of writing acted as a natural filter. If something was hard to write, you thought twice about whether it was worth the effort (first your effort, and second recipient’s effort). That filter is gone.

Unless your recipient also uses AI to summarise your messages! In which case, you’d have to be insane not to wonder what’s the point of this whole ceremony.

Who is all of this for?

This is all truly bizarre. Person A spends 30 seconds generating a polished two-page update. Person B spends 30 seconds asking an AI to extract the key points. The actual human-to-human information transfer? Three bullet points. But instead of just sending these three fucking bullet points, we’ve routed the conversation through two AI passes and wasted everyone’s attention in between (not mentioning the tokens, which are the cheapest in all of this grotesque performance).

Josh Bernoff wrote his seminal book “Writing Without Bullshit” before Gen AI was all the rage. His main point was that most business writing wastes the reader’s time — that every sentence should be useful or deleted. AI hasn’t fixed this. It’s made it dramatically worse by reducing the cost of producing bullshit to zero.

Going full circle to where we started, there’s a deeper issue here. Hywel Carver put it well at CTO Craft London this year. Here is the thing: some communication isn’t just about transferring information.

When your manager writes your annual feedback, part of the value is that they sat down and thought about your growth.

When a colleague sends a thank-you note, the effort is the message. If I told you “I generated your performance review with AI” or “I generated my thank-you message with ChatGPT” — would you feel recognised?

There are moments in organizational life where the effort is the point — where the act of sitting down to think about someone is what carries the meaning, not the words that come out.

The irony is that inside an organization, we don’t need polish. Externally, sure — clients, investors, and candidates expect a certain standard. With external audiences, we don't have shared context, so polish fills the gap. I can even understand - though I wish it wasn’t the case - that we generate a certain amount of marketing slop to pump up the volume.

But internally? An organization should value raw clarity over manufactured professionalism. Three bullet points in a Slack message beat a four-paragraph AI-crafted email every time. A rough sketch of an idea beats a polished deck no one reads.

“The present letter is a very long one, simply because I had no leisure to make it shorter.” Blaise Pascal’s famous quote is today, after 400 years, more relevant than ever.

We’ve confused the appearance of thoughtfulness with actual thought.

And AI has made that confusion penny cheap.

Recently, I sat down to record a Beyond the Commit episode with José Valim - creator of the Elixir programming language. We ended up talking for over 2 hours — about types, about AI, about where programming languages are headed.

It got me thinking. I've been picking up Elixir on and off for years — for personal projects, for POCs — then drifting back to whatever serious, enterprise language the day job demands. But I kept returning. And the reason is simpler than I expected.

I realized I genuinely enjoy reading Elixir code.

I've spent years reading code in various languages, and for most of them, "reading" is something I endure, not something I look forward to. It’s a means to an end.

What makes Elixir different is its simplicity. Pipe operators, pattern matching, protocols — each construct is just powerful enough to be flexible and useful, yet simple enough that the code stays readable.

Now, many other languages have achieved simplicity (Golang). But none that I know of has achieved this level of balance of simplicity and harmonious aesthetics (at least for me).

There's a narrow design corridor that Elixir walks remarkably well.

Contrast this with Scala, which I used to know well. Well-written Scala code is a joy to read. Poorly written Scala code is the ninth circle of hell.

Elixir gently constrains you toward clarity, and the result is that most Elixir code reads roughly the same way. Which is exactly what you want when your job is reviewing it.

This philosophy transcends the language itself and extends to its ecosystem. For my personal projects, I've been using Django for a few years now. I typically had to wire up hot reload, Stimulus, Tailwind, recurring jobs, and whatnot myself. It all ended up in a custom-made cookiecutter template eventually. In Phoenix, all of that comes built in as a single coherent package — powerful enough to be flexible, simple enough to pick up and start building immediately. Neat, elegant package.

Here’s the part I find counterintuitive. We’re living through a moment where people are debating whether hand-writing code even matters anymore. AI writes the code, you review and guide it. I think that actually makes the aesthetics of a language matter more, not less. If your main interaction with code is reading it, then how pleasant that experience is becomes a first-class concern. At least while we're still expected to understand the code we ship…

The conventional wisdom right now is that statically typed languages are better suited for AI-assisted development. Types give the model more context, catch errors earlier, and constrain the solution space. It makes intuitive sense, and maybe it is so. It certainly is a convincing argument for enterprise-grade software.

Meanwhile, we also have some interesting experiments like this one, testing the cost of generating (correct) pet projects. Yusuke Endoh tested Claude Code across 13 languages — Ruby came out on top. Fastest, cheapest, most reliable. Adding a type checker to Ruby made it 2-3x slower. Concise, expressive languages — the ones pleasant for humans to read — are also the ones where AI wastes the least tokens.

(There is also this interesting piece from José himself about the tension related to the impossibility of typing some trivial expressions correctly without type unsoundness, but that’s a completely different story)

In the meantime, OpenAI just built Symphony — their agent orchestration framework — in Elixir. A frontier AI lab reached for a language built on a 40-year-old virtual machine designed for telephone switches to orchestrate its agents.

There’s something poetic about that. In a world where AI handles more of the writing, what remains - at least for the time being - is taste, clarity, and the pleasure of working with something well-designed.

And Elixir has that in spades.

Anyone even casually following tech news (or ANY news, really) has heard how AI is making software development more efficient. Claims about 10x or 100x efficiency gains are not unheard of.

In fact, if you listen to AI Lab CEOs, they’re not just preaching improved developer efficiency - they’re talking about making software developers entirely obsolete, imminently. In short: AI will write all the software. According to Dario Amodei, AI might be able to write 90% of the software as soon as 3-6 months from now - which, given the prediction was made in March, puts it somewhere by the end of 2025. Sounds like your stereotypical Silicon Valley CEO’s or investor's wet dream - the former can’t wait to eliminate unreliable wetware from the equation; the latter realized that fortune to be made in selling shovels. So much so, in fact, that when I speak with senior engineering leaders, the challenge of dealing with CEO expecting 2x, 5x or 10x efficiency increase TODAY, becomes a recurring theme.

I remain sceptical about that. It’s one of those situations where everybody agrees on the direction; we only argue about the timing. The timing, though, is important. Go all-in too early, and you may drown in a deluge of AI-generated detritus. Do it too late, and you risk losing your competitive edge. And the truth is - no one really knows.

The realities of a typical software business are quite different from what internet influencers try to paint. Many leaders experience moderate efficiency gains from AI usage in software development. Now, assessing efficiency gains in software development is a tall order already. Various approaches have been tested over decades - starting from counting LOCs to DORA / SPACE metrics today. I am confident that a lot of consulting money was made on measuring development productivity along the way, too. The everyday practicalities of most software teams are that they just don’t measure productivity at all. If anything, they rely on loose, gut feeling as an indicator (“we seem to work on these longer than usual“ or “oh, we seem to introduce more bugs recently”).

Even with the gut-feeling approach, though, it seems that for most organizations, the typical AI-efficiency gains are in single-digit percentage numbers. This is slowly being backed by more and more research. In fact - and this is quite astounding as for the CEO of the company selling AI tooling - Sundar Pichai even cited “AI making Google engineers 10% more productive”. But it goes even further, recently the METR study made headlines online, with results showing an actual decrease in productivity with AI tooling.

Now, I find it very hard to believe that AI tools actually decrease productivity systematically. I do believe it can be the case in some specific, narrow cases, though. It might also be a case of a transition period - using a new tool and/or approach often leads to a temporary efficiency drop before people become fluent with the new ways of working. And besides, even a single-digit (or low two-digit) efficiency increase is worth billions of dollars in the industry. And that’s a conservative estimate!

However, the order-of-magnitude rift between online claims and the realities of software teams is stark.

Here are my thoughts on why I think that’s the case.

First of all, as with any gold rush, you can make shitloads of money by selling shovels. Most companies do that with exorbitant claims about the benefits they will bring. These claims, most of the time, either lack empirical substantiation or hold true only in narrowly defined contexts (e.g. synthetic benchmarks). We’ve seen this story before with public cloud, and especially with the alleged savings it was supposed to bring.

Second, at least as it is in mid-2025, most of these claims focus on the code-writing phase of the SDLC cycle. Typically, these are activities like code generation, debugging, code explanation, or brainstorming. The reality, however, is that for many organizations, writing code (or working with code in general) is only a part of the software engineering work. Depending on the source, it may be between 33% and 50% of the entire engineering time. And perhaps naturally, as the organization and/or seniority of the engineer grows, the pure code-writing phase shrinks. So even if the code writing phase has been improved by 2x, the end result might be that overall net productivity growth might be much less impressive 1.2x.

Third, many online claims come from small companies and startups - unsurprisingly, as they are typically the first ones to venture into uncharted territories. After all, agility is their key strategic advantage over larger incumbents. And at least partially because these companies are more relaxed about security or legal risks (in some cases, more relaxed is a euphemism for not giving a single fuck about these matters). Meanwhile, some of their larger competitors haven’t even managed to get Copilot approved by their legal or security teams (the opposite side of the spectrum).

Finally, and building on the previous point, startup codebases are typically neither large nor burdened by years of obscure changes driven by a tangled web of evolving requirements. Perhaps even more importantly, they are not being used by long-standing customers who depend on layers of osbscure logic up over years (often tailored to specific, idiosyncratic use cases). Customers, mind you, who will be very unpleased when the vibe-coded app starts to break.

Garry Tan said some time ago that for their recent batch AI is writing 95% of the code. It is quite jarring, but I tend to believe Garry.

Which leads us to the key difference I am seeing. Namely, AI tools are borderline absolutely fantastic for some specific cases. Some of these cases are:

• working on the greenfield projects, which are completely or nearly completely separated from the rest of the organization's codebase (at least up to a point when these projects become too complex)

• building throwaway POCs (even if they are not thrown away afterwards, which is the case more often than not)

• using technology (e.g. programming language, libraries, or services) that you are not intimately familiar with.

They are good at other cases, too (e.g. brainstorming or being faster Google), but they excel at the above in the context of software engineering.

Guess what - most of the Y-Combinator batch are pre-product-market-fit companies - all they do from software engineering is write POC / MVP, and the last thing they (should) care about at that stage is long-lasting code quality/readability.

But here’s the thing — most tech leaders don’t work in greenfield settings or build throwaway POCs. As surprising as it may be, a lot of devs don’t work at a hot SV startup or big tech - but rather in some utility provider, midwestern logistics company, or maybe some financial institution. More often than not, they’re knee-deep in brownfield legacy systems.

As it is in mid-2025, AI tools are not overly good with such codebases. One thing is that these codebases often have aged code, with many custom abstraction layers (in other words, out-of-distribution data), separating it from any open source libraries they might use (codebase that is likely in-distribution for the given LLM model). The other thing is that these codebases tend to be sizable. It is not uncommon for these projects to be in the range of hundreds of thousands to millions of LOCs. And while context windows are steadily growing — with models like Gemini 2.5 Pro hitting 1M tokens — that alone doesn’t solve the large codebase problem.

The unfortunate reality is that extending the context window (like in the case of analysing a big codebase) often leads to problems like reduced attention focus or even accidental context-poisoning. You may experience this while working in agentic-mode in Cursor, while trying to provide an increasing amount of information to LLM while debugging a nasty bug, and at some point, realizing that the model suggestions degrade over time.

If GenAI development follows S-curve - which is typical for many new inventions that become widespread - we may expect interesting things.

The classic example is smartphones, which experienced massive advancement and innovation in technology between 2010 and 2020. However, it is, hard to deny that the technology has stagnated recently, barely anyone is excited about new iPhone launches these days, and the technological improvements have become mostly incremental.

It is not outside the realm of possibility that it will take way longer for AI to work effectively with brownfield codebase than most people anticipate. @dhh had a great anecdote on his recent Lex podcast about that. (The presentation he mentions is “Web Design: The First Hundred Years with Maciej Ceglowski” from 2014; great presentation by the way).

In other words, it is difficult to say at which point of the S-curve we are currently at (A or B, above).

When it comes to software engineering specifically, I’d say we are starting to see incremental improvements already. Recent releases are definitely less exciting than the ones from 2023-2024. Some feel like almost backward steps 🤷. But it is worth being open-minded - for instance, GPT-5 is allegedly just around the corner.

So, where does it put us?

Real-world productivity gains are, as it is now, overhyped in real production code bases. If you are struggling with marrying LLMs with your messy legacy system, you are not behind. The whole industry is struggling with it.

It is not too late to experiment - and experiment you should because even if the gains present a sobering contrast to the prevailing hype narrative, they remain very much real!

And there are definitely levels to this game - the ability to work effectively with LLMs, even (or especially) with legacy codebases, is a skill that can be levelled up to unlock additional gains. For example, proper code compartmentalization seems to help (alas, it often is an elusive goal in legacy codebases). Heavier investment in company-wide cursor rules has also shown promising results, etc.

And as crazy predictions go: Who knows - maybe LLMs will suck with large legacy codebases for some more time, which will lead us to a situation where it is more practical to rebuild a system (with AI!), instead of refactoring/extending an existing codebase. In that case, everything will be greenfield until it isn’t, in which case it will cease to exist.

Until then, keep your shovel sharp.