Schrödinger’s Doomer: Software Is Not Dying, It Is Moving Up a Floor

It is late. On the left of the screen: software is collapsing. Valuations in free fall. Building has become free, a working product comes together over a weekend, and the only question left is whether anybody can still hear you. That is the post making the rounds in every feed right now.

On the right, a small tool that the person in front of that screen built for themselves three months ago using AI. And it works. Not sort of. It actually works.

Both of those feel true. And both of them are. Can AI develop software? Yes. And that is exactly where the misunderstanding starts. The doom crowd is measuring correctly, they are just measuring in the wrong frame of reference. Put the ruler against the layer, meaning the source code, the artifact, the job title, and yes, everything is dying. Put it against the function, meaning getting machines to reliably do useful things, and nothing has changed in sixty years.

I call this Schrödinger’s doomer. Both states are true at once for as long as nobody specifies where the measurement happens. Which means the mistake on the doom side is not an observation error. It is a coordinate error. They mistake a moving frame of reference for a collapsing universe. And where you put the ruler decides what you do next: build, wait, or relearn.

There are plenty of clean overviews on what AI is doing to software development by now. Fraunhofer has one, IBM has one. What I miss in them is a position. I come from software architecture and I work with businesses that have to live with whatever got built. So this is not an overview. It is an argument.

Can AI develop software?

Yes. Generating code is essentially solved. Which is precisely why the question is framed wrong: it measures the one layer that is currently becoming cheap.

My claim is this: source code is the new assembly language. I said that on a podcast a few months ago, and it has only settled further since. To see what that means, you have to go back sixty years and look at what the jump from assembly to high-level languages actually delivered.

Writing any single line did get easier, sure. But the real effect was a different one: high-level languages made software bigger. They enabled programs that were not impossible in assembly, but unmaintainable. The limit was never whether the machine could execute something. The limit was always whether a human could still understand it years later, across changing teams. And that limit did not go away. It just moved along.

And the result was not less software. It was absurdly more. The pattern has a name, the Jevons paradox: when a resource gets cheaper, consumption does not drop, it explodes. Every earlier collapse in development cost triggered a wave of applications nobody had on their radar beforehand. Assembly to high-level, mainframe to PC, desktop to web, web to mobile.

In fairness, that is not a guarantee. If demand saturates quickly this time, the displacement story wins. Right now nobody knows.

One thing is clear: the assembly people did not end up unemployed. A role appeared above them that had not existed before, namely systems architecture. The complexity did not disappear. It moved up a floor.

That this rotation is real today can be shown. In a Microsoft project called Societas, seven part-time engineers produced 110,000 lines of code in ten weeks, 98 percent of it AI-generated. The human work shifted from authoring to directing (Source: Futurum Group, 2026).

How much the measuring position decides shows up in the numbers these posts run on, too. SaaS valuations really did fall, the median sat at 3.4x revenue in March 2026 (Source: Aventis Advisors, 2026). What gets skipped is that the entire move is attributed to AI, when a good chunk of it is simply the interest rate environment. 2021 was zero rates. Today is not.

Far more interesting is what happened next. In the June quarter of 2026 the average was back at 4.7x, up from 3.9x the previous quarter, and SaaS stocks beat the S&P 500. The analyst read on it, in their own words: the market seemed to realise that many, if not most, software companies will not be replaced by AI (Source: First Analysis, 2026).

So the market itself was in superposition. Anyone who sold a snapshot as a structural claim in the spring made exactly the mistake this article is about. I say that without any glee. It is exactly the illustration.

How much longer will software developers exist?

The name, probably longer than many currently expect. The content underneath, not so long. Whether a new title ends up replacing it anyway is open, and it is being fought out right now.

Historically there are two patterns, and from the outside they look identical. Some titles really do die: typesetter, punch card operator. Others survive and get swapped out from the inside. Bookkeepers still exist, but nobody there adds up columns by hand.

What decides which pattern applies is the function underneath. The typesetter disappeared because typesetting disappeared. Bookkeeping stayed because books still get kept and only the method changed. That is the same question as before, applied to a single word: do you measure the title against the layer or against the function?

With “software developer” it does not resolve cleanly, though, and I am not going to pretend I have the answer. Two currents are pulling at the same time, in opposite directions.

One pulls towards staying. Attached to the title are salary bands, degree programmes, visa categories, tax classifications, HR levels. That is a load-bearing wall, and nobody tears one of those down over a change in method. On top of that comes an argument from my own field: a job title is an interface to the outside world and not a description of the work. Customers, recruiters, authorities and job boards need a stable name to connect to, and interfaces are the last thing anyone renames, long after the implementation behind them has become something else.

The other current pulls towards a fresh start. Once requirements and profile shift far enough, the old label stops fitting, and a new name appears for a role that did not exist before. That this is already under way shows up in the postings: roles for the classic developer profiles such as Android, Java, .NET, iOS and web are down 60 percent or more from 2020, while postings for machine learning engineers are up 59 percent (Source: Cloud Perspectives, 2026).

