CARDiac, syntax coloring, view source and vibe code

Photo by Bernd 📷 Dittrich on Unsplash

Here is a thought experiment. Take a brand new programmer — someone who has never written a line of code — and sit them down in front of a terminal today. Give them a natural language AI coding assistant. Tell them to build something. They will produce working software, probably within an hour, without ever understanding what a variable is.

Now ask yourself: is that a problem?

The answer is less obvious than most people assume, and the question has a fifty-year-old answer hidden inside a little cardboard toy from Bell Labs.

The CARDiac and the Gift of Legibility

In 1968, a team at Bell Labs created the CARDiac — CARDboard Illustrative Aid to Computation — a Turing-complete, fully functional computer made entirely of paper. No transistors. No chips. No electricity. Just cardboard slots, paper tokens, and a human being performing the role of the physics. You composed programs with pencil and paper, then physically moved tokens between memory slots and an accumulator according to the machine's instructions.

Adding one and one was a major undertaking. And that was precisely the point.

Cory Doctorow, writing in his newsletter Pluralistic this week, recalls being handed a CARDiac by his father in the mid-1970s as his very first computer. He was in third grade. What he got from it was not useful software — you cannot build a spreadsheet out of cardboard tokens. What he got was something far more durable: legibility. A physical, fingertip understanding of what a computer is actually doing when electrons race through its circuits.

The German word for this is Fingerspitzengefühl — fingertip feeling. The intuition that comes not from reading about a system but from operating it with your hands. The CARDiac was designed to give that intuition to an entire generation of students who were inheriting electronic machines so miniaturized that the actual computing process had become invisible to the naked eye. Bell Labs was worried — rightly — that programmers who couldn't see what their machines were doing would develop brittle, surface-level mental models of how those machines worked.

They weren't wrong. And their concern is exactly as relevant today as it was in 1968.

The Stack of Abstractions Goes All the Way Down

Every programming era has lived at a different layer of the abstraction stack. There's an old joke that physics is applied mathematics, chemistry is applied physics, biology is applied chemistry, and so on up the chain. The same ladder exists in computing, with each rung wrapping the rung below it in a smoother, more graspable interface.

Machine code wraps transistor logic. Assembly wraps machine code. C wraps assembly. Python wraps C. A web browser wraps Python and C and everything beneath them. A web page wraps the browser. And sitting at the very top of that stack today, wrapping everything, is a large language model that accepts a sentence of English and produces code without exposing a single intermediate layer to the person who asked for it.

Here is what matters about those abstraction layers, and what people misunderstand about them: they are not shortcuts. They are power multipliers that preserve legibility only if you know the layers below exist.

A biologist who understands chemistry thinks in richer ways about biological processes than one who doesn't. A chemist who understands physics catches things that pure chemists miss. None of this means every biologist must become a physicist — that would be absurd, and specialization is what makes science productive. What it means is that the most powerful practitioners are those who can move up and down the stack fluidly when a problem demands it. Legibility at multiple levels is the difference between a problem-solver and a brilliant novice.

View Source: The Web’s Greatest Accident

In the mid-1990s, every web browser shipped with a feature that nobody planned to be important: View Source. With two clicks, anyone could peel back the rendered page and see the HTML underneath — every tag, every link, every structural decision the page's author had made.

It was an accident of openness, a byproduct of the fact that HTML was never meant to be a compiled, opaque format. And it turned an entire generation of self-taught web developers into programmers. You saw something you liked on someone else's site, you hit View Source, you read their code, you adapted it, you broke it, you fixed it, and you learned. The web was one giant annotated textbook that you could copy from, experiment on, and publish back to immediately.

That pipeline — see a thing, open the membrane, read the instructions, understand, adapt — is one of the most powerful learning structures in the history of human knowledge transfer. It is the reason the early web produced so many self-taught developers who went on to build the modern internet.

Syntax coloring is a smaller but telling example of the same principle. Color-coded code is not just prettier — it is more readable. It creates visual structure that helps a reader parse what they're looking at faster, catch errors sooner, and build a mental model of the code's structure more efficiently. It is legibility engineered directly into the visual presentation of code. Every syntax highlighter is a tiny CARDiac, helping the human operator see what the machine is doing.

Enter Vibe Coding

Vibe coding is an AI-first development approach coined by Andrej Karpathy where developers describe what they want in natural language and let AI tools generate the code. Karpathy’s original formulation was deliberately playful: "fully give in to the vibes, embrace exponentials, forget that the code even exists."

