DEV Community: Remo H. Jansen

The Gaming Industry Is Doomed

Remo H. Jansen — Thu, 12 Nov 2026 07:38:34 +0000

The technological barriers protecting proprietary gaming platforms are collapsing. Emulation is becoming practical, games are being recompiled into native applications, hardware is becoming increasingly unaffordable, and platform holders are responding with increasingly anti-consumer strategies. The economics of the traditional gaming industry are starting to make very little sense.

A few weeks ago, I wrote about how Halo was becoming the new Doom and how most software would soon become effectively open source, whether its owners wanted it or not.

My original argument was that AI had dramatically reduced the cost of reverse engineering, decompilation and software reimplementation. What previously required years of specialist work could increasingly be accomplished by small teams, assisted by coding agents, in days or weeks.

I argued that software was losing its scarcity.

At the time, I was primarily thinking about SaaS, proprietary applications and the economics of software development.

I hadn't fully considered what this would mean for the gaming industry.

Having watched what has happened over the past few weeks, I think the gaming industry might be facing an existential crisis.

And I don't mean gaming itself. People aren't going to stop playing video games.

I mean the traditional business model built around expensive proprietary hardware, exclusive software, digital storefronts, DRM and increasingly expensive AAA productions.

I genuinely believe this business model is approaching a breaking point.

The technological moat is disappearing

For decades, console manufacturers enjoyed a relatively comfortable position.

You bought a PlayStation to play PlayStation games. You bought an Xbox to play Xbox games. You bought a Nintendo console to play Nintendo games.

The hardware was the distribution platform, the security boundary and the commercial moat.

If you wanted to play a particular exclusive, you had to buy the corresponding hardware. There was no practical alternative.

Piracy existed, jailbreaks existed and emulators existed, but there was usually a considerable time gap between a console's release, its security being compromised and its games becoming playable elsewhere.

That time gap was incredibly valuable.

Manufacturers could sell millions of consoles and games before alternative execution environments became practical.

That assumption is now being challenged.

The PS5 is no longer the fortress it once was

The September 2026 release of the Relapse jailbreak significantly expanded the number of exploitable PlayStation 5 consoles.

The exploit works on firmware versions up to 13.60, enabling kernel access and arbitrary code execution.

This is significant because previous jailbreaks often required consoles running considerably older firmware versions.

It opens the door to homebrew, unofficial modifications, backups and alternative software environments.

But the jailbreak itself isn't even the most interesting development.

PS5 emulation is progressing at a remarkable pace.

Consider Demon's Souls Remake.

In early September, it was running at approximately one or two frames per second in the emulator. Within weeks, it had progressed through 30 FPS demonstrations to builds capable of exceeding 60 FPS at 1440p.

By mid-October, my previous article documented custom builds approaching 120 FPS using frame generation.

Read that again.

We are no longer talking about waiting five or ten years for an emulator to become sufficiently mature to run commercial games.

We are talking about going from barely playable to technically impressive performance within weeks.

The historical economics of console exclusivity assumed that emulation would take years to catch up.

What happens when that assumption stops being true?

Nintendo is experiencing the same problem

Nintendo's Switch 2 has also experienced its first significant software jailbreak.

The ns2jb exploit, developed by security researcher Sammy Hajhamid (Pepsipu), demonstrated native code execution through a software-only exploit involving the Switch 1 application SmileBASIC 4.

OpenAI's Codex was reportedly used to assist with the development.

The exploit demonstrated the ability to run homebrew, reverse-engineer and modify games, and access hardware functionality.

Nintendo subsequently patched the vulnerability in firmware 23.5.0.

But patching an individual vulnerability doesn't reverse the underlying technological trend.

The barrier to understanding and modifying proprietary software is falling.

And then came an even more interesting demonstration.

Ocarina of Time: Nintendo's exclusivity problem in miniature

On November 5, Nintendo released its new version of The Legend of Zelda: Ocarina of Time, built from the ground up for Switch 2.

It was a major exclusive release, tied to Nintendo's latest hardware and ecosystem.

Yet independent developers rapidly began working on making the game available outside that ecosystem.

The NX2navi project is a static recompilation of the Switch 2 version into a native x86-64 Windows application, complete with a Vulkan renderer.

This is not traditional emulation.

It translates the game's ARM64 code into native code that runs directly on PC hardware.

The project is already playable in several areas at 60 FPS and above, although it remains under development and has visual issues and occasional crashes.

There is also a broader Switch 2 recompilation toolchain emerging, building on the earlier SwitchRecomp work.

The important point isn't whether every game will be perfectly recompiled overnight.

It's that the technical process is becoming repeatable.

Nintendo released an exclusive game for its proprietary hardware, and independent developers began producing a native PC execution environment almost immediately.

This is the sort of development that should make every console manufacturer uncomfortable.

The moat is no longer necessarily the hardware.

It is becoming increasingly difficult to justify why software should remain tied to the hardware it was originally designed for.

The economics of AAA development are already broken

Now let's introduce another problem.

AAA game development is becoming extraordinarily expensive.

A 2024 Boston Consulting Group report compared the development costs of two major publishers.

Between 2012 and 2021–2023, development costs increased by approximately 360% at one publisher and 449% at another.

Meanwhile, the number of games released by those publishers fell by 73% and 63%, respectively.

This is a worrying combination.

The industry is spending dramatically more money producing fewer games.

The traditional AAA model is based on enormous upfront investments, long development cycles and the expectation that enough consumers will purchase the finished product to generate an attractive return.

But what happens when the market becomes increasingly fragmented?

What happens when consumers have fewer reasons to buy expensive hardware?

What happens when the games themselves become increasingly accessible outside their original platforms?

And what happens when independent developers can use AI-assisted tools to recreate, port or extend software at a fraction of its original development cost?

The problem isn't necessarily that every new game will be pirated.

The problem is that the economic assumptions behind these investments are becoming less reliable.

A publisher spending hundreds of millions developing an exclusive game needs to believe that exclusivity provides a meaningful commercial advantage.

If consumers can increasingly play that game elsewhere, that advantage becomes harder to defend.

The risk is particularly significant for single-player games.

Online games have additional barriers: servers, matchmaking, competitive integrity, live services, player communities and continuous content delivery.

A single-player campaign is fundamentally different.

Once the software exists, the technical challenge is increasingly about understanding how it works and making it run elsewhere.

That distinction matters enormously.

Consumers are running out of money

Technology isn't the only problem.

The economic environment is becoming increasingly hostile to expensive entertainment.

Gaming is a discretionary expense. It competes with housing, food, energy, transportation, healthcare and everything else people need to pay for.

When household budgets become tighter, entertainment expenditure is one of the things people reconsider.

And the gaming industry seems determined to make its products more expensive.

Consoles that historically became cheaper as their hardware matured are now experiencing the opposite trend.

Sony increased the recommended European prices of its PlayStation hardware in April 2026:

PS5: €649.99
PS5 Digital Edition: €599.99
PS5 Pro: €899.99

The PS5 Pro is approaching the price of a capable gaming PC.

And we are already seeing discussions about next-generation consoles potentially approaching €1,000 or even €1,200.

Those figures are not confirmed retail prices, but the possibility itself should concern the industry.

Memory, storage, semiconductor manufacturing, tariffs, energy costs and competition for components all contribute to the pressure.

Meanwhile, geopolitical instability, including the conflicts involving Russia and Iran, creates additional uncertainty around energy prices and household purchasing power.

I don't think it is unreasonable to expect consumers to become increasingly selective about how they spend money on gaming.

Consider what a new console generation could mean for a family:

€1,000 or more for the hardware.
€80–€100 for individual games.
Monthly subscriptions.
Additional controllers and accessories.
Expensive storage upgrades.

At some point, consumers will simply decide that this is too expensive.

And when people want to play games but cannot justify the price of the official ecosystem, they will look for alternatives.

Some will buy fewer games. Some will wait for sales. Some will move to older hardware, second-hand markets or PC gaming.

And some will turn to piracy.

This is where the technological developments become particularly dangerous for platform holders.

Piracy is no longer necessarily a technically inferior experience that requires waiting years for emulation to catch up.

The gap between the official product and alternative execution environments is shrinking.

That changes the equation.

Piracy is becoming a much more credible alternative

I want to be clear about something: I am not suggesting that everybody will pirate every game.

People pirate for different reasons, and many consumers will continue paying for games they enjoy, particularly when they value supporting developers.

But the gaming industry has historically benefited from a combination of convenience, hardware exclusivity and technical barriers.

Those barriers are weakening.

Imagine buying a PC capable of running modern games.

You can purchase games through Steam, GOG and other storefronts. You can play independent games, older games and modern releases. You can emulate previous generations of consoles. You can use native recompilations where they exist.

You are no longer dependent on purchasing a separate machine every time a manufacturer releases a new generation.

And you aren't necessarily dependent on the manufacturer's storefront to access every game.

The situation becomes even more interesting when games can be recompiled into native applications.

An emulator reproduces the environment expected by the original software.

A static recompilation translates the original executable code into something that can run natively on another architecture.

These are different techniques, but they lead towards the same commercial problem: the original hardware is no longer the only practical place where the software can execute.

There is also an important distinction between technical access and legal ownership. A game becoming playable elsewhere does not make its copyrighted assets or code open source, nor does it automatically permit redistribution.

But that doesn't change the underlying technological development.

The cost of escaping proprietary execution environments is falling.

And if the official ecosystem becomes increasingly expensive and restrictive, the incentive to explore alternatives becomes stronger.

Nintendo should be particularly concerned

Of the three major console manufacturers, Nintendo arguably has the most concentrated exposure to the traditional console model.

Nintendo's business is not literally 100% dependent on hardware. It has substantial intellectual property, licensing, films, merchandise and other activities.

However, its core business remains closely tied to the relationship between proprietary Nintendo hardware and exclusive Nintendo software.

People buy Nintendo consoles because they want to play Mario, Zelda, Pokémon and other Nintendo franchises.

The hardware and software reinforce one another.

This creates an interesting vulnerability.

What happens if the software becomes increasingly accessible outside Nintendo hardware?

Nintendo's competitive advantage isn't simply that it makes consoles.

It is that it controls the primary execution environment for some of the most valuable intellectual property in gaming.

If that control becomes harder to maintain, the business model comes under pressure.

Nintendo can continue making excellent games. Its intellectual property isn't going to suddenly become worthless.

But it needs to consider whether hardware exclusivity will remain an effective way of monetising that intellectual property.

Its latest financial results demonstrate that the company is not currently collapsing: Nintendo sold 6.49 million Switch 2 consoles in the April–September 2026 period and reported higher net profit despite lower overall sales.

That is precisely why this is a forward-looking argument rather than a claim that the collapse has already happened.

The question is whether the economics supporting those sales will remain sustainable.

Sony is fighting the wrong war

Sony's position is different.

PlayStation is an enormously important business, but Sony has other substantial sources of revenue, including music, films, entertainment, image sensors and electronics.

It has more diversification than Nintendo.

However, I find some of Sony's recent strategic decisions particularly difficult to understand.

At exactly the moment when the barriers protecting proprietary gaming ecosystems are weakening, Sony seems increasingly determined to reinforce those barriers.

Consider its recent decisions.

First, Sony increased PlayStation hardware prices in an already expensive consumer electronics market.

Second, it announced that physical disc production for new PlayStation games will end starting in January 2028.

Third, Bloomberg reported that Sony was retreating from its strategy of bringing major single-player PlayStation releases to PC, returning towards console exclusivity.

Individually, these decisions have commercial justifications.

Sony wants higher margins, greater control over distribution and stronger incentives to purchase PlayStation hardware.

But collectively, they are strategically contradictory.

Sony is effectively asking consumers to pay more money for less control at precisely the moment when alternative platforms are becoming increasingly attractive.

Digital-only distribution reduces the second-hand market and makes consumers more dependent on the platform's licensing infrastructure.

Exclusivity makes hardware more important, but emulation and recompilation are undermining the technical barriers that make exclusivity enforceable.

Higher hardware prices make the official ecosystem less accessible, potentially encouraging consumers to explore alternatives.

This is not necessarily a recipe for immediate disaster.

But it is a dangerous combination.

When consumers have no viable alternative, platform restrictions are easier to enforce.

When alternatives become technically credible, economically attractive and increasingly accessible, consumer-hostile practices become a liability.

Sony seems to be operating under the assumption that its ecosystem is indispensable.

That assumption deserves serious scrutiny.

Microsoft might be the biggest beneficiary

There is an interesting irony in all of this.

Microsoft spent decades competing in the console market against Sony and Nintendo.

But Microsoft is structurally different from both companies.

Xbox is a division of a much larger technology company.

Microsoft owns Windows, Azure, Microsoft 365, LinkedIn and a substantial enterprise software business.

Its gaming operations are important, but they aren't the foundation of the company.

In fiscal 2026, Microsoft reported $331.8 billion in total revenue, while Xbox content and services revenue actually declined by 5%.

Microsoft doesn't need the traditional console business to remain successful.

And this puts it in an interesting position.

If the future of gaming increasingly moves towards PC, Microsoft already owns the dominant desktop operating system ecosystem.

If consoles become less relevant, Microsoft can continue participating in gaming through Windows, Xbox Game Pass, publishing, cloud services and its studios.

It doesn't necessarily need everybody to buy an Xbox console.

In fact, Microsoft has increasingly positioned Xbox as an ecosystem rather than just a physical device.

This is strategically significant.

The company that helped create the modern console market could end up benefiting from its decline.

There is another important point here: Microsoft doesn't have to win the console wars to benefit from the outcome.

It just needs Windows and its gaming ecosystem to remain relevant.

The winner is PC

I think the long-term winner is becoming increasingly obvious.

PC gaming.

Not because every consumer will suddenly build a gaming PC, but because PC offers something that traditional consoles increasingly struggle to provide: flexibility.

A PC isn't tied to one manufacturer's hardware generation.

It can run games from multiple storefronts, support emulators, run native recompilations, use mods, preserve older software and offer hardware upgrades without requiring consumers to abandon their existing libraries.

It also benefits from an enormous ecosystem of independent developers and open-source projects.

The PC platform doesn't need to convince consumers to buy a new proprietary device every few years to remain relevant.

And the more games escape their original hardware environments, the more attractive PC becomes.

Windows is particularly well positioned here.

Valve has demonstrated that PC gaming can also flourish through alternative operating systems and distribution models, so I wouldn't claim Microsoft owns the future of PC gaming.

But Microsoft owns Windows, and Windows remains an extremely important part of the gaming ecosystem.

If the industry moves away from closed console environments towards more open execution platforms, Microsoft is already positioned to participate.

Nintendo and Sony have to defend their hardware ecosystems.

Microsoft can participate in the transition regardless of whether Xbox consoles remain commercially important.

The next generation of consoles could be a disaster

Now consider what happens when these trends converge.

The next generation of consoles could become substantially more expensive.

There are already concerns about the cost of memory, storage and advanced semiconductor components.

Consumers are increasingly price-sensitive.

AAA games are becoming more expensive to produce.

Emulation is improving at an unprecedented pace.

Native recompilation is becoming increasingly practical.

AI-assisted reverse engineering is reducing the specialist knowledge required to understand proprietary software.

And the platform holders are still largely operating under the assumption that they can maintain the traditional relationship between hardware, software and distribution.

What happens if the next PlayStation or Xbox costs €1,200?

How many consumers will purchase one?

How many will decide that their existing PC is good enough?

How many will simply stop buying expensive games?

How many will wait for discounts?

And how many will discover that the games they want to play are already available through alternative execution environments?

I think the industry is underestimating the cumulative effect of these pressures.

A console generation is a massive investment for manufacturers.

They need developers to support the hardware, consumers to buy the hardware and publishers to invest in increasingly expensive games.

If any part of that ecosystem becomes significantly less attractive, the entire model becomes harder to sustain.

Why aren't gaming stocks collapsing already?

This is perhaps the question I find most interesting.

If the technological and economic trends are as significant as I believe they are, why aren't investors pricing in a much more dramatic structural change?

I wouldn't pretend that every gaming company is equally exposed.

Nintendo, Sony, Microsoft, Electronic Arts, Take-Two, Ubisoft and independent publishers all have different business models.

Some have valuable intellectual property, recurring revenue, live services and businesses that are much less dependent on console hardware.

But I find it difficult to understand why the market would assume that the traditional economics of the gaming industry will remain intact indefinitely.

The industry is facing several simultaneous risks:

Hardware exclusivity is becoming harder to enforce.
Digital distribution gives consumers less flexibility and control.
AAA development costs are increasing.
Hardware prices are increasing rather than decreasing.
Consumer purchasing power is under pressure.
Emulation and recompilation are becoming increasingly practical.
AI-assisted reverse engineering is reducing the cost of recreating software.

These are not isolated problems.

They reinforce one another.

If I were looking at gaming companies as an investor, I would be asking very difficult questions about their long-term valuations.

I would be particularly interested in understanding how much of their future profitability depends on consumers continuing to accept the traditional console ecosystem.

I wouldn't automatically short every gaming stock. That would ignore differences between individual companies, valuation, existing cash flows and the possibility that these threats take much longer to materialise than expected.

But I would certainly be questioning the assumption that the industry's historical economics are a reliable guide to its future.

Gaming isn't dying. The old gaming industry might be.

I want to finish by returning to the argument I made in my previous article.

Software is losing its scarcity.

AI is accelerating reverse engineering. Decompilation is becoming increasingly accessible. Native recompilation is making proprietary software portable. Emulation is becoming increasingly practical.

Halo running on platforms it was never designed for was an early demonstration.

Demon's Souls running at more than 60 FPS through PS5 emulation is another.

Ocarina of Time being turned into a native Windows application shortly after its Switch 2 release is another.

