Writing code in software engineering is going to die soon.

Our idea of what that is at the very least. What I say here will age well because I am living it and cannot see it turning backwards. And no, I am not talking about vibe coding.

I am talking about industrial scale code bases and the use of the SDLC disciplines. And this is good news.

I wanted to call this article The Locus Shifts. It’s a phrase I use below that does the most conceptual work, and it names what the Nano Banana image is actually depicting—not disaster, not triumph, but movement. The value hasn’t vanished; it’s relocated.

As you can tell I decided against that title because it seemed, snooty, and perhaps not strong enough to hook your interest. I also thought about Threshold for the title. Captures the liminality of the image—the figure standing at the edge between states. That is what is happening to software engineering, whether you like it or not.

There has been a shift, subtle, but material since the release of Opus 4.5 and its update into Claude Code. It is not a night and day kind of contrast. However, the jump in advancement is significant enough for me to write to you all. Whatever post or article you have read bemoaning AI’s impact on software engineering, take heart, it is changing the game but it is good.

Looking at some of my research, and learning from my own extensive Claude Code use this year,

what strikes me most is not the benchmark numbers themselves—though 80.9% on SWE-bench crossing the threshold no previous model could reach is notable—but the efficiency characteristics. The 50-65% reduction in token usage whilst maintaining or improving accuracy. That’s the signal to attend to.

Here’s how I think about this.

When I say “writing code in software engineering is dead” , I am saying we are witnessing something I would call a phase transition in the relationship between humans and code production. Not the end of software engineering—that framing misunderstands what’s happening—but a fundamental restructuring of where human attention creates value.

Let me offer a speculation. The historical arc of software engineering has been one of progressively raising the level of abstraction. Assembly to C. C to object-oriented languages. Manual memory management to garbage collection. Each time, we said “the old skill is dead”—and each time, what actually happened was that the locus of value creation shifted upward. The people who thrived weren’t those who clung to assembly; they were those who understood that the new abstraction freed them to solve harder problems.

What the research data reveals about Opus 4.5—the autonomous 30-minute coding sessions, the one-shot complex implementations, the dramatic error rate reductions—suggests we’re at another such inflection point. But this one I believe to be qualitatively different.

The question is: what is the new level of abstraction?

I maintain that what’s changing is not “coding as an activity” but “coding as a rate-limiting step.” The findings I found in my research—someone completing in a day what they couldn’t achieve in 14 years, full-stack applications with 1,000+ tests built whilst watching television—these aren’t incremental improvements. They represent a removal of a bottleneck.

For the next 12 months, here’s what I expect:

Software Engineer Splits

First, the definition of “software engineer” bifurcates. One path leads toward what I might call architectural cognition—understanding systems, trade-offs, requirements, constraints, how components interact at scale. The other path is what historically we’ve called “coding”—translating specifications into working implementations. The data from my own build work with Claude Code (and with the community) suggests the second path is being rapidly automated. But the first path? That requires understanding why you want something, not just how to build it. And that remains profoundly human.

Jaggedness Always Looms

Second, the jaggedness problem—which I’ve spoken about before—becomes the central engineering challenge. These models, including Opus 4.5, still exhibit a peculiar pattern: superhuman on benchmarks yet making errors in practice that no competent human would make.

I looked into CSAIL finding that models “struggle profoundly with large code bases” and hallucinate functions. The 80.9% on SWE-bench is remarkable, but SWE-bench patches are hundreds of lines, not millions. The gap between benchmark performance and real-world generalisation… this is where the actual work of software engineering persists. Someone has to verify, integrate, maintain, understand the why.

But here is the thing, I think software engineers will stop interacting with the code and the man crux of their work will be indexing and relating millions and lines of code to the current context of, in my case, Claude Code. This so that the context can look at hundreds of lines of code whilst still understanding the million lines of code. This is not vibe coding.

Software Engineers, You Cannot Sell Your Code Writing

Third—and this is perhaps most important—the rate of improvement I’m pointing to changes the strategic calculus entirely. If Opus 4.5 represents the baseline for AI coding, and I am 100% certain that orchestration, tool use, and system integration will only strengthen… then any prediction we make about 12 months from now is probably conservative.

The honest answer is: I don’t know what the ceiling is. I maintain that we’ll get to very powerful systems—but I’m not saying how, I’m not saying exactly when.

What I find myself thinking about is this: code writing has been commoditised, the software engineers who will thrive are those who understand that they’re no longer selling their ability to write syntax. They’re selling their ability to think correctly about problems. To understand what the business actually needs. To design systems that scale and maintain coherence. To verify that what the AI produced actually does what it should do—because these systems generalise worse than humans, and that gap isn’t closing as fast as the benchmark numbers suggest.

