Vibe Coding Is the FORTRAN of the 21st Century

And the people calling it “slop” might want to brush up on their computer history.

I’m reasonably certain that when the first generation of computer programmers encountered the second generation of programming languages, the reaction among the most accomplished practitioners was something along the lines of, “What is this slop?”

After all, real programmers wrote machine code. They understood precisely what instructions the processor would execute, how registers were allocated, and where every byte of memory went. Who were these amateurs writing assembly language and letting an assembler translate their work into instructions for the computer?

And then came FORTRAN and COBOL: Imagine the horror.

With those, and other, higher-level languages, people who didn’t understand the computer’s instruction set could write programs. Accountants could automate business processes. Scientists could solve engineering problems. Companies could build entire information systems using code that looked suspiciously like English or mathematical notation.

Surely this was the end of serious programming. How could FORTRAN possibly produce code as efficient as something painstakingly hand-crafted in assembly language? How could COBOL possibly compete with a programmer who understood the underlying hardware?

And efficient with respect to what resource, exactly? CPU cycles? Memory? Programmer hours? Calendar time? Dollars?

That last question tends to get lost whenever accomplished technicians explain why the next generation of technology isn’t quite as good as the one they’ve spent decades mastering.

The History of Programming Is the History of Abstraction

I started writing software in 1983. I’ve written plenty of code, spent decades developing software, and accumulated more than twenty patents in the process. I’ve also watched programming evolve from something relatively few people could do into something millions of people could do. Every major advance in programming has moved us farther away from the machine.

Assembly language freed programmers from writing raw machine instructions. FORTRAN and COBOL freed them from thinking primarily in processor instructions. C, Pascal, and their successors offered increasingly powerful ways to express algorithms and organize software. Modern languages, libraries, frameworks, and cloud services abstract away enormous amounts of complexity that earlier generations of programmers had to manage themselves.

Each transition surrendered some degree of direct control in exchange for productivity, accessibility, and the ability to solve bigger problems. And, sure, each transition created new opportunities for bad software. FORTRAN programs had bugs. COBOL applications had architectural problems. C programmers created memory leaks. Object-oriented programming gave us impressive new ways to turn relatively simple problems into elaborate systems of interacting abstractions.

Yet, somehow, civilization survived.

More importantly, a staggering number of valuable business, scientific, and engineering problems were solved by people who had never written a line of machine code.

Nobody seriously argues that every FORTRAN programmer should have been required to examine the compiler’s assembly output, instruction by instruction, to determine whether the resulting program was sufficiently efficient. We judged the software primarily by whether it accomplished its purpose, how reliably it worked, and what it cost to create and operate.

Which brings me to vibe coding.

Today’s Slop Is Yesterday’s High-Level Language

It’s become fashionable to dismiss applications developed with AI assistance as “slop.”

The criticisms are familiar: The code is unnecessarily complex. The architecture isn’t elegant. The application uses inefficient algorithms. It introduces dependencies that an experienced programmer wouldn’t have chosen. The person who requested the application may not understand how it works. And perhaps most damning of all, nobody has reviewed every line of the code.

These criticisms aren’t necessarily wrong, they’re just not particularly new. You could have said essentially the same things about generations of software developed using higher-level languages and tools.

Of course AI-generated code can be inefficient. Of course it can contain bugs. Of course the underlying implementation may be less elegant than something written by an accomplished software engineer who spent six weeks thinking carefully about the problem.

But suppose the AI-generated application took an hour to build, works reliably, and solves the business problem. And suppose the handcrafted alternative would have taken two months. Which one is more efficient? The answer depends on what you’re measuring.

The obsession with the elegance of the underlying code reminds me of criticizing a spreadsheet because its author couldn’t explain how Microsoft Excel implements floating-point arithmetic. The spreadsheet might be wrong. Its formulas might be poorly constructed. Its assumptions might be indefensible. Those are legitimate criticisms. But the fact that its author doesn’t understand Excel’s calculation engine isn’t one of them.

The ability to solve a problem and the ability to explain every instruction used to solve it are not the same thing.

They never were.

But AI Isn’t Just Another Compiler