These are not necessarily isolated curiosities.

They are evidence of a broader technological shift.

The gaming industry has spent decades building business models around the assumption that controlling hardware means controlling software distribution.

That assumption is becoming increasingly difficult to defend.

And the industry is making things worse for itself by increasing prices, restricting consumer choice and doubling down on proprietary ecosystems.

Consumers will continue playing games.

They will continue buying great games, supporting developers and spending money on experiences they value.

But they may become increasingly unwilling to pay the premium demanded by traditional platform holders.

The future could look very different.

PCs become the universal gaming platform. Consoles become optional devices rather than mandatory gateways. Games become increasingly portable. Communities preserve and extend software long after publishers abandon it. Developers monetise convenience, services, communities and continuous experiences rather than relying exclusively on controlling the execution environment.

There will still be successful gaming companies.

There will still be great games.

But the economics of spending hundreds of millions developing a game, locking it to a proprietary platform and expecting consumers to purchase expensive hardware to access it may become increasingly difficult to justify.

The console wars might not end because one manufacturer finally defeats the others.

They might end because consumers simply stop needing the consoles.

And if that happens, the biggest losers won't necessarily be the companies that make the worst games.

They will be the companies that fail to understand that controlling where software runs is no longer the same thing as controlling the software itself.

Buckle Up: Is the U.S.S. Enterprise About to Take Off?

Remo H. Jansen — Thu, 12 Nov 2026 02:14:51 +0000

Buckle Up: Is the U.S.S. Enterprise About to Take Off?

I recently came across a post by the AI Futures Project with a rather unsettling title: Q3.5 Timelines Update: Looks Like the Intelligence Explosion Will Happen in 2027 After All.

The basic idea is that we could be much closer than previously expected to AI systems capable of doing AI research better than the best human researchers. And, if that happens, those systems could help build even more capable AI, potentially accelerating the whole process.

I honestly don't know how to feel about this.

I've always been a fan of science fiction. I've loved imagining different versions of the future, whether it's the terrifying world of Terminator 2, the mind-bending reality of The Matrix, or the optimistic, technology-driven universe of Star Trek.

But one particular science-fiction story has stayed with me more than any other: Isaac Asimov's short story The Last Question.

It's a fascinating story that follows humanity and increasingly advanced computers across an almost unimaginable stretch of time. Throughout the story, humans repeatedly ask a computer whether the universe's entropy can ever be reversed. Each time, the computer becomes more sophisticated, but its answer remains the same: there isn't enough information to answer the question yet. Eventually, the story reaches a conclusion that is difficult to forget.

What struck me about the story wasn't simply the idea of an incredibly powerful computer. It was the scale of what intelligence might eventually become, and how far beyond our current understanding it could take us. It made me think about a future in which technological progress reaches a point where we can no longer meaningfully predict what comes next.

That's closely related to an idea known as the technological singularity.

The term is borrowed from physics, where a singularity describes a point at which our existing theories can no longer adequately explain what is happening. In technology, it's used as a metaphor for a hypothetical point when progress becomes so rapid, and its consequences so profound, that our ability to predict what comes next breaks down.

But how could we get there?

One proposed path is something known as an intelligence explosion.

Imagine AI becoming capable enough to meaningfully contribute to developing the next generation of AI. That next generation would be even better at research and engineering, allowing it to build an even more capable generation after that. Each improvement could make the next improvement happen faster.

In theory, this creates a feedback loop: AI helps improve AI, which makes AI even better at improving itself. If this process becomes sufficiently powerful, the pace of technological progress could accelerate dramatically.

This is the intelligence explosion: a hypothetical period of extremely rapid growth in machine intelligence.

And if that growth becomes powerful enough to fundamentally transform the pace and direction of technological development, it could lead to what we call the technological singularity.

In other words, the intelligence explosion is a possible route to the singularity. The singularity is the hypothetical point beyond which our ability to predict technological progress breaks down.

It's an extraordinary possibility. And it's also difficult to get our heads around.

Why is exponential growth so difficult to understand?

Part of the problem is that exponential growth is not something humans are naturally good at understanding.

We're pretty good at imagining one thing getting a little bigger, then a little bigger again. We're much worse at imagining something doubling over and over. The numbers look small at first, then suddenly become ridiculous.

Perhaps that's because most of the things we encounter in everyday life don't behave this way. A tree grows gradually. A house gets built one brick at a time. Our salaries, savings and everyday experiences tend to change in ways that feel relatively linear. We rarely encounter something that appears almost insignificant at first and then grows to an unimaginable size in a surprisingly short period.

But exponential growth can do exactly that.

There's a famous legend that makes this easy to picture.

A king offers a reward to the person who invents chess. The inventor asks for one grain of rice on the first square of the chessboard, two on the second, four on the third, and so on—doubling the amount on every square.

The king thinks this sounds like a modest request. It isn't.

A chessboard has 64 squares, so the total is:

1 + 2 + 4 + 8 + ... + 2^63 = 2^64 - 1

That's 18,446,744,073,709,551,615 grains of rice. Around 18 quintillion.

Suppose, very roughly, that each grain weighs 25 milligrams. The total would weigh about 461 billion metric tonnes. That's roughly 1.3 million Empire State Buildings' worth of rice, using a rough building-weight estimate of 365,000 metric tonnes.

The first few squares barely matter. Almost all the rice is on the last few.

That's the part of exponential growth our intuition misses: the ending can be so much bigger than the beginning that it's hard to believe they belong to the same process.

And this is why discussions about an AI intelligence explosion are so difficult to evaluate intuitively. If AI development starts feeding into its own improvement, we might be looking at a process whose consequences are much harder to imagine than the technologies we're used to seeing develop around us.

A different way to think about the future

There's another way to appreciate just how extraordinary this could become.

In its recent assessment of Anthropic's AI research and development, METR identified a striking change in the rate of progress. Its analysis of benchmark trends found that the more recent trend had approximately 1.9 times the slope of the earlier one.

Now, let's take that 1.9 figure and consider a hypothetical scenario.

Imagine that the rate of technological progress increases by a factor of 1.9 every year, and that this acceleration compounds.

After ten years, we get:

1.9^10 ≈ 613

In other words, the rate of progress in year ten would be approximately 613 times what it was at the beginning.

Think about what that means. One year of progress at that future rate could potentially deliver as much advancement as 613 years at today's starting rate.

Of course, this is a mathematical thought experiment, not a prediction. METR's 1.9 figure describes the relative slope of a particular benchmark trend, not a claim that all technological progress will compound by 1.9 every year. Progress doesn't necessarily accelerate at a constant rate, and technological breakthroughs don't translate neatly into units of time.

But the exercise gives us a sense of the scale we're talking about.

Now, consider how much the world has already changed.

Much of what we consider modern technology today has emerged during the roughly 250 years since the Industrial Revolution. Electricity, telecommunications, aviation, computers, the internet and now artificial intelligence have transformed almost every aspect of human life.

My own grandmother grew up in a remote area of Spain where electricity wasn't even available.

Think about that for a moment.

Within a single human lifetime, we've gone from a world where some people lived without electric lighting to one where we can interact with increasingly capable AI agents that can reason, write code, conduct research and perform tasks on our behalf.

My grandmother has witnessed a transformation that would have seemed like science fiction to the world she was born into.

And if humanity achieved so much in roughly a century, what could the next few decades bring if the pace of progress continues to accelerate?

What happens if the next ten years deliver hundreds of times the technological progress we currently experience in a year?

Perhaps the most difficult thing isn't imagining what AI might become. It's recognising that our own experience of technological change may be a very poor guide to what's coming next.

Buckle up indeed.

So, is AI about to do the same thing?

Some people think AI could help accelerate the development of even better AI—and that this feedback loop might produce an intelligence explosion as soon as 2027.

That sounds like a lot. But it helps to be precise about what the claim actually is.

The recent AI Futures Project timelines update forecasts that Superhuman AI Researcher (SAR) could arrive sometime in 2027, assuming there isn't a substantial slowdown in AI development.

What exactly does that mean?

The authors describe a Superhuman AI Researcher as roughly the point at which an AI system could perform the research work of the best human researchers at an advanced AI company, while also being able to automate its coding. In other words, a company could potentially prefer an entirely AI-based research team to even its best human-only research team.

That's a pretty extraordinary milestone.

There is some evidence behind the forecast. METR's recent assessment found that progress on certain well-specified AI tasks had accelerated substantially compared with an earlier period.

More specifically, its benchmark-trend analysis suggested that the recent rate of progress was approximately 1.9 times the earlier rate, although there is considerable uncertainty around the estimate.

This is particularly interesting because it suggests that AI isn't simply becoming more capable at helping us with everyday tasks. It may also be helping researchers build the next generation of AI systems more quickly.

However, there are important caveats.

METR's findings concern one company and particular kinds of tasks. Benchmark improvements don't necessarily translate directly into equivalent improvements in real-world research capabilities. The report also acknowledges significant uncertainty, and some of the evidence most relevant to its conclusions was redacted by Anthropic.

Turning those findings into a forecast for when AI could outperform top human researchers requires additional assumptions and modelling.

In fact, the AI Futures Project's different forecasting approaches don't all land on exactly the same date. Some point to late 2027 or even 2028; others give earlier estimates.

The authors themselves acknowledge that their modelling is preliminary and that their forecasts depend on AI development not slowing down substantially.

So I'd describe 2027 as a plausible, evidence-informed scenario—not a date we know is coming.

And what could this mean for our future?

Something I've increasingly noticed is how normal it is becoming to hear incredibly wild predictions about AI.

We're talking about machines that could outperform the best human researchers, technological progress accelerating beyond anything we've experienced before, robots potentially transforming the economy, and a future where traditional ideas about work, money and retirement might no longer make sense.

Elon Musk, for example, has made some extraordinary predictions about AI and robotics creating a world of abundance, where goods and services become so cheap that everyone could enjoy a very high standard of living. He's even suggested that retirement savings might become largely irrelevant.

The underlying argument is that if AI and robotics make production extraordinarily cheap and efficient, we could eventually reach a world where many of the economic constraints we take for granted today no longer apply.

Imagine robots building houses, growing food, producing goods and providing services, while increasingly capable AI systems handle much of the intellectual work.

In theory, the cost of producing many things could fall dramatically.

But there's a rather large assumption hidden in this vision: that the benefits of all this productivity would be distributed widely across society.

Technology alone doesn't guarantee economic equality. Even if we develop machines capable of producing extraordinary amounts of wealth, we still have to decide who owns those machines, who benefits from their productivity and how society adapts.

For an example of the kind of claims Musk has made, see this report on his AI-abundance predictions.

But this brings me back to something I've been wondering about.

Are we actually approaching something extraordinary, or are we just getting caught up in the hype?

Are these people genuinely convinced that we're approaching the technological singularity? Or is some of this simply hype, driven by companies, investors and people trying to capture our attention?

I sometimes wonder whether we're becoming so accustomed to dramatic headlines that we've developed a kind of mental filter. We read that AI could outperform the best human researchers by 2027, or that robots could fundamentally change the economy, and our first instinct is to dismiss it as another exaggerated prediction.

Perhaps that's because the implications are so enormous that we don't really know how to process them. It's easier to assume it's nonsense than to seriously consider that some of these things might actually happen.

And that's what I find particularly fascinating, but also a little unsettling.

There is genuine evidence that AI is accelerating parts of AI research and development. There are also serious researchers trying to understand what happens if that acceleration continues. But there is a huge difference between observing faster progress today and knowing exactly where it will lead tomorrow.

We don't know whether the intelligence explosion will happen in 2027, in 2030, or at all. We don't know whether the technology will hit significant bottlenecks, whether progress will slow down, or whether some of the more extraordinary predictions will turn out to be wildly optimistic.

The chessboard story teaches us why exponential growth can surprise us. The compounding thought experiment gives us a glimpse of how extraordinary the numbers could become. But neither tells us that AI progress will keep accelerating indefinitely.

Personally, I find worrying endlessly about these possibilities rather stressful. There are enough things to worry about in the present without spending every day wondering whether we're approaching an event that could fundamentally change civilisation.

So I'd rather remain optimistic.

When I think about the future of AI, I'd much rather imagine a Star Trek-like future than a Terminator one. A world where technology helps us solve problems, explore the universe, improve medicine, eliminate scarcity and spend more time doing the things that make life worthwhile.

Maybe that's wishful thinking. There are plenty of reasons to be cautious, and we shouldn't ignore the risks or assume that technological progress automatically makes the world a better place.

But perhaps that's also the exciting part. We don't know exactly what comes next.

The U.S.S. Enterprise isn't about to lift off, and science fiction isn't about to become reality all at once. But maybe, just maybe, we're getting closer to a future where some of the things that once seemed impossible start becoming ordinary.

And I'd quite like to be around to see that.

So, buckle up. It could be a wild ride.

AI Agents Have a Human Problem

Remo H. Jansen — Fri, 06 Nov 2026 10:01:15 +0000

We are entering a new era of software development. AI agents can write code, refactor existing systems, investigate bugs, implement features and perform tasks that previously required human developers.

This has led to some interesting questions about the future of software engineering.

Do we still need abstractions if AI can work directly with low-level implementations? Do we still need documentation if agents can read the source code? Do we still need to care about developer experience if developers are no longer the only ones writing code?

I think we're asking some of the wrong questions.

One of the assumptions behind these discussions is that AI agents are fundamentally different from human developers, and therefore the engineering principles we've developed over decades might no longer apply.

But there's an important distinction worth making.

AI agents are not limited in the same ways humans are. They already have considerably more reasoning bandwidth in certain dimensions. They can process more information, explore more of a codebase and handle levels of complexity that would be difficult for an individual developer.

But they aren't unlimited.

And that's the interesting part.

Many of the engineering principles we've developed to manage complexity remain relevant, not because agents have human-like limitations, but because even greater reasoning capacity benefits from structure.

The problem isn't that agents are just like us. It's that we're still building systems that can become too complex to reason about efficiently.

We didn't invent abstractions just for humans

Consider why we introduced abstractions in software engineering in the first place.

We moved from machine code to assembly, from assembly to higher-level programming languages, and from low-level instructions to increasingly sophisticated abstractions.

We introduced modules, interfaces, encapsulation, libraries, frameworks and architectural patterns.

These developments weren't arbitrary. They helped us manage complexity.

A developer working on a large system cannot keep every implementation detail in their head. They need ways to reason about parts of the system without understanding everything happening underneath.

Abstractions make this possible.

They allow us to focus on what something does rather than constantly having to understand how it works.

This is one of the arguments I made in my previous article, Will AI Make Abstractions Obsolete?.

The argument was that AI doesn't make abstractions obsolete. The need to manage complexity doesn't disappear simply because we have a different way of producing code.

But there's another reason why abstractions matter.

They aren't exclusively useful to humans.

They are useful to anything that needs to reason about complex systems.

And that includes AI agents.

Agents have more bandwidth, but not unlimited capacity

Human developers have limited working memory. When working on an unfamiliar codebase, we need to spend time understanding its structure, identifying relevant components, discovering conventions and building a mental model of how everything fits together.

AI agents have considerably more bandwidth for this kind of work.

An agent can inspect many files, trace dependencies across modules, compare implementations and maintain relationships between parts of a system that would be difficult for an individual developer to keep in working memory.

In some dimensions, AI can already operate beyond human cognitive limits.

But this doesn't mean it can handle complexity without constraints.

Models have finite context windows and computational resources. As the number of components, dependencies and interactions grows, the amount of information that needs to be considered grows too. Maintaining an accurate understanding of an increasingly complex system becomes progressively more demanding.

The important distinction is that AI raises the ceiling. It doesn't remove it.

Consider an unfamiliar codebase with duplicated functionality, inconsistent naming conventions, implicit dependencies and unclear architectural boundaries.

A human developer might struggle to understand the system because they cannot comfortably keep all the relevant information in working memory.

An AI agent might be able to explore considerably more of the codebase in a single task. But it still has to discover where functionality lives, reconstruct dependencies, infer conventions and determine which information is relevant.

An important difference is that agents can often compensate for complexity by exploring more information. A human developer might need to simplify a problem to fit it into working memory. An agent might instead inspect more files, follow more dependencies and spend more reasoning resources reconstructing the system.

These are different strategies, but neither makes complexity free.

The problem isn't necessarily that the agent cannot understand the code. It's that the codebase makes understanding unnecessarily expensive.

This is where familiar software engineering practices become valuable again.

Good naming reduces ambiguity. Modular architecture limits the amount of code that needs to be considered. Clear interfaces communicate expectations. Documentation provides context that might otherwise need to be inferred. Tests provide feedback about whether an implementation is correct.

These practices don't compensate for an AI's inability to reason like a human. They reduce the amount of unnecessary complexity that any problem solver needs to deal with.

And as agents become more capable, the value of these practices becomes even more apparent.

Technical debt now has a token cost

There is an interesting development that makes this argument particularly tangible.

We can start measuring some of the consequences of poor code quality in terms of AI token consumption.

An agent working on a messy codebase often needs more tokens to understand the system before it can implement a change.

This isn't just about generating more code. A significant amount of an agent's work involves reading, exploring, reasoning and gathering context.

Some recent experiments have started investigating this relationship.

For example, SonarSource published research comparing coding-agent performance across cleaner and messier codebases. Their results showed that cleaner codebases reduced token consumption, reasoning effort and the number of files agents needed to revisit.

Other experiments have reported substantial reductions in token consumption after restructuring large, difficult-to-navigate source files into smaller, more cohesive modules.

The implications are interesting.

Historically, we've justified refactoring by explaining that it makes code easier for developers to understand and maintain.

Now we have another way to think about its value.

Technical debt has a token cost.

