An agent can touch more code in an afternoon than I would normally review in a week. That has been the shape of the last few months for me. The writing part is more or less solved, or solved enough that I stopped worrying about it. The part that broke is me. I open the repo after a couple of agent sessions and I am behind on my own project.
For a while I assumed the fix was to read more carefully, or to read faster. It was neither. What actually fixed it was changing how I ask, and it costs two words at the end of a prompt.
# Where the bottleneck moved
You ask an agent to explain a config field, or trace an auth flow, or walk you through fifteen endpoints. You get an answer, and it is usually a good answer. It is also five pages long.
Then a PR merges. Another session rewrites half the billing module. You open the repo and feel behind again, and not because you got slower. The information rate went up.
Reading agent output like a design doc does not work, there is too much of it. Reading it like source does not work either, not while you still do not know which files matter. What I needed was a third mode: fast orientation, without pretending I already work here.
# The two words
I started ending prompts with:
Explain it like I am dumb and lazy.
I do not mean that I am incapable. I mean two specific things.
Dumb: do not assume I know your vocabulary, your schema names, or that I remember what we talked about last Tuesday.
Lazy: get me to understanding quickly, do not aim for completeness for its own sake.
That is a style contract. You are telling the model how to prioritise when it has two instincts pulling against each other, be thorough and be useful. Without the contract, the default is thorough.
# What actually changes in the answer
Same question, two modes.
What is cached_session_key on the user record?
| Default | Dumb and lazy |
|---|---|
Field 7 stores a denormalised WrappedSessionKey protobuf to cut key version lookups during token validation. Callers must go through the auth service rather than reading the blob directly. | A cached copy of the user's locked session master key, so every request does not have to ask "which key version?" all over again. Not the password. Not something app code should touch raw. |
Walk me through every method on BillingService.
| Default | Dumb and lazy |
|---|---|
| A section per method, with repository interfaces, idempotency keys, feature flag gates and dual write migration branches. | Storage in a table up front, then per method: why it exists, who calls it, and the arrow flow down to the database. Admin APIs grouped together, cheat sheet at the end. |
Same facts either way. What changes is the entry ramp and the density.
The lazy mode also does something I did not expect. It names the gaps. "This field is in the API spec but the handler does not write it yet." That one sentence has saved me an hour of grep archaeology more than once.
# Why "be concise" does not do the same thing
Be concise is too vague to change anything structural. The model shortens its sentences and keeps the same abstraction level, so you still get key derivation explained to you before you know what a key version is.
Dumb and lazy forces different choices:
- Analogy before jargon. A phone book, a nested lock, a filing cabinet.
- A TL;DR at the top, so you can stop reading once you have enough.
- Flows written as arrows, client → API → service → cache → database, instead of a wall of type names.
- Grouping. Fifteen endpoints become four buckets rather than fifteen mini essays.
- Honest scope. "You probably never touch the database layer directly."
The content does not get dumber. The on ramp does, and the ceiling is still there when you ask a follow up.
# A few phrases worth keeping around
You do not need my exact two words every time. These are the ones I reuse:
| What you want | What to say |
|---|---|
| Fast orientation | "TL;DR first, details after." |
| No assumed context | "Explain it like I have never opened this repo." |
| Minimum reading time | "Lazy mode: tables and flows, skip edge cases unless I ask." |
| A deep dive, later | "Onboarding doc structure, but keep part one to one screen." |
| Review prep | "Staff engineer mode: code citations, fewer analogies." |
They mix. "TL;DR, dumb on ramp, and tell me what is not implemented yet" is the combination I reach for most when catching up on a PR an agent wrote.
# How I use it around agent PRs
Before I read the diff, one pass in lazy mode: what changed, why, which tables, what is risky, what is stubbed.
While I read the diff, staff engineer mode on the handful of files that actually matter.
Before a meeting, cheat sheet mode. I want to issue a refund, so which endpoint, which table.
Two modes, two passes, much less whiplash.
NOTE 💡 The first answer is not the only answer. If it comes back too long, reply with "TL;DR only" or "cheat sheet only". That second message costs you nothing, and the first one is where the hours get saved.
# What I stopped doing
- Treating the first reply as final. Lazy mode is pass one, the follow ups go deep.
- Asking "explain X" with no hint about who is asking. Given nothing, the model assumes a senior engineer who already works on the codebase.
- Feeling odd about the word dumb. The model is not forming an opinion of you, it is reranking its output. You are editing the prompt, not your intelligence.
# Final thoughts
Two words are not magic. What they do is replace a paragraph of style instructions that I used to write out properly and then, more often, forget to write out at all. Dumb and lazy is simply the phrasing I will actually type at five in the evening when another agent PR has just landed.
Use whatever phrase sticks for you. The agents are not going to slow down, but the catch up strategy can be two words and one follow up question instead of a weekend spent reading nested OpenAPI comments.
Try it on the next thing you do not understand. One sentence of context, then explain it like I am dumb and lazy.
Thanks for reading, if you would like to hear more from me, feel free to reach out via email or follow me on Twitter.