Getting an AI up to speed

A one-line prompt gets one-line thinking

The first instinct everyone has is to type the task and hit enter. "Add caching to this service." You get back something that compiles and misses the point, because you asked a model that knows nothing about your code to make decisions it has no basis for. It fills the gaps with whatever is plausible. Plausible is the enemy. It looks right, it reads right, and it is built on guesses about your conventions, your constraints, and what you were actually trying to do.

So I do not start with the task. I start by getting the model to know the problem the way I know it. Most of the gap between a bad run and a good one closes here, before any real work happens, and almost none of it is a clever wording of the prompt. It is onboarding. I treat a fresh agent like a strong developer who started this morning and has not seen the codebase yet. Smart, fast, and totally without context. My job is to fix the second part.

Interview first, then narrow

The move I use most, the one running this whole blog, is to interview first and narrow second. I talk to the model. I let it ask me things, I let it poke at the problem, I let it get the shape of it wrong out loud so I can correct it cheap. Open questions load context. While it is still learning the problem, every answer it pulls from me is a new fact in its head.

Then I flip. Once it has enough to reason, I switch to closed questions, multiple choice, this option or that one. Open to load context, closed to make decisions. The interview is where it learns; the narrowing is where we commit. You are reading the output of exactly that process.

Do not spoon-feed, give it the keys

The slow way to onboard is to paste everything you know into the prompt. It is slow, it is incomplete, and it teaches the agent to wait for you. I do the opposite. I give it the CLI and let it self-serve. Read the repo. Run fledge run dev. Check the issues and the open PRs. Find out for itself instead of being told.

This is what AGENTS.md is for. It is the lay of the land, the street signs that orient an agent the moment it arrives, so it knows which tools to reach for without me naming each one every time. I give the agent my account and let it work the way I work, in the place I work, with the tools I use. Then I iterate on that until a run feels like me and not like a stranger guessing at my repo.

Set the target before you start

Context tells the agent where it is. The target tells it where to go. Before real work begins I set both: the target, written as a spec or a contract, and the context. Then I either dive straight in or ramp up slowly, depending on how big the job is.

The plan does not have to be heavy. A few lines of what we are aiming at beats a document nobody reads. But the agent needs that target, because without it the work does not stop, it just aims at something plausible instead of the thing you wanted. A plausible miss is the most expensive kind, because you only catch it after it is built.

That is the whole bet: good output is an onboarding problem, not a prompting trick. Spend your effort there, up front, and the real work mostly takes care of itself.