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.

The software engineering career path is fairly straightforward at the beginning of the career trajectory, from intern or junior up to senior engineer. It also tends to be similar across different organizations. It is in the post-senior engineering career that things start to get fuzzier. For many years, the unfortunate state of the industry was that the most viable long-term option was a foray into management. While this is an interesting and rewarding route, it is not for everyone. More than that, pushing everyone in that direction is detrimental both for the individual and organization as whole. The push toward management can either be direct (the only viable path in the organization) or indirect (for example, by not emphasizing the importance of the engineering path or by having an unreasonable pay gap between the engineering and management paths). Let's explore what the post-senior engineering path looks like and how you can prepare for what’s to come.

This article covers a few angles:

• Post-senior career trajectories

• Skills needed for post-senior career advancement and how they differ from pre-senior roles expectations

• A distinction between engineering and people management trajectories (with references to infamous tech skills vs soft skills debate that pops out every now and then).

I’ve previously covered bits & pieces of this topic, from an organizational perspective, in articles related to building an internal engineering career framework - part 1 and part 2. Here, I will focus on this phenomenon predominantly from the individual’s perspective.

Before I do that though, let's dissect the engineering career path at pre-senior stages so we can more clearly appreciate just how different a post-senior path is from what went on before.

Path up to senior level

In most companies there are few levels that precede senior roles. Typically these are: 

• Software Engineer Intern (aka Intern)

• Junior Software Engineer (aka Junior)

• Software Engineer (aka Mid)

These roles are usually followed by Senior, Staff (typically level above Senior) and Principal (depending on the organization it might be one or several levels above Staff).

Intern, Junior and Mid might be named differently like L2-L4 or E2-E4, but these are really just codenames for the same thing (big tech apparently likes codenames more than the rest of the industry). The actual sophistication or experience expectation at a given level differ from company to company but main underlying themes remain similar:

Scope, need for supervision and area of key focus undergoes an intuitive evolution as the seniority of engineer grows: scope and focus of daily activities expands and there is less supervision needed. 

An interesting aspect however is not captured explicitly above. This aspect is a matter of uncertainty that engineers need to deal with. Growing uncertainty is indeed the factor that many engineers struggle and feel uncomfortable with before they become fluent and capable with it. We can visualize it as below:

You typically expect Juniors to be given in-depth descriptions of problems, often coupled with decent descriptions of the desired solution. For instance there is usually some form of more or less detailed business expectation described (if my experience is any indication - usually less). 

If you work in the retail industry, the bug might contain the following description: "The generated invoice doesn't have the promoted line item with $0 value. Whenever we give a customer a gift due to promotion it should be the last item on the invoice with the price equal to $0". This actually forms a problem statement (missing line item) and a business solution (line item with $0 as the last position on the invoice). Usually what follows next is a conversation with a more senior engineer who might even tell the Junior which part of the system to look at and what is likely to be changed. This is part of the technical solution (where the change should be added). In short, the remaining work is the implementation, and even this is probably already roughly known by a more senior engineer.

The situation is a little more complex for mid-level engineers. They might get something similar to what’s above but, more frequently, the pointers to the actual implementation - where and how to modify code base - are less explicit or non-existent. After all, Mid-level engineers usually have the experience to use their own judgment and find the optimal implementation themselves.

Frequently, even a solution is not clearly given. What might happen is a problem statement such as: "This invoice doesn't seem right. Customer should have the promotion item highlighted somehow on it." Usually an engineer wouldn't have any idea what it should look like, but they'll extract some pointers to people who might know ("Talk with Mike from accounting, he might know"). In short, more communication outside of the direct engineering team area is needed and, to a significant extent, this communication is left in the hands of the engineer. This situation often becomes the ‘daily bread and butter’ for a senior engineer.

Beyond Senior engineers, the situation can become even more complex. The problem statement may be less clear, and it might even be expected that Staff (and higher-level) engineers help direct the organization toward the right problems to solve. While it may not typically be a business problem, it could certainly involve technical or organizational challenges, especially when these issues impact the effectiveness of the engineering part of the organization. Over time, problems often become a blend of business, financial, technological, and organizational factors. In larger organizations, many big problems exceed the boundaries of being purely technical.

One common example, highlighting the intersection of technical and business considerations, is deciding that some error conditions are too costly to prevent upfront, making occasional manual intervention more economically viable (e.g., Support contacting a customer to reverse an order). A notable anecdote from years ago is Amazon’s decision that it was more cost-effective to send an extra item in cases when a customer removed the item from their shopping cart just before finalizing the purchase (due to technical issue, the item was very rarely not correctly removed from the cart, even though customer didn’t pay for it), then actually technically preventing it happening.

And the further up the engineering ladder you go, the greater the uncertainty. Anyone who works successfully at Staff and Principal level eventually learns to live with it. As they say: it comes with the territory. Still, it takes time for most engineers to get used to it.

Post senior world

The traditional view is that engineers need to move into management after a certain number of years in industry. The tech world moves fast and, after a while, they cannot catch up and lose their edge. Or so the story goes. If my experience is any indication, some of the best engineers I've met are in their late forties, fifties or even sixties.

Sure, the way their work is performed usually changes. As the crowd wisdom goes - when you are young you have time but don't have money, and when you are older you have money (hopefully), but you value your time more. Similarly here: 20-year-old loose cannons can survive on coke and pizza in a 24h release crunch - which is still a necessity in certain areas of our industry or even a badge of honor for some. On the other hand, engineers in their fifties make it up with knowledge and experience (which might have even made the aforementioned crunch unnecessary in the first place 🤷).

Big tech got that right early on. In most of these companies, there are usually long career ladder branches for both management and technical disciplines. Here is part of the engineering career ladder from Google. It shows that engineering can be a lifetime career, spanning several decades.

This state of affairs is not evenly distributed across the industry. In many organisations, the engineering branch is significantly shorter than the management one. However, the situation is improving - perhaps due to the increased importance of technology in most companies these days - and the rest is also catching up.

When it comes to the management career path, a simple version might look like this:

At times, there might be a few steps in-between (Senior Engineering Manager, for example) or CTO might not be treated as a managerial role (CTO is a bit odd, some organizations treat it as the most-senior individual role, where the management aspect is handled by the VP of Engineering). It’s still pretty straightforward though.

Things aren’t that simple for the engineering roles. While building the Engineering Progression framework at VirtusLab, we realized that the engineering path up to Senior is intuitively simple. After that things become complicated as a variety of career trajectories emerge. 

Here are some of them:

• Tech lead - an engineer responsible for a particular area of software from a technology perspective (no people management as such). This might be either a service (or bunch of micro-services if this name still means anything) or a component. In many organizations Tech Lead might be mixed with Team Lead. Whereas this is certainly possible, it doesn’t have to be that way (I personally like to think of Team Lead as a first step in the Management career, rather than one of the steps on the Engineering ladder).

