On the eve of the Vibe Computing era: Why agentic coding feels like a 1980s terminal — and why that’s the point

On the eve of the birth of the Vibe Computer

— Why agentic coding feels like a 1980s terminal — and why that’s the point

The first time I used Claude Code, I had an oddly anachronistic feeling: this wasn’t an IDE. It felt like sitting in front of an old terminal, face-to-face with an interpreter. I would type a sentence, it would take a step; I would stare at the diff and the test output, and then nudge it again. The “program” wasn’t a file I wrote and compiled — it was the loop itself: intent → action → observation → adjustment.

That sensation got a name in 2025: vibe coding. Andrej Karpathy described it as a new kind of coding where you “give in to the vibes” and “forget that the code even exists.” (X (formerly Twitter)) Simon Willison quickly drew a sharper boundary: vibe coding is not “AI-assisted programming” in general — it’s the specific approach where you let the AI generate code without really caring about the code it produced. (Simon Willison’s Weblog)

It’s easy to treat all of this as a “new machine learning model” story: better models, better prompts, better workflows. But there’s a more useful framing — especially if you’re trying to understand what comes next:

We’re not just learning to use new models. We’re learning to operate a new kind of computer.

And Claude Code’s retro terminal vibe? That’s not a UX quirk. It’s a tell.

1) Vibe coding is a symptom, not the phenomenon

Karpathy’s line about “forgetting the code exists” is provocative because it inverts the usual hierarchy of software development. For decades, code has been the sacred artifact; understanding the code is how you control the system. Vibe coding (in its extreme form) demotes code into a disposable intermediate product and elevates the feedback loop as the real source of progress. (X (formerly Twitter))

That’s why the term triggers pushback. In production engineering, “not reading the diff” is a red flag. Willison’s insistence on the definition is essentially a safety rail: if we blur the term to mean “any AI help,” we miss the real discontinuity — this shift from code-as-artifact to loop-as-interface. (Simon Willison’s Weblog)

But if we treat vibe coding purely as a risky workflow choice, we still miss the deeper point: the workflow feels plausible because the underlying machine changed.

2) Claude Code feels like an 80s terminal because it is a kind of monitor

Anthropic’s own positioning of Claude Code is revealing: it’s a terminal tool, designed to be “low-level and unopinionated,” giving “close to raw model access” rather than forcing a single workflow. (Claude Code) That is a very specific design philosophy: it’s closer to a programmable shell than a guided IDE experience.

Then look at the extension surface area Claude Code exposes:

Custom slash commands: turn recurring interactions into reusable “macros,” stored as Markdown files. (Claude Code)
Hooks: deterministic, user-defined shell commands that run at lifecycle points like tool execution or session start — so you can enforce invariants, run tests, block risky actions, etc. (Claude Code)
Subagents: separate, configurable agent profiles stored as Markdown with YAML frontmatter — effectively named “processes” with their own tool permissions and responsibilities. (Claude Code)
Plugins: distributable bundles of commands/agents/hooks/MCP servers — basically “packages” for this environment. (Claude Code)
MCP (Model Context Protocol): a standardized way to connect the agent to external tools and datasets — an ecosystem-level “device bus.” (Claude Code)

If you squint, the shape looks less like “chat with a model” and more like a computer architecture emerging in slow motion:

An execution core (LLM)
A set of system calls (tool use)
A shell (Claude Code terminal interface)
A device protocol (MCP)
Early packaging and extension primitives (plugins)

This is exactly what a new machine looks like before it has a proper programming language.

3) We’ve been here before: new machines start with monitors and REPLs

If Claude Code feels like a primitive terminal, it’s worth remembering: early personal and minicomputers really did begin with something like that — often lower level.

The Altair front panel as “physical machine-code REPL”

The Altair 8800 Operator’s Manual describes the front panel’s SINGLE STEP switch (“implements a single machine language instruction each time it is actuated”) and the EXAMINE / DEPOSIT switches for reading and writing memory. (Altair Clone) That’s a literal read→write→step→observe loop — just implemented with toggle switches and LEDs.

Wozmon: a monitor program as the first shell

