In 1954, Grace Hopper proposed that programmers should write in English words instead of mathematical notation. She was told—for three years—that this was impossible because "computers don't understand English."
Today, computers understand English. And we're having the same argument about whether that counts as "real programming."
The skeptics are losing. Again.
The Abstraction Ladder
Every generation of programmers inherits a ladder. Each rung represents an abstraction layer—a way of expressing intent that compiles down to the layer below. And every generation forgets that the rung they're standing on was once considered cheating.
First Generation: Machine Code (1940s-50s)
Konrad Zuse's Z3, completed in 1941, was the world's first programmable digital computer. It "lacked conditional branching" and had storage capacity "too low" for complex tasks. Programming it required "detailed knowledge of instructions, registers, and other aspects of the central processing unit."
John Backus, who would later create FORTRAN, described this era as "hand-to-hand combat with the machine—and the machine often won."
Programming was a black art. Each programmer developed private techniques and inventions. There were no standards, no principles, no shared vocabulary. Just humans wrestling with hardware.
Second Generation: Assembly (1950s-60s)
Grace Hopper changed everything. In 1952, she completed the A-0 System—the first compiler. It translated mathematical notation into machine code automatically.
Then she went further. She proposed that programmers should write in English-like words, not symbols.
The resistance was fierce. "I was told very quickly that I couldn't do this," Hopper recalled, "because computers didn't understand English." She fought for three years. The establishment insisted that real programming required mathematical notation.
Her insight was simple: "It's much easier for most people to write an English statement than it is to use symbols. So I decided data processors ought to be able to write their programs in English, and the computers would translate them into machine code."
FLOW-MATIC led to COBOL, which "democratized coding." Companies could train everyday people to be productive programmers in months. The priesthood was horrified. The industry flourished.
Third Generation: High-Level Languages (1960s-80s)
In 1953, Backus assembled an unlikely team at IBM to create FORTRAN: "a chess wizard, a crystallographer, a cryptographer, a researcher from MIT, and the only woman on the team, Lois Haibt."
The project was supposed to take six months. It took three years. Everyone told them it couldn't be done.
The resistance came from programmers themselves. They "regarded themselves as guardians of arcane knowledge, possessing skills and knowledge of mysteries far too complex for ordinary mortals." Their objection was technical: "Compiled code could never be as efficient or compact as handwritten assembly."
They were wrong. By 1958—just one year after FORTRAN's release—over half of all code running on IBM computers was compiler-generated. A program that needed 1,000 assembly statements could be written in 50 FORTRAN statements. Fred Brooks later documented the productivity gains: high-level languages delivered a 5x improvement in programmer output.
The guardians of arcane knowledge had to find new mysteries to guard.
Fourth Generation: Declarative Languages (1980s-2000s)
The next leap was from "how" to "what." SQL didn't tell the computer _how_ to retrieve data—it described _what_ data you wanted and let the database engine figure out the rest.
James Martin's 1981 book was titled, provocatively, _Application Development Without Programmers_. The Santa Fe Railroad trained railroad experts to build systems using MAPPER because "it was easier to teach railroad experts to use MAPPER than to teach programmers the intricacies of railroad operations."
Domain knowledge started mattering more than programming skill.
The Failed Fifth Generation (1982-1992)
Not every rung holds.
Japan's Fifth Generation Computer Systems project spent $400 million on logic programming and Prolog. The technology worked—they achieved 150 million logical inferences per second. But the project failed commercially.
The critical lesson: "Applications were done in demonstration form only—not deployed." Abstraction without real-world applications is academic exercise. The technology was impressive. The value wasn't there.
The Pattern
| Generation | What You Write | Resistance Claim | Productivity Gain |
| ---------------- | -------------- | ------------------------------------ | ------------------- |
| 1GL: Machine | Binary | — | Baseline |
| 2GL: Assembly | Mnemonics | "Computers don't understand English" | 2-3x |
| 3GL: High-level | FORTRAN/C | "Never as efficient as hand-coded" | 5x |
| 4GL: Declarative | SQL | "Loss of control" | Domain experts code |
| 5GL: Logic | Prolog | (Failed—no real apps) | — |
| 6GL: Natural | Prompts | "Not real programming" | 55% faster |
Every transition met fierce resistance from experts whose status depended on scarcity. Every successful transition won anyway.
The question isn't whether natural language is a real programming language. The question is whether you're the assembly programmer in 1958 insisting that FORTRAN users aren't real programmers—while half the industry has already moved on.
The Economic Inversion
Here's what's actually changed: the economics have inverted.
Two costs compete in any debugging scenario:
1. Cost to understand: Read the code, trace the bug, understand the context, fix surgically
2. Cost to regenerate: Revert, improve the prompt, generate fresh
For decades, #1 was obviously cheaper. You'd spent hours or days writing that code. Understanding it was an investment in an asset you owned. Throwing it away was waste.
But I didn't write that code. I prompted it. It took seconds to generate. The asset isn't the code—it's the prompt.
GitHub's research found that developers using Copilot complete tasks 55% faster—1 hour 11 minutes versus 2 hours 41 minutes. Generation time is measured in seconds. Context windows can hold entire codebases. AI tools ship with built-in restore points.
We've crossed a threshold: regenerating is now cheaper than understanding.
The uncomfortable implication is that time spent understanding generated code is often waste. You don't read the bytecode your JVM generates. You don't inspect the assembly your compiler emits. Why are you reading the code your prompt generated?
Not because it's valuable. Because you haven't updated your instincts.
The Revert Reflex
My workflow has changed. Here's what it looks like now:
1. Checkpoint — AI tool's restore point, or a git commit
2. Prompt and generate
3. Verify — run the verification stack
4. If broken: analyze _the prompt_, not the code. Revert. Re-prompt.
The critical shift is step 4. When something breaks, I don't dive into the generated code to debug it. I ask: what was wrong with my prompt? What did I fail to specify? What constraint did I forget?
The Verification Stack
Verification is how you know whether to continue or revert. Each layer provides different signal:
| Layer | Signal Type | Speed | Confidence |
| --------------------- | ---------------------- | --------------- | ----------- |
| Linters | Style, patterns | Instant | Low |
| Type checkers | Structural correctness | Seconds | Medium |
| Compilers | Semantic validity | Seconds | Medium-High |
| Unit tests | Behavioral correctness | Seconds-minutes | High |
| Integration tests | System behavior | Minutes | High |
| Agent inspection | Visual, heuristic | Seconds | Variable |
| Human review | Judgment, intent | Minutes-hours | Highest |
Linters catch what type checkers miss. Tests catch what compilers miss. Agent inspection catches what tests miss—visual regressions, UX issues, things that are technically correct but obviously wrong.
The future is a Ralph Loop: an automated feedback loop where the AI iterates toward correctness, checking its own work against these verification layers. The human provides intent and acceptance criteria. The loop handles iteration. AI that debugs itself.
We're not there yet—but we're close enough that the workflow has already changed.
Debugging is becoming prompt refinement. The bug isn't in the code. It's in how you expressed your intent.
The Recipe, Not the Cake
Think of it like baking.
| Baking | AI Development |
| ----------------- | --------------------------------- |
| Recipe | Prompt |
| Cake | Generated code |
| Baker's technique | Feedback loops + verification |
| Tacit knowledge | System architecture + constraints |
The IP is the recipe, not the cake. You can always bake another cake. But the recipe—the precise articulation of what you want—that's the artifact worth versioning.
Expert bakers add nuance that improves outcomes: knowing when to fold, how to tell doneness, what humidity does to rising times. Expert prompt engineers add:
- Specific file paths and architectural constraints
- Clear success criteria
- Examples of desired patterns
- Knowledge of what the AI tends to get wrong
This tacit knowledge isn't in the prompt itself—it's in knowing _how_ to prompt. The recipe is explicit. The technique is learned.
If prompts are source code, should we version them? Diff them? Review them?
Yes. And this is already happening. The teams that treat prompts as first-class artifacts—reviewing them, iterating on them, building libraries of them—are the teams shipping faster.
Who Wins in This World
Three groups are advantaged in this transition:
1. Product-oriented engineers
They've always understood the "why." Now the penalty for vague specifications is immediate. Bad prompts produce bad code—instantly, visibly. Good prompts produce good code. Clarity of intent translates directly to quality of output.
The gap between "knows what to build" and "can build it" has collapsed.
2. Domain experts
"Update the authentication middleware to handle token refresh when the access token expires within 30 seconds of a request" beats "fix the login bug." Deep system knowledge enables surgical prompts. Specificity is leverage.
The people who know the system best can now communicate directly with the tool that modifies it.
3. Feedback loop builders
Those who invest in verification infrastructure—comprehensive tests, strict type systems, visual regression tools, linting rules—can iterate faster. Their loop is: prompt → generate → verify → refine prompt. Tight verification enables aggressive regeneration.
What depreciates:
- Raw code-reading speed (there's less code to read)
- Debugging heroics (cheaper to regenerate)
- Memorized syntax and APIs (the AI knows them better)
What appreciates:
- System design intuition
- Clear written communication
- Verification infrastructure
- Knowing what "done" looks like
What Still Matters
Not everything is generated.
Architecture remains human work. The shape of the system, the boundaries between components, the data flows—these are decisions that prompts can implement but not make.
Constraints matter as much as capabilities. What the AI _shouldn't_ do is as important as what it should. "Don't modify the database schema" is a constraint. "Use the existing authentication pattern" is a constraint. Prompts without constraints produce creative solutions to problems you didn't have.
Verification is essential. Tests, types, and human judgment remain the gatekeepers. The difference is that verification now runs _on_ generated code rather than _alongside_ written code.
Integration—connecting systems, managing state, handling edge cases—still requires human judgment. The boundaries between systems are where bugs live, and boundaries are architectural decisions.
The bytecode analogy holds, but with limits. You don't write bytecode, but you might read it during a performance investigation. Same with generated code: you won't write most of it, but you'll read it when verification fails.
The difference is frequency. Performance investigations are rare. Most bytecode goes unread forever. Generated code is heading the same direction.
The New Literacy
The engineers who thrive won't be those who resist this shift. They'll be the ones who recognize that their value was never in the keystrokes—it was in knowing what to build and how to verify it's right.
Code craftsmanship becomes prompt craftsmanship.
Debugging becomes intent refinement.
Code review becomes output verification.
The skills are transferable. Clear thinking is clear thinking, whether expressed in Python or English. System design intuition works regardless of who—or what—writes the implementation.
The ladder continues upward. Each generation abstracts the last. Machine code programmers thought assembly was cheating. Assembly programmers thought FORTRAN was cheating. FORTRAN programmers thought SQL was cheating.
They were all right, in a sense. Each new rung _does_ let you skip the work of the rung below. That's the point. That's what abstraction _is_.
The question isn't whether to climb. The question is whether you're holding on to a rung that's already below you—insisting that your way is the real way, while the industry moves on.
Grace Hopper fought for three years to prove that computers could understand English.
They can now. And they're waiting for your prompt.