• Subject matter expert - an engineer having deep expertise in one of the areas important for the organization. This might be a technical area (e.g. streaming) or a particular crossing of technology and business domain (e.g. the Insurtech ecosystem). Depending on the organization, these areas can be as narrow or wide as needed (e.g. Insurtech is a field wide enough to have individual experts focused on a particular area within the field).

• Architect - the days of white bearded architects sitting for eons in their ivory towers, only to finally come back to enlighten pariah engineers with voluminous tomes of UML diagrams, are pretty much over. These days, design and architecture is a team sport and requires a hands on approach. Still, there are engineers who are better at big picture thinking and architecture than others, and they might gravitate towards the architect’s trajectory.

• Process engineer - most tech organizations require processes spanning multiple teams or even entire organization. These processes might be engineering recruitment, development lifecycle standardization or improving software quality across the board and many others. The VP of Engineering is usually accountable for this domain (or CTO, if the organization lacks a VP of Engineering), and they often have Staff or a Principal engineer responsible for specific initiatives. Engineers that thrive while building such processes (which involves system thinking, tactical approach and generating organization buy-in) might be called process engineers (or organizational engineers).

• Presales engineer - these are engineers who excel in customer facing situations, such as helping sales with new customers or existing customers with their problems or cross-sell opportunities. Engineers on this trajectory need to have solid engineering skills, knowledge of the product (or tech domain) and outstanding communication and presentation skills.

The list above is not exhaustive - there are certainly others. For instance, DevRel (or Dev Advocate) engineer is a role that’s emerged in the past decade. Ultimately, trajectories depend on the specifics and needs of each organization.

To wrap up, we have at least two typical career branches for post-senior engineers: Management and Engineering. Both present rich and rewarding career options. Whereas management is typically straightforward, the engineering path might expand into plenty of trajectories (I discuss some of them in one of previous articles, along with real world examples from other organizations).

Is moving up a necessity?

There is another option, the third one, which is rarely mentioned but is worth emphasizing. The third option is to stay at the senior level. This might come as a surprise, because the outside world often tries to convince us that we need to progress (or grow) at every stage of our professional career. I don’t think this is true and I specifically believe the option to pause is especially compelling at the Senior level.

Think of it. By the time engineers are senior, they usually make a decent salary. And, due to the time it typically takes to reach that level, many start having (or already have) families or other obligations. I think there is nothing wrong with choosing to put your career on the back burner while you focus on other things. Just go to the office (or just your desk at home), work for 8 hours, don’t think too much about it afterwards and maybe read a book or an article about new technology every now and then. In contrast, post-senior roles usually require more involvement than this. Often, it is difficult to squeeze them into a typical 8 hour day. Calls with other teams across the Atlantic during non-work hours, might be more frequent. Both responsibilities and stress rise and there is an expectation that you keep your edge. As a result, continuing to progress may actually make you less happy.

Additionally, the senior level in many organizations seems to be the last level where you spend a lot of time hands-on coding. Sure, you already have a lot of other responsibilities - you might need to coach juniors, participate in calls with people from other departments (like Sales or, speaking generically, business people 😱) or draft a design doc. Nonetheless, plenty of your work still has a focus on building software. This is the luxury that many post-senior engineers don’t have. In many organizations, between helping with organizational processes, preparing risk assessments for the board, reviewing docs, and participating in committees of various kinds, they don’t have much time left to do any actual coding. Oh, and you have to deal with the politics. If spending a bulk of time on coding is what you love to do, staying on the senior level might be a good option.

Staying at the same level might not have been an option earlier on. In many organizations, both intern and junior levels are considered an “investment”. This means, some organizations perceive engineers on this level costing more (in terms of salary but predominantly in the form of time spent by more senior engineers) than the value of work they deliver. As such these roles are often perceived to be “up-or-out”. Up-or-out is a term taken from typical partnership firms, such as legal, architecture (buildings, not software) or medical practices. Essentially, it means that there is a period of time during which an individual must progress to the next level, otherwise they will be pushed out of the organization. In many classic partnership firms these conditions are explicit, whereas in tech companies it tends to be implicit i.e. at some point there starts to be a problem on the performance review cycle if you stay on these roles for too long (imagine being Intern for 5 years).

Technically speaking, one can choose to stay on Mid level. It is certainly possible. However, Senior is usually a natural extension of Mid (as the job responsibilities and expectations follow a similar pattern) and it has a better pay grade. With that in mind, the senior engineering level seems to be a good balance - an inflection point before the type of work shifts away from predominantly hands-on coding.

Speaking of change, let's focus on pre-senior vs. post-senior in terms of expectations and factors that might help you cross the chasm and move forward.

In this section I want to focus on some of the key attributes or skills that will help you progress your career in the post-senior phase. Now, you may notice that I've left out technical skills completely. That doesn't mean they're no longer important - they very much are. The degree of importance and angle you need to take for further development of technical skills depends on the engineering trajectory you pick (that is to say that e.g. Process Engineer might need different skills than Presales Engineer). You surely cannot go wrong with levelling up competencies in area of software architecture (and generally designing software), understanding tech landscape or full software development lifecycle (SDLC) processes etc.

The thing however is that Engineers by the time they are Seniors, already got accustomed to expanding their technical skills. Yes, further development of technical skills is still important, but it alone won’t be enough anymore. 

Let's look at the less obvious characteristics of the post-senior career path and the skills you’ll need to hone along the way.

Necessary vs sufficient conditions

Progressing from Junior to Mid is relatively straightforward. There are certain conditions (typically specified in the company’s engineering progression) that you must fulfill. As soon as you have fulfilled them, you may get promoted (well, technically you might need to wait for the next performance review cycle, etc.). At least that used to be the norm. In the newer, post-ZIRP world, many organisations are struggling with budgets (budgets that were overly-inflated in the ZIRP world) and this is having an impact on promotions. In this situation, it is often a question of salary increases rather than levelling up. This means that while your level may have increased, your salary may have lagged behind 🤷‍♂️. This situation becomes more complex in the post-senior world where multiple angles must be taken into account.

First, an extreme example just to make a point: the promotion to CTO. Whereas it is straightforward to be promoted from Junior to Mid, the situation here is more complicated. Unless your organisation is growing rapidly and has roles for different CTOs (e.g. field CTOs or CTO of a region or technology or domain area), which is rare, it is highly unlikely that you will get the role if the CTO is already there in your organisation. The window of opportunity may open when the CTO leaves. Even then, there is likely to be only one vacancy and the next person in line will often have to wait several years before the window opens again.

The bottom line is this: on one end, promotions from junior to pre-senior positions depends on you meeting the expectations. On the other end, promotion to CTO additionally requires an open window of opportunity; a factor beyond your direct control. Everything in-between senior and CTO is shades of gray in this respect. Naturally there are more spots (even theoretically unlimited) for e.g. Staff Engineer than VP of Engineering, but constraints may exist. For instance, promotion process may involve more scrutiny, whereas the promotion from Junior to Mid might have been the sole decision of your manager. Or there may be a company-wide committee responsible for promotions to Principal (a sort of bar-raisers), or it could be vetoed by your manager's peers or their boss (more on this later).

