A Stranger Explained the Future of Programming to Me in 1981

Electronics, then programming, then vibe coding. Every layer since has gotten faster at putting a result on your screen, and almost none of them got faster at telling you the result is right. That distance is now your job.

An almost empty cinema, a matinee, 1981. Two people in the room: me, and an older guy who seemed grown up at the time but was probably still in his late teens.

At the intermission (they used to have them back then) we started talking. He said he was into computer programming. The IBM PC was still ahead of us.¹ I said I was more into electronics, my word for anything you could build out of physical parts.

Then he said the sentence I've carried ever since.

I like programming better because you get immediate feedback.

He thought he was defending a hobby. He was describing the thing that decides which technology people move to, and he'd found it years before the industry had a word for it. Every new layer we build shortens the gap between having an intention and seeing a result, and the layer with the shortest gap is the one people end up living in.

That's the whole of the future of programming. Not that programming disappears, but that each generation expresses intent one level higher up while the engineering underneath stays real and stays somebody's job. What doesn't move up with it is validation, and that's the part nobody has priced.

The layer underneath doesn't go away when that happens. Somebody still designs the chip his program runs on, and the same physics that made my circuits work is what makes his code execute. What changes is who has to think about it. He got to spend his afternoon having ideas about software, while an entire discipline of electrical engineering sat underneath him, out of sight, already solved by other people.

You know the current version of this. You describe something in two or three sentences, wait maybe ninety seconds, and there's a working interface on your screen, with routing and a database and a login form you never asked for but would have needed anyway.

The feeling that arrives with it is out of proportion to the size of what happened, and no green test suite has ever given you anything like it. Then it fades a little and leaves a question behind that you can't quite answer: did you just get faster, or did you just get agreed with?

That's the right question to be stuck on. The structure behind it is much older than AI, and the thing that finally answers it may not be software at all.

The Abstraction Layer That Wins Is the One That Answers Fastest

Open any computer science textbook and abstraction gets explained the same way: it hides complexity. APIs, operating systems, the hardware abstraction layer, all of them tuck the messy details out of sight so you can work higher up and hold fewer things in your head at once.

True enough. But that describes what a layer does for you once you're already using it, and says nothing about why anybody switched to it in the first place.

Look at what I was doing at eleven. Between wanting a thing that blinked and watching it blink sat most of an afternoon: finding the parts, laying them out, wire, solder, a power source, and eventually the slow discovery that I'd run a lead to the wrong place and would have to undo a chunk of physical work to change one decision. Every revision cost me almost the whole afternoon again.

He had a file and a run command. Change a decision, run it again, ten seconds, and the machine tells you where you stand.

Everything since has been that same move made at a higher level, though it never arrived in a tidy line. The interactive prompt is older than the spreadsheet: you type one line and the language answers before you've finished the thought, instead of compiling a whole program to find out you were wrong.

Then VisiCalc put a grid on an Apple II in 1979, where changing one number recalculated every number that depended on it, instantly, and quietly turned a generation of accountants into programmers who never used the word.² Hot reload. The browser console, where you edit a live page and watch it rearrange itself under your hands.

Bret Victor built a whole talk around this in 2012, arguing that creators need an immediate connection to the thing they're making, and showing what a coding environment feels like when the gap goes to zero.³

Vibe coding is where that line currently ends. Andrej Karpathy named it in early 2025 and described it as giving in to the vibes and forgetting that the code even exists.⁴ You say what you want, the thing shows up, and the distance between those two moments is now short enough that you can't feel it anymore.

Which sounds like fifty years of unbroken progress. But there was always a second distance running alongside that one, and nobody spent much time measuring it, because for a long time nobody had to.

Every Tool Shortens One of Two Distances

Anything you make things with has two distances in it, and you always travel them in the same order.

The first is the screen distance. It runs from having an intention to seeing something: a blinking light, a program that runs, an interface sitting there looking finished.

The second is the world distance. It runs from seeing something to finding out what the world makes of it, which is a different question entirely. Whether it does what you think it does, for the cases you haven't tried, for the user who does something you'd never think to do.

Fifty years of tooling collapsed the screen distance. Clock time fell, from an afternoon down to seconds. The bigger collapse was in the work: a revision used to cost me a whole afternoon of soldering, and now it costs a sentence.

