In 2019, I asked Ralabs’ co-founder Roman whether we should spin up a no-code department.
They didn’t. The wave passed. The engineers stayed. We never built the no-code department.
Five years later, I’m watching the same pattern.
Jensen Huang told governments at the 2024 World Government Summit that their kids should study biology instead of computer science. Mark Zuckerberg announced in January 2025 that AI will write most of Meta’s code within 18 months.
Dario Amodei, CEO of the company that makes the model I use daily, said in January 2026 that we’re six to twelve months from AI doing everything a software engineer does end-to-end.
Somewhere in the back of my head, the 2019 version of me is raising his hand again.
Here’s the thing. I’ve spent the last few months going back through the actual record of these predictions. I went back through the actual record: the quotes, the dates, the people who made them, and what happened next.
The pattern is consistent enough to be predictable. And predictable enough to be profitable: every one of these claims moved markets, attracted investment, and rewarded the people making them, whether or not the timeline held.
Every major leap in abstraction: compilers, 4GLs, visual drag-and-drop, no-code, now AI, triggers the same claim: this time, the engineer is finally (almost) obsolete.
The claim has been always wrong about where the hard part actually lives.
Seventy years of the same prediction
The timeline above covers it all.
Every major abstraction leap since 1952 has triggered the same claim. Grace Hopper’s compiler would end manual coding. James Martin’s 4GLs would bypass the programmer entirely. Visual Basic and drag-and-drop would make code obsolete. No-code would finish the job.
Each time, the tools got genuinely better. And each time, the prediction was wrong in exactly the same way: it identified the right thing being automated and drew the wrong conclusion about what that meant for engineers.
2024–2026: The shortest timelines yet
The current wave is different in one specific way: the timelines have collapsed.
Grace Hopper didn’t give a deadline. James Martin implied a decade. The no-code movement said five years. Now:
Jensen Huang at the 2024 World Government Summit: “Nobody needs to program anymore.” No timeline. Present tense.
Mark Zuckerberg in January 2025: “Within 12 to 18 months, we’ll reach the point where most of the code going towards these efforts is written by AI.“
Dario Amodei in January 2026: “I think we might be six to 12 months away from when models may be doing all that SWEs do end-to-end.“
These are the CEOs of NVIDIA, Meta, and the company building Claude. And unlike their predecessors, they’re working with tools that actually do write code: working code, that ships to production. So something is genuinely different. But the question isn’t whether AI can write code. It clearly can.
The question is the same one that’s been wrong at every previous inflection point: where does the hard part actually live?
The thing everyone keeps misidentifying as the hard part
Here’s what I’ve noticed:
The syntax was never the bottleneck. It wasn’t the bottleneck when Fortran arrived in 1954, when 4GLs matured in 1987, or now. The bottleneck has always been understanding precisely what you’re trying to build, and why, and for whom, and under what constraints.
That means requirements gathering, architecture decisions, the conversation with a client who doesn’t know what they need until they’ve seen three versions of what they asked for. The call you make at 11pm when the integration breaks and you have to decide whether to patch it tonight or roll back and explain why. That’s the job.
There’s an economic principle called the Jevons Paradox: when the cost of producing something drops, demand for it increases faster than supply decreases.
When Fortran made programming 45x easier, the world didn’t need 45x fewer programmers. It started demanding millions of times more software. AI makes code cheaper to generate, so more software gets built, more systems need to be understood, maintained, integrated, and secured. The engineering surface area expands. The early data supports this: software engineer job postings are rapidly rising, up 11% year over year, even as AI code generation has become standard practice.
What remains after AI takes the boilerplate, the CRUD endpoints, the scaffolding, is the architecture, the judgment calls, the client relationships, the security reviews, and the ability to look at what the AI generated and know whether it’s right. That last one is new, and it’s not trivial.
What comes next
I want to take the 6-to-18-month claims seriously, because they deserve engagement rather than dismissal. Current models can complete well-scoped, well-specified tasks end-to-end. The question is what fraction of real engineering work fits that description, and in my experience, it’s not most of it. Most of it involves ambiguity at the requirements level and judgment calls that require someone who can think about the problem.
That could change. But we’ve been six months away from full self-driving for a decade, and the companies making these claims have significant financial incentives to set high expectations.
What seventy years of this pattern actually points toward is a profession that keeps migrating upward.
- The 1950s automated machine code.
- The 1980s automated application logic.
- The 2010s automated template-driven development.
- The current wave is automating syntax production.
Each time, engineers moved to the layer above.
That layer now looks like systems thinking: understanding how components interact, where failure propagates, what a business actually needs versus what it asked for. Less time writing low-level code and algorithms, more time reasoning about architecture, constraints, and consequences.
There’s also something that AI cannot take on: responsibility. When a system fails, when a security decision turns out to be wrong, when the architecture doesn’t scale, a human made that call and a human owns it.
AI generates. It doesn’t decide, and it doesn’t answer for what it produces. That accountability is structural, and it’s one of the reasons engineering, whatever it gets called next, stays a human job.