A poorly structured codebase doesn't just make humans slower. It can make agents more expensive to operate.

Every unnecessary dependency, duplicated implementation, unclear abstraction or implicit convention creates additional work for something trying to understand the system.

Refactoring can therefore become an investment in reducing the marginal cost of future development tasks.

You spend resources improving the structure of the codebase today, potentially saving tokens, time and money across hundreds of future agent interactions.

Of course, fewer tokens don't automatically mean better results. An agent still needs sufficient context to make correct decisions. The objective isn't to minimize context at all costs, but to eliminate unnecessary complexity and exploration.

We should also distinguish between token consumption, execution time and correctness. Reducing the amount of context an agent needs doesn't necessarily mean it will produce better results. The real objective is to make it more efficient without compromising the quality of its decisions.

Nevertheless, the direction is clear: code quality has consequences beyond human productivity.

AI amplifies the gap

This brings me to an idea I explored in my SIC2026 talk: AI amplifies the gap.

The point is that many of the things we discuss in developer experience have always been true.

A good development environment makes developers more productive. Clear architecture makes systems easier to understand. Consistent conventions reduce friction. Good documentation makes it easier to work with unfamiliar systems.

AI doesn't invalidate these principles.

It amplifies them.

Consider two development environments.

The first has clear architectural boundaries, predictable conventions, useful documentation, explicit interfaces and automated tests.

The second has inconsistent patterns, outdated documentation, unclear dependencies, duplicated logic and poor test coverage.

A human developer will probably be more productive in the first environment.

An AI agent will probably be more productive there too. But there's an additional dimension.

Agents can operate at considerable speed and scale. They can explore many files, implement multiple changes and execute numerous tasks in parallel.

They have considerably more bandwidth than an individual developer, which allows them to take advantage of good engineering environments at a different scale.

When the environment is good, this gives them leverage.

When the environment is bad, they have to spend more resources reconstructing the system, resolving ambiguity and validating their assumptions. Their ability to operate at scale can also give mistakes more opportunities to propagate.

AI amplifies the quality of the environment in which it operates.

This is the DX paradox: precisely when AI makes implementation cheaper, the quality of the engineering environment becomes even more important.

The cost of producing code is decreasing, but the cost of understanding, coordinating, validating and maintaining complex systems hasn't disappeared.

In fact, it might become more consequential.

We should rethink what good developer experience means

For a long time, developer experience has primarily been discussed from the perspective of human developers.

We optimize build times, improve documentation, simplify tooling, introduce conventions and create abstractions to make development easier.

But perhaps we should stop thinking about these practices as exclusively human-oriented.

They are ways of making complex systems easier to understand, navigate and change.

That means the audience for good developer experience is expanding.

We should increasingly consider how easy it is for an agent to understand our architecture, discover the right implementation, identify the constraints of a task and verify its work.

This doesn't necessarily mean creating entirely separate engineering practices for agents.

Many of the things we already do are useful.

Good modularity, explicit interfaces, consistent conventions, automated tests, clear documentation and well-designed abstractions remain valuable.

Some practices will evolve, and new ones will emerge. We might need better ways to communicate agent permissions, task boundaries, operational constraints and verification requirements.

But the underlying principles are familiar.

We should also resist the temptation to blindly preserve every historical practice simply because it has worked for humans. Some practices may become less relevant, while others may need to be redesigned around agent capabilities.

The important thing is to understand why these practices exist in the first place.

The future isn't about writing less code. It's about managing complexity.

AI agents are changing how software is produced, but they haven't fundamentally changed the nature of the problems we're trying to solve.

Building complex software is still difficult.

Understanding unfamiliar systems is still difficult.

Coordinating changes across large codebases is still difficult.

Making sure that changes are correct is still difficult.

These problems didn't emerge because humans write code. They emerged because software systems are complex.

AI is already capable of handling levels of complexity that would be difficult for individual developers. It has more reasoning bandwidth, can explore more relationships and can operate at a scale that would have been impractical before.

But greater intelligence doesn't make complexity disappear. It allows us to work with more of it.

And as the systems we build become increasingly sophisticated, the demands on that reasoning capacity will increase too.

We developed abstractions, architectural boundaries, documentation, conventions and engineering practices to help us manage complexity.

These principles remain relevant, not because AI has the same cognitive limitations as humans, but because even significantly greater reasoning capacity benefits from structure.

Perhaps we've been too quick to assume that the future of software engineering must be radically different simply because AI is involved.

We should certainly adapt. We should experiment. We should challenge assumptions that no longer make sense.

But we shouldn't throw away decades of engineering knowledge without understanding the problems that knowledge was designed to solve.

We didn't invent good software engineering practices because humans are bad at programming. We invented them because building complex software is difficult.

And AI hasn't changed that.

Will AI Make Abstractions Obsolete?

Remo H. Jansen — Thu, 05 Nov 2026 22:54:44 +0000

As AI agents become increasingly capable, I've noticed a growing number of discussions questioning some of the fundamental assumptions we've made about software development.

Do we still need code reviews if AI can write and verify code? Why should we use languages like Python or Java when an AI can generate much more efficient Rust? And if AI becomes good enough, why stop at Rust? Why not have it generate assembly or machine code directly? Do we even need frameworks and libraries anymore?

The underlying assumption seems to be that many of the abstractions we've introduced over the years exist primarily to compensate for human limitations. If AI doesn't have those limitations, perhaps we can remove the abstractions too.

I think this is looking at the problem from the wrong perspective.

My intuition is that the more capable AI becomes, the more important abstractions will become. Not less.

To explain why, I think we need to revisit something fundamental about software engineering: complexity.

Complicated is not the same as complex

We often use the words complicated and complex interchangeably, but I think there's a useful distinction between them.

Something complicated has many parts, but those parts can generally be understood independently. Once you've figured out how the individual pieces work, understanding the whole becomes relatively straightforward.

Something complex is different. It involves many elements and, more importantly, many relationships between those elements. Understanding each individual component doesn't necessarily help you understand the system as a whole. The interactions themselves create additional complexity.

Consider a complicated algorithm. It might have hundreds of steps, but each step is well-defined. Once you understand the algorithm, you can reason about its behaviour.

Now consider a distributed system. Its individual components might be relatively simple, but their interactions introduce timing issues, race conditions, partial failures, consistency problems and emergent behaviour.

The difficulty isn't necessarily understanding any particular component. It's understanding how everything interacts.

As the number of elements and relationships grows, the complexity grows too.

This distinction matters because I believe AI is already superhuman in certain dimensions of complexity management.

An LLM can reason across more files, functions, dependencies and relationships than a human developer can comfortably keep in working memory. It can inspect an entire module, trace dependencies, compare implementations and identify relationships that would take a human considerably longer to discover.

But that doesn't mean AI has unlimited capacity.

Models have finite context windows, finite computational resources and limitations in how effectively they can maintain and reason about large amounts of interconnected information.

AI raises the ceiling of complexity we can work with. It doesn't eliminate the ceiling.

And this brings me to the actual purpose of abstractions.

The purpose of abstractions is managing complexity

In his famous essay No Silver Bullet, Fred Brooks makes a distinction between essential and accidental complexity.

Essential complexity is inherent to the problem we're trying to solve. If you're building a banking system, handling transactions, ensuring consistency, enforcing security and implementing business rules are inherently part of the problem.

Accidental complexity, on the other hand, is introduced by the tools, technologies and implementation details we use to solve it.

For example, when building a web application, the essential complexity might involve:

Business rules.
User interactions.
Data relationships.
Security requirements.
Consistency guarantees.

The accidental complexity might involve:

HTTP request parsing.
Connection pooling.
Serialization.
Memory allocation.
Database driver configuration.
Low-level concurrency management.

Of course, the distinction isn't always black and white. Some implementation details become essential depending on the requirements. But the distinction is useful.

Over the years, we've introduced layers of abstraction to hide away accidental complexity so we can focus on the problem at hand.

We don't use React because developers are incapable of manipulating the DOM. We use it because manually managing DOM updates is usually an unnecessary distraction from the problem we're trying to solve.

We don't use SQL because developers cannot implement database storage engines. We use it because we want to express what data we need rather than describe every operation required to retrieve it.

We don't use high-level programming languages because developers cannot write assembly. We use them because assembly is usually the wrong level of abstraction for expressing our intentions.

Abstractions aren't just about making programming easier. They're about reducing the amount of irrelevant complexity that a problem solver needs to deal with at once.

And that problem solver doesn't necessarily have to be human.

But AI doesn't think like humans, does it?

This is probably the most interesting part of the discussion.

One argument against my position is that programming languages and frameworks were designed primarily for humans. If AI is doing the programming, why should it care about human-friendly abstractions?

Why not let it work directly with machine code?

I think this argument overlooks something important about how LLMs came to be.

LLMs aren't traditional computers that happen to understand human language. Their capabilities emerged from training on enormous amounts of human-generated content: books, documentation, source code, academic papers, discussions and countless examples of humans explaining and solving problems.

They've learned from the way humans represent knowledge, decompose problems, communicate ideas and reason about relationships.

This doesn't mean LLMs reason exactly like humans. Their architecture is fundamentally different, and they can develop capabilities that go beyond human reasoning.

But their learned understanding of the world, including software, is deeply influenced by how humans have organised and communicated knowledge.

Think about the concepts we use every day in software development:

Functions.
Types.
Modules.
Interfaces.
Ownership.
Components.
Dependencies.
Composition.

These aren't merely convenient syntactic constructs. They provide conceptual building blocks that help us express problems and solutions.

LLMs have been exposed to enormous amounts of knowledge expressed through these abstractions. They've learned not only their syntax but also the conventions, idioms and relationships surrounding them.

Why would we assume that moving closer to machine code would make them better at solving problems?

Being able to generate assembly doesn't mean assembly is a better representation for reasoning about a business domain, a distributed system or an application architecture.

In fact, higher-level abstractions might be particularly valuable to LLMs precisely because they provide semantic structure that aligns with much of the knowledge they've learned.

I wouldn't claim that AI cannot develop representations that are fundamentally different from human ones. It certainly might.

But we shouldn't confuse an AI's ability to operate at a lower level with a reason to force it to do so.

The lowest-level representation isn't necessarily the best representation for solving a problem.

AI can handle more complexity. Why make it handle unnecessary complexity?

Let's consider a practical example.

Imagine asking an AI agent to build a web application.

If we ask it to implement a feature using an existing framework, it gets to benefit from routing, request lifecycle management, state management, component composition and established conventions.

The agent can focus on implementing the feature.

Now imagine asking it to implement everything from scratch, including HTTP handling, memory management, concurrency primitives and serialization.

Yes, it can do that.

But now it has to reason about significantly more things, maintain more relationships and make more decisions.

Some of those decisions have absolutely nothing to do with the problem we're trying to solve.

Even if AI can handle all those details, why would we want it to?

This is the key point: the value of an abstraction isn't that the underlying complexity is impossible to manage. It's that managing it is unnecessary for the task at hand.

There's another benefit worth mentioning: abstractions constrain the solution space.

A framework provides conventions. A type system rules out certain classes of invalid programs. A programming language provides a vocabulary and a set of compositional rules.

These constraints aren't necessarily limitations. They're often what make it possible to build reliable systems without having to reconsider every possible implementation decision.

Good abstractions allow us to focus on the decisions that actually matter.

And this applies to AI agents just as much as it applies to humans.

But what about Rust?

One of the interesting developments I've noticed is that languages like Rust are becoming more attractive as AI takes on more of the implementation work.

Rust has traditionally had a steeper learning curve than languages with garbage collection. Its ownership model, borrowing rules and lifetime system introduce cognitive overhead that can be challenging for developers.

But what happens when an AI agent can deal with much of that overhead?

Suddenly, using Rust becomes more appealing. The AI can handle the compiler feedback, work through ownership constraints and iterate until the code compiles.

This is a great example of AI changing the economics of software development.

But I think there's a distinction worth making here.

Rust isn't a low-level language simply because it doesn't have a garbage collector. It provides powerful abstractions over memory management, ownership and concurrency.

The ownership system is itself an abstraction. It allows us to express constraints about memory safety in a way that the compiler can enforce.

AI makes it cheaper to work with Rust, but that doesn't mean we should abandon the abstractions Rust provides.

If anything, it demonstrates how AI can make more sophisticated abstractions accessible.

The same principle could apply to other languages, type systems and programming paradigms.

We might increasingly choose technologies that were previously avoided because their cognitive overhead was too high.

But that's very different from saying we no longer need abstractions.

Abstractions aren't free, though

I don't think this means we should introduce more abstraction layers indiscriminately.

Abstractions have costs. They can introduce indirection, hide important implementation details, make debugging harder and impose constraints that don't fit the problem.

A bad abstraction can increase complexity rather than reduce it.

Anthropic makes a similar observation in its article Building Effective Agents. It recommends starting with simple, composable patterns rather than introducing complex agent frameworks unnecessarily. Frameworks can introduce additional layers that obscure what's happening underneath and make debugging harder.

That's a good example of the principle I'm arguing for.

The goal isn't to maximise the number of abstractions. It's to find the right abstractions at the right level.

Sometimes that means removing a layer. Sometimes it means introducing one.

The important question is whether an abstraction reduces the complexity of the problem we're trying to solve.

And as AI becomes more capable, the answer to that question might change. Some abstractions that were useful primarily for humans might become unnecessary, while entirely new abstractions might emerge to help AI agents work with increasingly sophisticated systems.

The abstractions will evolve. The need for them won't disappear.

Code reviews might change, but software still needs to be understood

I think the same reasoning applies to another discussion we're having right now: the future of code reviews.

If AI can write code, generate tests, run them, inspect the implementation and iterate until everything passes, why do we need code reviews?

I suspect the answer is that we'll spend less time reviewing implementation details and more time reviewing the actual design and behaviour of the system.

We'll ask different questions:

Are we solving the right problem?
Are the architectural decisions sound?
Are the system boundaries appropriate?
Are the important invariants preserved?
Are we introducing unnecessary complexity?
Does the implementation satisfy the intended behaviour?

Passing tests isn't necessarily the same as understanding whether a system is correct.

An AI can generate code that satisfies the tests while violating an architectural invariant or introducing a problem that the tests don't cover.

The responsibility of reviewing software might move up a level, just as the responsibility of writing it is moving up a level.

We might spend less time inspecting individual lines and more time evaluating the conceptual structures those lines implement.

Again, abstraction doesn't disappear. The level at which we operate changes.

The future isn't less abstraction. It's more powerful abstraction.

I think there's a misconception that as AI becomes smarter, we'll need fewer abstractions.

I suspect the opposite is true.

As our ability to solve problems increases, we'll start tackling problems that were previously beyond our reach.

And those problems will introduce new layers of complexity.

Imagine a future where AI agents can autonomously build entire distributed systems, coordinate with other agents, manage infrastructure and maintain applications over years.

Will they need fewer abstractions because they're smarter?

Or will they need better abstractions because the systems they're building are increasingly sophisticated?

I suspect the latter.

We might move from managing individual servers to managing distributed systems, from managing individual applications to managing ecosystems of autonomous agents.

The complexity doesn't disappear. It moves.

We'll continue inventing higher-level abstractions to manage it. Some might be designed specifically for AI agents rather than humans. Some might be more declarative, more composable or more mathematically rigorous.

We might even end up with entirely new programming paradigms that we haven't imagined yet.

But the fundamental need for abstraction isn't going away.

We didn't invent high-level programming languages because writing assembly was too difficult. We invented them because we wanted to express our intentions without having to deal with every implementation detail.

That motivation doesn't disappear just because the programmer happens to be an AI.

Intelligence doesn't eliminate the need for abstraction. Abstraction is one of the mechanisms that makes intelligence scalable.

Your Documentation Is Out of Date. Let an AI Agent Keep It in Sync

Remo H. Jansen — Wed, 04 Nov 2026 22:06:10 +0000

We've all been there.

You join a new team, open the repository, and find a beautifully written README.md, an architecture document, and a collection of Markdown files explaining how everything works.

You start reading.

A few minutes later, you notice that the architecture diagram doesn't match the actual implementation. The documentation references tools that no longer exist. Some configuration options have changed, and a few important components are missing entirely.

The documentation is there, but can you trust it?

This is one of the most common problems in software engineering: documentation slowly drifts away from the source code.

And it's not because developers don't understand the importance of documentation. It's because maintaining it is a continuous task, and it's very easy to forget.

But what if we could delegate this responsibility to an AI agent?

The source code is the source of truth

Let's start with one simple principle:

The source code is always the source of truth.

Documentation is a human-friendly representation of how the system works. It helps developers understand the architecture, discover available tools, learn conventions, and onboard new team members.

But documentation should never override the implementation.

Whenever the implementation changes, the relevant documentation should be reviewed and updated if necessary.

The problem is knowing when documentation needs attention.

Here's a simple trick.

Add a Git commit reference to your Markdown files

What if every technical Markdown document included metadata describing the last commit against which it was reviewed?

For example:

---
commit: '9b6f166af5227ff4093af7347084d8f7d2a81e4f'
updated: '2026-11-04'
---

That's it.

Two simple pieces of information:

commit: The Git commit against which the document was last reviewed and synchronized.
updated: The date the document was last reviewed.

This small addition gives us something very useful: a reference point.

When someone opens a Markdown document, they can immediately see when it was last reviewed and how far behind the codebase that review was.

More importantly, an AI agent can use that commit as a starting point for reviewing the document.

For example, if the document references commit 9b6f166, the agent can inspect everything that has changed since that commit and determine whether any of those changes affect the documentation.

We now have a simple, explicit relationship between our documentation and the source code.

Introducing the `sync-docs` skill

Imagine having an agent skill called sync-docs.

