If you clicked on this title expecting either a love letter to Bubble and Webflow or a eulogy for software developers, I have bad news for both camps. The future of coding really is no-code. But the “no-code” that’s winning looks nothing like the one we were promised — and it doesn’t eliminate developers. It does something far more interesting.
Let me explain what I mean, because I think most of the conversation around this topic is stuck on the wrong question.
The promise we were sold
Cast your mind back a few years. The pitch was seductive: drag-and-drop builders, visual workflows, citizen developers. Anyone could build an app. IT backlogs would evaporate. Gartner fueled the fire, forecasting the low-code market would reach $44.5 billion by 2026, with around 70–75% of new enterprise applications built on low-code technologies.
The market did grow. The money was real. But walk into any engineering organization today and ask how many production systems run on classic drag-and-drop no-code platforms. Then ask how the migration went when they outgrew them.
The pattern repeated everywhere: no-code tools were brilliant for prototypes and MVPs, but fell short at scale. Teams hit customization walls. Vendor lock-in turned “we built it in a weekend” into “we can’t leave without a rewrite.” And the citizen developer revolution? One survey found that 86% of developers didn’t use any low-code platform at all in 2024. The people who were supposed to be replaced simply… kept coding.
Here’s the thing though: the diagnosis behind no-code was correct. Writing software involved too much ceremony, too much boilerplate, too much translation between “what I want” and “what the machine needs.” The cure was just wrong. Visual builders didn’t remove complexity — they hid it behind a canvas, where it waited patiently for you.
Meanwhile, the actual no-code revolution arrived from a completely different direction. And almost nobody called it no-code.
”The hottest new programming language is English”
In 2023, Andrej Karpathy — co-founder of OpenAI, former AI lead at Tesla — tweeted that the hottest new programming language is English. It sounded like a quip. It turned out to be a roadmap.
Two years later he coined “vibe coding”: describe what you want in natural language, let a large language model write the code, iterate by conversation. By early 2026, the numbers stopped being a curiosity. Developers report that around 42% of their code is now AI-generated or assisted — up from roughly 6% in 2023 — and 84% of developers use or plan to use AI tools in their workflow.
Think about what this means. The dream of no-code was “build software without writing code.” That’s exactly what’s happening — at massive scale — except the interface isn’t a drag-and-drop canvas. It’s a conversation. The “citizen developer” tool that finally worked isn’t a visual builder. It’s a chat box.
This is the twist the title promised: the future of coding is no-code, but “no-code” turned out to mean “no code written by hand” — not “no programming.” Those are radically different things, and confusing them is where most hot takes go wrong.
This movie has played before
If you’re a developer feeling a pit in your stomach, let me offer some historical perspective, because we have been exactly here before.
In the 1950s, programmers wrote machine code and assembly by hand. When FORTRAN appeared, the reaction was not applause. Few people believed a machine could generate code as efficient as a human’s, and von Neumann himself reportedly saw no need for a high-level language. Frances Allen, who later won the Turing Award, was hired to teach FORTRAN to IBM’s own scientists — and said the hardest part was convincing them it was useful at all. To an assembly programmer, FORTRAN was no-code. It generated the “real” program for you. You just described the math.
It happened again with every layer that followed. Compilers were distrusted. Garbage collection was for people who couldn’t manage memory. SQL let analysts query data without writing procedural code — that was “no-code” too, we just don’t call it that. The satirical essay “Real Programmers Don’t Use Pascal” exists precisely because every generation of programmers mocks the next abstraction as not-really-programming… right up until it becomes the default.
Notice what didn’t happen at any of these transitions: programmers didn’t disappear. There are orders of magnitude more developers today than in the assembly era, because every time the cost of producing software dropped, the demand for software exploded to fill the gap. Economists call it the Jevons paradox: make a resource cheaper to use, and total consumption goes up, not down.
And here’s my favorite example, because it hides in plain sight: the most successful no-code platform in history is Excel. Hundreds of millions of people “program” with it daily — building financial models, simulations, entire business processes — and almost none of them would call themselves programmers. Excel succeeded where drag-and-drop app builders struggled because it didn’t pretend complexity doesn’t exist; it gave non-programmers a real computational model (cells, formulas, dependencies) at a higher level of abstraction. That’s the recipe: don’t hide the power, raise the interface. Large language models are doing the same thing with natural language, at a vastly larger scale.
Natural language as a programming interface is the next rung on this exact ladder:
Machine code → Assembly → High-level languages → Frameworks and managed runtimes → AI-assisted natural language.
Each step traded fine-grained control for expressiveness and speed. Each step was declared “the end of real programming.” Each step instead expanded who could program and what got built. There is no compelling reason to believe this rung is different in kind — only in steepness.
What actually changes (and it’s a lot)
“It’s just another abstraction layer” is not the same as “nothing changes, relax.” Abstraction shifts are violent for the people standing on the wrong layer. COBOL didn’t kill programming, but it absolutely ended the era when hand-optimizing machine code was a career. So let’s be honest about what this layer dissolves and what it concentrates.
What dissolves: the mechanical middle of the job. Translating a well-understood spec into syntax. Writing the CRUD endpoint, the form validation, the test boilerplate, the integration glue. This was a huge fraction of working hours, and it’s exactly what LLMs are best at. If your professional value is “I can type the implementation of a clearly described feature,” you are standing on melting ice — the same ice the assembly optimizers stood on in 1960.
What concentrates: everything above and below that middle.
Above: deciding what to build, decomposing fuzzy problems, defining “done.” Even Karpathy has already moved past his own term, describing the professional version as “agentic engineering” — less vibing, more orchestrating. In practice, vibe coding in 2026 looks nothing like the casual experiment of 2025: natural-language specs, multi-model workflows, structured human oversight. Writing a precise spec in English is still programming. It’s hard programming. Ambiguity that a human colleague would resolve with common sense becomes a bug factory when your colleague is a token predictor.
Below: judgment about what the machine produced. Here’s the statistic that should define this whole era: developers report high AI usage, yet nearly half don’t trust the output. They’re right not to. AI-generated code is confident, plausible, and wrong in ways that are expensive to detect — subtly mishandled edge cases, security holes, architectural drift accumulating across hundreds of generated commits. The engineers thriving right now aren’t the best typists; they’re the best at not trusting AI code — at reviewing, verifying, and catching the failure modes.
So the role inverts. For seventy years, the developer’s scarce skill was production — humans were the bottleneck that turned intent into code. Now production is nearly free, and the scarce skills are intent (specifying precisely) and verification (judging ruthlessly). The developer moves from bricklayer to architect-plus-building-inspector. Fewer hours typing; more hours deciding, reading, and rejecting.
And this is why the classic no-code platforms got disrupted by the thing they predicted. They bet the bottleneck was syntax, so they replaced syntax with boxes and arrows. But the bottleneck was never syntax — it was clarity of thought about systems. LLMs erase the syntax problem more thoroughly than any visual builder ever did, and in doing so they expose the residue: the part of software that was always the actual job.
What a working day actually looks like now
Abstract arguments are easy, so let me make this concrete. Compare two versions of the same task: “add team billing to our SaaS product.”
2019 version: a senior engineer breaks the feature into tickets. Developers spend two weeks writing the Stripe integration, the database migrations, the permission checks, the invoice UI, the tests. Code review focuses on style and obvious bugs, because reviewers know a human wrote it with intent. Most of the elapsed time is typing and debugging.
2026 version: the same engineer spends half a day writing what is essentially a specification in English — entities, edge cases (what happens when a team downgrades mid-cycle? when the card fails on seat #47?), constraints, acceptance criteria. An agent produces a working implementation, tests included, in hours. Then comes the part that didn’t exist before: the engineer spends days reviewing — not for style, but interrogating the design. Did it handle proration correctly or just plausibly? Did it invent a permission model that conflicts with the existing one? Is this migration safe on a table with 40 million rows?
Total calendar time: maybe a third of the 2019 version. But look at where the human hours went. Almost zero typing. Heavy thinking at the front (specification) and heavy judgment at the back (verification). The middle — the part the no-code movement and the “AI replaces developers” crowd both fixated on — collapsed to nearly nothing.
That’s the shape of the new job. It isn’t “prompt and pray,” and it isn’t traditional development with autocomplete. It’s a different allocation of the same underlying skill: understanding systems well enough to specify them precisely and to judge an implementation ruthlessly.
”So should I still learn to code?”
This is the question I get most, and the abstraction-layer lens gives a clean answer: yes — but understand why, because the why has changed.
You no longer learn to code because the economy needs your fingers to produce syntax. It increasingly doesn’t. You learn to code for the same reason pilots still learn to fly manually in an age of autopilot: you cannot supervise what you cannot understand. Reading code, reasoning about state and failure and concurrency, smelling a bad design — these skills are more valuable when an agent produces in an afternoon what a team used to produce in a quarter. Someone has to be able to tell whether the mountain of generated code is a cathedral or a landfill, and that someone commands the salary.
What I’d tell three groups specifically:
Aspiring developers: don’t skip fundamentals because “AI writes the code now.” That’s exactly backwards. Fundamentals are the only part AI doesn’t commoditize. The juniors in trouble are those who use AI as a substitute for understanding; the ones who’ll thrive use it as the fastest learning tool ever built — generate, then interrogate every line.
Working developers: your leverage is shifting from output to judgment. Practice the spec-writing muscle. Get good at reviewing machine-scale volumes of code. Learn to operate agents the way a previous generation learned to operate CI/CD — it’s becoming infrastructure, not novelty.
Non-technical builders: this is genuinely your moment — better than the no-code platforms ever offered, because you’re not trapped in a vendor’s walled garden; the output is real code you own. But respect the ceiling. AI will happily build you an insecure, unscalable app with total confidence. The democratization is real; so is the graveyard of vibe-coded apps that fell over the moment they met real users.
The punchline
Here’s the irony I can’t stop thinking about. The no-code movement said: the future of software is people describing what they want and getting working applications, without writing code. They were completely right. They just built the wrong interface for it, a decade too early. The winning interface wasn’t visual. It was linguistic.
And the deeper irony: this “no-code” future employs more programming judgment than ever, not less. We’ve abstracted away the typing and kept the thinking. Which, if you look at seventy years of this industry, is what every successful abstraction has ever done.
The future of coding is no-code. There’s just one catch nobody put in the pitch deck: code was never the hard part.
If you’ve lived through this shift on your own team — as the developer reviewing AI output or the founder who vibe-coded an MVP — I’d love to hear how it’s going. The comments are open.