By 2026, vibe coding has become the dominant way developers ship software. The numbers are staggering: 92% of US developers have adopted vibe coding practices, and 60% of all new code written in 2026 is AI-generated.

The reaction from traditional developers has ranged from mild unease to outright alarm. How can you debug code you didn't write and don't understand? How can you maintain a system whose internals are opaque to you? How do you know when the AI has made a mistake that will only surface six months from now, in production, at the worst possible moment?

The data suggests those concerns have merit: AI-generated code carries 1.7 times more major issues and 2.74 times more security vulnerabilities than traditionally written code. These are not rounding errors. They are the measurable cost of operating at the top of the abstraction stack without visibility into what’s below it.

But here's what the alarm-ringers consistently miss — and what Doctorow's CARDiac story illuminates beautifully.

The Funnel That Makes Civilization

Doctorow makes an argument that cuts against both the AI boosters and the worried traditionalists. Vibe coding, he says, is not the end of the road. It is the top of a funnel.

Most people who generate code with an AI won’t look under the hood. They’ll describe what they want, get something that works, and move on. And that’s fine — genuinely fine. There’s nothing wrong with code that solves your problem, even if you don’t know how that code works, even if it breaks in a couple of years, even if no one else could maintain, extend or debug that code. Personal software is fundamentally different from software made to be used and maintained by others.

Personal software has always existed at the top of the abstraction stack. People who recorded Excel macros in the 1990s were vibe coding. People who copy-pasted JavaScript from Stack Overflow were vibe coding. People who tweaked their Myspace page by inspecting someone else's HTML were vibe coding. The activity is not new. The scale is.

And that's where the funnel argument becomes genuinely interesting. Every person who starts at the top of the stack — generating code with an AI, or recording a macro, or copying from View Source — is standing at the entrance to a funnel. The membrane between their generated code and the instructions beneath it is transparent. Peel it back and look. Most people won't. But the more people standing at the top of that funnel, the more who eventually will.

The ones who peel back the membrane, who get frustrated by a bug the AI can't fix, who need to understand what's actually happening in order to make a correction — those people start sliding down the abstraction chute. They learn what a variable is. Then what a loop is. Then what a function is. Then what memory allocation is. Then what a transistor is. Not all the way down, not necessarily, but far enough to become genuinely powerful operators at their chosen level.

The more people we put at the top of the funnel, the more chances our civilization gets to produce another skilled artisan who understands and can improve, iterate and repair the code the rest of us use.

What This Means For the Vibe Coding Debate

The right way to think about vibe coding is not as a replacement for programming skill. It is as the latest in a 70-year sequence of tools that have made the top of the abstraction stack more accessible to more people — from the BASIC interpreters of the Apple ][+ era, to the View Source affordance of the early web, to the drag-and-drop builders of the 2010s, to the natural language code generators of today.

Each of these tools lowered the floor without removing the ceiling. Each one brought more people into contact with computing, which meant more people eventually hitting the wall where the tool ran out of power, and more people consequently being motivated to look underneath it.

The legitimate worry is not that people are vibe coding. It's that the membrane has gotten thicker. Going from a natural language prompt to the code it generated is one peel of the membrane. Going from that code to the mental model of what it's doing in memory is another. Going from that mental model to the semiconductor physics that executes it is several more. Each layer is still penetrable — the internet, Wikipedia, tutorials, and documentation still exist — but the distance from the top of the stack to any given layer below has grown.

What that argues for is not restricting access to vibe coding tools, which would be both futile and counterproductive. It argues for investing in the CARDiacs of 2026 — tools and curricula that make the layers visible, that build Fingerspitzengefühl at multiple levels, that give people who start at the top of the stack a compelling reason and an accessible path to descend when they need to.

Syntax coloring is a CARDiac. View Source was a CARDiac. A great debugger is a CARDiac. A good error message that explains what went wrong in terms the user can act on is a CARDiac. Each one of these is a small act of legibility-building embedded in the tool itself.

The question worth asking about any new AI coding tool is not "does it generate working code?" — they all do, more or less. It is: "does it make the code it generates legible?" Does it invite the user to look underneath? Does it create the conditions for that funnel to operate? Does it build Fingerspitzengefühl, or does it seal the membrane and call that success?

The Bell Labs scientists who built the CARDiac were worried that transistors had made computing invisible, and that invisible computing would produce a generation of programmers who didn't really understand what they were doing. They were right to worry. And they did something about it: they made a cardboard computer that put the invisibility back on display.

We need the CARDiacs of the AI era. We just have to build them.