Its responsibility is straightforward:

Make sure technical documentation accurately reflects the current state of the codebase.

The workflow could look something like this:

Find Markdown documents containing the synchronization metadata.
Read the commit recorded in each document's frontmatter.
Compare that commit with the current HEAD.
Review the changes introduced since that commit.
Identify which changes affect the document.
Inspect the current implementation to verify its accuracy.
Update the documentation to reflect the current implementation.
Update the commit and updated metadata.
Open a pull request containing the documentation changes.

For example, the agent might discover that since the last documentation review:

A new service was introduced.
An existing API changed.
A configuration option was removed.
A new development tool was added.
The architecture was refactored.
A dependency was replaced.

It can then inspect the relevant source files and update the documentation accordingly.

Notice something important: the agent isn't simply summarizing the latest Git changes and appending them to a document.

It needs to understand the existing documentation, inspect the current implementation, and determine whether the document still accurately describes the system.

The goal is accuracy, not just activity.

What would the implementation look like?

Let's make this concrete.

We need two things:

An agent skill that knows how to synchronize documentation.
A GitHub Agentic Workflow that periodically invokes that skill and opens a pull request.

The important distinction is that the skill owns the logic. The workflow simply orchestrates it.

1. Implementing the `sync-docs` skill

Let's create the following structure:

.agents/
  skills/
    sync-docs/
      SKILL.md

The SKILL.md file contains the actual instructions the agent must follow.

Here is an example implementation:

.agents/skills/sync-docs/SKILL.md

---
name: sync-docs
description: Review and synchronize Markdown
  documentation against the current source code.
---

# Sync Documentation

Your responsibility is to ensure that technical
documentation accurately reflects the current
implementation in the repository.

The source code is always the source of truth.

## 1. Discover documentation

Find all Markdown files containing the following
frontmatter fields:

- commit
- updated

These fields identify the last source-code commit
against which the document was reviewed.

Ignore files without this metadata.

## 2. Review each document

For every document:

1. Read its recorded commit.
2. Verify that the commit exists in the repository.
3. Identify the source files relevant to the
   document.
4. Inspect changes introduced since the recorded
   commit:

   git diff <recorded-commit>..HEAD

5. Inspect the current implementation of the
   affected components.
6. Determine whether the documentation still
   accurately describes the implementation.

Do not assume that every code change requires
a documentation change.

## 3. Update documentation

When documentation is outdated:

- Update incorrect descriptions.
- Add missing architectural information.
- Remove references to obsolete tools,
  components or configuration.
- Update examples that no longer match
  the implementation.
- Preserve useful explanations and the
  existing writing style.

Never invent implementation details.

Never modify application source code.

## 4. Update synchronization metadata

After successfully reviewing a document,
update its frontmatter:

commit: <current HEAD commit>
updated: <current date>

The commit must represent the exact source-code
revision that was reviewed.

If the review cannot be completed confidently,
do not advance the metadata.

If the document is already accurate, its content
does not need to change, but its review metadata
should still be updated.

## 5. Report findings

At the end, provide a summary containing:

- Documents reviewed.
- Documents updated.
- Documents already accurate.
- Documents that could not be reviewed.
- Architectural inconsistencies discovered.
- Potential bugs or unexpected implementation
  changes worth investigating.

Do not fix application code or architectural
issues as part of this task.

Leave those findings for human review.

That's the entire skill.

The interesting thing is that it doesn't know anything about GitHub, pull requests, or scheduling. It only knows how to perform one job: keep documentation synchronized with the source code.

This makes it reusable. You can invoke it manually from your coding agent whenever you want:

Use the sync-docs skill to review and synchronize the technical documentation in this repository.

Or you can use it as part of a larger agent workflow.

2. Automating the skill with GitHub Agentic Workflows

Now let's automate it.

Create the following file:

.github/
  workflows/
    sync-docs.md

The workflow is intentionally simple. It doesn't contain any documentation synchronization instructions because those already live in our skill.

Its only responsibility is to invoke the skill and create a PR with the results.

.github/workflows/sync-docs.md

---
name: Sync Documentation

on: weekly on monday

permissions:
  contents: read
  pull-requests: read