Nobody got meaningfully faster at the world distance. Reading code you didn't write is slow. Imagining the input you didn't think of is slow. And the wait for the case nobody covered is however long it takes a real user to walk into it, which no tool has ever compressed.

The clearest version of this is sitting inside DORA's own numbers. A decade of work pulled lead time for changes down to under a day for the strongest teams, and left change failure rate parked around five percent the entire way.⁵ One of those numbers travelled a very long distance. The other one barely noticed anything had happened.

So here's a test worth running on anything that impresses you. When a new tool thrills you, ask which distance it just shortened.

Run it on your own week. Autocomplete: screen. Hot reload: screen. A preview deploy on every branch: screen, at higher fidelity. Error monitoring that wakes you at 3am: world distance, and notice that it's the only one on the list nobody has ever described as a joy to use.

It's almost always the screen distance, and the screen distance happens to be the only one you can feel in your body.

Which leaves a question I was far too young to ask in that cinema. If the world distance was always the harder one, how was it getting closed before any of this abstraction arrived?

Physics Doesn't Do Plausible. Models Do.

In electronics, the world distance was almost nothing. Not because I was careful, and not because I checked anything. Because the physical world can't produce a convincing imitation of what you asked for.

The circuit works, or nothing happens, or something gets warm and you learn a permanent lesson about polarity. Reality isn't impressed by your intentions, has no idea what you were going for, and takes no account of how long you spent. It just answers. That's the blunt reviewer, and for most of history it was the only one anybody had.

Software introduced something genuinely new into the world: the thing that runs and is wrong. A program can execute without a single error, render beautifully, hand you back a number, and be false in a way that nothing on your screen will indicate. That option wasn't available to me with a soldering iron.

I'm not claiming hardware is honest all the way down. A board can pass on the bench and fail at temperature, a meter you calibrated wrong will read confidently wrong all day, and intermittent faults have ruined better engineers than me (and I'm not even a proper one). The narrower claim survives. Physical failure mostly announces itself as failure. Software failure learned to show up wearing the clothes of success.

AI is the extreme version of that, for a reason worth sitting with rather than skimming past.

A language model is optimized to produce output that looks like what was asked for. I mean that as a plain description of the training objective, and no insult is intended by it. But sit with what it implies: the technology is aimed with unusual precision at the screen distance, and only glancingly, secondhand, at the other one.

The measurements have started arriving. Veracode tested more than a hundred models across eighty coding tasks and found security flaws in 45% of the generated code. The detail that matters more is that the security pass rate stayed flat through mid-2025 while those same models kept getting functionally better at writing code that works.⁶ Two abilities, sitting in one system, moving at completely different speeds.

The part that should bother you more is what all this does to your own perception. METR ran a randomized trial with experienced open source developers working on real tasks in repositories they already knew well. They finished 19% slower with AI assistance than without it. Afterward they estimated they'd been about 20% faster.⁷ The people inside the loop could not feel which direction it was pointing, and these were not beginners fooling themselves.

Once the work leaves your hands, the world distance stops being a private feeling and turns into a queue. LinearB looked at 8.1 million pull requests and found the AI-generated ones sitting 4.6 times longer before a reviewer even picked them up, then merging at 32.7% against 84.4% for the human-written ones.⁸ Generation went instant. Everything downstream of it stayed exactly as human-shaped and slow as it always was.

Then notice what that number quietly assumes. A pull request sitting 4.6 times longer is a bad result, and it's still a result that only exists because somebody was going to look. Ship on your own and there's no queue to be slow. Nothing waits, nothing gets picked up late, and your first reviewer is a user who will not file a report and will not come back.

None of that is an argument against the tools, and I'd be a hypocrite to make one, because I use them every day. It's an argument for knowing which of your two distances just collapsed, since the one that collapsed and the one that decides whether you shipped something real have quietly stopped being the same distance.

Cheap Building Doesn't Hand You Something to Build

The hopeful version of this story says that once the friction disappears, everybody becomes a builder. I don't think that follows.

Shortening the screen distance clears away what stood between an intention and a result. It doesn't manufacture the intention. So the people arriving first are the ones who already had something they wanted to make and kept bouncing off the cost of getting started: the designer with a folder of half-started projects, the operations lead who's been describing the same missing internal tool for six years, the person who tried to learn to code three separate times and quit at environment setup on all three.