Enablers

Roles below Senior are clearly individual contributor roles. Engineers participate in the larger scheme of things by contributing their efforts to the equation. We can visualize their work as a part of a sum (technically called a summand):

(Naturally, that’s an oversimplified model yet I hope it will help drive the point).

Managers, even if they contribute significantly to the overall work (they have a summand element) also have a bigger effect on the work of the entire team. That is, assuming they do their work well, they are an “enabling” element. Unfortunately, this means that they also can become blocking (or obstructive) to the whole team. This is intuitive to anyone who has spent a few years in the industry. Good managers can get a mediocre team to achieve great results, bad managers can get a great team to achieve mediocre results (or worse, get all their great players to quit).

Here are some ways managers may improve or hamper the team’s effectiveness:

• Good managers set clear goals and expectations for the team (e.g. by managing external stakeholders well). Bad managers allow priorities to change often without a single coherent vision. 

• Good managers ensure that required resources are allocated for the team (e.g. compute cluster time is available when needed). Bad managers don’t have sufficient organizational influence and are never able to provide resources the team needs. 

• Good managers foster a healthy team atmosphere where people can freely criticise ideas and problems in order to find better solutions. Bad managers emphasize individual achievements, where teamwork is always secondary and any root cause analysis turns quickly into a blame game.

In a way, a significant part of the managers work is to be a “multiplier” (or factor in mathematical terms) in our simplified equation:

In fact, this is true for all leadership roles - not only pure management. The more we go into leadership roles, the more impactful the “factor” element in the equation is (for better or worse, as mentioned earlier). 

There is an interesting point one may argue about here, namely the fact that “Not every Manager is a Leader, and not every Leader is a Manager” (you can read more about it here). I am not going to argue with the former part. Many organizations use the name Leadership as a synonym for Management (e.g. Leadership Career Path). We would most likely all agree that all Managers should at least aspire to be Leaders. I do believe that the second part - that “Not every Leader is a Manager” - is a crucial part in the context of this paragraph. Specifically I’d argue that Leadership becomes an increasingly important part of the role in the post-Senior stages of an engineering career. I made that point earlier in one of my previous articles. In fact, one could argue that the Leadership component of post-senior engineering roles is in a way even more demanding, than in Management roles. This is due to the fact that Engineering path usually doesn’t involve traditional direct reporting lines. For example, Staff Engineers working to improve the security of an organisation's software supply chain, or to improve the effectiveness of the technical recruitment process, may need to influence many teams across the organisation and generate buy-in without a direct reporting structure. Not to mention, they are often responsible for mentoring more junior engineers or setting an example in the organisation. In short, much of the work of the post-senior is an empowerment style of working. 

The bottom line is that post-engineering roles require the development (and use) of leadership skills. These include competencies such as communication, decision-making, strategic thinking, accountability, mentoring, conflict resolution, influencing and emotional intelligence. Each and every one of these is a learnable skill (up to a point) and engineers aspiring to post-senior roles will do well investing in developing them.

Communication

I mentioned communication earlier but, based on how important it is for post-senior engineers, I believe it deserves a dedicated section. By the time engineers become Staff-level, they’ve already likely authored or co-authored many design docs and other types of engineering documents. This is both useful (in terms of the function these docs serve) and educational (in terms of honing communication skills).

However, I am talking about communication more broadly, including:

• Written - design docs, guidelines, wiki pages, emails and Slack (or whatever communicator you are using) 

• Spoken - direct 1-1 or speaking within a group of people 

• Hybrid - usually presentations. 

Of these above, I believe that written communication is the most important. A few famous companies, amongst the many that rely heavily on outstanding written communication, are: Shopify, Hashicorp, 37signals or Stripe. In general, it is fair to say the written form represents the majority of communication within most modern day tech companies. Especially so, if we consider emails and instant messaging tools (Slack, Teams etc). And consider them we must, since they are the main communication media. When it comes to working with senior managers, directors and executives, the difference between a sloppy and well-written email may cause the initiative you are advocating being pushed through, entirely blocked or (most-common) not considered important enough to be granted sufficient budget. It is that serious.

I won’t dive into how to write well in the business context. Josh Bernoff already did it extensively in his book: Writing Without Bullshit. It is roughly 300 pages long and, since it will be relevant for anyone moving beyond Senior, I just recommend reading it instead.

One of the key concept covered by Josh is his ROAM framework which stands for:

• Readers - who is your audience (What is their understanding of the topic? What are their goals? How much time would they invest in reading your text? etc)

• Objective - what change in the reader do you expect your text to make? (Will they change their mind regarding the topic? Will they determine they got all the information regarding the decision to make?)

• Action - what action do you expect the reader to do after reading your text (What desired action should the reader do afterwards? What would you consider to be a success after the reader reads your text?)

• iMpression - what impression will your text instill in a reader? (in other words - how would they perceive you after reading the text? Would they think you are professional? Would they think you valued their time by presenting the information clearly and succinctly?)

Here is an example:

• After reading this email, my VP of Engineering, who is involved in many performance reviews at this time of the year [reader], will understand the risks involved with keeping the legacy payment component in place [objective] and agree with my proposal of spending 2 weeks of engineering effort in replacing it with a new version [action]. They would also value my thorough, unbiased and professional analysis of pros&cons, that helped them go through the proposal effectively [impression]. 

You can read an extract about this sole idea here. That’s one of the concepts that I found extremely useful on a daily basis. There are many more in the book. Do yourself a favor, and read it. 

Team Work

Nearly all technology organizations doing complex work rely on teams, instead of individuals. You might have great players, but in most growing companies, it is a team effort that counts. As work of engineers beyond seniors has a growing enabling component (which I covered earlier) its inevitable part is effective team work. 

Key skills in this area include: 

• communication - covered more extensively earlier, 

• adaptability / open-mindedness - ability of being flexible to changing circumstances, 

• empathy - ability to understand others’ feelings, 

• conflict resolution - ability of resolving conflicts (or even difference of opinions) peacefully and effectively, 

• conscientiousness - doing your work with responsibility and diligence, being reliable

• and agreeableness - ability of being compassionate, cooperative and friendly (which doesn’t mean you need to agree to everything).

Sure, some of them - like high levels of empathy - are given, you are born with them or you developed them in your early years. Still, all of them can be significantly improved with deliberate practice or even just self awareness. Bottom line is - as Steve Jobs famously said - “Great things in business are never done by one person, they are done by a team of people”. Investing in skills to increase effective team work is a sure bet that will pay off. 

Ownership and limits of your sphere of control

This phenomenon comes up in conversations so often, I thought it deserved its own section. As already discussed above, most larger initiatives require team effort. In the life of a post-senior engineer these teams might be informal, temporary and part-time (e.g. working groups assembled to improve tech recruitment process), but they are teams nonetheless.