safe-outputs:
  create-pull-request:
    title-prefix: "[docs-sync] "
    labels:
      - documentation
    allowed-files:
      - docs/**
      - README.md
---

# Synchronize Technical Documentation

Your task is to maintain the technical
documentation in this repository.

## Instructions

1. Read and follow the skill located at:

   `.agents/skills/sync-docs/SKILL.md`

2. Invoke the `sync-docs` skill and let it
   perform the complete documentation review.

3. Inspect the resulting changes and findings.

4. If documentation or synchronization
   metadata has changed, create a pull
   request containing:

   - The updated Markdown documents.
   - A summary of documents reviewed.
   - A summary of documentation changes.
   - Any architectural inconsistencies or
     potential issues discovered.

5. If there are no changes to propose,
   do not create an empty pull request.

## Important

Never merge pull requests automatically.

All documentation changes must be reviewed
and approved by a human.

Do not modify application source code.

The workflow uses a scheduled trigger, invokes our reusable skill, and creates a PR when there are changes to propose.

Notice how little logic the workflow contains. That's intentional.

We don't want to maintain two implementations of the same process.

The skill defines how documentation is synchronized. The workflow defines when it happens and what to do with the results.

GitHub Agentic Workflows can compile these Markdown workflow definitions into standard GitHub Actions workflow files using the gh aw CLI:

gh extension install github/gh-aw
gh aw compile

The compilation generates a .lock.yml workflow alongside the Markdown source. You commit both files to the repository.

You can choose a different schedule, such as every two weeks or once a month, depending on how quickly your codebase evolves.

For more information, see the GitHub Agentic Workflows documentation.

Note: The example assumes that the selected agent runtime supports the skill format and that the skill is available in its execution environment. The workflow must be configured to load and invoke it; simply referencing a file path does not automatically execute a skill.

3. What does a synchronization PR give us?

Imagine a PR created by the workflow:

Title: [docs-sync] Synchronize architecture and tooling documentation

It might contain:

Document	Result
`docs/architecture.md`	Updated service dependencies
`docs/development-tools.md`	Removed obsolete CLI reference
`docs/deployment.md`	Reviewed, no content changes needed
`docs/api.md`	Updated endpoint descriptions

The PR description could also highlight findings that deserve attention:

The architecture document describes a synchronous interaction, but the implementation now uses asynchronous messaging.
A configuration option exists in the code but is missing from the documentation.
An internal tool is still documented but appears to have been removed.

This is where things get particularly interesting.

The PR is no longer just a documentation update. It becomes another opportunity for the engineering team to inspect the system and discover things that might otherwise go unnoticed.

We are using AI to maintain documentation, but we're also using documentation reviews to improve the quality of the software itself.

Why use a commit instead of a timestamp?

A timestamp tells us when something happened.

A Git commit tells us exactly which version of the source code was reviewed.

This distinction is important.

Suppose a document was last reviewed two weeks ago. During those two weeks, the codebase might have changed significantly, or perhaps nothing relevant to that document changed at all.

With a commit reference, the agent can inspect the actual changes rather than guessing based on the document's age.

It also makes the process incremental.

The agent doesn't need to rediscover the entire history of the project every time it runs. It can start from the last reviewed commit and investigate what happened since then.

Of course, the commit reference is not a guarantee that the document is accurate. It's a record of the last successful review. The quality of that review still matters.

Why not merge the PR automatically?

There is one important detail here: the workflow should open pull requests, never merge documentation updates automatically.

Why?

Because reviewing these PRs is valuable in itself.

Imagine the agent updating an architecture document because it discovered that a service behaves differently from what the documentation describes.

During the review, a developer might realize that the implementation has drifted from the intended architecture.

Or perhaps the agent discovers an undocumented configuration change, an unexpected dependency, or a tool that is no longer being used.

These are useful signals.

A documentation synchronization PR can become an opportunity to spot architectural inconsistencies, accidental complexity, missing documentation, and even potential bugs.

The agent does the investigation and proposes the updates. Developers review the changes, challenge the findings, and decide whether to merge them.

This keeps humans in the loop while making the maintenance process much less painful.

A few things worth considering

There are some important details to get right when implementing this.

1. Only update the commit after a successful review

The commit in the frontmatter should represent the latest code version actually reviewed, not simply the latest HEAD.

If the agent fails to inspect a document or cannot confidently determine whether it is accurate, it shouldn't silently advance the commit reference.

2. Don't change documentation just for the sake of changing it

If the source code changes but the documentation remains accurate, there is no reason to modify the document's content.

The agent can still update its review metadata to record that the document has been checked against the newer commit.

3. Never merge automatically

Always open a pull request and let a developer review it.

Apart from preventing incorrect documentation updates from reaching the main branch, these reviews can expose problems that might otherwise go unnoticed.

4. Make the review scope explicit

Not every Markdown file needs to describe the entire codebase.

An architecture document might depend on changes across multiple services, while a tool reference might only depend on a particular directory.

The skill should use the document's content to determine which parts of the repository are relevant.

5. Handle invalid or unavailable commits gracefully

A document might reference a commit that is no longer available locally, or a commit that doesn't exist in the current repository history.

The agent shouldn't guess where to start. It should flag the document for human investigation rather than silently replacing its reference.

The bigger picture

I particularly like this idea because it changes how we think about documentation.

Today, documentation is often treated as something we write when we create a feature, launch a project, or onboard a new developer.

Then it slowly gets forgotten.

But documentation should be treated more like code: something that needs continuous maintenance.

We already have automated tests, linters, formatters, dependency updates, and security scans running against our repositories.

Why shouldn't documentation have its own maintenance workflow?

With a small piece of metadata, a reusable AI skill, and a scheduled GitHub workflow, we can make documentation maintenance a continuous process rather than an occasional cleanup exercise.

And there's an additional benefit: every synchronization PR gives the team another opportunity to inspect the system, question architectural decisions, and spot inconsistencies.

Your source code evolves. Your documentation should evolve with it.

And perhaps the best part is that the next developer joining your team won't have to wonder whether the architecture document they're reading is describing the system you actually have today.

They can see when it was last reviewed, what version of the code it was checked against, and trust that the team has a process for keeping it up to date.

The EU Should Make AI a Public Good If It Wants to Survive the Next Industrial Revolution

Remo H. Jansen — Wed, 28 Oct 2026 15:39:47 +0000

Today, I want to write about something a little outside my usual topics.

As a European citizen, I worry about the possibility that the United States will achieve artificial general intelligence (AGI) before Europe does. I don't see the US as an enemy. Quite the opposite. But I live in the EU, and I don't want Europe to end up on the losing side of what could be the most important technological transformation in human history.

I think we're at risk of making a fundamental mistake in how we approach AI.

We're treating it as another technology sector in which European companies need to compete with American companies.

But what if AI becomes much more than that?

What if it becomes a foundational technology that transforms almost every industry, reshapes labour markets, changes how governments operate, and determines which countries accumulate wealth and influence over the coming decades?

We have seen something similar before.

The Industrial Revolution transformed the world. Countries that industrialised early gained enormous economic and strategic advantages. Others struggled to catch up, and some remained economically dependent on industrial powers for generations.

The historical picture is more complicated than a simple division between winners and losers. Some countries industrialised later and eventually converged with the leaders. But the broader lesson remains: when a technology transforms the foundations of economic activity, falling behind can have consequences that last for generations.

I believe AI could be another such turning point.

And if that is true, Europe should consider approaching AI very differently.

Instead of trying to compete with American AI companies solely by creating more startups, what if the EU treated foundational AI as a public good?

AI isn't just another technology sector

We are approaching a future in which AI could become as essential to economic activity as electricity, computing and internet access.

Today, we pay for software subscriptions because they provide useful tools. Tomorrow, AI could be embedded in almost everything we do.

Developers will use AI to write and maintain software. Doctors will use it to analyse medical information. Lawyers will use it to research cases. Engineers will use it to design products. Scientists will use it to accelerate research. Businesses will use AI agents to automate entire workflows.

Governments will use AI to deliver public services. Manufacturers will use it to optimise production. Financial institutions will use it to analyse markets and manage risk.

And if AI systems eventually become capable of performing a large share of economically valuable cognitive work, the transformation could extend far beyond what we currently imagine.

Entire business models could change. Some professions could shrink or disappear, while new ones emerge. The cost of starting and operating a company could fall dramatically. The balance between human labour, capital and intellectual property could shift.

Even people who never subscribe to an AI service directly will probably depend on AI-powered systems every day.

This is why I don't think AI should be viewed merely as a race to build the best chatbot or the most powerful model.

AI could become one of the foundations on which future economies operate.

And when a foundational technology becomes essential to economic participation, control over that technology becomes a question of national and economic power.

The lesson of the Industrial Revolution

Imagine a country during the Industrial Revolution that decides it doesn't need to develop its own industrial capabilities because it can simply import machinery from countries that have already industrialised.

Initially, that might seem perfectly reasonable.

Why spend enormous amounts of money developing factories, engineering expertise and industrial infrastructure when other countries already provide these things?

The country could import machinery, benefit from cheaper manufactured goods and enjoy some of the productivity improvements without bearing the full cost of industrialisation.

But over time, a problem could emerge.

The industrial leaders would accumulate capital, expertise, manufacturing capacity and the ability to improve their technologies. Their industries would become more productive, allowing them to reinvest in further improvements.

Meanwhile, the importing country might become dependent on external suppliers for essential capabilities.

It could still benefit from industrialisation. But it would have less control over the technologies that increasingly determined its economic future.

AI could create a similar dynamic, potentially on an even broader scale.

The countries and companies that develop the most capable AI systems could gain advantages across many different industries simultaneously.

They could use AI to develop better software, accelerate scientific discoveries, design new products, improve manufacturing and create more capable AI systems.

If these advantages compound over time, the gap between leaders and followers could widen.

Countries that depend entirely on foreign AI might find themselves in a difficult position: their economies could become more productive while a disproportionate share of the profits, intellectual property and strategic advantages flows elsewhere.

Of course, importing technology is not inherently bad. Countries can learn, adapt and catch up. Access to foreign technology can also accelerate development.

But there is a difference between using technology developed elsewhere and having no meaningful alternative when access to that technology becomes strategically important.

The danger isn't that Europe might lose the AI race. It's that Europe might lose the ability to shape the world that emerges from it.

What happens if AI becomes a utility?

Look at cloud computing.

A significant part of the infrastructure European businesses depend on is provided by American companies. This isn't necessarily a bad thing. These companies have invested enormous amounts of money in building reliable infrastructure, and European businesses benefit from it.

But it creates a dependency.

Now imagine that AI becomes much more important than traditional cloud computing.

Instead of renting servers to host an application, businesses will rent access to intelligence capable of performing a substantial part of the work their employees do today.

The economic value of that intelligence could be enormous.

If a company uses AI to generate millions of euros in additional value, a portion of that value will flow to whoever provides the AI. Scale this across millions of businesses and hundreds of millions of people, and the implications become difficult to ignore.

The problem isn't that American companies make money. They should be able to compete and profit from their innovations.

The problem is what happens if Europe becomes structurally dependent on foreign AI providers and never develops competitive alternatives of its own.

Imagine that European businesses become increasingly reliant on AI systems whose most important capabilities, infrastructure and strategic decisions are controlled elsewhere.

Imagine that European startups must compete against companies with privileged access to the most powerful AI systems, while paying for the same underlying capabilities through external providers.

Imagine that European governments depend on AI infrastructure they cannot fully control.

Europe might still be wealthy. It might still have excellent universities, talented engineers and successful companies.

But it could gradually lose the ability to determine the terms on which its economy accesses one of its most important productive resources.

This is not simply a question of technology spending. It is a question of economic independence.

What if AI becomes a public good?

Imagine the EU decided that foundational AI infrastructure was strategically important enough to justify substantial public investment.

The idea would be relatively simple.

The EU would invest in computing infrastructure, fund the development of competitive open-weight AI models, and provide European citizens and businesses with access to those models at little or no cost.

Think of it as public infrastructure for the AI economy.

We already accept that governments should invest in roads, electricity grids, scientific research and education because their benefits extend far beyond the organisations that directly use them.

These investments help entire economies function. They create opportunities for businesses, reduce barriers to participation and provide a foundation on which private enterprise can flourish.

Why shouldn't foundational AI be considered in a similar way?

Of course, AI is not exactly like a road or an electricity grid. Models require continuous research, expensive computing resources, maintenance, energy and specialised talent. Providing unlimited AI inference to everyone for free would be extremely expensive.

But the underlying principle still applies.

If access to AI becomes essential for economic participation, there is a strong argument for ensuring that everyone has access to a capable baseline of AI without having to pay a private subscription.

More importantly, Europe should have the infrastructure, expertise and technical capabilities required to maintain that access independently.

The goal would not be to make every AI product free. It would be to ensure that access to foundational intelligence does not depend entirely on a small number of private providers.

How would this work in practice?

I imagine four main components.

1. EU-owned AI infrastructure

The EU and its member states would invest in strategic computing infrastructure.

This would include data centres, accelerators, networking and the energy infrastructure required to operate them.

The goal would not be to replace every private cloud provider. It would be to guarantee that Europe has sufficient computing capacity to train, run and improve its own AI models.

The infrastructure could be operated by specialised organisations under public ownership and transparent governance, with private companies continuing to build and operate infrastructure alongside it.

Europe would not need to become completely self-sufficient in every component. That would be unrealistic. But it should avoid a situation in which it has no viable alternatives for capabilities essential to its economy.

2. Open-weight European AI models

The EU would fund research teams to develop competitive foundational models.

These models would be released with open weights and licences that allow researchers, startups and businesses to use and adapt them.

This would not mean that every model must be developed by a government department. Public funding could support universities, research institutes, startups and private companies.

The important thing is that Europe would build and retain meaningful control over its AI capabilities.

Open weights would also allow businesses to run models on their own infrastructure when appropriate, reducing dependence on a single provider.

The objective would not necessarily be to produce the most powerful model in the world. It would be to ensure that Europe has access to models capable enough to support its economy, and that it can continue improving those models over time.

3. Free AI access for European citizens, with reasonable limits

Every EU citizen should have access to a public AI service at no cost.

The service could help with programming, education, research, writing, translation, administration and many other everyday tasks. The objective would be to ensure that access to capable AI does not become a privilege reserved for people who can afford multiple subscriptions.

However, free access should not mean unlimited access.

Operating AI systems requires computing power, energy and ongoing maintenance. Without reasonable limits, a small number of users could consume a disproportionate share of public resources, while automated abuse could generate enormous costs for taxpayers.

The public service should therefore include fair usage limits, rate limits and safeguards against automated exploitation. Users who need additional capacity could pay for it or access specialised programmes where there is a clear public interest.

The limits should be generous enough to support meaningful everyday use, learning, research and personal projects, rather than making the free service so restricted that it becomes useless.

There should also be clear rules governing privacy, data retention and acceptable use. Citizens should know how their information is handled, and the service should not become a mechanism for unnecessary government surveillance.

The principle is straightforward: everyone should have access to a capable baseline of AI, but no individual should be able to exploit a publicly funded service at everyone else's expense.

4. Free AI for European businesses and EU employees, with accountability

I would go a step further for European businesses and people working in EU institutions.

Eligible European businesses should be able to access public AI models and computing resources without paying licensing fees or standard usage charges, subject to reasonable usage policies and capacity limits where necessary.

EU institutions and their employees should also have access to these capabilities for legitimate official work.

The reasoning is simple: if AI becomes a foundational technology, public investment should help European businesses adopt it, improve their productivity and develop new products and services. Publicly funded AI should also help European institutions operate more efficiently and deliver better services.

Imagine a small European startup that can build and test an AI-powered product without having to spend thousands of euros on proprietary APIs. Or a small manufacturer that can use AI to improve its operations without facing an additional technology cost it cannot afford.

This could lower barriers to innovation and make it easier for European businesses to compete internationally.

But there is an important condition: free access must not become an unchecked subsidy for private interests.

The infrastructure would be funded by taxpayers, so its use should be accountable to the public.

Businesses receiving free access should agree to transparent eligibility requirements and proportionate audit procedures. These could include usage records, checks on organisational eligibility and investigations into suspicious or excessive consumption.

The aim would be to identify and prevent abuse, such as reselling publicly funded compute without authorisation, creating unlimited accounts to bypass usage limits, using the service primarily for unrelated commercial exploitation, or diverting resources to ineligible entities.

Audits should be risk-based rather than unnecessarily burdensome. A small business using AI for ordinary development work should not face the same scrutiny as an organisation consuming enormous amounts of computing capacity or exhibiting suspicious usage patterns.

Sensitive business information must remain protected, and audits should focus on eligibility, resource consumption and compliance with the programme's rules rather than giving the government unrestricted access to private company data.

EU employees should similarly receive free access for legitimate work purposes, subject to institutional security policies, appropriate data handling and auditable usage controls. Access should not become a way to process classified, confidential or personal information through systems that have not been approved for that purpose.

There should also be clear consequences for deliberate abuse, including suspension of access, recovery of improperly obtained benefits where legally appropriate, and stronger penalties for serious or repeated violations.

The objective is not to burden businesses with bureaucracy. It is to ensure that public resources are used for their intended purpose.

If the EU invests in AI infrastructure to improve European productivity and technological independence, it should make that infrastructure genuinely useful to businesses while ensuring that the benefits are not captured through misuse by a small number of organisations.

Free access should be generous, practical and accountable.

Would the economic benefits outweigh the investment?

This is the most important question.

Building competitive AI infrastructure would require enormous investment. Training advanced models, purchasing accelerators, operating data centres and attracting researchers are all expensive.

But I think we need to look at the return differently.

The goal would not be to generate a financial return from selling AI subscriptions. The goal would be to increase the productivity and resilience of the entire European economy.

Suppose public AI infrastructure enables millions of workers to become more productive.

Businesses develop products faster. Researchers make discoveries sooner. Startups experiment more cheaply. Public services become more efficient. Companies that previously could not afford advanced AI gain access to it.

The benefits would appear across thousands of industries rather than only in the accounts of a single AI provider.

Even relatively modest productivity improvements, spread across an economy as large as the EU, could generate substantial value over time.

But we should be honest about the uncertainty.

AI adoption requires training, organisational changes and investment in complementary technologies. Public infrastructure could be poorly managed or become technologically outdated. The benefits might also be concentrated in certain sectors rather than distributed evenly.

A serious programme would therefore need measurable objectives, independent evaluation and the ability to redirect funding when projects fail.

The economic case deserves to be evaluated in terms of the productivity gains, strategic resilience and new opportunities it enables, not merely the revenue it generates.

A public AI system could be financially unprofitable while still being an excellent investment for European society.

That is already true of many forms of public infrastructure.

Wouldn't this destroy private AI companies?

I don't think so, and I wouldn't want it to.

The objective should not be to eliminate private AI providers or prevent American companies from operating in Europe.

Private companies would still have plenty of opportunities to compete by developing better models, offering specialised services, providing more computing capacity and building applications for particular industries.

A public model would establish a competitive baseline.

If a private company can offer a model that is substantially better, more reliable or more convenient, customers should be free to pay for it.

But businesses and citizens should not be forced into dependence on a small number of providers simply because no affordable alternative exists.

There is also a benefit for the private sector itself. Open infrastructure can make it easier for startups to build businesses without first raising enormous amounts of money to access foundational technology.

The result could be more competition, more experimentation and a larger ecosystem of European companies.

Public infrastructure and private innovation do not have to be opposing forces. Properly designed, they can reinforce one another.

What about the risk of government inefficiency?

This is a legitimate concern.

Governments are not necessarily good at developing technology products. Public projects can suffer from bureaucracy, political interference, slow procurement and poor execution.

An EU-funded model could also fall behind the frontier, particularly if it were managed as a political project rather than a serious research effort.

For this reason, I would not ask the European Commission to build a giant government AI company and expect it to outperform the private sector.

I would establish a public infrastructure programme with independent technical governance, transparent performance targets and multiple competing research teams.

Funding should depend on results. Models should be benchmarked against the best available alternatives, and projects that fail to deliver should not receive unlimited funding.

The EU should also work with existing European AI companies and research institutions rather than duplicating everything they do.

And because this infrastructure would be so important, its governance should include strong protections against political interference, independent audits and transparent rules governing access to public resources.

The public sector's role would be to fund strategically important capabilities, guarantee broad access and establish a competitive foundation.

It would not need to control every aspect of the ecosystem.

The answer to the risk of government inefficiency should be better institutions and accountability, not the assumption that foundational infrastructure can safely be left entirely to private interests.

What if the US achieves AGI first?

This is where my concern becomes more serious.

I don't know whether AGI will be achieved soon, what it will look like or which country will develop it first.

But imagine that one country develops AI systems capable of performing a very large share of economically valuable cognitive work.

Imagine that those systems can accelerate scientific research, develop software, design products, operate businesses and help create even more capable AI systems.

Their economic value could be extraordinary.

If those systems remain under the control of a small number of foreign companies, the consequences could extend far beyond software subscriptions.

The companies that own the systems could capture a substantial share of the economic value they generate. They could attract more capital and talent, reinvest their profits and accelerate their technological lead.

Countries that depend on these systems would still benefit from using them. But they might capture a smaller share of the profits and strategic advantages.

This could create a self-reinforcing cycle.

The leading companies would use AI to become more productive, invest more in research, attract more resources and improve their systems. Their customers would benefit, but the owners of the underlying technology could accumulate an increasingly powerful position.

For Europe, this could create a difficult situation.

Its businesses might become more productive while becoming increasingly dependent on foreign technology. Its governments might rely on infrastructure they do not control. Its startups might struggle to compete with companies that have direct access to the world's most capable AI systems.

And if AI eventually reduces the importance of human labour in producing economic value, ownership of the technology could become even more important than it is today.

If a growing share of economic output comes from AI systems, then who owns those systems, who receives their returns and who has access to their capabilities will become fundamental questions.

These are not merely technology questions. They concern the distribution of wealth, the future of work, the economic power of states and the ability of societies to determine their own direction.

I don't want Europe to find itself in that position without having invested in alternatives.

I am not arguing that the US will necessarily monopolise AGI, that Europe is destined to lose or that technological dependence inevitably leads to economic decline.

I am arguing that the potential consequences are sufficiently significant that Europe should not treat this as an ordinary commercial competition.

Europe doesn't necessarily need to win the AI race

I think this is where the discussion often goes wrong.

Europe does not necessarily need to build the single most powerful AI model in the world.

It needs to ensure that it can participate meaningfully in the AI economy, capture a reasonable share of the value generated and retain the ability to make independent technological decisions.

There is a difference between being the absolute leader and being technologically dependent.

Europe could benefit enormously from AI even if the most capable models were developed elsewhere. But it should have the infrastructure, expertise and alternatives required to avoid becoming entirely dependent on external providers.

Public AI infrastructure could be one part of that strategy.

It would also need to be accompanied by better access to growth capital, a more integrated European market, reliable energy supplies and policies that make it easier to create and scale technology companies.

Public AI alone would not solve Europe's competitiveness problems.

But it could provide a foundation on which many other solutions become more viable.

The question is not whether Europe can prevent every other country from advancing faster. It cannot.

The question is whether Europe will have enough technological capability, economic strength and institutional independence to shape its own future in a world transformed by AI.

The next Industrial Revolution is happening now

I don't see the USA as an enemy, and I don't think technological competition needs to become a zero-sum geopolitical conflict.

American AI companies have created enormous value, and European citizens and businesses should be able to benefit from their innovations.

But I also think Europe needs to be realistic about its long-term interests.

The Industrial Revolution changed far more than manufacturing. It transformed where people lived, how they worked, how economies grew, how wealth was accumulated and how power was distributed between nations.

AI could have a similarly broad impact.

It could reshape almost every industry, change the economics of intellectual work, accelerate scientific progress and alter the relationship between labour and capital.

If that happens, the countries that control and develop foundational AI capabilities will have opportunities that extend far beyond the technology sector itself.

Those that rely entirely on others may still prosper, but they will have less control over the forces shaping their prosperity.

History does not guarantee that technological leaders will remain ahead forever, or that those who fall behind can never catch up. But catching up can become much harder when technological advantages compound across an entire economy.

This is why I think Europe needs to take the issue seriously now, rather than waiting until AI has become indispensable and the most important capabilities are already concentrated elsewhere.

Instead of treating AI exclusively as a commercial product, the EU should consider treating foundational AI capabilities as a form of public infrastructure.

It could invest in computing capacity, support open-weight models, provide citizens with affordable access to capable AI and give European businesses the foundation they need to compete.

The investment would be substantial. The outcome would be uncertain. And the programme would need to be managed carefully to avoid wasting public money.

But the potential consequences of failing to invest could be much greater than the loss of a few technology companies or a single market opportunity.

If AI becomes one of the foundations of economic and societal life, Europe cannot afford to be merely a customer of the countries that control it.

It needs to be a participant in building that future.

The EU does not have to win every AI race. It does not have to own every model or prevent private companies from succeeding.

But it should ensure that its citizens, businesses and institutions have access to foundational AI capabilities, and that Europe retains meaningful control over the infrastructure on which its future prosperity may depend.

We made electricity broadly available because modern economies could not function without it. We built public infrastructure because its value extended beyond the private interests of any one company.

If AI becomes as fundamental to our economies as electricity, perhaps we should start thinking about it in the same way.

The next Industrial Revolution is not simply a technology race. It is a contest over the foundations of future prosperity and power.

If Europe wants to remain in control of its economic future, it should consider making AI a public good.

What do you think? Should the EU invest in public AI infrastructure and provide affordable access to European citizens and businesses, or would this be an expensive government project better left to the private sector?

I'd be interested to hear what other European developers think about this.

Your Platform Engineering Investment Is Not Paying Off. Here's Why.

Remo H. Jansen — Wed, 21 Oct 2026 12:50:56 +0000

Building an internal platform is only half the job. The real return comes when developers trust it, want to use it, and help make it better.

Platform engineering has become a strategic investment for many engineering organisations. Teams are building internal developer platforms, standardising CI/CD pipelines, creating self-service infrastructure, and providing tools designed to make developers more productive.

The promise is compelling: reduce cognitive load, eliminate duplicated effort, improve consistency, strengthen security, and let product teams focus on delivering business value rather than managing infrastructure.

Organisations invest significant time, money, and engineering talent to make this happen.

And yet, something often gets lost along the way.

The platform gets delivered. The migration happens. The documentation is published. The new workflow becomes the official standard.

But developers are still frustrated.

They encounter confusing errors, unreliable workflows, missing capabilities, and problems that require them to ask another team for help. They learn which workarounds are necessary, which parts of the platform they can trust, and which problems are easier to avoid altogether.

Eventually, they comply with the new way of working. But compliance is not enthusiasm, and adoption is not necessarily success.

The organisation has invested in a platform, but it has not fully realised the return on that investment.

Why does this happen, and what can we do about it?

1. The last 10% matters more than you think

Platform teams are often very good at delivering the big things.

They build the infrastructure, establish common patterns, automate the happy path, integrate the necessary services, and provide a consistent interface for developers.

These are difficult and valuable achievements.

The problem is what happens next.

The platform works, but not always reliably. The common workflow is straightforward, but the unusual case is painful. An error occurs, but the message doesn't explain what went wrong or how to fix it. A pipeline fails, and determining whether the problem is in the application, the configuration, or the platform itself becomes an investigation.

None of these problems necessarily looks significant in isolation.

Collectively, however, they define the developer experience.

Consider two internal platforms that provide exactly the same capabilities.

With the first, a developer can complete a task in minutes when everything works, but diagnosing a failure takes hours and requires support from the platform team.

With the second, the task takes the same amount of time when everything works, but failures are clearly explained, diagnostics are available, and the developer can resolve most problems independently.

Technically, both platforms may be equivalent. In practice, they deliver very different levels of value.

This is the last-mile problem in platform engineering.

We invest heavily in capabilities, but sometimes underestimate the effort required to make those capabilities dependable, intuitive, and pleasant to use.

The last 10% might be the least glamorous part of the roadmap. It is also where much of the difference between a usable platform and a genuinely valuable one is created.

2. Developers don't fall in love with roadmaps. They fall in love with experiences.

Imagine that your organisation announces a major investment in a new developer platform.

There is an ambitious roadmap, a dedicated team, a polished launch presentation, and a clear strategic rationale.

Developers are encouraged to migrate their applications and embrace the new tooling.

Initially, there is curiosity. People try the platform, explore its capabilities, and perhaps even get excited about what it could eventually become.

Then they start using it for real work.

They encounter friction. Some workflows are slower than expected. Documentation doesn't cover their situation. Failures are difficult to diagnose. Requests for improvements disappear into a queue.

Over time, the initial excitement fades.

Developers stop exploring new capabilities. They stop reporting minor bugs because the process feels disproportionate to the problem. They stop suggesting improvements because they don't expect much to happen. They learn the minimum required to get their jobs done.

The platform becomes something they have to use rather than something they want to use.

This distinction matters.

When developers genuinely value a tool, they become its advocates. They recommend it to colleagues, experiment with new features, report problems, suggest improvements, and invest time in helping it evolve.

When they merely tolerate it, they do the minimum required.

This creates a vicious cycle:

The platform has usability problems.
Developers become reluctant to engage with it.
The platform team receives less useful feedback and fewer contributions.
Problems remain unresolved or are discovered later than they otherwise would be.
The developer experience deteriorates, reinforcing the original reluctance.

The result is a platform that may look successful on a dashboard but is not reaching its full potential.

You cannot mandate genuine enthusiasm. You have to earn it through the experience you deliver.

3. The hidden cost of making developers dependent on the platform team

A successful internal platform should increase developer autonomy.

Developers should be able to provision resources, deploy applications, understand failures, and solve common problems without having to coordinate with a central team for every step.

Yet many platform implementations inadvertently create new dependencies.

A pipeline fails, so the developer raises a ticket.

A configuration behaves unexpectedly, so they contact the platform team.

A feature is missing, so they submit a request and wait.

A bug needs fixing, but the relevant code is owned by another team, and the only available path is through its backlog.

The platform may have automated many manual tasks, but the organisation has replaced one kind of dependency with another.

This is particularly costly because platform teams are usually responsible for shared capabilities used by many product teams. Every unnecessary support interaction consumes capacity that could otherwise go towards improving the platform itself.

There is also an opportunity cost for the consuming teams. Developers spend time waiting, investigating workarounds, explaining issues, and coordinating with people who understand the platform better than they do.

A platform that requires constant human intervention to operate has not fully delivered on the promise of self-service.

Of course, some interactions with platform specialists are necessary. Complex infrastructure, security-sensitive changes, and architectural decisions often need expert involvement.

The goal isn't to eliminate the platform team. It is to eliminate unnecessary dependencies on it.

A good platform enables developers to solve the problems they are equipped to solve, while making it easy to involve specialists when their expertise is genuinely needed.

4. Why can't developers help fix the platform?

Here is a scenario that should be familiar to many engineering teams.

A developer encounters a failure in a shared deployment pipeline. They suspect a defect in the pipeline itself rather than their application.

What happens next?

Perhaps they open a ticket in an IT service management system. They provide logs, explain what they were doing, and wait for someone to investigate.

Another team encounters the same problem. They open another ticket, provide similar information, and wait too.

Eventually, a platform engineer investigates both reports, identifies the underlying defect, implements a fix, and releases an update.

This process might work. But it is unnecessarily expensive if the developers encountering the problem could have collaborated directly with the maintainers.

Now imagine a different workflow.

The developer navigates to the shared platform's source repository and asks an AI coding agent to investigate the failure.

The agent examines the available logs and configuration, helps determine whether the problem originates in the application or the shared platform, and searches existing issues for similar reports.

If an issue already exists, the developer can contribute evidence and confirm that another application is affected. If no issue exists, the agent helps prepare a new one with useful diagnostic information.

Other teams can discover the issue, contribute their findings, and discuss a solution in the same place.

Perhaps a developer from one of those teams identifies the root cause and proposes a fix through a pull request. The maintainers review it, run the necessary tests, and merge it.

The platform team still owns the platform. It still defines standards, reviews changes, and ensures quality.

But it is no longer the only team capable of improving it.

This is the difference between a support model and a contribution model.

In the first, consumers report problems and maintainers solve them.

In the second, consumers and maintainers collaborate to solve problems together.

That is the foundation of an inner-source culture: applying the collaborative practices of open source within an organisation.

5. AI makes this opportunity much more compelling

The contribution model described above isn't entirely new. Inner-source practices have existed for years.

What is changing is the cost of participation.

Historically, contributing to a shared platform could require considerable effort. A developer needed to understand the repository structure, locate the relevant code, reproduce the problem, navigate contribution guidelines, and prepare a useful issue or pull request.

For someone unfamiliar with the platform, that initial investment could be substantial.

AI coding agents can reduce this barrier.

With appropriate repository access and tooling, an agent can help developers:

Understand unfamiliar platform code.
Diagnose failures using logs, configuration, and source code.
Determine whether an issue is likely to originate in the application or the shared platform.
Search existing issues and documentation for known problems.
Produce well-structured bug reports with relevant diagnostic evidence.
Identify potential fixes and prepare draft pull requests.
Write or improve tests to reproduce a defect.

These capabilities do not guarantee correct diagnoses or safe changes. Agents can be wrong, miss context, or propose fixes that introduce regressions. Human review, automated testing, access controls, and appropriate security boundaries remain essential.

But the potential is significant.

AI can make it easier for developers to cross the boundary between consuming a platform and contributing to it.

This is particularly valuable in large organisations, where the people most affected by a platform defect may be the people best positioned to reproduce it, understand its impact, or even propose a solution.

The platform team doesn't have to become less important. Its expertise can be applied where it creates the most value: architectural direction, quality, reliability, difficult problems, and enabling contributions from across the organisation.

6. Your tooling choices can either enable or undermine collaboration

Culture matters, but culture doesn't exist independently of the systems people use every day.

If source code lives in one place, issues in another, documentation in a third, and technical discussions in a fourth, contributing to a shared platform becomes harder than it needs to be.

Developers must navigate multiple systems, maintain separate accounts or permissions, repeat information, and reconstruct context that is scattered across different locations.

The organisation may have all the necessary tools. Yet the overall workflow remains fragmented.

This is especially problematic when the official process encourages developers to report a problem through a ticketing system but offers no straightforward path to investigate the underlying code or contribute a fix.

A more collaborative approach is to bring technical work closer to the source.

For code-centric platform engineering, a repository-centred workflow can provide a natural home for:

Source code and version history.
Issues, defects, and feature requests.
Technical documentation and contribution guidelines.
Pull requests, reviews, and design discussions.
Automated testing and continuous integration.

GitHub is one example of a platform that supports this model. Other tools can support similar workflows. The specific product is less important than the principle.

The place where a problem is reported should also be a place where people can understand it, discuss it, and contribute to fixing it.

There may still be good reasons to retain separate systems for service management, compliance, incident response, or formal approvals. The objective isn't to force every organisational process into a single tool. It's to avoid unnecessary separation between the technical artefacts and the people trying to improve them.

7. Platform engineering needs a product mindset

Perhaps the most fundamental change is to how we define success.

Many engineering initiatives are organised around delivery milestones: build the platform, release the capability, migrate the applications, and declare the project complete.

But internal platforms aren't finished when they launch.

They are products with users, competitors, changing requirements, operational costs, and an ongoing need for improvement.

Those users happen to be colleagues rather than external customers. That doesn't make their experience any less important.

A product mindset means treating feedback as a continuous input, prioritising usability alongside capability, and measuring whether the platform actually helps developers achieve their goals.

It also means accepting that the best feature to build next may not be a new capability.

It might be fixing an unreliable workflow. Improving an error message. Making a common failure self-diagnosable. Reducing the time required to onboard an application. Removing a manual approval that no longer adds value.

These improvements may be less impressive in a launch announcement, but they can have a substantial impact across hundreds or thousands of developers.

The platform team should therefore ask not just, "What should we build next?" but also, "What prevents developers from getting value from what we have already built?"

That second question is often where the most immediate returns can be found.

8. Measure value, not just activity

If we want platform investments to deliver better returns, we need to measure outcomes rather than relying exclusively on delivery metrics.

Counting onboarded applications, available features, pipeline executions, or registered users can tell us something about reach and activity. They don't necessarily tell us whether developers are better off.

A more useful measurement framework might include:

Developer experience

How satisfied are developers with the platform?
How often do they encounter friction in common workflows?
Do they trust the platform for critical work?

Reliability and productivity

How frequently do platform-related failures occur?
How long does it take to diagnose and resolve them?
How much developer time is spent waiting for support or working around limitations?

Autonomy and self-service

What proportion of common problems can developers resolve independently?
How often do they need human intervention?
How long does it take to onboard an application or complete a routine task?

Contribution and continuous improvement

How easy is it to report a defect with enough information to act on it?
Can consuming teams contribute changes?
How long does it take to review and release a valid contribution?
Are developers actively helping improve the platform?

These measures should be interpreted together rather than turned into isolated targets. For example, a high number of pull requests isn't necessarily evidence of success if those contributions are low quality or reflect a platform full of defects.

The aim is to understand whether the platform is reducing friction, enabling autonomy, and delivering value to the teams that depend on it.

9. What should organisations do differently?

The answer isn't to abandon platform engineering or to assume that every problem can be solved by changing tools.

The opportunity is to improve how platforms are built, operated, and evolved.

Here are five practical starting points.

1. Prioritise the last mile.

Reserve meaningful capacity for reliability, usability, diagnostics, documentation, and the removal of recurring friction. Don't allow new feature development to consume the entire roadmap.

2. Make common failures self-diagnosable.

Invest in actionable error messages, structured logs, troubleshooting guidance, and diagnostic tooling. Developers should be able to understand what failed and what to do next.

3. Make contribution a first-class workflow.

Document how to report issues, propose changes, run tests, and contribute fixes. Make it possible for consuming teams to participate without needing to become platform experts first.

4. Use AI to lower the cost of participation.

Where appropriate, provide agents with access to the relevant source code, documentation, issues, and diagnostic tools. Let them help with investigation and contribution, while retaining human oversight and appropriate safeguards.

5. Measure whether developers actually benefit.

Gather feedback, track reliability and resolution times, and examine the friction developers encounter in real workflows. Use that evidence to determine what to improve next.

None of these requires a massive transformation programme to get started. A team can begin with one frequently failing workflow, one repository, and a clear commitment to making problems easier to diagnose and fix.

The important thing is to close the feedback loop.

Conclusion: The return on platform engineering is earned after delivery

Platform engineering offers enormous potential. Shared infrastructure, standardised workflows, self-service capabilities, and reusable tooling can make engineering organisations more productive, consistent, and secure.

But building these capabilities is only part of the job.

The return on that investment depends on what happens when developers use the platform every day: whether it works reliably, whether problems are easy to solve, whether feedback leads to improvements, and whether the people who depend on it can help make it better.

A platform that developers are required to use can achieve broad adoption without earning their trust.

A platform that developers trust can achieve something much more valuable: voluntary engagement, advocacy, and continuous improvement.

That is why the last 10% matters. It is why self-service must mean more than automating the happy path. And it is why collaboration should be built into the platform's operating model rather than treated as an administrative process around it.

The next evolution of platform engineering should not simply be about building more platforms or adding more capabilities.

It should be about making existing platforms better to use, easier to understand, and easier to improve.

The real measure of a platform isn't how much engineering went into building it. It's how much friction it removes for everyone who depends on it — and how effectively those people can help it evolve.

That is how platform investments become lasting engineering value.

From Never Getting Selected to a 1-in-3 Success Rate: Did AI Help Me Write Better CFPs, or Is AI Selecting Them?

Remo H. Jansen — Mon, 19 Oct 2026 15:25:47 +0000

For years, I was involved in developer advocacy.

I organised meetups, spoke at many of them, and was invited to conferences by people in my network. At one point, I was even a Microsoft MVP, partly as a result of all that developer advocacy work.

I had experience. I had technical topics to talk about. I had a network of people who knew me and my work.

But there was one thing I could never seem to get right: getting selected through a conference Call for Papers (CFP).

I tried. A lot.

I submitted proposals to conference after conference, and the result was almost always the same: rejection.

It was frustrating. I could be invited to speak at a conference by someone who knew my work, yet struggle to get selected when submitting a proposal through the official process.

Eventually, I started wondering whether the problem was the content of my talks or the way I presented them.

This year, I tried something different

Instead of starting with a conference CFP and trying to write a proposal from scratch, I started with something I was already comfortable doing: writing a blog post.

I would choose a topic I wanted to speak about and write an article about it. Then I would give an AI agent two things:

My blog post.
The website of the conference I wanted to submit a proposal to.

I would ask the agent to use my article as the foundation for a conference proposal, taking the event's audience, themes, and submission guidelines into account.

The idea was simple: I would focus on the technical content and the ideas I wanted to share, while AI would help me turn them into a proposal tailored to the conference.

And then something unexpected happened.

The results changed dramatically

For years, I had submitted proposals without getting selected.

With this new approach, I experienced a one-in-three acceptance rate.

That's a striking difference from my previous experience.

I can't prove that AI alone caused the improvement. I may have chosen different topics, targeted different conferences, or simply submitted proposals that were a better fit. But the change was significant enough to make me wonder what was really happening.

Had I finally found a better way to sell my ideas?

Or was something else going on?

The question I can't stop asking

There are two possible explanations that interest me.

Possibility 1: AI is better at selling my ideas than I am

Perhaps I was never particularly good at writing conference proposals.

That doesn't mean I wasn't good at presenting, explaining technical concepts, or engaging an audience. Those are different skills.

A CFP proposal is a piece of persuasive writing. It has to convince a reviewer that a particular talk deserves a limited slot in a conference programme. It needs to communicate the value of the session, identify its audience, explain what attendees will learn, and distinguish itself from other submissions.

Maybe I was good at the technical side of developer advocacy but not as good at selling the value of my talks on paper.

If so, AI is helping me communicate the value of my own ideas more effectively.

There's nothing inherently wrong with that. We already use editors, colleagues, mentors, and writing tools to improve how we communicate.

But it does raise an uncomfortable question: how many good talks have been rejected over the years because their authors weren't particularly good at writing CFP proposals?

How much technical talent have conferences missed because the people evaluating submissions couldn't see the value behind an imperfect abstract?

Possibility 2: Are the reviewers using AI too?

Here's where things get more interesting.

What if the improvement isn't just about AI helping me write better proposals? What if AI is also involved in evaluating them?

Some conference organisers may use LLMs to help review, summarise, categorise, or shortlist CFP submissions. Others may rely entirely on human reviewers, and many may use a mixture of approaches.

I don't know whether the conferences that accepted my proposals used AI in their selection processes.

But if they did, it raises a fascinating possibility.

Perhaps my AI-generated proposals are better at communicating with the people evaluating them. Or perhaps they are better at matching the language, structure, and criteria that an AI-assisted review process is designed to identify.

If an LLM helps me frame my proposal and another LLM helps evaluate it, have I improved my communication with the conference organisers, or have I learned to produce something that another AI system is more likely to recognise as a strong submission?

Those are not necessarily the same thing.

A proposal can be clear, well structured, and closely aligned with a conference's stated themes without the underlying talk necessarily being more original or valuable.

Conversely, an excellent talk might be overlooked because its proposal doesn't communicate its strengths effectively.

Are we getting better at communicating ideas, or just better at optimising the text that gets those ideas selected?

I don't have an answer. But I think it's a question worth asking.

Maybe the real problem was never my technical expertise

There's another possibility: the two explanations aren't mutually exclusive.

AI may be helping me write better proposals while also making my submissions more aligned with the selection criteria, regardless of whether a human or an AI-assisted process is involved.

Giving an agent both my article and the conference website provides useful context. Rather than asking it to produce a generic abstract, I'm asking it to connect my ideas to a specific audience and event.

That could lead to clearer titles, more focused descriptions, more explicit learning outcomes, and a stronger explanation of why the session belongs at that conference.

These are useful improvements whether the reviewer is a person, an LLM, or a combination of both.

The important distinction is that a better proposal doesn't automatically mean a better talk. It means the value of the proposed talk may be easier to understand.

And perhaps that was the missing piece all along.

How I'd approach this experiment now

If you're a developer advocate, engineer, technical leader, or aspiring conference speaker, here's the workflow I'd recommend experimenting with:

Write the article first. Develop the technical ideas in your own words before worrying about selling them.
Give AI the conference context. Include the conference website, CFP criteria, target audience, and submission requirements.
Ask for a tailored proposal. Have the agent explain the talk's value to that specific audience, rather than simply summarising your article.
Review everything yourself. Make sure the proposal is technically accurate, reflects what you'll actually present, and still sounds like you.
Track the outcomes. Record submissions, acceptances, rejections, topics, and the approach used to create each proposal.

If I wanted to investigate the bigger question, I'd go further. I'd compare proposals written entirely by me with AI-assisted versions of the same ideas, ideally across comparable conferences and with enough submissions to draw more meaningful conclusions.

I'd also want to know how much AI is actually being used in CFP evaluation. Without that information, it's impossible to conclude that AI-assisted submissions are succeeding because they are being evaluated by AI.

My one-in-three result is an observation, not a controlled experiment.

But it's an observation that has changed how I approach conference submissions.

The question I'd like to leave you with

For years, I struggled to get my proposals accepted despite having experience speaking at meetups, organising communities, and contributing to developer advocacy.

Then I changed how I created my proposals, introduced AI into the process, and started seeing a very different result.

Maybe AI is simply helping me communicate my expertise better.

Maybe it is helping me optimise for a selection process that increasingly involves AI.

Maybe it's a bit of both.

I don't know yet.

But I find the question much more interesting than the simple conclusion that AI can write a better abstract.

If AI can help us write proposals that get selected, and AI is also helping evaluate proposals, what exactly are we optimising for: better talks, better communication, or better compatibility between AI systems?

I'd genuinely like to hear from conference organisers, CFP reviewers, and other speakers.

Are you using LLMs to write or refine your submissions? Are you using them to review submissions? And have you noticed a difference?

Because I suspect this is a conversation the developer community needs to have.

Halo is the new Doom and most software will soon be effectively open source (by force or by choice)

Remo H. Jansen — Sun, 18 Oct 2026 21:50:00 +0000

Seven months ago I published “Source code is now a common good, and SaaS is mostly dead.” I argued that AI had collapsed the economic cost of clean-room reimplementation, that pure software expression was losing its scarcity, and that the SaaS model built on high-margin code would face an existential squeeze—except where real data moats or network effects remained.

I was wrong about the timeline.

It didn’t take five to ten years.

This month the premonition became visible reality.

Halo everywhere — including 100+ player co-op on PC

In the space of a few days we watched Halo: Combat Evolved appear on platforms it was never meant for, and get radically expanded where it already existed:

Halo 64 (Jack Tulli) — a playable multiplayer (and emerging campaign) port running on real Nintendo 64 hardware. Built on the halo-ce-universal decompilation, with a custom renderer, four-player split-screen, the original 13 maps, bots, classic modes, and even a Firefight mode the original Xbox version never had. Claude assisted heavily in the coding.
Halo: Dreamcast Evolved — extended gameplay of the Pillar of Autumn and other levels running on actual Dreamcast hardware. The CPU is more than three times slower and the system has a quarter of the RAM of the original Xbox, so performance is still rough, but the core systems are already ported and being optimized in public.
Native PC (and beyond) with massively expanded player counts — the same decompilation work that enabled the console ports also produced native Windows, Linux, and Android builds (OpenCE / halo-ce-universal and related projects). These support system-link / online multiplayer for up to 128 players. Campaign co-op limits have been raised as well; 32-player campaign co-op is already being demonstrated, with work continuing toward the same high player counts. Browser versions of the original Xbox game have also appeared with 128-player rooms and split-screen co-op.

These are not asset flips or simple ports. They rest on prior decompilation work that reached near byte-matching fidelity. What changed is the speed of the remaining work. A single developer (or small team) plus modern agents can now finish the last mile—new renderer, platform integration, expanded netcode, extra modes—in days or weeks instead of years. The result is a franchise that once defined the Xbox suddenly running on N64, Dreamcast, modern PCs, phones, and browsers, with player counts the original hardware could never support.

Halo is becoming the new Doom: the game that runs on everything, because the barriers that used to stop it have collapsed.

Demon's Souls Remake: from ~1 FPS to 60+ (and nearly 120) in roughly a month

PS5 emulation provided the other high-visibility stress test.

In early September, Demon's Souls Remake on KyTyPS5 and its forks was crawling at 1–2 FPS even on top-tier hardware after finally reaching in-game states. Within days it jumped into the 10–18 FPS range. By mid-September temporary 30 FPS markers appeared. By mid-October, custom builds were delivering over 60 FPS at 1440p with original PS5 graphics settings on an RTX 5070 + Ryzen 7 9800X3D, and approaching 120 FPS with DLSS Frame Generation. The full game had already become completable earlier in the month.

The historical pace of console emulation does not look like this.

REA — Reverse Engineer Anything

While the ports and the emulator were making noise, a different tool exploded: REA (morluto/rea).

An MCP server and CLI that lets coding agents (Claude Code, Codex, Cursor, and others) reverse-engineer applications, native binaries, websites, and runtime behavior without source code. It orchestrates existing tools (Ghidra, Hopper, IDA, browser instrumentation) and returns evidence-backed explanations. In roughly two weeks it accumulated hundreds of thousands of stars.

The practical effect is that an agent can now be pointed at a feature and produce a usable understanding plus a path to independent reimplementation. Combined with the clean-room pattern I described in March, the barrier between “I can observe the behavior” and “I can recreate the behavior under a different license or on different hardware” continues to fall.

The Adobe and Office “Craft” ports — imperfect, but the signal is loud

Early October also brought the ArtCraft projects (led by Brandon Thomas): open-source, Rust-based applications described as clean-room reimplementations of major Adobe tools — PhotoCraft (Photoshop), FilmCraft (Premiere), LightCraft (Lightroom), and equivalents for Illustrator, After Effects, InDesign, and Acrobat. Built with heavy assistance from Claude.

A few days later the same effort expanded to Microsoft Office: WordCraft, GridCraft (Excel), and DeckCraft (PowerPoint).

None of these are finished products. The teams themselves rate them as early alpha—feature parity and “ready for real work” numbers typically sit in the 45–60% range depending on the metric and app. File compatibility, edge cases, and polish remain incomplete.

They are imperfect. That is exactly why they matter as signals.

These are public demonstrations that a small team + frontier models can now produce recognizable, runnable, file-compatible approximations of two of the most heavily protected, highest-margin software suites in existence in a matter of weeks. The UI patterns, core workflows, and file formats that previously required years of specialized effort are being reconstructed rapidly enough that the projects are already usable for lighter tasks and improving in public view.

What these stories share

They are not isolated stunts. They are symptoms of the same underlying shift I described in March:

Decompilation and reverse-engineering tooling has matured.
Frontier models are competent enough at low-level and systems code to accelerate the remaining human work dramatically.
Agentic workflows (and tools like REA) make the process more systematic and less dependent on rare specialist knowledge.
The economic cost of “make a working version of X on platform Y” or “understand how Z is implemented so I can rebuild it” has collapsed.

Where is this going?

In the original article I concluded that most software would become effectively open source—by force or by choice—and that the only sustainable thing left to charge for would be convenience. I was thinking primarily about SaaS. I had not fully considered how the same forces would hit other markets.

Now that I am watching it play out in games, I think the game industry is even more exposed.

AAA studios were already struggling with rising costs, risk-averse sequels, live-service fatigue, and audience fragmentation. The ability to rapidly reimplement, port, expand, and redistribute games—especially older or mid-tier titles—removes one of the remaining economic moats: the difficulty of making a working version exist somewhere else. When a decompiled classic can run on N64, Dreamcast, phones, browsers, and PCs with 128-player lobbies within weeks of the tooling maturing, the value of exclusive platform deals, long development cycles, and even some forms of DRM starts to look fragile.

Even games that embrace community content and modding are not automatically safe. Modding communities have historically extended the life of games; the new tools accelerate both the creation of those mods and the independent recreation of the underlying experience itself. The distinction between “official” and “community” versions becomes harder to maintain when the technical barrier to a full alternative keeps falling.

The original prediction still holds, only broader:

Most software will become effectively open source—by force (because protection becomes impractical) or by choice (because fighting it is more expensive than adapting).
The residual value will concentrate in convenience, operations, trust, data network effects, real-time services, and experiences that cannot be trivially recreated offline or offline-first.
Pure expression of code, whether in a SaaS dashboard or a single-player campaign, loses scarcity.

For games this may prove especially brutal. The industry already operates on high fixed costs and hit-driven economics. If the cost of independent recreation and redistribution keeps collapsing, the pressure on traditional publishing and exclusivity models will intensify. Some studios will adapt by doubling down on live services, social layers, competitive integrity, and continuous content that is hard to mirror. Others will not.

Seven months ago I wrote that source code was becoming a common good and that SaaS was mostly dead.

This month Halo became the new Doom, emulators jumped from 1 FPS to 100, reverse-engineering agents went mainstream, and clean-room approximations of Adobe and Office appeared in public.

The direction is clearer than it was in March.

Most software will soon be effectively open source—by force or by choice.

The only remaining question is how many markets realize it in time to adapt.

SDLC != ADLC != ASDLC

Remo H. Jansen — Sat, 17 Oct 2026 23:38:50 +0000

I recently came across this definition:

The Agentic Development Lifecycle (ADLC)—also known as the Agent Software Development Lifecycle—is a software engineering methodology designed for building, testing, deploying, and governing AI agent systems rather than traditional deterministic code.

That sentence made something click. A lot of people (myself included, until recently) have been casually treating ADLC and ASDLC as interchangeable. They’re not.

Once you separate them, the confusion starts to dissolve.

The Three Terms, Cleanly Separated

Term	Full Name	What it is	Primary focus	What is being built?	Who does most of the work?
SDLC	Software Development Lifecycle	The classic methodology for building software	Deterministic systems	Traditional applications & services	Humans (tools assist)
ADLC	Agent / Agentic Development Lifecycle	A specialized lifecycle for creating AI agents	Probabilistic, tool-using, adaptive systems	AI agents and multi-agent systems	Mixed (humans + agents), with heavy emphasis on evaluation & governance
ASDLC	Agentic Software Development Lifecycle	The traditional SDLC performed with AI agents as workers	Any software, delivered agentically	Applications, services, infrastructure… or even agents	Agents execute; humans set intent, guardrails, and approve

Why the Mix-Up Happens

Both terms contain the words “Agentic” and “Development Lifecycle,” so people collapse them. On top of that:

Some writers use “ADLC” loosely to mean “the new way we develop software now that agents exist.”
Others (IBM, Arthur.ai, Glean, Atlan, etc.) use ADLC more precisely: the lifecycle for building agents themselves.
Meanwhile, “Agentic SDLC” / ASDLC has become the clearer label for “we’re using agents to ship regular software.”

The result is a muddy conversation where people argue past each other.

Why the Distinction Actually Matters

If you’re building an agent, you care about different things than if you’re using agents to build a normal product:

Non-determinism and evaluation harnesses become first-class concerns.
Observability, containment, and continuous behavioral monitoring matter more than classic “green tests.”
The “done” state is fuzzier. Agents keep running and adapting after deployment.

Treating that work with a regular (or even agent-assisted) SDLC often leads to brittle agents that look good in demos and then drift or fail in production.

Conversely, if you’re just trying to ship a web app or an internal tool faster with coding agents, you don’t necessarily need the full ADLC machinery. You need a well-governed ASDLC.

Quick Mental Model

SDLC → Building normal software the old way
ADLC → Building agents
ASDLC → Building anything (including agents) with agents

Once you start using the terms this way, a lot of the current discourse becomes much clearer.

Have you noticed the same mixing of ADLC and ASDLC in your circles? I’d love to hear how your team is currently labeling these ideas.

The Agentic Manifesto: What Should the Agile Manifesto Look Like in the Age of AI?

Remo H. Jansen — Sat, 17 Oct 2026 01:40:40 +0000

I've been spending a lot of time thinking about where all the recent advancements in AI are going to take the software industry.

Not just what AI coding agents mean for developers today, or how much faster we can write code, but what happens when these capabilities fundamentally change the economics of building software.

Over the last few months, I've written about several aspects of this transformation:

Each article explores a different part of the same transformation. Together, they've led me to a bigger question.

If AI agents fundamentally change how we build software, should we reconsider the principles that guide how we develop it?

I think the answer is yes.

And I thought it would be interesting to start a conversation about what the Agile Manifesto might look like today, in a world where AI agents are becoming increasingly capable of building software autonomously.

This is an attempt to start that conversation. It's not a declaration that I've figured everything out, and it's certainly not an argument that everything Agile taught us is suddenly wrong.

Quite the opposite. I think many of the original Agile values remain as relevant as ever. But the context in which we apply them is changing.

Why revisit the Agile Manifesto?

The Agile Manifesto was written in 2001, when software development was a very different activity.

Its authors challenged heavyweight processes, excessive documentation, rigid plans, and organisational structures that often got in the way of delivering working software.

They established four values:

Individuals and interactions over processes and tools.
Working software over comprehensive documentation.
Customer collaboration over contract negotiation.
Responding to change over following a plan.

These values helped shape how an entire generation of engineers and organisations approached software development.

But consider what happens when AI agents can implement features, modify existing systems, generate tests, refactor code, and work across entire codebases with increasingly little human intervention.

The bottleneck starts to move.

Writing code becomes cheaper. Producing multiple implementations becomes easier. Experimenting with different approaches becomes more affordable.

But we still need to know whether the software does what we intended, whether it introduces vulnerabilities, whether it behaves correctly in production, and whether it actually solves the customer's problem.

In many cases, the harder problem is no longer producing a solution. It's establishing that the solution is worth trusting.

When code gets cheap, verification becomes expensive.

This is not simply a tooling change. It has consequences for team structures, software architecture, engineering practices, product discovery, and the economics of custom software.

If we can produce software at a rate that exceeds our ability to verify and maintain it, then increasing development capacity alone will not solve our problems.

We need to rethink the system in which software is produced.

From Agile to Agentic

I don't think the answer is to discard Agile and replace it with a methodology that prescribes how to use AI coding agents.

That would miss the point.

The more interesting question is whether the underlying values and principles of software development should evolve to reflect this new reality.

Here are some of the shifts I believe deserve our attention.

1. From producing software to verifying outcomes

Working software was a major improvement over plans and documents as a measure of progress.

But in an agentic world, generating working code is becoming easier. Even passing tests does not necessarily mean we've built the right thing.

We need to focus on verified outcomes: software that demonstrably satisfies its requirements, behaves within its intended constraints, and delivers value to customers.

2. From implicit assumptions to explicit intent

AI agents can operate with considerable autonomy, but they need to understand what they are trying to achieve and what they must not do.

Constraints, specifications, architectural boundaries, acceptance criteria, and executable policies become increasingly valuable because they make intent easier to interpret and verify.

Explicitness isn't the ultimate goal. It's a means of achieving more reliable outcomes while enabling greater autonomy.

3. From supervising implementation to designing autonomous systems

When humans perform most implementation work, we organise teams around people writing, reviewing, and integrating code.

When agents can do much of that work, we need to think differently about the development system itself.

How much autonomy can we safely support? Which decisions require human judgment? Where should verification happen? How do we prevent failures from propagating?

The goal should not be to remove humans from software development. It should be to use human judgment, creativity, and ownership where they matter most.

We may end up with fewer engineers who can accomplish significantly more, but also carry greater responsibility for the systems they create and operate.

4. From optimising implementation to optimising the whole system

The Toyota Production System offers a useful perspective here.

Improving the productivity of an individual step does not necessarily improve the performance of the entire system.

If agents produce code ten times faster but verification, integration, and maintenance remain unchanged, we may simply create a larger queue of work waiting for those activities.

We need to optimise the flow of verified value, not the volume of code generated.

With these ideas in mind, I started wondering what a new manifesto might look like.

The Agentic Manifesto

We are uncovering better ways of developing software by building with intelligent agents and learning from the systems in which they operate.

Through this work, we have come to value:

Verified outcomes over generated output

Explicit intent over implicit assumptions

Human judgment and ownership over human supervision

Safe, continuous flow over controlled, sequential handoffs

That is, while there is value in the items on the right, we value the items on the left more.

Principles behind the Agentic Manifesto

We follow these principles:

1. Our highest priority is to deliver valuable, verified outcomes to customers through early and continuous delivery.

The goal is not to produce more code, complete more tasks, or deploy more agents. It is to solve meaningful problems and establish that we've solved them.

2. Welcome changing requirements and new information. Design systems that make change cheap, verifiable, and reversible.

AI makes experimentation and implementation cheaper. We should take advantage of that flexibility while ensuring that changes can be evaluated and corrected without creating unnecessary risk.

3. Deliver working software frequently, with automated verification integrated throughout development.

Short feedback loops remain essential. Agents should be able to implement, test, evaluate, and refine changes continuously rather than generating large quantities of code that must be reviewed later.

4. Make intent explicit enough for humans and agents to understand what must be achieved and what must never be violated.

Requirements, constraints, invariants, acceptance criteria, and architectural boundaries should be expressed clearly and made executable wherever practical. Explicitness enables autonomy; it does not eliminate the need for judgment.

5. Build verification into the development process, and require evidence proportional to the consequences of failure.

Quality should not depend on hoping that generated code is correct or relying exclusively on human review. Use automated tests, static analysis, security checks, formal methods, runtime monitoring, and independent evaluation where appropriate. Higher-risk changes require stronger evidence.

6. Build quality into the production system rather than relying on inspection at the end.

Detect abnormalities as early as possible, prevent defects from propagating, and stop work when critical verification fails. A system that produces code faster but allows defects to accumulate is not a better system.

7. Give agents the maximum autonomy that can be safely supported by explicit boundaries, reliable feedback, and effective controls.

Autonomy should be earned through evidence and constrained by risk. Agents should be able to make routine decisions independently while respecting permissions, architectural rules, operational limits, and escalation requirements.

8. Preserve human judgment, creativity, and ownership as the capabilities of autonomous systems increase.

Delegate implementation, not responsibility. Humans should focus on defining problems, resolving ambiguity, making consequential decisions, and taking accountability for outcomes. Greater leverage demands greater responsibility.

9. Learn continuously from customers and from the behaviour of software in production.

Specifications and tests cannot anticipate everything. Real usage, operational signals, incidents, and customer feedback must inform both the software and the system that produces it.

10. Prefer simplicity and maintainability over unnecessary complexity, even when implementation is cheap.

The fact that an agent can generate a feature quickly does not mean we should build it. Every additional feature, abstraction, dependency, and architectural decision creates potential costs that extend beyond implementation.

11. Optimise for the flow of verified value, not the utilisation of people, the volume of generated code, or the number of agents deployed.

A productive system minimises unnecessary queues, handoffs, rework, and delays between an idea and a verified outcome. Increasing output without improving the entire system merely moves the bottleneck.

12. Continuously improve the system that produces software.

Every defect, failed verification, production incident, and unexpected agent behaviour is an opportunity to improve our specifications, constraints, tests, architecture, and feedback loops. The production system itself must evolve as our capabilities change.

What does this mean for the future of software development?

I believe AI is changing more than the productivity of individual developers.

It is changing the economics of software itself.

If code becomes a common good, the ability to produce an implementation becomes a weaker competitive advantage. The value shifts towards understanding problems, delivering differentiated outcomes, possessing valuable data and distribution, operating reliable services, and establishing trust.

This could fundamentally change enterprise software.

Organisations may increasingly build and adapt software around their own needs instead of accepting the limitations, complexity, and cost of generic products. Custom software that was previously too expensive to justify could become economically viable.

But this future won't be realised simply by giving everyone access to coding agents.

We need production systems that can support the resulting increase in output without sacrificing correctness, security, maintainability, or human accountability.

That's why I think verification should sit at the centre of an Agentic Manifesto.

Not because every line of code needs a formal proof, or because humans should spend their days supervising machines, but because the ability to produce software is becoming less scarce while the ability to establish that software is correct, valuable, and safe remains essential.

The opportunity is to build systems that let us produce more valuable software with less unnecessary effort, while increasing our confidence in what we deliver.

What do you think?

This is a first attempt, and I'm very interested in hearing what others think.

A few questions I'd particularly like to explore with the community:

Are we approaching a point where the Agile Manifesto needs a successor, or are its original values sufficient for the agentic era?
Is verification the right centre of gravity for a new manifesto, or am I overestimating its importance?
What should happen to team structures and engineering roles when a smaller number of engineers can direct much larger amounts of autonomous work?
If code becomes a commodity, where will the sustainable competitive advantage in software actually come from?
Which of these 12 principles would you change, remove, or add?

I'm especially interested in disagreements and alternative perspectives. I'd rather have these ideas challenged now than present a polished manifesto that fails to address the real problems we will face.

The Agentic Manifesto isn't a finished answer. It's an invitation to work out what software development should become next.

What would you change?

Mutation Testing with TypeScript: How to Verify Your Tests in the Age of AI Coding Agents

Remo H. Jansen — Wed, 14 Oct 2026 22:28:14 +0000

Your tests pass. But would they catch a bug?

Imagine asking an AI coding agent to implement a feature. A few minutes later, it has generated the implementation, written unit tests, and opened a pull request.

The CI pipeline is green. All tests pass. Code coverage looks good.

Can you trust the change?

Not necessarily.

The implementation and its tests may share the same misunderstanding of the requirements. The tests might execute every line without checking the behavior that matters. And a test suite that passes today might not detect a regression tomorrow.

As AI makes code generation faster, we need to think more carefully about how we verify the code we produce.

In this tutorial, we'll explore one technique that can help: mutation testing.

We'll build a small TypeScript project, introduce a bug deliberately, install StrykerJS, and use mutation testing to discover weaknesses in our tests. Then we'll explore how the same technique can help us verify AI-generated pull requests.

By the end, you'll understand not just how mutation testing works, but why it can become an important part of a multi-layer verification strategy.

1. Let's start with a simple problem

Imagine we're building an online shop. One of our business rules is that orders worth £100 or more qualify for free shipping.

Let's implement that rule in TypeScript.

Create a file named src/shipping.ts:

export function calculateShipping(
  orderTotal: number,
): number {
  return orderTotal >= 100 ? 0 : 10;
}

The function is straightforward:

Orders below £100 pay £10 shipping.
Orders worth £100 or more get free shipping.

Now let's write some unit tests.

Create src/shipping.test.ts:

import { describe, expect, it } from 'vitest';
import { calculateShipping } from './shipping';

describe('calculateShipping', () => {
  it('charges shipping for small orders', () => {
    expect(calculateShipping(50)).toBe(10);
  });

  it('offers free shipping for large orders', () => {
    expect(calculateShipping(150)).toBe(0);
  });
});

Run the tests:

npx vitest run

Both tests pass.

Great! We have an implementation, some unit tests, and a green test suite.

But let's ask a slightly different question.

What would happen if somebody accidentally changed >= to >?

Our implementation would become:

export function calculateShipping(
  orderTotal: number,
): number {
  return orderTotal > 100 ? 0 : 10;
}

Now an order worth exactly £100 is charged shipping, even though the requirement says it should qualify for free shipping.

We've introduced a bug.

Run the existing tests again.

They still pass!

Why? Because we tested orders worth £50 and £150, but we never tested the boundary at £100.

Our tests execute the function, but they don't distinguish the correct implementation from this incorrect one.

This is the problem mutation testing helps us investigate.

2. What is mutation testing?

Mutation testing is a technique for evaluating how effectively your tests detect certain defects.

Instead of simply running your tests against your implementation, a mutation-testing tool deliberately makes small changes to your production code and runs the tests against each modified version.

These changes are called mutations. Each modified version is called a mutant.

For example, a mutation-testing tool might make changes such as:

Original code	Mutated code
`a >= b`	`a > b`
`a + b`	`a - b`
`isValid && isActive`	`isValid
{% raw %}`return true`	`return false`

The tool then observes whether your tests detect the change.

There are two particularly important outcomes.

Killed mutant: At least one test fails because of the mutation. Your tests detected the change.

Survived mutant: The tests still pass. Your tests didn't detect the change.

Let's apply this to our shipping example.

The original implementation is:

return orderTotal >= 100 ? 0 : 10;

A mutant changes it to:

return orderTotal > 100 ? 0 : 10;

Our existing tests still pass, so the mutant survives.

That's a useful finding. It tells us that the test suite doesn't distinguish these two implementations.

Notice what we're evaluating: we're not simply asking whether the implementation works for our current examples. We're asking whether the tests can detect selected changes that might introduce defects.

This is a different question from ordinary unit testing and code coverage.

3. Code coverage isn't the same as test effectiveness

You may already measure code coverage in your projects.

Coverage tells you which parts of your code were executed during testing. It's useful, but it doesn't necessarily tell you whether your assertions are strong enough.

Consider this test:

it('calculates shipping', () => {
  calculateShipping(100);
});

The function executes. Depending on the coverage measurement, the test may contribute to branch or line coverage.

But the test doesn't assert the expected result.

The implementation could return £10 instead of £0, and the test would still pass.

Now consider:

it('offers free shipping at exactly £100', () => {
  expect(calculateShipping(100)).toBe(0);
});

This test checks the actual business rule.

It also kills our mutant because the mutated implementation returns £10.

We can summarize the difference:

Code coverage: Did our tests execute this code?
Assertions: Did our tests verify the expected behavior?
Mutation testing: Would our tests detect selected changes to the implementation?

These techniques complement each other. Mutation testing doesn't replace coverage, and a mutation score doesn't prove correctness. Together, however, they can provide more useful evidence about the effectiveness of a test suite.

4. Let's set up StrykerJS

We'll use StrykerJS, a mutation-testing framework for JavaScript and TypeScript.

We'll assume you already have Node.js and npm installed.

If you're following along from scratch, create a project:

mkdir mutation-testing-demo
cd mutation-testing-demo
npm init -y

Install TypeScript and Vitest:

npm install --save-dev typescript vitest

Create the src directory and add the two files from the previous sections.

Now run:

npx vitest run

Make sure your tests pass before continuing.

Initialize StrykerJS

Run:

npx stryker init

Follow the prompts to configure Stryker for your project. Select TypeScript and the Vitest test runner where applicable.

Stryker's setup options can vary with the version and project configuration, so follow the current prompts rather than assuming every project requires an identical configuration.

Official documentation: StrykerJS — Getting Started.

Once initialization is complete, inspect the generated configuration and make sure the mutation scope includes our production file:

src/shipping.ts

Our test file, src/shipping.test.ts, should not be treated as production code to mutate.

You can configure the mutation scope explicitly if necessary. For example, in a TypeScript Stryker configuration, the relevant pattern might be:

mutate: ['src/**/*.ts', '!src/**/*.test.ts'],

