Is GenAI the Next Step in the Programming Abstraction Ladder?

While I consider myself fantastically lucky to be working for a company that doesn't incorporate GenAI in the development of their products, I still use it occasionally in side and personal projects, mostly in "Ask Mode" like a glorified search engine.

Economic, political, and environmental concerns aside, I believe AI can be incredibly useful when deployed and used effectively.

This article is my attempt to challenge the argument often summarized as "English is the new programming language, hand coding is obsolete, you should no longer learn to code," which essentially asserts that AI is a replacement for high-level languages.

This seems to be a fairly common argument in the programming Twitterverse and other communities where programmers and technical builders of all levels like to argue.

#The Following Is My Elaboration on Why I Find This Position Problematic

#Unpredictable & Indeterministic

The first issue I have with this position is the intrinsic paradigm that LLMs are built on, which makes them fundamentally indeterministic and unpredictable, traits that are CRUCIAL in software engineering and engineering in general.

Claiming that LLMs are "the next higher abstraction" disregards this. Graduating from programming with assembly/machine code to high-level languages was beneficial largely because these higher-level languages are compiled/interpreted into low-level/machine code in a consistent, predictable, and deterministic manner. LLMs, in their current state, are woefully lacking in this regard.

#Detaches the Programmer from Basic Constructs & Building Blocks

"Hand coding is no longer economically viable" and "All SWE roles should shift to system architecture and design."

These soundbites suggest that learning and practicing the basic constructs that make up functional software is no longer valuable.

I find this troubling, especially for new engineers, because I don't think engineers can think in systems or architecture properly without first getting their hands dirty with the implementation/mechanical details.

Yes, we've had calculators for a long time now, but understanding arithmetic or mathematics is still valuable, as it enables us to create better calculators and diagnose broken ones.

#The Skill Void

The advent of English-like high-level languages abstracted away many primitive, lower-level implementation details responsible for basic operations. They offered more capable constructs that do more with less, and a natural, expressive syntax that enhances readability and understanding (assuming these features are used effectively).

Then came frameworks and libraries, adding another layer of abstraction that typically offers higher-level functionality, components, and subsystems in distributable packages.

Trying to insert LLMs as the next step in the ladder is a misjudgment because, unlike high-level languages and frameworks, LLMs have no skills inherent to them.

#Why Is That Distinction Important?

It's not, so long as you're using LLMs for prototypes, throwaway projects, or single-purpose tools.

But when the target is serious, production-grade applications meant to serve users at scale, the reliance on LLMs becomes problematic. Extracting a meaningful product or value from current state LLMs depends, among other things, on the skills gained from using high-level languages and frameworks to build reliable, complex, and mature systems that solve real problems. This makes the replacement argument logically unsound.

#But Software Engineers Aren't Paid to Code

True, I'm paid to deliver outcomes, not just output code.

I translate vague business requirements into proper system requirements, decide which problems within my domain are worth solving and how to best solve them, and I own the high-level decisions I make long term.

But to say that code is purely a means to an end is not accurate, because in matters of scale, security, and performance, the "end" or outcome is dictated by code quality. Thus, code is an essential part of it.

This is why I believe coding by hand is still a prerequisite for juniors to effective systematic problem solving, as it represents a path to systematic thinking and allows you to wrestle with problems and continue to grow and gain exposure as an engineer.

This is how the mind expands, not in the spoon-feeding, highly-guided environment that agentic AI provides.

#Dependency & Lack of Ownership & Agency

High-level languages, most frameworks, and libraries are free to learn and use (and always will be, no heavy subsidization needed). You can largely attribute the phenomena of "self-taught devs" to these two things.

Not to mention, they've never raised concerns about potentially exposing your IP to unauthorized use or training merely by using them.

Furthermore, as a software professional ultimately responsible for the code I push to production systems, I find that agentic workflows present a serious risk to ownership.

Do you really own the code you ask of or let an LLM generate? Maybe, but even then, the degree of ownership is generally lower vs hand coding, even if you're ultimately responsible for it regardless.

Sure, you can try and compensate with code reviews, but depending on how much code you're producing with AI, this has the potential of crippling your pipeline to the point where hand coding starts to prove more productive overall.

#Conclusion

Is GenAI THE next step in the programming abstraction ladder? Maybe that's true one day.

In the current state of things, though, I'd argue that it's at best A step in the ladder, an aid in implementation, iteration, and maintenance, rather than a replacement for them.

Keep on engineering!