Staff and Principal engineers might be put in charge of such teams. As such, their area of ownership (or as some call it - accountability) expands. An ownership is an important word here - because this ownership may expand beyond the areas you are directly responsible for. A particular area might be a responsibility of someone from the working group, but you are still accountable for it.

All this is pretty much daily bread and butter for engineers who have moved up the management career ladder. Yet, it seems to come as a surprise for many following the engineering career progression.

The first step is to accept and understand the phenomenon of ownership going beyond your direct work. The second step is to learn at least a little bit about management, and especially delegation. Yes, you are on an engineering career trajectory, but the management skills are still relevant, just to a lesser extent than on the management path. In this subject, you cannot go wrong with High Output Management - the seminal work about management, by legendary Intel CEO - Andy Grove. 

Business understanding 

I’ve used the phrase “business understanding” to emphasize that it goes way beyond “business domain”. The phrase encompasses areas like:

• Business domain 

• Organization priorities 

• The key stakeholders and influencers, together with their priorities. These may range from slightly different from the organization’s priorities to completely misaligned (sorry to break it to you, but the latter might happen more than anyone involved would like to admit!)

Creating business software is inextricably tied to achieving some business results. These results might range from increasing revenue, decreasing costs, increasing customer satisfaction, lowering the business risks and so on. The key is that there are some concrete business goals. Real world organizations are rarely as laser-focused as depicted in business books. Often the reality is that there’s more than one business priority that needs fulfilling. Five or more is not uncommon and the key stakeholders might not clearly articulate which are more important than others. It may sound sub-optimal, but its a situation you’ll need to deal with.

Understanding the goals and priorities of the software you are working on is paramount. In general, software architecture should be built around business needs and characteristics. It is difficult to build software or design organisational processes that support technology well without at least some understanding of it.

Likewise, understanding who is pulling the strings, what kind of influence particular stakeholders (individuals or organizations) have on the project, is also important. Being effective in any organization means generating buy-in from the right people or parties and it is very difficult to move the needle without understanding these matters.

This may sound like borderline being involved with organization politics, and that’s generally correct. However I do not suggest immersing yourself entirely in politics. People who do that to a large extent and (!) enjoy it, usually come with a package of additional questionable traits. What I do advise is to be aware of its existence and not ignoring it.

Network

Last but not least there is an interesting subject of building your work relationship and network.

First of all, as mentioned earlier, the post-senior promotion process is usually more involved than at the earlier levels. It may require acceptance from your manager or even an entire committee (usually your manager’s peers or more senior engineers - e.g. Staff or Principals). Sometimes, there is a strict budget or other limit for promotions in higher-level positions. As such a good rule of thumb is to build a good relationship, not only with your manager, but also their peers, their manager and most senior engineers in the organization. Generally, the higher up the chain the better. Usually, your reach has vertical limits and stretching it starts to seem dishonest (the work of the director 3 levels above your manager might be too detached from your area of work anyway). The rule of thumb above is a good tradeoff. If you want to improve your luck, try to ensure you have some exposure to these people. Sure, you might try to create a casual encounter in the kitchen and strike up a conversation about common interests —perhaps discovering that you both enjoy playing squash, pickleball, or whatever the next trendy activity might be. Some might see this as perfectly fine, while others could view it as bordering on "sucking up" - depending on the character and cultural environment. Also, social endeavors like this may just not be your thing. That’s actually fine as a far better and more reliable option is just to get involved in the practical, work initiatives with exposure to the right people. Perhaps there is an initiative looking for volunteers that you could apply for? This may be participating in an organization-wide initiative of unifying APIs, improving tech recruitment processes or helping to update engineering progression guidelines. Opportunities abound, if you look for them. Nothing helps people remember you (build your “internal brand”) better than showing professionally done work.

The second thing is building a network outside the organization. This comes from a simple fact of life: as you grow in your seniority, the number of people who could coach or mentor you quickly decreases. This could be intuitively visualized by juxtaposing junior engineer and CTO. Junior engineer, a role which is pretty much entry level, still has a lot to learn in their career and, more importantly, has many more senior engineers around them. At least, hopefully that’s the case. If they don’t then that’s a problem on its own. These senior engineers are not only capable, but also incentivized (again, hopefully!) to mentor more junior engineers. 

Now, let’s take the other extreme: CTO. As the most senior person in the engineering organization, they might not have anyone nearby with experience in the scope of their role, or generally, a more senior engineering leader. Moreover, engineers typically work with other peer engineers (on the same level, or more or less senior) and a CTO’s typical group of peers is composed of a CFO, COO or CMO. At best, they might have a peer CIO (Chief Information Officer) or one of the more modern roles like CDO (Chief Data Officer), though such settings are rare. I’m not saying that a CTO cannot learn from someone in their engineering organization (either direct or indirect reports). Sure, the organization probably has people more skilled and experienced in specific areas, but there is likely no one who wore the boots of CTO before.  

So, comparing a junior engineer (the most junior technical position) with a CTO (the most senior technical position) gives us an extreme example. The roles in between fall on a spectrum spanning these extremes. Staff engineers work less frequently and less directly with more experienced engineers than junior engineers. 

Ultimately, the solution is to mix internal mentors and coaches with external ones. This might be a group of peers that you know from previous companies. Or it might be a network group that you built yourself over your career. An external group has a lot of benefits such as being emotionally detached, having an unbiased perspective and a different set of experiences. 

If you don’t have such group, there are some paid options:

• Luca Rossi organizes a lightweight version via his Refactoring Community (a companion to his Refactoring newsletter). 

• CTO Craft organizes lightweight (Slack based) access to other industry tech leaders, as well as more structured (and priced higher) monthly round tables with a smaller, more intimate group. I’ve been part of it for 2 years, and I highly recommend it if you can afford it.

• I’ve heard some good opinions about Plato Community - including it’s 1-1 - but never have tried it myself.

Structured/facilitated options are in my opinion better for discussing concrete challenges. The problem is the price, which might easily go north of $1,000 a year, though some companies might reimburse the fee for more senior employees. 

There are likely many other options available, including ones local to where you live (face-to-face beats Zoom calls when it comes to support groups). 

Wrap up

We have covered a lot of ground in this article, depicting the characteristics of the engineering roles beyond senior level, potential career paths and the skills needed.

One additional thing that’s worth noting: choosing a path (e.g. Management) that eventually turns out not to be in line with your vocation, is not usually a grave mistake. Most organizations allow lateral movement between Engineering and Management paths (often with none or minimal negative effect on salary - depending on the depth of their engineering career track). 

My personal experience is that such a temporary foray into management might be beneficial for a post-senior engineering career. Charity Majors even wrote a whole article about the idea of switching back and forth between engineering and management - The Engineer/Manager Pendulum. There is nothing better than direct experience on the other side to cure some of the detachment that happens between Engineering & Management in some organization. The grass is always greener on the other side.  

As a closing note I am linking some great book resources that might help you in post-senior engineering roles:

• Writing Without Bullshit by Josh Bernoff - hands down best book about effective business writing.