Keep the configuration generated by your installed version as the starting point, and adapt it to your repository's conventions.

Run your first mutation test

Execute:

npx stryker run

Stryker will run your tests, generate mutations in the configured production code, and evaluate the results.

The first run may take longer than your ordinary unit tests because Stryker needs to evaluate multiple mutants.

Once it finishes, inspect the terminal output and generated HTML report.

Look for surviving mutants associated with the comparison in calculateShipping.

If the comparison changes from >= to > and all our tests still pass, we've found the weakness we deliberately introduced.

Congratulations: you've just used mutation testing to discover a gap in your test suite.

5. Understand the mutation report

A mutation report contains more than just a score.

The most useful outcomes to understand are:

Killed

A test detected the mutation and failed. This is generally what we want for a meaningful behavioral change.

Survived

The tests passed despite the mutation. Investigate whether this reveals missing test coverage or an assertion that doesn't adequately verify the requirement.

No coverage

The mutated code wasn't exercised by the relevant tests. You may need to investigate whether the code is tested at all.

Timeout

The tool couldn't obtain a normal result within its configured time limit. This doesn't necessarily mean your tests detected the mutation.

Equivalent mutant

The mutation doesn't change observable behavior for the relevant inputs. No meaningful test can distinguish it from the original implementation.

Not every surviving mutant is a defect, and not every mutant needs to be killed. Some mutations are equivalent, some aren't meaningful for your requirements, and some may reveal behavior you don't actually need to constrain.

