The End of Software Development. And Its Beginning.

In 1989, Francis Fukuyama famously declared the end of history. The Cold War was over, liberal democracy had won, and the great ideological struggles were finished. He was wrong, of course. Not because nothing had changed, but because he mistook the end of one arrangement for the end of the contest itself. The upheaval was real. The conclusion he drew from it was not.

Fukuyama’s thesis echoes throughout the software industry today. You hear it everywhere. That AI has ended software development as a whole, or will soon. These statements are misguided in the same way and for the same reason as Fukuyama’s proved incomplete. Something real has changed. But the contest, the work of building software that serves people and holds up under pressure, is not ending. It is entering a new phase, and most of us in the industry are trying to make sense of it all, to put up some semblance of structure in this new frontier.

I’ve been thinking about this since last October. AI had been around for years already, but working with Claude Code last fall, as Opus 4.5 came out, it became clear that something more fundamental had changed. Was it “the end of history”? I wasn’t sure. But as time went on, it became clear that the way we had been working was plainly coming to an end. So when my most recent contract came up for renewal at the end of January, I opted not to continue, and to take some time off. To take a bit of a sabbatical. To stop and look around at an industry changing faster than its practices can absorb.

I’ve been building software long enough to have survived several hype cycles, and the pattern is always the same: new language wrapped around old practice, until the old practice quietly reasserts itself and everyone moves on to the next thing. But something did change this time, and I saw it clearly in the final months of my last project. I had been developing a skills-based workflow, a structured way of working with AI agents as method rather than novelty. Defined steps. Clear guardrails. The agent handled implementation within boundaries I set, and I handled architecture, review, and direction. By the end of my time on that project, I was shipping ten tickets a day. I saw, with my own eyes, and through my own hands, the implementation capacity of a single developer change by an order of magnitude.

That changed the math for me. Not in the abstract way that conference talks change math, where someone shows a graph and everyone nods. In the specific, undeniable way of having done the work and seen the result. I looked at the staffing ratios, the team structures, the economics of how we organize the work of building software, and the conclusion was plain: this can’t stay as it is. Code is now the commodity. And our interfaces with it, and patterns for creating it, now beckon for new approaches.

What’s ending

It’s not yet entirely clear. It seems at one level we can be reasonably certain that software itself is not ending. Nor is the need for people who understand systems deeply. But it’s also clear that what is ending, or has already ended, is a set of assumptions about how the implementation gets done. The assumption that implementation requires large development teams. That the hard part is typing the code. That you measure progress by headcount to drive velocity.

The five-person dev team that needs to become two developers working differently. The three-month build that could be three weeks with the right methods. These assumptions shaped how we staff projects, how we price work, how we structure careers. They held for decades. They don’t hold anymore.

Another assumption that is ending is the idea that software is written primarily for humans, to be consumed and used by humans. This is a bit more nuanced of course. The end goals of software, the reasons we create it, are still human-centered and human driven. And the building of software is still a team sport, comprised of humans, managing things like feature priorities, budgets, deadlines, and so on. There are still users whose needs have to be understood. Stakeholders whose constraints matter. Analysts who define requirements. Designers who shape the experience. Security and privacy specialists who keep it safe. Operations teams who keep it running. Development teams are getting smaller, but the broader team that makes software worth building isn’t disappearing in the near future. And while some software now will be written for agents, or while APIs might be finding new life in MCPs, the human side of software remains as important as ever. If anything, when implementation accelerates, the work of understanding what to build and why becomes a larger share of the effort.

What’s not replacing it

Speed without structure. The current wave of enthusiasm treats code generation as the whole job: prompt in, application out, ship it, move on. This works for demos. It works for prototypes. It does not work for anything that has to survive contact with production, with other people’s hands, with the Tuesday morning six months from now when something breaks and nobody remembers why it was built that way.

Anyone who has maintained a system for more than a year knows the first version is the easy part. Maintenance is the hard part. Handoffs are the hard part. Traceability, knowing why a decision was made, what changed, what depends on what, is the hard part. The people building throwaway projects with AI right now are having a wonderful time. The people who will inherit those projects are not going to have a wonderful time. We’ve seen this before. We’ve seen what happens when speed outpaces discipline. We just used to call it technical debt.

What doing it well looks like

This can be done well. It requires care about things that aren’t fashionable to care about right now: safety, transparency, traceability, maintainability. These aren’t product features. They’re the difference between software that works and software that worked once. Between a system you can hand to someone else and a system that only its creator can operate, assuming they remember how.

The craft of building software isn’t dying. It’s changing shape, the way it always has. Every generation of tooling has moved the work up a level of abstraction. We stopped writing machine code. We stopped managing memory by hand. Each time, the tools took over the mechanical work and the human role shifted toward judgment, architecture, and decision-making. This is the same pattern. It’s just faster this time, and the jump is bigger.

That jump is exactly why experience matters more now, not less. A powerful tool in the hands of someone who understands the terrain is a force multiplier. The same tool in the hands of someone who doesn’t is a fast way to create problems at scale. And the terrain is never just code. It’s the users, the business rules, the regulatory environment, the team that will maintain the system after you leave.

I’m working on this now. On the methods and the processes that make agentic development something you can rely on, not something you demo and discard. The work ahead is not about preserving old arrangements. It is about building new ones, processes that still bring the right people together, that still hold up under scrutiny, but that account for what a developer with the right tools can now do.

Software has always been a team effort. That doesn’t change. What changes is the shape of the team, the pace of the work, and what we expect from each person in it. Developers now have extraordinary implementation power. That makes the surrounding disciplines more important, not less: the analysis that ensures we build the right thing, the design that makes it usable, the review that keeps it safe, the process that keeps it maintainable.

The interesting question was never whether AI would transform how we build software. It is whether we rebuild our practices, our teams, and our standards to match what the tools now demand of us.

The end of software development, much like the end of history, is not nigh. We’re on the precipice of its next era.