That's a large group, and it's about to get considerably louder. It still isn't everybody. Plenty of people have no unbuilt thing sitting in them, and no amount of removed friction is going to install one.

The bigger shift comes later, when this stops feeling like programming at all. Nobody sitting in front of a spreadsheet in 1985 thought they were writing software. They were doing their job, in a tool that happened to be programmable, and the programming had gone invisible underneath them. That's the honest answer to whether programming disappears. The name goes first, the work goes underneath, and somebody is still down there making sure it holds.

Nobody Ever Fell in Love With a Tool That Says No

The easy explanation for all of this is that the world distance is simply the harder problem. Knowing whether a thing is right is a deeper question than making it appear, so of course one of them lagged.

I don't think that's most of it. The better explanation is sitting back at the start of this article, in a cinema, in a sentence a teenager said about a hobby.

A layer wins by making you feel something quickly. That's the selection pressure, and it has never once been about how correct the layer is. Now look at what a world-distance tool has to do for a living. Its entire function is to discover that you were wrong and inform you. The better it gets, the more often it does that. The faster it gets, the sooner you hear it.

So the two distances were never competing on the same terms. One of them pays out on delivery. The other one hands you a bill.

Plenty of people built the second kind anyway. Formal methods, contracts, property testing, fuzzers, static analysis. Serious work, most of it, and none of it ever became the layer anybody lives in. It kept losing to whatever felt better that year, and after enough rounds of losing, the effort goes where the wins are.

The obvious objection here is test-driven development, and it's a good one. Red, green, refactor is the tightest feedback loop anybody has ever designed on purpose, seconds long, bad news delivered immediately, and by my own rule it should have swept the industry. It didn't. Twenty-five years of advocacy later it's still something people say they should be doing more of.

Which sharpens the rule rather than breaking it. The TDD loop is fast, but only once you've written the failing test yourself, in advance, for a failure you haven't had yet. The warning doesn't come to you. You build the thing that gives it.

So speed was never the whole requirement. The bad news has to arrive fast and cost you nothing to receive.

But one of them got through, and how it managed it is the useful part.

Type checking is a world-distance tool wearing a disguise. It takes a category of wrongness that used to surface in production, weeks later, in front of somebody who trusted you, and moves it to now. That's the second distance shortening, which is the thing I've just spent five paragraphs saying doesn't happen.

For decades it mostly didn't. Static typing was old and unloved, and a whole generation went the other way on purpose, into dynamic languages, because a compile step felt like a tax on the loop. Better type systems did help turn that around, and gradual, structural typing gave people a way in without rewriting everything they owned. But what made it stick, from what I can tell, was the squiggly red line that appears under the variable while you're still typing the word.

Bad news, delivered fast enough to feel like help. As far as I can find, that's the only way a tool like this has ever been adopted at scale.

Which tells you something uncomfortable about the careful version of you. Reading the model's output closely, writing tests, reviewing the diff before it merges: that work is worth doing and I'd rather you did it. It is also not the second distance closing.

Tests convert things you already thought of into things you get told about quickly. The case you didn't think of is the whole substance of the world distance, and no amount of care turns one into the other. Do all of it well and what you have is a faster, better-lit screen.

The Four Properties of a Squiggly Red Line

That red line is probably the only clean example we have of the second distance closing at scale, which makes it worth pulling apart. It has four properties, and it needs all four.

1. It arrives before you've moved on. Not at commit, not in CI, not in review. While your hand is still on the word.
2. It shows up where you're already looking. You don't navigate to it, open it, or schedule it. It appears in the file, under the thing it's about.
3. It covers cases you never specified. You didn't ask it to check that field name. It checks everything, every time, whether or not you thought of it. This is the property tests don't have.
4. It never asks to be adopted. It ships with the editor, on by default, and leaving it on costs less than turning it off.

Now hold the current crop against that list.

Evals arrive long after you've moved on, live somewhere else entirely, and have to be written by the person who would need to imagine the failing case first. That's one, two, and three. CI fails the first. Code review fails all four, and the LinearB numbers are what failing all four looks like at scale.

None of it passes. That gap is a more useful thing to know than another prediction about jobs.

One thing does come closer than the rest, though, and it's worth mentioning.