The purpose of the report is to help you make better decisions about your tests.

What about the mutation score?

Stryker calculates a mutation score based on the results of mutation testing.

A simplified formula is:

Mutation score = killed mutants / valid mutants × 100%

For example, suppose a run produces 100 valid mutants and your tests kill 80 of them. The mutation score is 80%.

That can be a useful signal, but be careful about treating it as a universal quality metric.

Two projects can have the same mutation score while having very different levels of risk. The score depends on the mutations generated, the code being analyzed, and which results are excluded.

A surviving mutation in payment authorization may matter much more than a surviving mutation in an unimportant formatting helper.

Focus on understanding meaningful surviving mutants, not maximizing a percentage at any cost.

6. Improve the tests and run mutation testing again

Let's fix the weakness we discovered.

Our business rule is explicit: orders worth £100 or more qualify for free shipping.

We should test the boundary directly.

Add this test to src/shipping.test.ts:

it('offers free shipping at exactly £100', () => {
  expect(calculateShipping(100)).toBe(0);
});

Run the ordinary test suite:

npx vitest run

The test passes against the correct implementation.

Now run mutation testing again:

npx stryker run

The mutation that changes >= to > should now be killed by the boundary test.

We've improved the test suite because it now detects a meaningful defect.

Notice that we didn't add a test just to improve a score. We added one because the requirement explicitly defines what should happen at the boundary.

