AI Is Not Killing Software Engineering. It Is Making Syntax Less Valuable.

People who equated software engineering with producing code are mistaking the loss of a bottleneck for the loss of the profession.

I keep reading predictions that AI is dismantling software engineering. The argument usually starts with an agent writing code that once required a programmer and ends with the assumption that there is no meaningful work left between an idea and a running system.

That only makes sense if software engineering was primarily the act of translating intent into syntax.

I never saw it that way.

Code was always one part of the job

I started building computers around the beginning of the 2000s, when I was about sixteen, and sold them to local small offices. Being the computer person often meant doing all of it: choosing the hardware, installing the operating system, configuring the network, figuring out the software, supporting the users, and fixing whatever failed afterward.

I later moved through software testing, development, network operations, infrastructure, databases, communications systems, automation, and engineering leadership. Those roles had different titles, but the useful skill was always the same: understand enough of the whole system to make it work and keep it working.

Code mattered. It still matters. But it was a means to an end, alongside a shell command, a database index, a routing change, a replacement disk, a deployment plan, or a conversation with the person who actually had the problem.

The system was the point.

Specialization hid the rest of the system

Technology grew, and specialization was unavoidable. Nobody can be deeply competent in every layer of a modern platform. Specialization gave us better databases, safer languages, more capable networks, and people who can diagnose problems I would not know how to begin solving.

It also made it possible to spend an entire career inside one narrow slice of the process and mistake that slice for the profession.

Some programmers came to treat fluency in a language, framework, or collection of syntax traps as the proof that somebody belonged. The work became an art whose gatekeepers were the people most familiar with its esoteric details. Questions about deployment, failure modes, neighboring services, or what the user was trying to accomplish could be somebody else’s problem.

That bargain works while implementation is expensive. If expressing a decision in code consumes most of the schedule, the person who can do it quickly holds a scarce skill.

Agents are changing that price.

Cheap implementation is not cheap engineering

An agent can produce a credible implementation in minutes. It can also produce the wrong implementation in minutes, wrap it in clean abstractions, add passing tests for its own assumptions, and explain the result with complete confidence.

That is not a reason to reject the tool. It is a reason to understand what the tool made cheaper and what it did not.

It made syntax cheaper. It shortened the slog between a well-defined change and a candidate implementation. It reduced the cost of exploring an unfamiliar codebase, writing repetitive tests, translating an established pattern, and trying an approach that may be discarded.

It did not decide whether the requirement was coherent. It did not discover every unstated dependency. It did not choose the correct system boundary, define the acceptable failure mode, understand the organization’s appetite for operational complexity, or accept responsibility when the result reaches production.

Those are engineering decisions. Faster code makes them more visible because implementation can no longer consume the entire conversation.

The vantage point is moving upward

I find this exciting. We can spend less time manually expressing every line of a design and more time working at the level of complete systems.

That does not mean typing a vague request and accepting whatever appears. It means defining the architecture thoroughly enough that several agents can work within it. It means making interfaces, constraints, tests, deployment behavior, and observability part of the design instead of details deferred until the code exists.

It also means engineers need broader technical range. When one person can direct changes across multiple components, that person needs to understand more about infrastructure, data, security, delivery, and operations. The ability to generate code across the stack is not the same as understanding the stack.

Google’s 2025 DORA research describes AI as an amplifier. Strong systems and teams gain leverage; weak processes produce problems faster. That is a much more useful model than either “AI will replace every developer” or “AI is only autocomplete.”

The tool raises the ceiling and lowers the floor at the same time. A capable engineer can explore and build at a scale that previously required much more time. Someone without the surrounding knowledge can create a convincing system whose defects only appear under real load, during a deployment, or six months later when another component changes.

The craft is not disappearing

There is real craft in programming. I do not want unreadable systems assembled from generated code that nobody understands. Performance work, concurrency, protocols, compilers, storage engines, security boundaries, and many other areas still reward deep specialization.

What is disappearing is the assumption that manually producing ordinary application code is, by itself, the highest-value part of software engineering.

That distinction matters. Defending the value of clear thinking, good design, and maintainable implementations is useful. Defending repetitive implementation because it once kept other people outside the profession is not.

I am self-taught. I learned technology by wanting to build things and following each problem into the next layer. I do not have nostalgia for an era when knowing the correct incantation was enough to establish credibility. Everything in this field changes. Operating systems change, languages change, hardware changes, deployment models change, and the boundaries between jobs change with them.

The ability to learn the next layer has always lasted longer than mastery of the current syntax.

Building systems should have been the dream

If somebody’s dream job was writing syntax, AI is understandably threatening. I think the larger opportunity is better than that.

We can take an idea, reason through its consequences, design the system, delegate much of the mechanical implementation, test the result from several directions, and iterate at a speed that would have been absurd a few years ago. Work that once required months of code production can move toward architecture, experimentation, and operation.

There will still be bad software. There may be much more of it. There will also be engineers who use the same tools to build systems they could never have attempted before.

The profession is not disappearing. Its center of gravity is moving away from the scarce ability to express a solution in syntax and toward the harder ability to understand what should exist, how its pieces should interact, and what happens after it runs.

That is not the end of software engineering. It is much closer to what engineering was supposed to be.

The operational side of that argument is the work required to teach an AI software factory how your systems actually work.

Source

• Google Cloud DORA, State of AI-assisted Software Development 2025.