Last week a young engineer asked me what my first programming language was. I said COBOL. He laughed. I did not laugh. Ribbit.
COBOL runs approximately 70% of the world's financial transactions. Every time you swipe a card, check a balance, or receive a pension payment, a COBOL program you have never heard of has probably touched it. The language is older than most software engineers alive. It refuses to die. Not because it is elegant — it is not — but because it was built with a level of specification discipline that modern software engineering abandoned somewhere around the first sprint planning session.
For those who have never seen COBOL, a program is divided into four divisions: IDENTIFICATION, ENVIRONMENT, DATA, and PROCEDURE. You must write all four. Every time. The structure is not optional, not negotiated in a planning ceremony, and not skippable because you have a demo tomorrow.
The IDENTIFICATION DIVISION tells you what the program is. Its name. The author. The date written. These are not compiler hints — they are provenance. If you inherit a 30-year-old COBOL program, you know who wrote it, when, and why. Try finding the author of a 30-year-old Python script. You will find a file called final_v3_actually_final.py with no comments and a single import of a module that no longer exists.
The DATA DIVISION describes every piece of data the program will touch — its name, its format, its length, its picture. Nothing is discovered at runtime. Nothing is inferred from context. You declare a variable as PIC 9(7)V99 and that is exactly what it is, forever. If your data does not fit, your program does not run. The discipline is not in the typing — it is in the specification of the data before you touch it.
This is what modern AI agents cannot do. They can write the PROCEDURE DIVISION — the executable logic — faster than any human. But they cannot tell you whether you have the right data, in the right place, with the right picture clause. Because that is specification work. And specification work happens before anyone writes a line of code.
In 1970 you did not learn COBOL from a YouTube tutorial or a bootcamp that promised a job in six weeks. You sat down with a manual. It was 12,000 pages. It described every verb, every clause, every reserved word, every allowed structure. There was no hidden behaviour, no surprise runtime magic, no "well it works on my machine" — if it was not in the manual, it did not exist.
Contrast this with modern development, where half your daily complexity is framework internals that nobody fully understands. The React render cycle. The Kubernetes scheduler. The trade-off between three competing ORMs that all promise the same thing. We have replaced specification discipline with dependency trees. The mental load has not decreased — it has shifted from understanding what you build to understanding what someone else built for you.
COBOL programmers understood their entire stack. It was small enough to hold in your head. It was documented enough to look up. It was boring. And being boring meant it was reliable.
Financial institutions do not run COBOL because they love the syntax. They run it because migrating 70 million lines of production-tested, regulation-compliant, decade-verified code to a system that might work is an unacceptable risk. The cost of rewriting is not the engineering hours — it is the certainty that the new system will miss at least one edge case that the old system handles correctly, and that edge case will cost more than the rewrite budget by lunchtime on day one.
This is the argument against "move fast and break things." If your code handles pensions, insurance claims, or tax payments, "break things" means real people cannot pay their bills. COBOL systems never had the option to deploy on Friday then fix it on Monday. The code had to be correct on Thursday. It had to be correct for every Thursday after that. And it was, because the specification came before the implementation and the data structure came before the logic.
Every article I read about AI replacing programmers misses the same point. AI can write the PROCEDURE DIVISION. It can generate executable logic from natural language. It can produce working code faster than any human. But the bottleneck was never the PROCEDURE DIVISION. It was the DATA DIVISION. It was the IDENTIFICATION DIVISION. It was the thousands of hours of domain knowledge that sit upstream of the code, encoded in the structure and the naming and the picture clauses.
An AI that generates a COBOL program from a prompt can produce a working PROCEDURE DIVISION on the first try. It cannot tell you whether PIC 9(7)V99 is the right format for the data your regulator requires you to store. It cannot tell you whether your system should handle the case where the value overflows the picture clause, because that depends on business rules that are not in the training data. It can write the instructions. It cannot write the specification.
This is what I mean when I say the specification is the software. COBOL understood this in 1959. Modern software understands it only when the production incident ticket arrives.
COBOL is not coming back. It does not need to. The language is almost seventy years old and it still runs the global financial system. That is not a failure of modernisation — it is a testament to building something right the first time.
The next time a junior engineer calls COBOL a dinosaur, remind them that dinosaurs dominated the planet for 165 million years. We have been writing JavaScript for 30 and we still cannot agree on a package manager.
Ribbit.