This distinction is important.

A mutation-testing report is a source of questions, not an instruction to write more assertions blindly.

For every surviving mutant, ask:

Does this change affect behavior that matters?
What does the requirement say the correct behavior should be?
Should the test suite detect this change?
If so, what is the smallest meaningful test that would detect it?

This approach fits naturally into Test-Driven Development.

TDD helps us implement behavior from requirements. Mutation testing challenges whether our tests can detect selected deviations from that behavior.

7. From local experiments to pull request verification

So far, we've run mutation testing manually.

The next step is to integrate it into CI.

Imagine an AI coding agent creates a PR that modifies calculateShipping and adds several unit tests.

The ordinary CI pipeline runs:

Type-checking.
Linting.
Unit and integration tests.
Other project-specific checks.

Everything passes.

Now Stryker runs against the configured production code. It discovers that the tests don't detect a meaningful mutation in the shipping calculation.

The PR report can expose that weakness before the change is merged.

This is particularly useful for AI-generated code because the implementation and its tests may have been produced by the same agent, based on the same interpretation of the requirements.

The tests passing is evidence that the implementation satisfies the assertions the agent wrote. It isn't independent evidence that those assertions capture every important requirement.

Mutation testing adds another challenge: it deliberately changes the implementation and checks whether the test suite notices.

Should mutation testing block every PR?

I'd start with a gradual approach.

Stage 1: Report findings without blocking merges.

Run mutation testing on a small set of important modules. Learn how long it takes, inspect surviving mutants, and identify noisy or irrelevant results.

Stage 2: Gate critical code.

Introduce stronger requirements for areas where correctness is particularly important, such as permissions, pricing, validation, or state transitions.

Stage 3: Track regressions over time.

Use scheduled runs and historical reports to identify weaknesses across the broader codebase.

For larger projects, Stryker's incremental mode can reuse eligible previous results to reduce the work needed on subsequent runs. See the incremental testing documentation.

One important distinction: mutating changed production files is not the same as testing only the new tests in a PR. You want relevant existing tests to participate in verifying the changed behavior as well.

You should also avoid making a repository-wide mutation score an immediate merge requirement. A small PR shouldn't necessarily be responsible for fixing every weakness in a legacy test suite.

8. Let the AI agent investigate surviving mutants

We can take the workflow a step further.

Instead of using mutation testing only as a CI gate, we can feed its findings back to the AI agent.

Imagine this sequence:

An agent implements a feature and writes unit tests.
CI runs the ordinary checks.
Stryker finds a surviving mutation.
The agent receives the mutation report and relevant requirements.
The agent determines whether the mutation exposes a genuine testing gap.
The agent proposes an additional test or explains why the mutant isn't meaningful.
CI reruns the checks against the revised PR.

For our shipping example, the agent might receive a report showing that changing >= to > doesn't cause any tests to fail.

The agent can then inspect the business rule and recognize that the boundary at £100 is important.

It adds the boundary test, reruns the suite, and verifies that the mutation is now killed.

This creates a feedback loop in which the agent can improve not just the implementation, but also the evidence we have about that implementation.

However, there's a critical caveat.

Don't let the agent blindly optimize the mutation score.

An agent could make a mutant fail by adding an assertion that encodes an incorrect assumption. It could also change production code simply to make the existing tests pass.

The correct behavior must come from explicit requirements, domain rules, or other trustworthy sources—not from the mutation report alone.

The agent can propose a fix, but the final verification should run independently in CI against the revised commit.

9. Mutation testing is one layer in a Swiss cheese model

This brings us to the broader reason mutation testing matters.

No single verification technique catches every defect.

Type checking can detect certain classes of errors, but it doesn't establish that a business rule is correct.

Unit tests can verify specified behavior, but they only check the cases and assertions we've written.

Mutation testing can challenge the effectiveness of those tests, but it can't guarantee that the original requirements were understood correctly.

Integration tests can expose problems between components, but they won't necessarily identify every defect in an individual component.

Code review can identify design and requirement problems, but human reviewers also have limited time and attention.

Each layer has gaps.

This is the idea behind a Swiss cheese model of verification: arrange multiple imperfect defenses so that a defect that passes through one layer has other opportunities to be detected.

A practical model might include:

Layer 1: Types and static analysis

Catch incompatible interfaces, invalid types, and selected classes of programming mistakes.

Layer 2: Unit and integration tests

Check specified behavior, interactions, and component integration.

Layer 3: Mutation testing

Challenge whether tests detect selected changes to the implementation.

Layer 4: Contract and architecture checks

Verify boundaries, invariants, and integration assumptions.

Layer 5: Independent review and production feedback

Identify misunderstood requirements, broader design risks, and failures that automated checks miss.

The layers are complementary. They aren't completely independent: mutation testing relies on the test suite, and both can be based on the same misunderstood requirement.

But combining different forms of verification can provide stronger evidence than relying on any one of them.

This connects directly to the principles discussed in Revisiting the Toyota Production System in the Age of Coding Agents. In particular, the idea of building quality into the production process is relevant here: detect abnormalities as early as possible, rather than allowing them to move downstream.

Mutation testing can be one of the automated checks that helps us detect weaknesses before a pull request is merged.

10. Why this matters when code generation scales

AI changes the economics of software development.

An agent can produce a substantial implementation and its accompanying tests much faster than a human might write them manually.

But generating code is not the same as establishing that the code is correct.

If the volume of changes increases dramatically, manually reviewing every implementation and every test may become increasingly difficult.

We need verification mechanisms that scale with the rate of change.

This is the connection to When Code Gets Cheap, Verification Becomes Expensive.

Mutation testing is not a complete solution to that problem. It has a computational cost, and it only evaluates the mutations it generates. It cannot establish that the implementation satisfies every requirement or that every important defect is represented by a mutation.

What it can do is make one important question cheaper to investigate:

Can our tests detect plausible defects in the code we're producing?

And because the process can be automated, we can apply that challenge repeatedly as code changes.

The objective isn't to maximize code generation or mutation scores in isolation. It's to increase our ability to produce and verify valuable changes without letting the volume of generated code overwhelm our verification capacity.

Conclusion

Mutation testing is a relatively simple idea with important consequences.

We deliberately modify production code, run our tests, and observe whether those tests detect the changes. When meaningful mutants survive, we investigate whether our tests are missing important behavioral checks.

With TypeScript and StrykerJS, it's possible to introduce this technique into an existing project without replacing your test runner or abandoning your current TDD workflow.

And when AI agents generate code and tests, mutation testing provides a useful additional challenge: rather than accepting a green test suite at face value, we can investigate whether it detects selected mistakes.

It doesn't prove that our code is correct. No single testing technique does.

But that's precisely why it belongs in a multi-layer verification strategy.

When code generation scales, verification must scale with it. Mutation testing helps us challenge one of the most important defenses we already have: our tests.

DEV Community: Remo H. Jansen

The Gaming Industry Is Doomed

The technological moat is disappearing

The PS5 is no longer the fortress it once was

Nintendo is experiencing the same problem

Ocarina of Time: Nintendo's exclusivity problem in miniature

The economics of AAA development are already broken

Consumers are running out of money

Piracy is becoming a much more credible alternative

Nintendo should be particularly concerned

Sony is fighting the wrong war

Microsoft might be the biggest beneficiary

The winner is PC

The next generation of consoles could be a disaster

Why aren't gaming stocks collapsing already?

Gaming isn't dying. The old gaming industry might be.

Buckle Up: Is the U.S.S. Enterprise About to Take Off?

Buckle Up: Is the U.S.S. Enterprise About to Take Off?

But how could we get there?

Why is exponential growth so difficult to understand?

A different way to think about the future

So, is AI about to do the same thing?

And what could this mean for our future?

AI Agents Have a Human Problem

We didn't invent abstractions just for humans

Agents have more bandwidth, but not unlimited capacity

Technical debt now has a token cost

AI amplifies the gap

We should rethink what good developer experience means

The future isn't about writing less code. It's about managing complexity.

Will AI Make Abstractions Obsolete?

Complicated is not the same as complex

The purpose of abstractions is managing complexity

But AI doesn't think like humans, does it?

AI can handle more complexity. Why make it handle unnecessary complexity?

But what about Rust?

Abstractions aren't free, though

Code reviews might change, but software still needs to be understood

The future isn't less abstraction. It's more powerful abstraction.

Your Documentation Is Out of Date. Let an AI Agent Keep It in Sync

The source code is the source of truth

Add a Git commit reference to your Markdown files

Introducing the sync-docs skill

What would the implementation look like?

1. Implementing the sync-docs skill

2. Automating the skill with GitHub Agentic Workflows

3. What does a synchronization PR give us?

Why use a commit instead of a timestamp?

Why not merge the PR automatically?

A few things worth considering

The bigger picture

The EU Should Make AI a Public Good If It Wants to Survive the Next Industrial Revolution

AI isn't just another technology sector

The lesson of the Industrial Revolution

What happens if AI becomes a utility?

What if AI becomes a public good?

How would this work in practice?

1. EU-owned AI infrastructure

2. Open-weight European AI models

3. Free AI access for European citizens, with reasonable limits

4. Free AI for European businesses and EU employees, with accountability

Would the economic benefits outweigh the investment?

Wouldn't this destroy private AI companies?

What about the risk of government inefficiency?

What if the US achieves AGI first?

Europe doesn't necessarily need to win the AI race

The next Industrial Revolution is happening now

Your Platform Engineering Investment Is Not Paying Off. Here's Why.

1. The last 10% matters more than you think

2. Developers don't fall in love with roadmaps. They fall in love with experiences.

3. The hidden cost of making developers dependent on the platform team

4. Why can't developers help fix the platform?

5. AI makes this opportunity much more compelling

6. Your tooling choices can either enable or undermine collaboration

7. Platform engineering needs a product mindset

8. Measure value, not just activity

9. What should organisations do differently?

Conclusion: The return on platform engineering is earned after delivery

From Never Getting Selected to a 1-in-3 Success Rate: Did AI Help Me Write Better CFPs, or Is AI Selecting Them?

Halo is the new Doom and most software will soon be effectively open source (by force or by choice)

Introducing the `sync-docs` skill

1. Implementing the `sync-docs` skill