Explainers · grep, from 1974 to your AI · 8 min

What is grep? A 50-year-old idea your AI still runs.

Half a century after it shipped, grep is still the default way software finds things in files, including the AI coding agent on your machine, which shells out to grep (or its modern cousin, ripgrep) dozens of times a session. This is what grep is, why it has lasted, and the one thing it was never built to do: search a whole machine, instantly, on every query.

Where the name comes from

grep was never a word. It was a command you typed.

Before grep was a program it was a keystroke inside ed, the Unix line editor. To search a document and print the hits you typed g/re/p: globally, for every line matching a regular expression, print it. As the story goes, that fragment was so useful on its own that Ken Thompson lifted the regular-expression engine straight out of ed and, in a single night at Bell Labs, turned it into a standalone program. He named it after the keys: g/re/p. It shipped with Unix in 1974 and never left.

The job was simple: find lines. The lore says an early user was hunting for words across a large body of text (the kind of authorship study people ran on the Federalist Papers), and grep gave the answer in seconds. Within a few years it had become a verb. Engineers “grepped” their logs, their mail, their code. Today it sits on effectively every server, Mac and Linux box on earth, and (through ripgrep) inside the editors and AI agents you used this morning.

How it actually works

It reads every line. That is the whole trick, and the whole cost.

A regular expression is just a pattern for text: ERROR.*timeout matches any line where ERROR is followed somewhere later by timeout. grep's work is mechanical and honest: open a file, read it one line at a time, test each line against the pattern, print the matches, close it, move to the next. Point it at a folder with -r and it does exactly that for every file it can reach.

Nothing is precomputed. The work happens the instant you press Enter. That is why grep is so dependable, and why its cost is set by the amount of text on the disk, not the size of your question. An index inverts that bargain. Here is the difference in one picture.

Left: a walker visits every line of every file, every query: the dashed path is grep reading in order, the blue bars are the two lines that match. Right: the reading was done once ahead of time, so the same query jumps straight to the two hits and opens nothing. Same question, two costs. Ryzen 9 9950X3D · 64 GB DDR5 · NVMe · Windows 11 · 4.47M files.

Why it lasted fifty years

Fifty years is not an accident. grep earned it.

grep does one thing and does it well: the whole Unix idea in a single tool. It needs zero setup, is already on the machine, starts instantly, and composes: pipe anything into it with | grep and it filters the stream. For one file or a live pipe it is a tight loop of C that is genuinely hard to beat. Nothing about that has aged.

And it got a worthy successor. ripgrep, released in 2016, kept grep's model and made the walk faster: it searches every CPU core at once, honors your .gitignore, skips binary files, and speaks Unicode with no setup. ripgrep is now the find-in-files inside VS Code, the search in many terminals, and the tool most AI agents reach for by default. If you want the honest ledger of exactly what ripgrep improved, we measured it here.

So this is not a takedown. For one file, a quick log scan, or a pipe, grep and ripgrep are the right answer, full stop. The interesting question is what happens when the target isn't one file but a whole machine, and the thing doing the searching isn't a person typing once but an agent asking dozens of times a minute.

The part nobody expected

Your AI finds code by grepping. On every question.

Here is the twist. The most advanced coding agents of 2026 (Claude Code, Cursor, Copilot) have no secret way to find things on your disk. When one needs a file or a symbol, it shells out to the same primitives: grep and ripgrep, walking the tree. On a small repo that is fine. On a real machine (4.47 million files across a dozen repos plus everything that was never in git), the walk is the bottleneck, and the agent pays it again on every question it can't answer from memory.

Every one of those greps is honest work the agent should never have had to do. Tokens spent reading directory listings are tokens not spent thinking; minutes spent walking are minutes you sit and wait. The tool isn't wrong. It is being asked a question it was never designed for. grep was built to search one file, for a person, once. An agent is searching a whole machine, continuously. Measured on the same box, that gap is where most of a session's budget quietly goes.

Keep grep. Add a floor under it.

Give your agent something faster to reach for.

Everything local is free forever, on all your devices, no card. Hosting starts at $5.99/mo. Download for Windows.