• Staff Engineer: Leadership Beyond The Management Track by Will Larson - great book focusing on first beyond-senior role - Staff Engineer

• The Software Engineer’s Guidebook by Gergely Orosz - covers the role and skills for senior engineers, the foray into team leadership and into post-senior roles

• The Manager’s Path by Camille Fournier - isn’t related exactly to the career of post-senior engineer as it covers Engineering Management path - from Team Lead to CTO. However it might give you a good overview of how life on the management path looks like.

• High-Output Management by Andy Grove - absolute classic when it comes to management books. As mentioned earlier, some management skills are needed anyway on the engineering path and this book provides the basics, bundled with an interesting story.

As always, don’t hesitate to reach out to me if you are interested in any of the areas outlined in the article. You can find my contact details here.

Till next time 👊

This is the second of three parts of articles describing the journey we made at VirtusLab while creating an updated version of the engineering framework.

This time, there are two major sections here:

1. Analysis of most common structures of engineering progression framework in real-world organizations (starting from section Choose a structure for your progression)

2. Tips & Pitfalls to have in mind while building framework (starting from section Things to consider when detailing your engineering progression)

In the first installment, I covered the case for building engineering progression and the groundwork. In this article, we switch to the nitty-gritty details of creating an engineering progression and its release.

Wait. You skipped the first article? Here’s a quick reminder of what I mean when referring to an engineering progression framework:

An engineering progression is a career ladder for engineering roles within a given organization. From a high-level perspective, it is a roadmap for an engineering career designed to help both engineers and their managers navigate their career paths over the years. From a low-level perspective, it covers a set of required skills and expectations to be met at a given level of seniority. In addition, it more or less directly indicates the engineer's salary.

Choose a structure for your progression

Let's begin by picking a basic form for your engineering progression. But where to start? How about taking a look a progression.fyi, where you'll see many different progressions, each drawn from a real organization. If you are building an engineering progression for your organization, I strongly recommend you browse through the examples on that webpage.

Engineering progressions typically fall into a small handful of distinct forms. Different organizations, of course, emphasize different aspects of how engineers work or how their culture works (which I covered in the first part of this article series, in the section Things to be clear on before building your engineering progression). What's less obvious is that the most appropriate structure for you will be a function of several parameters related to your organization. Most likely, the key parameters will be:

• The size of your engineering organization 

• Role diversity of your engineering organization (number of various roles e.g. application engineer, data engineering, technical project manager, etc).

What does this look like in practice? Let’s look at a few typical approaches.

A simple approach

In a small, relatively homogeneous engineering organization with mostly one type of role, perhaps the simplest approach is the one Basecamp / 37signals used in 2017. 

It focuses on just one type of role - programmer. Each seniority-level description consists of just a few bullet points. When the junior role is dissected, it contains these basic elements:

• Scope of work: “Works primarily on tightly scoped, routine problems.”

• Skills/capabilities: “Basic language features are mastered, but some advanced structures may still be unfamiliar.”

• Length of experience: “Usually less than 2 years of experience being a professional programmer in the specific domain.” 

I've noticed that adding explicit years of experience is controversial for some people. Personally, I think it is a good idea, and will cover the pros and cons in the Years of experience vs. speed of climb section later in this article.

All in all, this structure is simple, and that is its greatest strength. In fact, I'd go so far as to say that, in my experience, this is the way to go for most companies that are:

• Relatively small (say up to even 50 people); especially if they have mostly similar roles

• Building their first engineering progression framework (because it is likely to provide the best bang for the buck).

It is also simple from the perspective of particular ladder levels. It is a straight path, with fairly obvious stages, without any branches. 

It is no coincidence that I used this approach when I was building an engineering progression framework, circa 2012. This was for a small consulting firm that I co-founded. We had about 10-15 engineers back then, and we needed something simple. We also used something very similar at VirtusLab between 2015-2020. In retrospect, I see the framework we built had a ton of problems, but we’ll get to that in a moment.

There are also other notable, well-structured examples of this approach - for instance, Monzo’s Engineering Progression Framework v3. This one has more levels - and now they aren’t universally as obvious as the previous example. This requires some additional Monzo context-specific information - which they do provide with the basic split into Impact, Technical Skills, and Behaviors categories.

It is clearly more complicated than the simpler approaches used above, but it seems very well justified - at the time of this writing, Monzo had likely more than 200-300 engineers on board. This leads to a full-blown competency-based approach, which will be discussed next. 

Competency-based approach

The competency-based approach is effective, although more complex. As long as you capture the characteristics and culture of your engineering organization accurately, it can work quite well. 

As an organization grows, the limitations of the simple approach become apparent. 

As an organization grows, it becomes more fragmented and siloed (unless leadership consciously and relentlessly counters this drift). This is a phenomenon that may be all too familiar to anyone working in a growing organization. 

At VirtusLab, noticing the lack of consistency in how engineers were being evaluated, we created a quick experiment.

1. I wrote a list of artificial engineer profiles. The role descriptions consisted of general characteristics, strong/weak points, some indication of recent accomplishments, and a general indication of previous work experience. 

2. I showed this list to 10 managers and team leaders and asked them to match these synthetic profiles to the seniority levels seen in our existing engineering progression framework.

3. The results left much to be desired. We had good alignment for some profiles. We also found that for others - about half of them - we had discrepancies for the same profile ranging from Junior+ (advanced Junior) to Staff- (early Staff). The experiment’s results made us realize it was time to raise our game and modernize the engineering progression framework.

At this point, we were clear we needed to bring in more fairness and consistency, and help managers and engineers with career guidance.

What we'd experienced is what often happens in organizations as they grow, briefly:

1. More managers/leaders appear in the organization. Direct lines of communication become less effective and the need for more concrete guidelines arises. 

2. The organization becomes more diverse in terms of its engineering roles. 

These are challenges that the simple engineering progression can be adapted to meet:

1. Split the general expectations into separate, more quantifiable characteristics or competencies.

2. Add multiple parallel engineering progression ladders.

This typically leads us to what I’d call a competency matrix (sometimes called a rubric). My favorite example is the CircleCI progression. It is very well thought through.

The basic elements in this progression are:

• Seniority levels (e.g. “E3 Senior Engineer”)

• Scope of work (called “scaling of competencies” in the CircleCI progression)

• Competencies (e.g. “Debugging”).

In this progression, the competencies and seniority levels work together intuitively. The scope of work scales from an individual task (for a junior or associate engineer), to teamwork (for senior engineers), to the entire organization (for principal engineers).

The competencies are also grouped into categories. For CircleCI these are: 

• Technical skills

• Delivery

• Feedback/communication/collaboration

• Leadership

• Strategic impact.

Five in total. While these categories are specific to CircleCI, when you look at a number of organizations, patterns emerge. For example, in our second approach to engineering progress at VirtusLab, we developed three categories: Engineering, Delivery, and Teamwork. Another example is Dropbox, which uses: 🏆 Results (a variation of Delivery), 🌟 Direction, 🌈 Culture, 🌳 Talent (all closely related to Teamwork), and 🦉 Craft (a variation of Technical Skills).