There’s an important distinction between traditional programming languages and AI-generated software: A compiler generally translates a program according to defined language rules. A FORTRAN programmer specifies an algorithm, and the compiler produces machine instructions implementing that algorithm. The programmer may not understand the resulting assembly code, but the compiler isn’t ordinarily inventing the business logic.

AI is different. When I ask an AI to build an application, I’m frequently delegating not only the mechanics of writing code but also substantive implementation decisions. The AI may select algorithms, design data structures, choose dependencies, construct database schemas, and decide how to handle circumstances I never specifically addressed.

Sometimes it makes good decisions. Sometimes it makes terrible ones. And sometimes it makes decisions that appear entirely reasonable until the application encounters a circumstance nobody anticipated.

But here’s the question: Does the fact that AI makes implementation decisions mean that every one of those decisions must be independently reviewed by a human programmer?

I don’t think so. I think it means we need to think more carefully about how software is verified.

Traditional software development already depends on extensive delegation. Programmers use libraries containing millions of lines of code they haven’t personally reviewed. They depend on operating systems whose internals they don’t understand, database engines they didn’t write, and cloud services whose implementation details they couldn’t inspect even if they wanted to. That arrangement works, not because every line of code has been examined by the person deploying the software, but because we have developed ways of evaluating reliability without requiring universal knowledge of implementation: Testing. Validation. Documentation. Established interfaces. Monitoring. Independent audits when the stakes justify them. None of these methods is perfect, of course. Neither is human code review.

The difference with AI is that we may need to apply some of these disciplines more deliberately, especially when the system is making decisions that would previously have been made by a human developer.

And that brings us to a much more useful question than whether the code is “slop.”

What level of verification is justified by the consequences of getting the answer wrong?

A little utility that reformats a CSV file doesn’t require the same scrutiny as software that calculates payroll, manages investment accounts, or controls an aircraft. Some applications can be adequately verified through carefully designed functional tests. Others require security assessments, examination of algorithms, analysis of failure modes, and human review of critical portions of the implementation. In some cases, the AI-generated code may be entirely unsuitable without substantial revision.

Fine. Those distinctions existed before AI, too. The goal isn’t to eliminate software engineering discipline. It’s to apply that discipline where it produces the greatest value. Requiring a human to review every line of every AI-generated application, regardless of purpose or risk, is not engineering rigor. Instead it’s an extraordinarily expensive process that only looks like engineering rigor.

You Don’t Have to Understand Every Line. You Have to Understand the Requirements.

Here’s where I think much of the criticism misses the point.

The most important skill in developing useful software has never been typing instructions into a computer. It’s understanding the problem well enough to specify a solution. That hasn’t changed. Under-specified software produces bad results. Incorrectly specified software produces incorrect results. Requirements that fail to contemplate foreseeable edge cases produce systems that fail when those cases arise. AI doesn’t repeal those rules.

In fact, as the cost of producing code approaches zero, the relative importance of getting the specifications right increases dramatically. If I ask an AI to create a system that calculates child support, and I fail to specify the applicable jurisdiction, statutory caps, treatment of multiple support obligations, or effective dates of statutory changes, I shouldn’t be surprised when it produces something that looks impressive but calculates the wrong answer. That’s not principally a coding problem, it’s a specification problem.

But even a beautifully written specification won’t anticipate every possible circumstance. That’s why verification must involve more than asking the AI whether it did what it was told. The system needs to be tested against independently established expectations. Edge cases need to be considered. Critical calculations need to be checked against authoritative sources. And where the consequences justify it, experienced professionals need to inspect the underlying logic.

Notice, though, what we’re doing. We’re concentrating human effort on determining whether the software is correct and trustworthy, rather than assuming that trustworthiness necessarily requires a human being to personally construct or inspect every component. This is an important distinction.

A programmer can understand every line of an application and still misunderstand the business problem it’s supposed to solve. Conversely, someone who understands the business problem exceptionally well may be able to specify, test, and validate an AI-generated application without understanding every line of its implementation. Neither expertise is sufficient in every situation. But the proposition that only the person who understands the code can determine whether the software is useful is increasingly difficult to defend.

Why All the Hostility?

I suspect three things are driving much of the hostility toward AI-generated software.

First, the technology is improving faster than the commentary.