Which current wins, I do not know. It is a stubborn tug of war and both sides have good arguments. I would not bet on either. What you can rely on is the movement underneath: whichever label ends up on it, the work shifts in the same direction. That is the part you can plan with.

What actually goes away is the middle. The thinking above stays: deciding what should be built and how you will recognise that it is right. What falls away is the layer below it, the one that translates: fully specified ticket in, code out. That was always the most mechanical floor, and it goes first. For a business that buys software, that is the part that actually matters. That layer is what used to show up on the invoice as implementation.

And the floor right at the bottom, the craft on the actual code? Here I will let my own analogy count against me. Nobody climbs down into assembly today, apart from a few very specialised corners like compiler work, embedded, or security. If source code really is the new assembly language, then hand work on code becomes just as much of a speciality. What still looks like it today is usually something else already: steering the agent more tightly, showing it the right trail, instrumenting the system so the fault becomes visible at all. Debugging by hand becomes the exception.

There is one place where the doom side is right anyway. I come back to it at the end, because I do not want to talk it away.

Where does the value go when code gets cheap?

In three directions: verification, responsibility over time, and specification. All three sit outside the system that produces the code.

Before I open those up, a word on why they will still matter in two years. Any sentence of the form “AI cannot do that well enough yet” is scrap paper in six months. So I need a claim that still stands when the models are three times better.

A system cannot be its own acceptance criterion. Someone outside has to say what correct means, and carry the consequences when it was not.

No model closes that gap. It is structural.

And it reaches further than those three directions. A model is trained on whatever scored best on average. Its default is therefore the middle, not because it could do no better, but because the middle is where it drifts without steering. For text I took that apart in “Why AI text sounds generic”, where the line runs: the default is the middle, not your edge. For software it holds just the same. And that produces a shift reaching past my three categories: the middle becomes the baseline, and what gains value is everything above it.

And here is the part of the assembly analogy I consider the most important. Assembly to C was a deterministic abstraction. The compiler is a function. Same input, same output. And when it is wrong, it is reproducibly wrong. That is precisely why you were allowed to stop reading the assembly.

Prompt to code is not deterministic. The new compiler is stochastic, it is not provable. So the abstraction leaks downward, permanently. You cannot take your eyes off the lower layer yet, for as long as the upper one ships without a proof.

Which means the real question of the coming years is not whether AI replaces developers. It is this: what becomes the verification layer that makes a stochastic compiler deterministic enough?

Verification: the bottleneck already moved

The data here is fairly unambiguous. AI now writes 42 percent of all committed code. 96 percent of developers do not fully trust that code to be functionally correct. And only 48 percent always check it before committing (Source: Sonar, 2026). AWS CTO Werner Vogels coined a name for what accumulates here: verification debt. Like any debt, it does not come due immediately.

In production it looks like this: 43 percent of AI-generated changes need manual debugging in live operation, even after passing QA and staging. And not a single one of the engineering leaders surveyed described themselves as very confident that the code would behave correctly once deployed (Source: Lightrun, 2026).

And one uncomfortable observation belongs here, otherwise this sounds too tidy: the value has already moved, the practice has not. 96 percent distrust it, 48 percent check it. That is not a knowledge gap, it is a time gap. And in exactly that gap, the systems being built right now are the ones that surface much later.

Responsibility over time: building a system you can actually answer for

Mike Grouchy put the risk in one sentence that has stuck with me. The problem is not unemployment, it is more software than organisations can safely operate, secure, and maintain (Source: AmazingCTO, 2026).

Operate, secure, maintain. Those three verbs are the work. Because responsibility over time does not mean somebody stands there afterwards and takes the blame. It means building a system that can be answered for in the first place. And that gets decided before the first line of code, across four questions.

How does this fit into the existing system landscape? Not: does the thing work on its own. But: what already exists, what talks to what, where do duplications appear, and where does a second version of the truth about the same customer suddenly show up. A tool that works perfectly in isolation while keeping its own customer list does not have a feature problem. It has a landscape problem.

Which other systems do I use, and how do they connect?Every connection outward is an assumption about someone else’s system. About field names, about error codes, about what happens when the other side does not answer. Those assumptions belong in exactly one place that everything else validates against. Otherwise you find out they were wrong during an incident, and then you are searching in three systems at once.

Who is actually allowed to do what? Permissions are not a detail for later. Who sees which customer data, who can delete, who can export, who can change prices. A quickly built prototype usually has exactly one permission level, namely everything. And that is the decision that is most expensive to correct afterwards.

What happens when something goes wrong? Not if, but when. Who even notices, and how fast? Is there a backup, and has it ever been restored? And above all: how big is the radius when this one part fails? Does one form stop working, or does the business?

None of those four is a code question. All four need a person who knows the context and carries the consequences. Which is why this is the floor that does not get automated away. The questions a prototype should answer before real customer data sits on it are collected in the nine production-readiness questions. The short version: software that works and software that holds are two different things.

