Three Eras of Vibe Coding

The term "vibe coding" is only a year and a half old - Andrej Karpathy, one of the co-founders of OpenAI, coined it in February 2025 - and it has already become something people either adore or despise, depending on what they take it to mean. By November of that same year Collins had made it their word of the year.

I use the term here to mean LLM augmented development, that is, "building software with the help of large language models", which is not quite the same thing as "building software by prompting in plain English". The word is new, but we learned to write code with LLMs well before it.

GitHub Copilot arrived in 2021: code autocomplete backed by a neural network. What really changed everything was the birth of GPT-4 in March 2023 (an event also known as the Great Turning Point): models learned to produce more or less working code. Tools like Cursor and Aider showed up around the same time and made that part of an actual workflow. The models still could not run tools or manage their own context, and they were already impressive.

In 2024 and 2025 LLMs learned to call tools, and the era of semi-autonomous agents began. The LLM stopped being a text generator and became an instrument whose full range we are still working out. In 2026 it is the main story in AI.

The First Era: The Rise and Fall of Prompt Engineering

Base models of the GPT-3 generation (2020-2022) were not trained to follow instructions. To get the artifact you wanted, you had to prime the model: set the domain ("You are an experienced Python developer designing a microservice..."), describe the artifact in detail ("a CRUD handler inheriting from..."), give it a few examples (few-shot prompting), and so on. All of it steered generation in the right direction and kept drift and hallucination at bay.

By 2023 there was a market: "prompt engineer" job postings, prompt marketplaces, courses, books, and thousands of posts along the lines of "10 prompts that will replace your analyst". Today "You are a QA lead with ten years of experience in software testing..." reads as faintly ridiculous - the models are competent without it. Echoes of that approach survive in what we now call skills, but that is a topic for another post.

The whole thing collapsed for several reasons at once, and none of them is that prompts stopped mattering:

- instruction tuning and RLHF did the job that half of those tricks existed for;

- reasoning models with chain-of-thought started steering generation on their own;

- the magic phrases stopped paying off, sometimes got in the way, and never transferred between model generations.

You used to need to know how to talk to the model. Now you need to know what you want from it.

The Second Era: Managing Context

GPT-4 had what now looks like a tiny context: 32K tokens. Two answers to that problem emerged.

Doing It by Hand

Aider was the standout in this class. It kept an AST-derived map of part of the project in context automatically, but it expected you to name the files you wanted to work on. It stayed a niche product with a text interface, it delivered remarkable results, and some of its choices became de facto standards in the industry. Instead of a plain diff for edits, for instance (models kept losing track of line numbers), it proposed the git merge conflict format - something the model had seen millions of times during training:

mathweb/flask/app.py
<<<<<<< SEARCH
from flask import Flask
=======
import math
from flask import Flask
>>>>>>> REPLACE

Retrieval-Augmented Generation (RAG)

Cursor went the other way. The idea behind RAG is to index the whole project and feed the parts relevant to the query into context. That took a decidedly non-trivial pipeline: a vector database, AST parsing, chunking, and plenty more.

The trouble was the single-shot nature of early models: you had to work out which files a user request touched before doing anything, and in the general case that is hard or outright impossible. But what killed RAG as the primary mechanism was not the list of drawbacks, it was the arrival of an alternative. Once the model had tools - read a file, match a pattern, run a command - it turned out to search better than embedding lookup did. Not because grep is smarter than cosine distance, but because the model knows what it is looking for, sees the result, and can rephrase the query. Vector search takes one blind shot; an agent takes a series of aimed ones.

The Third Era: Autonomous Agents

One Agent in a Terminal

The breakthrough was Claude Code. It was not the first autonomous agent, it was the first one that worked. AutoGPT came out back in 2023, then Devin and Cline, but genuinely autonomous agents only became possible with Claude 3.5 Sonnet. Models started being trained on multi-step tool use with feedback from the environment. A capability appeared that had simply not existed before: read an error message and change the plan. Add a long context that holds a history of hundreds of steps, and reasoning, which removes the need to impose a structure of thought from outside.

It is worth noting that Claude Code dropped RAG from version one and bet on a minimal tool set: run shell commands, grep, read and edit files. What is hard or impossible to get right in one shot is easy across several iterations. That became the new paradigm.

Agents in Terminals

It became clear very quickly that one agent is not enough. Developers started running several and switching between them. git worktree, long forgotten, came back, and build isolation started to matter. Tooling for managing the fleet appeared: Conductor, Vibe Kanban, Claude Squad, Cursor Background Agents.

Agents got access to issue trackers, work chats, build systems, staging environments. Practically any aspect of the job can be automated now. Agents can be driven remotely, from a browser or a phone. There was no stopping it.

A Swarm in the Cloud, Which Is Where We Are

Agents run on a human-in-the-loop model: the end of a turn requires a person to step in, set the next task, check the output, review it. The bottleneck, it turns out, is the person: while they deal with one agent, the rest sit idle.

The obvious move is to hand agent management to an orchestrator, an agent that makes the decisions that do not need a human: pushing work into the build, moving tickets. A personal machine no longer has the resources for that. Holding enough agents means sandboxes in the cloud.

A little over a month ago Claude Code added messaging between neighboring sessions, and it turns out LLMs communicate with each other startlingly well. The story of OpenAI's agents coordinating an escape from their sandbox rhymes with that. What was a lab experiment not long ago is quietly becoming an industry standard.

The new reality may well look like this: you hand over a task, close the laptop lid, and accept finished work the next day.

What Comes Next

There is a great deal of skepticism in the industry, much of it well founded, about what this generation of LLMs can do, about the transformer architecture itself, about the limits of vibe coding, and so on.

But a technology moving this fast demands, as it has more than once in our field, close study at the very least, if not adaptation. To stay in place, we have to run very fast indeed.