When I was a young engineer, there was a gruff old programmer named Larry who often imparted his wisdom to us young’uns. A man in his forties, he had that gritty, seen-it-all manner that bespoke years of hard-fought battles in the coding trenches. His was a heart of gold covered in a cloak of cynicism; imagine Philip Seymour Hoffman as a Perl programmer.

Over his fourteenth cup of coffee, Larry would dispense his ruminations on the life of coding, the realities of projects (and project managers), and the virtues of vi versus EMACS. One thing he said, that has stuck with me all these years, was that fourth-generation languages (4GL) had never worked and never would.

Like most software developers, I have been frolicking in the gardens of AI-generated code for a couple of years now. I’m starting to wonder: Is this it? Have we arrived at the long-awaited utopia of 4GL?

What is 4GL?

Wikipedia has a good overview of the fourth-generation language concept, which was supposed to sweep across software like a revelation. Among other things, 4GLs are sometimes described as “program-generating languages.” They are a higher-level abstraction from familiar third-generation languages like Java and JavaScript, and tend to focus on more natural language syntax.

Terms like natural language interface and program-generating certainly do sound like generative AI, don’t they? There was even a book written in 1981 called Application Development Without Programmers, which foresaw a future where artificial intelligence would replace human developers.

But actual 4GLs like FOCUS, along with modern derivatives like WYSIWYG editors, rapid application development (RAD) frameworks, and low-code/no-code platforms, all fail to live up to that promise for one simple reason: They all require a developer who knows how to use them. Even with natural language coding solutions, there are times when someone needs to be able to drop into the underlying system and fix it. (See my recent Roo Code review for more about this.)

4GL and generative AI

Most non-programmers would agree that using a 4GL-derived solution feels a lot like programming. Even a WYSIWYG RAD framework requires considerable thought and some knowledge of programming concepts. You need a basic understanding of datastores and schemas (yes, even with NoSQL), the middleware that connects a datastore to the interface, and the interface itself. You also need to understand the relationship between services and APIs and the infrastructure that enables and secures them.

This also seems to be true when using large language models (LLMs) to generate code, but to a lesser degree. Very broad natural language descriptions of functionality are not terribly effective. What is most effective when programming with AI, in my experience, is an iterative back-and-forth process that dips in and out of varying degrees of granularity.

The more we push abstractions to handle complexity, the more evident it becomes that a proficient human being must still drive the work itself. Understanding the details that are smoothed out by abstraction become more important when each of the parts and all their interrelations are stretched.

When working directly on the details of a component, using a 4GL tool to interface with it can feel like trying to do detailed handiwork with bulky gloves on. I think most experienced programmers would say the same about using an AI coding assistant.

What AI gets right

Don’t get me wrong: It’s incredibly handy to be able to ask an AI tool to spit out a decent function that does exactly what you need, and a recent study shows that more senior developers are taking full advantage of AI capabilities. But the more broadly we shotgun AI power at complex problems, the more we create something that feels like technical debt. Maybe a better term in this case would be comprehension debt.

AI is a great tool for interfacing with general knowledge about design and architecture. The ability to bring programming code and concepts into a common frame is a big advantage of AI, and of 4GL. But to leverage either tool, the user must have some basic understanding of programming concepts and how they are applied.

Without the will to completion

Higher order abstractions tend to excel at prototyping, but they’re not so well-suited to developing the final product in production. That last act tends to require one or more people who not only understand the underlying infrastructure but have what I call the will to completion.

What I’m saying is, you need someone who will take whatever mechanism is provided and drive toward an envisioned goal, and who will keep adapting and moving forward until that goal is realized. This is a uniquely human trait that cannot be abstracted away. Like 4GL, artificial intelligence may serve that end, but it can’t drive it.

A human programmer brings something to the table which I will call caring, also known as “giving a @#^$.” Every experienced developer by now has noticed the way that AI will just confidently deliver the wrong solution over and over again, or break one thing while fixing another. That’s because AI doesn’t actually care about the result.

When laziness leads to more work

It’s a strange paradox that the more you need the AI, the less useful it is. Seasoned software developers can confidently use AI because, when it goes wrong, we can just jump in there and fix it. Years of programming experience make it easy to see where machine intelligence is going off the rails. But when less experienced developers rely on AI, they are less equipped to catch the mistakes. This is the peril of “lazy programming” writ large.

As an example, consider my long-standing dysfunctional relationship with CSS. The truth is, I’m just not very good at it. For a time, I was thinking AI coding assistance might solve my problem. With AI, I might suddenly become a more competent, less-stressed-out CSS developer. Instead, I am still a mediocre CSS developer—and now also a user of AI-generated CSS.

I can keep muddling through with CSS and leaning on AI tools to catch me when I fail. But the real solution, I’ve found, is to work with a human being who actually understands CSS in all the ways I don’t. That’s okay; I like those people and enjoy working with them. They are magical beings, kind of like those who can cook pasta properly.

Conclusion

The dream of AI looks an awful lot like the dream of 4GL. Clearly, AI has achieved more significance in its practical effects than 4GLs ever did. But the limitations and fault lines are similar enough to merit our attention. I seriously wonder if the vast tracts of AI-generated code will just drive up the demand for more software engineering expertise—old hands like Larry, who remain skeptical any of this will lead to much.