The Apple-1’s “human interface” was mediated by a monitor program known as the Woz Monitor (Wozmon), stored in a tiny ROM and responsible for letting the machine do anything sensible after reset. (APPLE2.ORG.ZA — Mirrors) Wozmon’s command style — examine memory, deposit bytes, run from an address — embodies the same direct-manipulation relationship between human and machine state. (SB项目)

ODT: debugging as a command language

DEC’s Octal Debugging Technique (ODT) is documented as a tool that lets you examine/modify memory and set breakpoints — essentially a command-driven control plane over execution. (维基百科) In some PDP-11 variants, ODT functioned as a substitute for a physical front panel, using a serial console to read/write memory and control execution. (Gunkies)

CP/M: even “operating system” grew out of “monitor”

CP/M originally stood for Control Program/Monitor, later reinterpreted as Control Program for Microcomputers. (维基百科) That “monitor” word matters: it signals an era where the OS is still a resident control layer — half shell, half supervisor — rather than the modern abstraction stack we take for granted.

Put those together and a historical pattern snaps into focus:

When a new computing form appears, humans start by operating it interactively — through monitors, REPLs, and debuggers — and only later do languages and toolchains harden into place.

So when Claude Code feels like “BASIC era terminal computing,” it’s not nostalgia. It’s a developmental stage.

4) The misframing of the last few years

The industry’s default lens has been: models are the new thing, agents are apps built on models. That lens forces everything into the “ML product” vocabulary: prompting, temperature, chain-of-thought, agent frameworks, etc.

The “Vibe Computer” framing flips that:

Prompting becomes programming, just in a pre-language era.
Tools become I/O and syscalls, not “plugins.”
Memory becomes state, not merely “context.”
Evaluation becomes replay and verification, not only benchmarks.

Claude Code’s own features — hooks, permissions, subagents, plugins, MCP — make this flip hard to ignore, because they are exactly the kinds of control surfaces you build when you’re turning interactive use into dependable systems. (Claude Code)

5) What’s missing: a “program artifact” for this new machine

A chat transcript is not deployable. A vibe-driven session is not reproducible. An agent that can touch the real world (codebases, infra, money, users) needs the things software has always needed:

explicit boundaries (permissions)
deterministic guardrails (hooks)
tests and evidence
audit trails
replayable executions

Claude Code’s hooks are a strong example of this evolution: they exist specifically to make certain actions always happen, instead of trusting the LLM to remember to do them. (Claude Code)

That is the “toolchain wants to exist” signal. The next step is almost certainly some form of AgentScript — not necessarily a single language, but a move toward versioned, testable, replayable artifacts that describe intent, constraints, and verification in a structured way.

You can see the embryos already:

A CLAUDE.md or project rules file becomes a kind of “firmware.” (Anthropic)
Slash commands become a macro library. (Claude Code)
Subagents become specialization and isolation. (Claude Code)
Plugins become packaging and distribution. (Claude Code)
MCP becomes a standardized peripheral ecosystem. (The Verge)

These are exactly the building blocks that, historically, precede a stable programming model.

6) A simple litmus test: are we still in the “monitor era”?

Here’s a practical way to ground the whole idea:

If you can only reproduce behavior by re-enacting a conversation, you’re in the monitor era.
If you can reproduce behavior by running a versioned artifact (spec/script/tests/replay), you’re crossing into “software.”
If permissions, auditing, and failure recovery are default semantics, you’re building an OS.

Vibe coding is compelling because it makes the monitor era feel powerful. It’s also dangerous because it tempts us to ship monitor-era practices into production.

Closing: why “the birth of the Vibe Computer” is the right metaphor

The phrase “On the eve of the birth of the Vibe Computer” works because it captures a precise moment in the lifecycle of a new machine:

The execution core becomes capable enough to be useful.
Humans interface with it interactively (REPL/monitor).
Toolchains and languages emerge to make it reliable.
Software practices re-form around the new runtime.

Claude Code’s terminal feel is stage (2). Vibe coding is a cultural name for what stage (2) feels like when the interpreter suddenly got powerful.

If this framing is right, the most important question isn’t “which model is best?” but:

What are the languages, runtimes, and operating disciplines* that will make this new computer dependable?*

That’s the real work of the next chapter.

Zhang Di