Specification: the most boring discipline becomes the most important

The third destination is almost funny. When implementation gets cheap, everything shifts to the question before it: what exactly do I want, and how will I recognise that I got it. That is not a documentation task, that is the actual thinking. “The customer should get a confirmation” sounds like a finished requirement. Until somebody asks what happens when the same order comes in twice. And that thinking is exactly what everyone found boring for decades.

What kind of role emerges from this shift, and what actually fills the day, I spelled out in “The slow death of the programmer”. Here I am interested in the floor below that: why the rotation runs in this direction at all.

Can I develop software with AI?

You can build it. The real question is whether you can answer for it afterwards. That does not get decided on day one. It gets decided in month fourteen.

I like using an image for this. Anyone can build a cabin in the woods. A six-storey building is something else. And the difference is not a question of size, it is a change of regime. With the cabin, the roof caves in and it costs you an afternoon. In the building there are people. Above a certain height, different physics apply: load paths, escape routes, fire protection. Every line of building code is congealed experience from buildings that fell down.

That sounds like an analogy, but it is in the literature now. Mark Russinovich, CTO of Microsoft Azure, and Scott Hanselman wrote in a peer-reviewed piece for Communications of the ACM: programming is not software engineering (Source: Communications of the ACM via InfoQ, 2026).

The pattern then looks roughly like this. A small business builds its own order management with AI. And it works. On day one, the cabin feels like a building.

The bill arrives in month fourteen. No backups. Nobody knows how it works anymore. The person who built it has moved on. The feedback loop is broken, because the receipt arrives so late that nobody connects it to the original decision.

Which shifts the buying question. A small business does not buy features. It buys reliability over time. So when it comes to custom software development, the question today is less “how much capacity do I need” and more “whose judgement am I buying”. The market for hands is falling in price. The market for responsibility is not.

And here is the part I like to give small teams, because it gets lost in the whole decline debate. Small businesses have a structural advantage here. The person who decides is usually the same person who answers for it later. That closeness between decision and consequence is exactly what large organisations are currently rebuilding at great cost. In a five-person business, it is simply there.

What goes missing when the bottom rung disappears?

The learning path. People starting out learned the craft on exactly the translation work that is now automated. Right now nobody has a good answer to that.

Russinovich and Hanselman call the phenomenon AI drag. AI lifts experienced people enormously and drags early-career developers down, because they lack the judgement to steer, verify, and repair AI output. The incentive consequence is predictable: companies hire seniors and automate juniors. And the pipeline that produces the next generation of seniors quietly collapses.

Their example lands. An AI agent responded to a race condition by inserting a sleep call. A classic masking fix: the symptom disappears, the actual bug stays in and eventually shows up under load. Anyone who has hit that three times in production sees it instantly. Anyone who has never debugged a real race condition, because an AI always wrote the code, does not.

The authors have a term for what gets lost here: systems taste. The intuition that develops over years of real production exposure. And you cannot, they write, prompt-engineer your way there.

That is the structural difference to every earlier rotation, and it is why I take it seriously. With assembly to C this was not an issue, you kept writing C and learned while doing it. This time the learning path itself has been automated away. Forrester projects a 20 percent decline in computer science enrolments to match (Source: Forrester, 2026).

I do not have a good answer to this. The best proposal I know comes from the same authors: a preceptor model borrowed from nursing education, where learning becomes a measured and compensated organisational goal rather than a by-product of shipping. Whether that holds remains to be seen.

Which brings me to the second uncomfortable point I do not want to skip. Structurally nothing changes. Biographically everything changes. Earlier rotations gave a generation time, the path from assembly to high-level languages ran over fifteen, twenty years. This one is compressing into three to five. A rotation you cannot complete inside a working life is functionally a wall, even if the curve looks the same from far enough away.

The closest thing to a rebuttal comes from Stephan Schmidt. He argues the Jevons rebound lands on the ideas side and not on the labour side: companies are constrained by ideas, not by developer capacity, and the largest new wave of software will be built by people who never had developers and never will hire any. His conclusion: more software, fewer developers.

Honestly, I barely read that as a counter-position. It is the same observation, counted differently. He counts heads in the old category, I count the work. That the translation layer collapses is in his argument just as much as in mine.

Where the two readings genuinely part ways is one single question: who does whatever is left? Schmidt bets that the people with the ideas will take it on themselves. I bet that operating, securing, and maintaining stays its own thing, something you buy in, because it takes a feel for large systems and that is not something you pick up on the side. So if coaches, restaurants, and teachers build the next wave of software, that wave needs someone for exactly this. Which reading lands closer will show.

What remains

A profession spent sixty years automating everyone else’s work. Now, for the first time, it stands inside the blast radius itself. And the ones who come through are the same as back then: the people who defined themselves by the outcome and not by the artifact.

Anyone who says “I write code” is losing their profession right now. Anyone who says “I make sure machines reliably do useful things” never tied it to the code in the first place.

Which is why the question of where you put the ruler is not academic. It decides whether you can see the next step at all.