The most surprising finding for some, however, is that hard technical skills typically represent only a small fraction of the total expected competencies. This is interesting in the context of recurring online debate about whether soft or hard skills are more important for software engineers. Here’s my take, based on my experience with hundreds of engineers I’ve managed over the course of my career:

• Hard skills are required and are key conditions for promotion in the first part of the engineering career. 

• Soft skills start to play an enabling role in the later stages, from senior engineer onward. They won't guarantee advancement on their own, but a lack of them will severely limit further development.

Don't get me wrong. Not paying attention to soft skills (collaboration, communication, etc.) will be detrimental to an engineering career at any level. However, you want to pay a significant amount of attention to this for the more senior engineers. On the one hand, your seniors, staff, and principal engineers set the tone for the entire organization (by orders of magnitude more than juniors). On the other hand, most senior positions require strong leadership skills (which in turn require good soft skills), even if they appear to be individual contributor roles. 

I covered this in the Leadership Management vs Engineering section of the first article in the series. It is almost impossible to perform well in Staff and above engineering roles without well-developed soft skills. 

Returning to the explicit split of competencies in the progression framework - even Basecamp (now 37signals) has begun to use separate competencies in their engineering progression circa 2018.

While it is definitely not the case that EVERY organization will eventually move in this direction, it is pretty typical for many growing organizations. I'd say when you have +100 engineers in your organization (and thus likely between 10 and 20 teams), the need for such a change will be apparent. 

In addition, most growing organizations dealing with complex technology products quickly build more diverse roles. While they may initially have front-end and back-end engineers, they will eventually introduce designers, cloud engineers, data analysts, or ops. Whereas you can probably handle a fair share of traditional engineering (e.g. backend/frontend) with a single engineering path, it might not be feasible anymore to do that for all types of engineering roles (e.g. designers, ops). 

Sure, you can create a very general progression, but I would argue that its usefulness quickly diminishes if it becomes too general. Since one of the purposes of an engineering progression is to establish consistency across the organization, it must, by definition, be tangible enough to be understood similarly by engineers and managers throughout the organization.

One thing to keep in mind is the increased effort required when moving from a simple progression to a more complex one, complete with explicit competencies and different career paths. The division into different specializations (career ladders) effectively multiplies the work you need to do to create and optimize the progression. In addition, explicit competencies require a deep understanding of the specifics of your organization and its evolutionary path.

While a simple engineering progression could be written almost overnight by a founder (well, the first draft, at least), a more complex version with a competency matrix and multiple career ladders will most likely require a working group active for many weeks. This is not easy work. There are several reasons why:

• You need to break the work down into discrete, concrete competencies/characteristics.

• You need to provide concrete descriptions of the competencies at different ladder levels.

• You need to cover multiple roles, some of which may be less familiar to you (most engineering leaders have experience with some parts of the engineering work; but how many have the work experience with all the roles in the organization?)

• By the time you are ready to build a complex engineering progression, your engineering organization will likely have many practice areas with their respective leaders or role models. It will be critical during the rollout phase to have their buy-in. Getting them (or someone from their sphere of influence) involved early on will definitely help.

Make sure you plan accordingly!

Optionality and trajectories

One of the problems that typically arises with competency matrices is that they assume that everyone within a given career ladder is the same. That is, there are specific requirements for each competency for an individual to be at that level. And it's worth noting that CircleCI relies on no less than 28 different competencies to define whether an individual is at a given level.

I have found this approach too prescriptive for larger, more diverse organizations. It's even unrealistic for smaller organizations, but not as obviously as in a larger organization. You are bound to end up with many engineers who not only meet certain requirements, but far exceed them while falling short in others.

A more liberating example is the progression used by Medium. They have done a great job of describing how it works in this series of articles. Basically, they have four different areas (Build, Execute, Support, Strengthen), each of which contains multiple competencies. You can see them here. Achieving milestones in these competencies gives you a specific number of points, and there is a specific threshold of points you must achieve to be promoted. How the engineer earns these points (which track they choose) is entirely up to them! 

This is an extreme example of codified choice, but it is far from unique. Another example is used by a company very close to me - and now part of VirtusLab - SoftwareMill. You can read more about their "badge-based engineering progression" here.

Above, you can see an extract from SoftwareMill’s engineering progression. Here’s a note on how to decode it:

• J1, J2, M1, S1, E1 - these are engineering levels (Junior, Mid, Senior, Expert)

• 7B, 9S, 2G - these represent specific badges. They fall into three types: Bronze (B), Silver (S), and Gold (G), each being more difficult to earn than the previous one.

Badges are related to achievements in specific competencies. For instance, knowledge sharing, architecture, production maintenance, etc.

Competencies are segregated into three groups: Technical (hard skills), People and Development (soft skills), and Organizational.

As you can see, the progression framework allows for considerable flexibility, but it also imposes some constraints. For example, to advance from S1 to S2, you must earn 9 silver badges, 5 of which must be in the technical category. 

In my opinion, some flexibility in the progression framework is desirable. This is especially true at higher levels. Staff+ is where most people's careers start to diverge according to their different strengths. But be aware of the trade-off - this is another level of complexity you bring to the table.

I think you want to allow some flexibility, but at some point, you have to split into separate career paths. In the case of Flatiron, Cat Miller says they eventually decided to split engineering after the E5-E6 level into two paths: the Principal Track and the Architect Track. I think this is a reasonable compromise.  

All right, we have covered the most typical structures used for engineering progression frameworks. Now let's discuss the key aspects to consider, tips from experience, and typical gotchas.

Things to consider when detailing your engineering progression

Now, let's move away from the high-level structure and zoom in on the details and key considerations to keep in mind when building the framework.

Picking competencies to add to your matrix

Whatever type of engineering framework you're working on, you need to think about competencies and attitudes - whether you show them implicitly (as with a simple approach) or explicitly (a competency matrix). Either way, you need to be clear about what set of skills and attitudes is required for a given role and level. 

For any non-trivial job like software engineering, we quickly conclude that there are many skills and attitudes to consider. I'd say it's worth spending some time identifying the most important ones. In my experience, it is difficult to narrow it down significantly below 10. On the other hand, more than 20 can be overwhelming. The CircleCI example used earlier contains 27 different competencies. In my opinion – even though it may work great for CircleCI – it might be too many.

Keep in mind that distilling them into the engineering progression framework is just step one - the easy part! Then you need to get all engineers and managers to understand them well and use them regularly for performance reviews and 1:1s. Depending on the nature of your organization, you’ll spend different amounts of time on these activities, but keep in mind that if it’s too complex or time-consuming, it’s likely that only a few people will do it well, and everyone else will just treat it as another company bullshit they need to get through. 

The obvious trick is to group them into some logical buckets. This is backed by science - grouping helps you remember more. In our context, it helps managers and engineers remember the competencies relevant to the organization and their careers. 

