In 1972, Edsger Dijkstra stood up to accept a Turing Award and gave a lecture called "The Humble Programmer." He had never seen an LLM. He had never watched an agent rewrite a file in his terminal. And yet what he said that day reads like a direct response to the way we argue about AI coding in 2026. So does a good deal of what his contemporaries wrote over the two decades that followed.
That's the strange thing about the current moment. We talk about vibe coding, generated-code trust, and "is learning to code even worth it" as if they're brand-new problems. They're old problems wearing a new model's clothes. Here are ten quotes, most of them decades old, that predicted the exact arguments we're having now. I'll give you the line, who said it, and why it lands harder in 2026 than the day it was written.
1. The whole case for AI coding, stated in 1972
"The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague."
— Edsger Dijkstra, The Humble Programmer (ACM Turing Award Lecture, 1972)
This is the entire justification for handing work to an agent, written 50 years early. We reach for AI because our skulls are, in fact, strictly limited. The catch is the second half: Dijkstra's humility meant avoiding clever tricks, and a model prompted to be impressive will hand you the cleverest trick it can find. The humble move in 2026 isn't refusing AI. It's refusing the clever output it gives you when a boring version would do.
2. "It ran" is not "it's correct"
"Testing shows the presence, not the absence of bugs."
— Edsger Dijkstra, NATO Software Engineering Conference (1969)
The single most useful sentence to keep taped above your monitor when reviewing generated code. An agent produces something, the tests go green, and there's a powerful urge to call it done. Dijkstra's point is that green tests prove your bugs hid well, not that they're gone. With AI-written code the gap is wider, because the model also tends to write tests that confirm its own assumptions. Passing its own exam is not the same as being right.
3. Why vibe coding has an expiration date
"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."
— Brian Kernighan, The Elements of Programming Style (1978)
Now substitute the model for "you." If an LLM writes code at the absolute limit of its cleverness, and you accepted it without understanding it, then by Kernighan's arithmetic nobody in the room is smart enough to debug it. That's vibe coding's actual failure mode, and I've lived it: a two-hour prototype I didn't read, followed by half a day of re-reading my own project to add one feature. Fun until the bill comes.
4. Confidence is not correctness
"Beware of bugs in the above code; I have only proved it correct, not tried it."
— Donald Knuth (1977)
Knuth could prove his code correct and still warned you it might be broken. LLMs do the opposite: they can't prove anything, but they'll present output with the serene confidence of someone who can. If the most careful computer scientist alive hedged on code he'd formally verified, the right posture toward a model's "this should work" is somewhere south of trust.
5. The readability quote that aged into an AI strategy
"Programs must be written for people to read, and only incidentally for machines to execute."
— Harold Abelson & Gerald Sussman, SICP (1985)
For 40 years this was about your teammates. In 2026 it's also about the agent. The model is now one of the readers, and clean, well-named, well-structured code is exactly what lets it make correct edits instead of confidently wrong ones. The same code that's kind to a junior engineer is legible to an LLM. Readability stopped being a courtesy and became a performance feature.
6. There is still no silver bullet
"The amateur software engineer is always in search of magic."
— Grady Booch
Booch was writing in the lineage of Fred Brooks's "No Silver Bullet," and AI is the most convincing-looking silver bullet the field has ever produced. But Brooks's distinction holds: a tool can strip away accidental complexity (boilerplate, syntax, glue) and do nothing about the essential complexity of figuring out what to build. AI is a phenomenal accidental-complexity eraser. The amateur thinks that's the whole job. It never was. I'd know: I once spent a weekend wiring up an elaborate agent pipeline to dodge the fifty lines of logic that were the actual point, then wrote the fifty lines anyway.
7. AI lets you take on debt 10x faster
"Shipping first-time code is like going into debt."
— Ward Cunningham
Cunningham coined "technical debt" to explain code quality to people who think in money. The 2026 update writes itself: AI lets you ship first-time code at ten times the volume, which means ten times the debt if you never go back to pay it. Debt with no repayment plan is the problem. An agent that can generate a thousand lines before lunch is also an agent that can quietly max out your credit.
8. "Move fast and break things" already got revised once
"Move fast and break things."
— Facebook internal motto (~2009–2014)
Facebook itself retired this in 2014 for "Move fast with stable infrastructure." The motto is a complete lesson, limit included. It's right for a throwaway prototype and reckless for code with millions of users downstream. Autonomous agents make moving fast trivial; they don't make the breaking part any cheaper. The phase you're in still decides whether speed is a virtue or a liability.
9. The counterweight, from someone who'd know
"Saying that learning to code is unnecessary because of AI is some of the worst career advice ever given."
— Andrew Ng
Ng founded DeepLearning.AI and led AI at both Google and Baidu, so when he says don't stop learning to code, it isn't nostalgia. His logic is leverage: the better the tools get, the more value accrues to the person who can direct and verify them. You cannot review an output you couldn't have written. The people who get the most out of AI coding are precisely the ones who didn't skip the part where you learn to code.
10. The 2026 argument in two quotes
"Talk is cheap. Show me the code."
— Linus Torvalds"The hottest new programming language is English."
— Andrej Karpathy (2023)
I'm ending on a collision because the whole debate lives in the gap between these two. Torvalds spent decades insisting that talk is cheap and only running code counts. Karpathy says the talk is the code now. They're both right, which is the uncomfortable part: English is how you instruct the machine, and the code is still the only thing that tells you whether the English worked. The skill of 2026 is doing both, describing intent precisely and reading the output critically. Karpathy gets you a draft. Torvalds tells you whether to trust it.
The point
None of these people were predicting AI. They were describing software, and software didn't change its nature just because the author did. The arguments we're treating as unprecedented (can you trust generated code, is cleverness a trap, is coding a dying skill) were settled, or at least well-framed, by people working in languages most of us have never touched. The tools are new. The wisdom is paid for.
If you enjoy this kind of thing, I collected 100 of these quotes and unpacked why each one stuck (the history behind it, the rhetorical structure that makes it memorable, and the lesson for working engineers today) in Engineering in 100 Quotes. The AI-era chapter is where the old lines and the new ones finally meet.
Top comments (0)