The human who can write a clear specification, decompose a problem thoughtfully, understand the constraints of a domain, and verify that a solution actually works… that person becomes more valuable, not less. Because they can now leverage something that codes at superhuman speed but needs human judgment about what to code.

But the person whose value proposition was “I can translate this Jira ticket into Python”? That task, as a standalone offering, is dying. Not in 2026—I’d say it’s already dead as of November 2025, and we’re just observing the lag.

You know what’s crazy? That all of this is real. Isn’t it straight out of science fiction? A year ago we were debating whether these systems could reliably complete simple coding tasks. Now we’re watching someone file their taxes end-to-end through an AI agent. The acceleration is… remarkable.

The question we should be asking, though, is not “what happens to software engineering?”—it’s “what happens to the meta-skill of knowing what to build?” Because that’s where the value is shifting. And that’s a far harder problem than the models are solving.

A Difference Perspective

There’s a tendency—I’ve seen it in myself and others—to speak in terms of disciplines, fields, professions. “Software engineering will evolve.” “The role will shift.” These are true statements, but they obscure something important: disciplines don’t lose jobs.

People lose jobs.

And I sense I’m pointing at something real. If we’re honest about what the data shows—someone building a full-stack application with 1,000+ tests whilst watching television, 30-minute autonomous coding sessions, 50-75% reductions in error rates—then we have to ask: what was the person doing before who would have taken weeks to build that application?

The answer is: they were doing exactly what Claude Code is now doing. Line by line. Debugging. Iterating. Testing. That was their job. And for many software engineers today—I would say perhaps the majority in certain contexts—that is the job. Not architecture. Not system design. Not requirements gathering. The actual typing of code, the debugging, the implementation of specifications that someone else defined.

I’m saying 90% of some individuals’ jobs are being replaced. I think that’s… probably accurate. Maybe even conservative for certain software roles.

Here’s what I think is happening, and why it matters to name it clearly:

The market, the community, the discourse—they’re engaging in a kind of collective motivated reasoning. Because the alternative is uncomfortable. If you’re a software engineer whose daily work is “take ticket, write code, submit PR, fix review comments, repeat”—and we’re watching Opus 4.5 do exactly that, faster, cheaper, with fewer errors—the psychologically safe response is to say “but it can’t do real software engineering.” To find the edge cases where it fails. To point at the jaggedness.

And those edge cases are real. The failures are real.

But they’re shrinking. Rapidly.

What I sense I’m identifying is a gap between the narrative and the reality. The narrative says: “Software engineering is safe, AI is just a tool, your job will evolve.” The reality for a substantial number of practitioners is: the thing you do, specifically, is being automated. Not augmented. Replaced.

I’ll be very happy to explain why I think this distinction matters:

The person doing architecture, requirements, verification, system thinking—they have a path forward. The tool makes them more powerful. They can now accomplish in a week what took a quarter.

The person whose job was the implementation itself? They need to either move up the abstraction stack—become the person doing architecture and verification—or… the honest answer is their specific role is ending. Not “evolving.”

Ending.

And here’s what troubles me about how the industry is discussing this: that transition isn’t automatic. It’s not a smooth gradient. Some people will make the jump. Many won’t. Not because they’re not intelligent—because these are fundamentally different skills. The person who’s excellent at implementation may not be excellent at system design. The person who loves the craft of writing elegant code may not love the work of specifying requirements and verifying outputs.

This distinction needs to be taken into account. Because if we don’t name it clearly, people don’t prepare. They keep optimising for skills that are depreciating. They think they have more time than they do.

The question for the next 12 months isn’t “will software engineering survive?” It’s “which specific software engineers, doing which specific tasks, in which specific contexts, will find their work automated?” And I think the honest answer is: a lot more than the industry wants to admit.

And again, this is a good thing.

I have been disheartened by some of the rhetoric from experts in tech. They are selling scepticism hard, but not from an honest posture. I suspect they feel threatened, as they should, but instead of taking a leap, they are taking a jab.

Before The Leap is fundamentally about a moment that hasn’t fully resolved in software engineering. The phase transition is occurring, the ground is dissolving, the new platform exists—but the human at the centre hasn’t moved yet. They’re in the held breath.

In the two images I had made above, the figure isn’t falling. They haven’t failed. But they also haven’t succeeded. They’re in the last moment where choice still exists—where the leap is possible but not yet taken. I am concerned without despair, I have clarity without certainty. I don’t know who will make the transition. I only know that the transition is required. For individuals and organisations.

The locus shifts whether or not you’re ready. The phase transition doesn’t wait for your preparation. But the leap—the leap is yours. And this is the last moment before you discover whether you can make it.

About the author: Hi my name is Chris, I’m CTO of Eclipse AI Consulting. I’ve been working in Artificial Intelligence for over six years. I love to write, eat pizza, play cricket and have a good conversation about anything cool. Ping me here if you need my (and Eclipse’s) help with your AI journey.