Will Vibe Coding Replace Developers? COBOL Already Tried.

Last month I spent about forty minutes arguing with Claude Code about a rate limiter.

Not debugging a rate limiter. Not implementing one. Arguing. I had typed “add a usage limit to the free tier” and gotten back something that technically worked — it counted things and stopped you when you hit the limit — but was also completely wrong in about six different ways that I hadn’t specified because I hadn’t thought to specify them.

When does the counter reset? Daily? Monthly? On the billing cycle? What counts as a usage event — an API call, a feature access, a row stored? What happens at exactly 100%: hard block, soft warning, grace period where we beg you to upgrade? Do existing free users get grandfathered, or do they wake up tomorrow blocked from the thing they’ve been using for three months? What if someone hits the limit mid-checkout?

I hadn’t answered any of those questions. I had typed eight words and expected a computer to answer them for me. And the computer, being a computer (a very impressive one, but still a computer), had silently picked answers that seemed reasonable. UTC midnight resets. Hard blocks. No grandfathering.

Nobody wants UTC midnight resets. Nobody wants a hard block in the middle of checkout. And nobody, including me, had thought to say so.

That forty-minute argument was, in the precise technical sense, programming. Not in the syntax sense. In the real sense: figuring out exactly what I wanted the computer to do, in enough detail that it could actually do it.

Which brings me to Grace Hopper, and why the current panic about AI replacing developers is about sixty-five years old.

In 1959, Grace Hopper helped create a programming language called COBOL.

Common Business-Oriented Language. The name is the pitch. This isn’t for programmers — it’s for business people. The syntax looked like a business memo. You wrote ADD SALESTAX TO TOTALPRICE GIVING INVOICE-TOTAL. Sentences. Paragraphs. English words that a manager could theoretically read and understand and maybe, just maybe, write.

The promise was explicit: if the language is human enough, we won’t need programmers as intermediaries. Business users could specify their own software. The bottleneck — translating business requirements into code — would evaporate.

You know how this ends. COBOL created more programmer jobs than almost any technology before or since. Banks ran it for sixty years. Governments still run it. The programmer shortage it was supposed to prevent became one of the most persistent gaps in technology. The job postings for COBOL developers today — today, in 2026 — pay embarrassingly well because the people who understand those systems are retiring and there aren’t enough people to replace them.

The promise evaporated. The programmers did not.

Now, the obvious response here is: that was 1959. We were trying to replace programmers with verbose English-looking syntax. That’s completely different from vibe coding, which uses actual English, processed by a large language model that has ingested most of human knowledge. The comparison is unfair.

Fair enough. Let me make it fair.

After COBOL came 4th generation languages — the 70s and 80s promised that business users could generate reports and query databases without programmers. And they could! Until anything got complex, at which point someone had to specify what “complex” meant. That someone was, increasingly, a programmer with a different job title.

Then HyperCard in 1987. Anyone could build interactive applications — stacks, cards, buttons, scripts. And many people did! Wonderful things. And then the moment you wanted it to do something non-trivial, you needed to understand enough about conditional logic and data structures that you were, functionally, programming. The interface was friendlier. The underlying activity was identical.

Then no-code in the 2010s. Citizen developers. Visual workflows. Drag-and-drop databases. I watched three different companies I worked at try to use no-code platforms to “reduce dependency on engineering.” It reduced dependency on engineering the same way COBOL did: by creating a new class of technical specialists (now called “no-code developers” or “operations engineers”) who spent their days fighting with visual tools that couldn’t quite express what they needed to express.

Same experiment, sixty-five years, same result. Better interface, same bottleneck.

Here’s what I think is actually happening, and a comment on a Hacker News thread about agentic engineering said it more precisely than I can:

“When you get down to breaking down that problem... you become a programmer.”

The average person doesn’t know what their actual problems are in sufficient detail to get a working solution. Not because they’re not smart. Because the act of breaking a problem down into precisely specified steps that a computer can execute without ambiguity is programming — regardless of whether the syntax is COMPUTE TAX = PRICE * RATE or def calculate_tax(price, rate): return price * tax or “hey, write me something that calculates tax.”

The specification is the programming. The syntax is just notation.

Vibe coding is genuinely different from COBOL in one important sense: the interface change is more dramatic. Natural language processed by a model that can write working TypeScript from a vague description is qualitatively new. The gap between “what you type” and “what runs” has never been smaller.

But the gap between “what you type” and “what you actually wanted” is exactly as large as it’s always been. Possibly larger, because the tool is so capable that it confidently fills in every unspecified detail, silently, in ways that seem reasonable until they’re not.

My rate limiter reset at UTC midnight because I didn’t say it shouldn’t. The agent wasn’t wrong. I was underspecified.

What vibe coding has genuinely changed: the syntax, the boilerplate, the standard implementations of standard patterns are now basically free. A solo developer with Claude Code can ship in a week what used to take a team a month. That’s real leverage and I use it every day.

What hasn’t changed: the irreducible core of the job — figuring out with enough precision what you want the computer to do — is still entirely human work. And based on sixty-five years of running this experiment, there’s a reasonable argument that it’s definitionally human work. When you get specific enough about a problem to get a working solution, you’ve already done the programmer’s job. You might be doing it in plain English now instead of Python. You’re still doing it.

The developer job is changing. Less time on syntax, more time on the thinking that was always the hard part. More time arguing with your tools about exactly what you meant. More time specifying the edge cases before the tool invents its own.

If you’ve ever wanted to spend less time fighting TypeScript compiler errors and more time actually thinking about what you’re building — genuinely, that part is better now.

But the thinking is still yours.

The programmers are still here. They’ve been here since 1959. They’ll be here after vibe coding. They just keep getting better tools.

Learn from the evidence. It’s sixty-five years old and it’s not subtle.