A map of the changes coming for everyone who builds software for a living.
There is a genre of writing about AI that has been proliferating lately, and most of it is trying to scare you. Matt Shumer's essay Something Big Is Happening — viewed more than 80 million times since its publication in February — argues that the gap between what AI can do today and what the public believes it can do has become enormous and dangerous, and that the people who work with these tools daily know something that most people don't yet. He's right about that. Citrini Research's thought exercise The 2028 Global Intelligence Crisis takes the fear further, modeling a scenario in which AI-driven white-collar displacement spirals into a structural economic crisis — Ghost GDP, mortgage defaults in prime zip codes, a feedback loop with no natural brake.
These are not fringe arguments. They are being made by serious people with serious data, and they deserve to be taken seriously. The title of this post borrows from that same atmosphere of urgency. The apocalypse is in the air.
But this post is not that kind of writing. The alarm has been sounded, loudly and well, by others. What's been harder to find is a map — something that describes where we actually are, names the horizons ahead with some specificity, and gives the people doing this work a way to think about what it asks of them at each stage. Fear is not a strategy. What follows is an attempt at one.
The shift isn't driven by enthusiasm — it's driven by competition forcing companies, and companies forcing individuals. A clear-eyed look at who is applying the pressure, why, and what your company's governance structure means for how it arrives at your desk.
When I try to make sense of what's happened and what's coming, I find it helps to think in horizons rather than timelines. A horizon isn't a date on a calendar. It's a meaningful shift in what's possible — one that changes not just the tools available to you, but what it means to do the job.
I count six of them. We're standing in the middle of Horizon 3. Everything behind us is history. Everything ahead is trajectory, and the view from here is enough to make the next few horizons feel uncomfortably close.
We don't know yet. The honest answer. Anyone who tells you otherwise is selling something.
The shift from workshop to factory that defined the industrial revolution maps almost perfectly onto what's happening to software development now — not as a loose metaphor, but as an actual structural description of what's changing.
The workshop craftsman knew how to make the thing. Every product passed through his hands and carried the marks of his particular skill and knowledge. The factory worker who replaced him didn't need to know how to make the thing — he needed to know how to operate and maintain the machine that made it. Same intelligence. Same pride in craft. Entirely different domain of knowledge.
We have been a software workshop. One developer, one codebase, hands on every line. We are becoming a software factory. The question worth sitting with is: which part of the factory are you learning to operate?
In the factory, two roles become essential. The operator runs the machines — directing their output, making decisions about what gets made and how. The maintainer keeps the machines healthy — understanding them well enough to diagnose failures, make repairs, and know when something is behaving strangely. In the language we've started using, these map to the Software Delivery Operator and the Software Delivery Maintainer. SDO and SDM.
Neither is lesser. The factory breaks without both. What I want to be careful about is the assumption that these new roles somehow flatten everything — that experience stops mattering, that the years you've put in learning systems thinking and developing judgment suddenly carry no weight. Trust, scope, depth of understanding — these still accumulate. A senior SDM who has spent years debugging complex systems is not the same as someone who just started. The tools changed. The need for hard-won judgment didn't.
What shifts is where you apply it. A few horizons from now, the senior engineer won't be debugging the code. She'll be debugging the system that writes code. That is not a lesser problem. It may be a harder one.
But here is the part that I think will be hardest for a lot of us to sit with: the SDO and SDM are not engineering roles. They are not QA roles, or design roles, or ops roles. They are all of those things at once — or more precisely, they are something new that the old distinctions don't map onto cleanly anymore. The silos we've spent careers building and defending — engineering on one side, QA on another, design somewhere else entirely, ops in the corner trying to get everyone to care about reliability — those walls are coming down. Not because anyone decided to knock them down, but because the machine doesn't recognize them.
When AI can generate a feature, write the tests for it, flag the edge cases a designer would have caught, and prepare a deployment plan — the question of whose job is that starts to lose its meaning. What remains is the judgment to direct it, and the knowledge to maintain it. That judgment will need to span what used to be four or five different specialties.
I'll be honest: that's going to require some swallowed pride. The engineer who has long viewed QA as a downstream concern will need to genuinely absorb that tradition — not as a courtesy, but because the role demands it. The QA specialist who has felt condescended to by engineering for years will need to step onto that turf without bitterness and claim it. Design, ops, delivery — each tradition carries real knowledge that the others have historically undervalued. The factory ahead needs all of it in the same hands. Whether those hands can actually open that wide is the human problem at the center of this transition, and it's a harder one than any of the technical horizons.
What each role actually demands — and where each one traps you. The SDO runs at business speed as a generalist embedded near the product. The SDM maintains specialist depth on a pipeline that, in most cases, should be bought rather than built.
The question worth sitting with isn't whether these changes are coming — they are — but what to do before they arrive. A few things seem worth the investment now.
Think product first. Each horizon moves the meaningful layer of developer work closer to the question of why something is being built rather than how. If you've spent years with your head down in implementation — which is honorable, necessary work — now is a good time to lift it. Understanding the product deeply enough to make decisions about it, not just execute against a spec, will matter more with each passing horizon.
Reduce the jargon. Not because technical rigor doesn't matter — it does, deeply — but because the audience for your work will keep expanding as AI absorbs more of the implementation layer. The ability to speak plainly to a product manager, a business stakeholder, someone who doesn't think in systems — that's not a soft skill. It's an increasingly load-bearing one.
Developers fluently choose the right programming language for every runtime. Natural language works the same way — and most engineers are running the wrong dialect in the wrong environment. A deep dive into what that costs and how to fix it.
Learn to evaluate AI output, not just produce it. At this horizon and the ones ahead, one of the most valuable things you can do is develop the judgment to know when the machine is wrong. That's a different skill than knowing how to write code. It requires taste, pattern recognition, and enough domain depth to catch a plausible-sounding mistake. The developers who build that evaluative muscle early will have a meaningful edge over those who learn to trust the output uncritically.
Understand the full delivery pipeline. If the silos are collapsing, fluency with only your slice of the process becomes a liability. How does a requirement become a ticket? How does a ticket become code, tested and deployed and monitored in production? Most specialists have a vivid picture of one part of that chain and a vague sense of the rest. That vagueness is fine until it isn't. Closing those gaps — even partially — is one of the most practical investments you can make right now.
Start building tools that shrink the distance between product and deployment. This is where I think the most interesting work is happening right now, and where engineers can create disproportionate value. Recently I built a Slack app with a simple slash command — /bug-report — that allows a product person to intake a bug directly from where they already work. The system refines it into a fully fleshed-out Jira ticket and reviews the affected code, all without involving an engineer in the intake loop. The natural extension is the system drafting a suggested fix and opening a PR for review. That's one small tool, but it collapses what used to be a multi-step, multi-person, multi-day process into something closer to a single action. The gap between "a product person noticed something" and "the codebase has a proposed fix" shrinks from days to minutes. Finding those gaps in your own organization and building toward them — that is the SDO/SDM work before the tools do it for you.
Protect your institutional knowledge. The history of a codebase lives in people — why a system was built the way it was, which decisions were made under pressure and regretted later, which parts are held together with good intentions and old assumptions. As the mechanical work of software development gets automated away, that contextual knowledge becomes more valuable, not less. It can't be generated. It can only be accumulated, recorded, and passed on. The developers who have it, and who take seriously the responsibility of preserving it, will find themselves more needed at each horizon, not less.
What this moment is disclosing is something that was always true about software development: the writing of code was never really the point. The judgment, the communication, the understanding of systems and people and problems — that was always the job. We just spent a long time in a world where writing the code was also required.
The workshop craftsman who understood his trade deeply didn't become useless when the factory arrived. He became essential to running it — if he was willing to learn what running it required. The developers who come through this well won't be the ones who resisted the change or the ones who surrendered to it uncritically. They'll be the ones who understood what was actually being asked of them at each horizon, and showed up for it.