Grep like an LLM · part 1 of 6

Playbook

11 June 2026

Watch an AI agent work in a repo and you'll notice something. It barely reads any code. It runs a search, glances at the result, runs another. Then it opens one file and goes straight to the right line.

The speed comes from reading just enough to be informed of the next move.

Maps before files

A codebase with thousands of files contains maybe three that matter to your task. This is how to work with your codebase to efficiently get you to the right place:

$ git grep -ci 'loyalty'
repositories/LoyaltyRepository.ts:11
services/loyalty/LoyaltyService.ts:23
apps/sundae.shop/app/account/page.tsx:4

This counts the matches per file, and that is your map. High numbers mark the centre of gravity. You haven't opened a single file yet, and you already know where the feature lives.

Searches are questions

Every command in this series answers one question. Where does this live? Who sets this value? When did this string appear? Before you type, know which question you're asking. Then the result either answers it or rules something out, and both are progress.

A search that finds nothing costs two seconds and tells you something true, meaning you can guess freely and verify instantly.

Stop early

The method has one ending: stop the moment your question is answered. Not when you've read the whole file. Not when you understand the module. When you can answer the question your ticket actually asked.

This is the part that feels wrong at first. It isn't thoroughness you're giving up, it's ceremony. You can always search again.

What the modules are for

None of this is hard to understand. It's hard to remember at 9am with a ticket open. The modules exist to close that gap: one command at a time, each with a small exercise to try at your desk, until reaching for the map becomes the reflex and reading everything becomes the thing that feels wrong.

Next: making a map of sundae-service, an ice cream van with a loyalty problem.