I’ve personally watched AI models generate completely unworkable code. I’ve watched them confidently produce applications that ran but didn’t actually do what I asked. I’ve spent plenty of time correcting their mistakes. That was a fair characterization of a lot of early AI-assisted programming. But the capabilities have improved enormously, and they continue to improve.

A criticism that was entirely justified eighteen months ago may be hopelessly outdated today.

Unfortunately, the editorial cycle doesn’t necessarily move at the speed of the technology. And in a world where provocative headlines generate clicks, “AI Code Is Slop” is a more marketable headline than “AI Coding Systems Have Improved Substantially, Although Important Limitations Remain.”

Second, there’s a certain amount of professional snobbery, perhaps accompanied by a failure of imagination.

A talented Python or Rust programmer has invested years learning how to build software well. That’s an impressive accomplishment, deserving of respect. But expertise can become a liability when it makes someone incapable of imagining a fundamentally different way of accomplishing the same objective. If you’ve spent your career refining your ability to do something that takes two months, it’s understandably difficult to embrace the possibility that a machine might accomplish substantially the same thing in an afternoon.

It’s tempting to respond by pointing out everything the machine did differently from how you would have done it. And if you look hard enough, you’ll find plenty. But proving that the machine didn’t do the job the way you would have done it isn’t the same as proving that the machine didn’t do the job.

Third, I think there’s some genuine fear about what comes next.

This is the part people tend to be less comfortable discussing. If a machine can eventually perform 80% of the work traditionally performed by an entire profession, at a fraction of the cost, without vacations, sick days, evenings, or weekends, that profession is going to change. Some jobs–probably a great number of jobs–will disappear. Others will change dramatically. New jobs will emerge, although not necessarily for the same people, in the same places, at the same compensation, or even one for one. There will be some losers. Different (important, maybe urgent) topic for a different day.

We’ve seen versions of this story before. But knowing that technological change creates new opportunities doesn’t make it any less threatening to the people whose existing skills are being commoditized. And one predictable response to that threat is fear, uncertainty, and doubt: The technology is dangerous. It can’t be trusted. The output is inferior. The people using it aren’t real professionals.

Maybe if enough people repeat those criticisms loudly enough, the change can be slowed. I suspect that’s a little like trying to stop a tsunami by screaming at the ocean. Even a million people screaming at the ocean won’t change what happens next.

The Next Generation of Programmers May Not Be Programmers

I don’t think traditional software engineering is going away entirely. There will continue to be important problems requiring people who understand algorithms, architecture, security, performance, and the underlying machinery.

In fact, as AI makes it possible to create dramatically more software, some of those skills may become more valuable, particularly in designing verification systems and evaluating high-consequence applications.

But I think we’re witnessing something much more significant than the arrival of a new tool for professional programmers. We’re watching the cost of transforming an idea into working software collapse. A business owner who understands a workflow, a scientist who understands a research problem, or a lawyer who understands a legal process can increasingly create useful software without first spending years learning the languages and techniques historically required to implement it.

That doesn’t mean everyone with an idea will produce good software. It means the people who understand the problems may no longer need to hire an entire team of people who understand computers before they can begin solving them.

That’s an extraordinary development. And it should remind us of what happened when FORTRAN and COBOL put computational capabilities into the hands of people who weren’t machine-language programmers. The result wasn’t the destruction of software engineering, it was an explosion in the number of problems that software could solve.

I expect AI-assisted development to produce a similar expansion, probably on a much larger scale. Some of the code will be terrible. Some of the applications will fail. Some of the people creating them will have no idea what they’re doing. And some will create enormously valuable software that would never have existed under the old economics of software development.

The proper response isn’t to pretend that AI-generated software has no risks. It’s to develop economically sensible ways of managing those risks. Inspect what needs inspecting. Test what needs testing. Verify what matters. And stop confusing the amount of human labor invested in producing software with the quality of the software itself.

The important question isn’t whether an AI can write code as elegantly as the best human programmer. It’s whether the resulting application solves a problem, reliably, at an acceptable total cost—including the cost of verifying that it works.

Vibe coding is the FORTRAN of the 21st century.

And the people dismissing it as slop may someday sound a lot like the assembly-language programmers who couldn’t understand why anyone would let a compiler write their machine code.