Why 2026 Kills Coding, But Not Engineering

Claude Opus 4.5 just dropped. And the Anthropic research team claims software engineering could be automated by mid-2026. Our team has been deep in Claude lately and we are genuinely impressed. But we think the industry is conflating two very different things.

Coding Is Not Engineering

Coding is turning logic into syntax. Writing instructions that a machine can execute. Today, LLMs have gotten remarkably good at this. They generate functions, fix bugs, refactor code, and even pass technical interviews better than most humans.

But software engineering? That is everything around the code. Architecture decisions that will not haunt you three years later. Understanding what users actually need versus what they say they want. Coordinating across teams with different priorities. Making tradeoffs when there is no clear right answer.

Soft skills are becoming the new hard skills. Coding is syntax. Engineering is algorithmic and critical thinking.

What Models Still Cannot Do

Software engineering happens in messy environments. Legacy systems with undocumented dependencies. Business requirements that change mid-sprint. Stakeholders who do not know what they want until they see what they do not want. An LLM can write perfect code for a well-defined problem. But how does it handle a situation where the right solution depends on your team's skill set, deployment timeline, technical debt, and the company's risk tolerance?

These demand judgment and taste. Across our engagements, most AI project failures are not technical. They are institutional: misaligned incentives, poor communication, nobody clear on the problem by the time the first sprint closes. The code passes every test. Nothing in the repository explains what went wrong, because nothing in the repository was the problem.

The Context Problem

Think like a software engineer for a moment. You are reading through a codebase someone else wrote five years ago, trying to figure out why they made certain decisions. You are debugging why staging behaves differently from production. You are deciding whether to add that feature now or wait for the refactor next quarter.

You might stop us and say: why not just feed all this to an LLM? You can. But holding a million tokens is not the same as understanding context. It still does not know why that architectural decision was made, what shaped the codebase, or which shortcuts were deadline panic versus deliberate tradeoffs.

The Judgment Gap

Here is what we keep seeing in the field. The companies leveraging AI for code generation are not struggling with code quality. The code models produce today is often clean, well-documented, and follows best practices. The real struggle is everything else.

• Should we build this feature at all?
• Is this the right architecture for our scale?
• What happens when this integrates with the three legacy systems nobody wants to touch?
• How do we handle the security implications nobody thought about?

These questions require empathy. Understanding the business, the users, the timeline, the risk profile, and a dozen other factors that do not appear in any prompt. They are also the reason we put engineers inside client teams rather than handing over a specification. The context that matters is rarely written down anywhere.

The Realistic View

The companies we have seen progressing with AI transformation are not trying to replace their engineers. They are using AI as a multiplier to handle the mechanical parts so their engineers can focus on the judgment calls that actually matter: architecture decisions, tradeoff analysis, and the "should we even build this?" conversations.

The Bottom Line

Is software engineering done in six months? Not even close. The work happens in messy, human environments where requirements are unclear, stakeholders disagree, and the right answer depends on context nobody wrote down.

A model can already write the code. It cannot sit in a room where two directors want different things, work out which one is actually paying for this, and say out loud that the feature they have both agreed on should not be built. That is the job. It was always the job.