Curious Human
Towards a safe, maintainable future for agent-assisted development
In 1989, Francis Fukuyama declared the end of history. The Cold War was over, liberal democracy had won, and the great ideological struggles were finished. He was wrong. 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 the industry is now trying to catch up.
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. Real work, on a real project, meeting acceptance criteria written by analysts and validated by QA. 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. Not because the people doing the work are wrong or the work they do is bad. Because the economics changed underneath all of us, and most of the industry hasn't reckoned with it yet.
Not software. Not the need for people who understand systems deeply. What's ending 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 and 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.
What isn't changing is that software is still built for people and with people. 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 get smaller, but the broader team that makes software worth building doesn't disappear. If anything, when implementation accelerates, the work of understanding what to build and why becomes a larger share of the effort.
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.
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.