A balanced, manageable number, 10-20, will also help you be concrete when applying it to a variety of different roles. For example, at VirtusLab we've found that we can use the same skill set for backend application engineers and frontend engineers, even if they specialize in different technologies, from Scala to Java to Typescript. However, we concluded that Data Engineering would require a modified skills matrix. Designers would also get a different matrix.

Avoiding low-level concepts, such as knowledge of specific tools or frameworks, is the key to achieving broad applicability while still being tangible and useful. We concluded that, even if we wanted to separate frontend from backend paths, we wouldn’t focus on tools and frameworks because they change too often from project to project. Instead, we divided technology competencies into high-level skills: writing code, maintenance/production, technology landscape expertise, architecture, and DevOps. I’m sure the exact breakdown is pretty much specific to us, but it shows the level of granularity. 

The key here is that it doesn’t make sense to get too specific (e.g. talking about the particular programming language, framework or methodology) because it changes over time and from team to team. Also, it sounds a bit too dogmatic and counterproductive to focus your engineering culture on particular tools. On the other hand, being too general doesn’t make too much sense either - remember that the main goal is to build consistency across the organization. Being too general won’t help. Pick the competencies that are relevant to your organization. If observability or security is relevant to most engineers in your organization, it should be part of the rubric. Not every organization emphasizes these aspects for every engineering team - especially with a siloed dev vs. ops culture. For example, we chose "maintenance and production readiness," which includes security, observability, diagnostics, etc. 

We also found that for different engineering roles (Ops, data engineering, application development), even if we create separate career ladders and competency matrices, the competency matrix really only differs in terms of the hard skills. Delivery and teamwork remain largely the same. This is not unusual, as these categories are more tied to company culture and organization and, thus are likely to be more common across disciplines. One exception is purely management roles, but that’s a different story, probably a separate career ladder and perhaps a topic for another article.

The bottom line is:

• Do your homework: verify the competencies that are relevant to your organization (as opposed to copying them from other hot companies)

• Keep the number of competencies in check (< 20)

• Group competencies into logical buckets that help people keep track 

• Don’t be overly specific, especially with technologies, or too general either.

Track record vs. present capability

We put statements like these in our first engineering progression:

Is able to plan & design the architecture on a project-wide level. Can discuss requirements with customers / stakeholders. Is able to set up processes. Can drive interactions / integrations between multiple, technologically diverse components or products.

Capable of leading regular projects, with several engineers involved or is starting to be widely recognized for his/her expertise in their field of choice. Share knowledge with others (mentoring, conference talks, blog posts, workshops, meetups).

There are a number of problems with such statements. First of all, it is asking for trouble to use statements like: "is capable of...". What does that even mean? We've had many situations where engineers come to managers and say they can do X, but they don't have enough opportunities to prove it. It bit us many times, and countless hours were spent on such conversations during 1:1s.

The harsh truth is that no matter how you design your career ladder, there will be patches in the organization (a project or group of projects) where the local situation doesn't allow engineers to manifest or hone certain skills. For example, there may be a team that is effectively keeping the lights on for one of your legacy projects that will (hopefully!) be decommissioned next year, and they have limited potential to excel in architecture skills.

The same goes for the availability of leadership opportunities, such as taking the lead on initiatives that span multiple teams or stakeholders. While these opportunities may come up from time to time, there is still the issue of timing in the context of a given performance review cycle. There will be periods of time when some people may be technically ready for something, but they just haven't had the opportunity. 

In my opinion, the better way is to have an actual track record. We should at least have some tangible - even if imperfect - proof that engineers are actually doing the work to a given standard. It may be a bit unfair (again, opportunities are not evenly distributed), but it saves a lot of headaches that can ripple throughout the organization. 

The bottom line is to avoid phrases like "can do" or "is able to. It is much better to rely on "has a track record" or "has demonstrated the ability to do X more than once.

Frequency and intensity

There’s a similar kind of problem found in statements such as:

Shares knowledge with others (mentoring, conference talks, blog posts, workshops, meetups).

Is one internal workshop enough to qualify? How about one per year or one per quarter? I am against being too prescriptive, but there should at least be a guideline for what we expect. You definitely want to avoid the checkbox exercise where you're asking some people to do certain activities once to check the requirements for promotion. 

Sometimes it might be enough to clarify that we are talking about the pattern of repeated behavior (such as: "this person is known for sharing knowledge with others") rather than concrete numbers ("you must do some form of knowledge sharing 3 times" for example).

Years of experience vs. speed of climb

I am not a big fan of role prerequisites based on years of experience. First of all, not everyone is the same - some people grow and learn faster than others. Second, not all years of experience are the same. As the saying goes: "Some people have 10 years of experience. Others have 1 year of experience 10 times over.” At the same time, experience that comes from practice is important. And practice takes time. Most experienced engineers would (and should) be suspicious of someone with 2 years of experience claiming to be senior.

I don't think we should be too dogmatic about this. I favor descriptively stating typical years of experience for a given level of seniority. It shouldn't be a showstopper for someone who doesn't meet those values, but it should at least make you suspicious and ask the right questions. Having some benchmarks might also make it a little harder for managers to give in in times of intense hiring pressure from the CEO or otherwise (and thus tendencies to lower standards). 

The same goes for the time it takes to progress from one level to the next. If someone is progressing too fast, it shouldn't be a showstopper, but it's probably worth investigating. In the worst case, an exceptional individual comes to your attention thanks to such investigation. At best, you discover a situation where the manager gives in to pressure from a very salary-conscious engineer who, for example, threatens to leave if they don’t get a raise. At the end of the day, you want to be fair (promotions based on merit, impact, attitude), and allowing pushy engineers to be promoted faster does not do that. This is also related to the point made in Frequency & Intensity above. If we are going to focus on a "pattern of repeated behavior", it is definitely going to take some time to establish that.

What are the right values here? It depends on the organization, but a good rule of thumb might be to wait at least one or even two years before promoting to higher levels. Again, that's a guideline, not a hard and fast rule. 

Is “up or out” effective?

The "up or out" scheme comes from some partnership systems, especially law and consulting firms. It generally says that you have a certain amount of time to reach a certain rank. If you fail to do so, you must leave the organization. 

I don't believe in the myth that everyone in IT needs to advance their career indefinitely. This may be fine for some people (achieving certain roles as a life goal), but I think it is beneficial also to be able to accommodate people who want to stabilize (or pause) their career advancement for a period of time (e.g. more family-focused time) or even indefinitely. 

Generally speaking, up or out doesn't make sense. However, I think it might make sense for entry-level positions - namely interns and juniors. If you subscribe to this line of thinking, it is worth making this expectation clear upfront.

