Getting good results
The single most useful habit: brief your agent the way you would brief a competent contractor who is new to your company. They are good at the work and know nothing about your situation.
Say what you want, not how to type it
Describe the outcome and the constraints. Prescribing every step wastes the agent's judgement and tends to produce worse results than stating the goal.
fix the login bug
Users on Safari get logged out after ~5 minutes; Chrome is fine. Started after last Thursday's release. Find the cause and fix it — the session cookie handling in the auth middleware is my first suspicion, but don't anchor on that. Open a PR, don't merge.
The second version gives it a symptom, a discriminator (Safari but not Chrome), a time window, a hypothesis it is explicitly allowed to discard, and a stopping point.
Point it at the ground truth
An agent that has to guess where things live will guess. Naming the repository, the file, the log group, the dashboard, or the AWS account removes an entire class of wasted effort.
Where you genuinely do not know, say that too — “somewhere in the billing service, I think” is more useful than silence, because it scopes the search without falsely constraining it.
State the boundaries you care about
Agents act. If there is a line you do not want crossed, say so up front — it is far cheaper than undoing.
- “Open a PR; do not merge or deploy.”
- “Staging only. Do not touch production.”
- “Read-only — investigate and report, change nothing.”
- “Ask me before creating anything that costs money.”
Right-size the task
“Build the whole app” produces something shaped like an app that matches little of what you had in mind. The agent has a finite working context, and a very long task loses early detail.
Break large work into stages with a checkpoint between them: schema first, review; then the API; then the UI. You catch a wrong assumption after twenty minutes instead of after four hours.
Ask for the reasoning when it matters
For consequential work, ask it to explain its approach before it starts, or to report what it found before it fixes. Two lines of plan will tell you whether it understood the problem — much cheaper than reviewing a large diff built on a wrong premise.
Equally, ask it to say what it is unsure about. A good report distinguishes what was verified from what was assumed.
Give it durable context once
Anything you would otherwise repeat every week belongs in memory. Say it plainly and it will keep it:
- “Remember: we use pnpm, never npm.”
- “Remember: all infra changes go through Terraform, never the console.”
- “Remember: Jordan owns billing, ask them before touching Stripe.”
Correct it the same way. “That was wrong — we deprecated that service last month” updates its understanding going forward, not just in this thread.
When a result disappoints
Usually one of three things is missing: it did not know something you did, a constraint went unstated, or the task was too big to hold at once. Saying which is more productive than restating the request.
“You used the old API — we migrated in March, see docs/migration.md” gets a correct second attempt. “That's wrong, try again” usually gets a differently wrong one.