An agent that writes code, runs the test suite, reads the failure, and goes back in without being asked is doing world-distance work while wearing screen-distance clothes. Same disguise as the red squiggle, one level up. It passes the first property easily, and the fourth one completely: nobody adopts it for the checking, they adopt it for the speed, and the checking arrives in the box.

Where it breaks is the third. It runs your tests, and your tests are still a list of cases somebody thought of, except now the somebody is often the same model that wrote the code. It's grading its work against its own idea of what the work was supposed to do.

Nothing from outside gets into that loop. The loop got longer and it got smarter, and it still runs entirely on your screen. That's a real improvement. It still isn't the world telling you that you're wrong.

Still, look at the shape of it. The most credible move on the second distance in twenty years did not arrive as a correctness tool. It arrived as a speed tool that happens to check.

So something has to force the issue, because on the evidence of the last fifty years, nobody picks it voluntarily.

Robotics Is the World Coming Back as the Reviewer

Most people treat robotics as the frightening escalation. Natural language goes in, physical action comes out, and now the mistakes have mass and can break something on the way down.

Run it through the two distances, though, and a stranger picture shows up.

A robot can't pass by looking plausible (though plenty of companies are trying, one carefully cut demo video at a time). This is close to the defining difficulty of the field: policies that perform beautifully in simulation come apart on real hardware, because the simulator quietly smoothed away friction, contact, sensor noise, and all the specific ways real objects decline to be where you predicted.⁹

That's the screen distance losing its authority. Nobody in the field puts much weight on how a result looks in simulation anymore, because too many results looked right there and fell over on a real table.

And once the arm is moving in an actual room, the world distance nearly closes on its own. A robot that misunderstood you drops the cup, and there's no version of a cup on the floor that looks correct. Nobody gets told the cup is fine while it lies there.

That would make robotics the first layer to shorten the world distance without needing a disguise, and it gets there by the only route available. Not because anyone finally chose the unpleasant tool. Because when the output has to survive contact with a room, the grading is done by something that was never asking to be adopted, has no interest in how the demo went, and cannot be made to feel better about it.

I'm not putting a date on any of this. I'm saying that the loop I found so unbearably slow as a child, where you build the thing and reality tells you flatly what you got wrong, is the same loop we've spent five decades engineering our way out of. It may be sitting on the far side of all this, waiting.

What He Traded Away Without Knowing It

He made a prediction in that cinema, and it's fair to score it now. He was right. Not marginally right: the entire industry went where he said the value was, and I'm typing this into a tool that exists because he was right. What he couldn't price was the other half of the trade, because in 1981 nothing that ran had yet learned to be convincingly wrong.

He traded a slow build for a fast one, and he was right to. He also traded a blunt reviewer for a polite one, and there was no way for him to notice that half of the deal, because the polite reviewer hadn't done anything wrong yet.

We've made the same trade every few years since. Each layer moved us further from the thing that would tell us plainly whether we'd gotten it right, and each time we took it, because the other half kept getting cheaper and the bill kept arriving late.

So the next real advance in the future of programming won't be another way to make things appear faster. The screen distance is nearly spent. Whatever comes after it has to win on the news it brings rather than the feeling it gives, and nothing in this entire story has ever had to do that.

Which makes one thing checkable, so hold me to it. If the mechanism in this article is right, the next tool that meaningfully closes the second distance will not be sold as a correctness tool. It will be sold on something else, probably speed, and it will do its checking as a side effect nobody asked for, and the people adopting it will not describe it as a safety product. If something marketed as a verification layer for AI-generated code wins the next five years on its own merits, I've read this wrong.

Until then, the world distance is yours to walk. Every tool you have makes the first step faster. Not one of them takes the second step for you.

Want to know how relevant this is in your specific case?

Answer a few quick questions to get a clear analysis and next steps, with 802 unique, useful text-result personalized results, including one that matches your case. All of this is available here with no gate, no signup, completely free.

Rabbit Hole

More on this subject

• No Circle Is Round and AI Isn't Deterministic. So What.: Set a reliability threshold for the job, then engineer the checking to meet it.
• The One-Shot Illusion: What skipped checking costs, paid in full by the first stranger who opens your app.

See this concept in another subject

• Why the Most Consistent People Don't Need Discipline (Free tool included): The same law in personal effort: what has to be forced on you never lasts.