Juniors require the mentorship and attention of mids and seniors and, as such, represent an investment. This investment is expected to provide a return on investment at some point. If that is the case, then there should be some pressure on junior engineers to get through those early stages in a reasonable amount of time. So, I think it makes sense to set benchmarks for how long we expect engineers to stay at the intern and junior level. Exactly how long depends on the specifics of your organization. After all, junior doesn't mean the same thing in every company. It is common for juniors in one company to be considered mid-level in another. I think the reasonable starting point is to expect interns to be promoted to juniors within at most 1 year and juniors to be promoted to mid-level within another 1.5-3 years. 

If you want to ensure this is adhered to, it is worth codifying it explicitly in engineering progression. 

Time to add more career tracks?

At some point you inevitably face the dilemma - is one of the roles sufficiently distinct to build a separate track for it? A separate track might have two manifestations: 

• It’s either a separate career ladder with distinct requirements and competencies (for instance, application developer vs UX designer paths). 

• Or it can be a branch from the existing career ladder (a typical example is software engineering branching into engineering management).

These examples are high-contrast. After all, the role of a UX designer is quite different from that of a typical software engineer. One might even ask whether UX design is really engineering at all. I will leave those philosophical questions aside. The bottom line is that UX designers are typically part of the engineering organization in most companies, so they deserve a career ladder just as much as anyone else in the engineering part of the organization.

What about data engineers versus application developers? I'd say it depends on the nature of the work in your organization. It's a lot of work to build separate career ladders, but fitting square pegs into round holes doesn't really serve the overarching goals of engineering development. If it is to add value, it has to be used, and that requires sufficient buy-in. 

My quick rule of thumb is to build a career ladder for any role that affects more than 20 people in the organization (and at least consider it for roles with more than 10). If you decide to use a typical breakdown of competencies (hard skills, communication/teamwork, and leadership/organizational) for most individual contributor roles, it is likely that most of the time only the hard skills will vary significantly. The rest will remain largely the same.

It is hard to miss the point at which a separate career ladder is potentially needed. If the role is truly distinct and doesn't fit well into the existing career ladder, it's almost certain that people in that role will come to you and complain about it (which is great!). They may even suggest that they create a separate ladder for themselves (which is even greater!). If you decide that a separate ladder is worth the effort at that point, it is good to have a basic framework and structure thought out so that they can do it themselves.

In both cases (separate ladders and branching), it is worth making sure that lateral movement is possible (people moving to other departments or between individual contributors and management positions). How to do this from an organizational perspective (training, salary, position, etc.) is beyond the scope of this article, but from an engineering progression perspective, they should at least "feel familiar" with the new technical ladder they will be using (structure, organizational/teamwork skills, etc.). 

There is also a more subtle area related to career branching. In some roles, there are several possible paths of development. These are often referred to as archetypes or trajectories and become apparent at higher levels of an engineer's career. At VirtusLab, we have defined the following archetypes:

• Team Leader: The first step in a leadership career that begins with managing a single team. This is typically still a very hands-on technical role.  

• Rock: It describes a well-rounded engineer who can basically perform almost any task on a given project. They know the domain very well and are well versed in the business environment of the project. They usually spend long periods of time (many years) on a single project and tend to be the bedrock of the project, knowing it inside and out.

• Subject matter expert: This trajectory describes an engineer with exceptional depth and/or breadth of knowledge, skills, and experience in a specific area. The area may be more technical (e.g., cloud platform engineering or stream processing) or domain-oriented (technology in InsurTech or manufacturing). The impact of these engineers comes from sharing knowledge/training others internally, supporting VirtusLab's outreach (articles, presentations, panel participation, community activity), helping with pre-sales efforts, and consulting with other teams. 

• Architect: Architects are often involved in pre-sales activities or the initiation of new projects. They must be able to understand the business environment, constraints, and customer requirements. Since customers often don't really know all of their requirements, engineers in this role need to have solid experience in figuring out what the real requirements are. Typically, they spend a limited amount of time on the project (6 to 12 months) or work on it part-time - while being involved in other initiatives (either continuously or from time to time in a more consultative manner). 

• Organization engineer: Organization Engineers thrive on building engineering organizations - they are often involved in key organizational tasks. They may play a leading role in areas such as engineering progression, building VirtusLab's ways of working, redesigning the hiring process, building training for new team leaders, etc. 

At VirtusLab we distinguish these archetypes from the Staff+ level on. In our case, they don't require completely separate branches in the career ladder. They do, however, allow us to emphasize certain competencies and help guide engineering careers at a certain point. They are also specific to VirtusLab, based on our retrospective identification of notable senior engineers with different skill sets.  I would be surprised if they could be applied "as is" to your organization. Here are examples from other organizations that may give you food for thought:

• Meta – as described by Gergely Orosz – uses the following archetypes: Generalist, Specialist, Coding Machine, Tech Lead, Fixer, Systems Thinker, and Product Hybrid. 

• Flatiron Health – Cat Miller describes their journey that involved separating the Principal Track from the Architect Track starting from E6 (E6 is roughly Staff Engineer).

When promotion requires more than just meeting requirements

There is a tendency to treat meeting the requirements for a given engineering level as a sufficient condition to warrant promotion. "I've done what was required, so I should be promoted soon after" - right? While this is certainly true for some levels and perhaps even desirable for all, I don't think it's always and everywhere the case.

It definitely makes sense for the first part of the career: interns, juniors, mids, and seniors. As soon as the engineer meets the requirements, they are eligible for promotion. Things get more complex in the second part of an engineer's career and definitely in management roles. 

Let's start with a simple example and assume that our management engineering career ladder looks like this:

Almost all steps in this career are based on available opportunities. You can't really move from team lead to engineering manager if there isn't a vacancy. Granted, opportunities abound as organizations grow, but of course, constant growth is not a given. In fact, it is almost guaranteed that your organization will plateau at some point. If attrition isn't perfectly aligned with the growth rate of your people, there will come a time when even people who meet all the requirements can't be effectively promoted.

The extreme case of this example would be the CTO position. Unless the current CTO of your organization leaves (by their own choice or otherwise), you are unlikely to promote anyone else into that role.

Going back to the pure engineering (non-management) roles, I think this also applies to the Staff+ engineering levels, although it depends on your organization’s stage (hypergrowth, stagnation, contraction, etc.) and the attrition rate. Would your organization be even able to utilize a new Principal Engineer every time there's a new person, who meets the requirements? It's worth thinking about. 

The thing that helps here is that Staff+ engineers are less common than less experienced engineers. And Principals are even rarer. So, it is unlikely that the supply of these very senior roles waiting in line for promotion would become a major problem. Still, I think it is worth clarifying that meeting the requirements is not sufficient for some roles. Addressing this issue openly and upfront may save you some headaches down the road.

Next steps

That's about it. I've tried to cover a lot of the ground needed to build a successful engineering progression. It is a lot of work. Or rather, doing it right is a lot of work.

The real fun, however, starts with the rollout, building in the change process, getting buy-in, and dealing with the various outliers in your organization. This will be the focus of the third and final part of this short series, which I plan to publish in the next few weeks. If you've found this information useful, I'd love for you to subscribe to this publication. 

Until next time.