The coding agent hackbook: 40 techniques to ship faster with AI agents

Write the repo map once

BeginnerContext · Team setup

Keep a short agent instructions file at the repo root: stack, build and test commands, conventions, no-go zones. Most agents read it at the start of every session, so you stop repeating yourself.

▸ Details

Ask the agent to draft it from the codebase.
Cut it to what a new teammate would need on day one.
Commit it and update it whenever the agent repeats a mistake.

Starter prompt

Read this repository and draft an agent instructions file (under 60 lines) covering:
- Stack and key folders
- Exact commands to install, build, lint and test
- Coding conventions we actually follow (cite example files)
- Folders and files that must never be edited
Flag anything you are unsure about instead of guessing.

Point, don't paste

BeginnerContext

Reference file paths, function names and line ranges instead of pasting code into the chat. The agent reads the current version, and you avoid feeding it a stale copy.

Clone a good example

BeginnerContext · Prompting

Name an existing file as the pattern to follow. "Build it like this one" beats three paragraphs describing your conventions.

▸ Details

Starter prompt

Create [NEW_THING] following the same structure, naming and error handling as [EXAMPLE_FILE_PATH]. Do not introduce new patterns or libraries. List any place where you had to deviate and why.

Fresh session per task

BeginnerContext

Long conversations pile up stale assumptions and dead ends. Start a clean session for each new task so the agent reasons from the code, not from an hour of chatter.

Handoff note before a reset

Power userContext · Planning

Before clearing a long session, have the agent write a handoff file with the goal, decisions, files touched and next step. The next session starts from that note instead of from zero.

▸ Details

Starter prompt

Write a handoff note to [HANDOFF_FILE_PATH] for a fresh session that will continue this task. Include:
1. The goal in one sentence
2. Decisions made and why
3. Files changed so far
4. What is verified vs. not verified yet
5. The exact next step
Keep it under 40 lines.

Fence off the no-go zones

BeginnerContext · Git & safety

Say explicitly which folders are off-limits: generated code, migrations, vendored libraries, lockfiles. Agents follow boundaries far better than they guess them.

Bring the docs to the agent

Power userContext

For fast-moving libraries, save the relevant docs page or changelog as a local file and point the agent at it. Training data can lag behind the version you actually use.

▸ Details

Check the library version in your lockfile.
Save the matching docs section to a local reference folder.
Tell the agent to follow that file over its own memory.

Keep a domain glossary

Power userContext · Team setup

A short list of business terms and what they mean in code stops the agent from inventing names. "Account" and "Customer" should never be synonyms by accident.

Outcome, constraints, done-when

BeginnerPrompting

Every brief answers three questions: what should exist after, what must not change, and how we'll know it works. Vague goals produce plausible but wrong code.

▸ Details

Starter prompt

Goal: [WHAT SHOULD EXIST WHEN YOU ARE DONE]
Context: [RELEVANT FILES OR TICKET]
Constraints: [WHAT MUST NOT CHANGE, LIBRARIES TO USE OR AVOID]
Done when: [COMMAND THAT MUST PASS] and [BEHAVIOUR I CAN CHECK MANUALLY]
Work in small steps and stop if a constraint blocks you.

Questions before code

BeginnerPrompting · Planning

Ask the agent to list its clarifying questions before writing anything. Ten seconds of answers saves a twenty-minute wrong turn.

▸ Details

Starter prompt

Before writing any code, ask me up to 5 clarifying questions about [TASK]. Only ask what you cannot find out by reading the repository. Then wait for my answers.

Make it explain back

BeginnerPrompting

Have the agent restate the task and its approach in three bullets. If the restatement is off, you caught the misunderstanding before it became a diff.

One task per prompt

BeginnerPrompting

Bundling a bug fix, a refactor and a new feature into one request blurs the diff and the review. Ship them as separate tasks, even if they touch the same file.

Say what not to do

BeginnerPrompting · Git & safety

Agents like to be helpful beyond the ask. A short "do not" list keeps them from adding dependencies, renaming things or tidying unrelated code.

▸ Details

Starter prompt

While doing [TASK]:
- Do not add new dependencies
- Do not rename or move existing files
- Do not refactor code outside [SCOPE]
- Do not change tests unless I ask
If you think one of these is necessary, stop and ask.

Paste the error verbatim

BeginnerPrompting · Verification

Give the full error, the stack trace and the exact command that produced it. A paraphrased error sends the agent hunting in the wrong place.

Plan first, code second

BeginnerPlanning

Ask for a written plan with the files to touch and the order of changes, review it, then say go. Fixing a plan costs a minute; fixing a diff costs an afternoon.

▸ Details

Starter prompt

Do not write code yet. Propose a plan for [TASK]:
- Files to create or modify, and why
- Order of changes
- How each step will be verified
- Risks or unknowns
I will review before you start.

Plan as a checklist in the repo

Power userPlanning

Store the plan as a markdown checklist the agent ticks off as it goes. It survives session resets and shows you progress at a glance.

Slice thin and vertical

Power userPlanning

Break features into thin end-to-end slices, each one working and testable on its own. Agents do far better with five small wins than one giant leap.

▸ Details

Ask the agent to split the feature into slices that each run end to end.
Build and verify one slice per session.
Commit after each green slice.

Spike, then throw it away

Power userPlanning

Let the agent build a quick throwaway prototype to learn where the hard parts are. Then discard it and start over with a clean plan informed by what you learned.

Ask for three options

BeginnerPlanning

Request two or three approaches with trade-offs before picking one. You stay the architect, and the agent often surfaces an option you hadn't considered.

▸ Details

Starter prompt

Propose 3 different approaches to [PROBLEM]. For each: a short description, files affected, main trade-off, and what could go wrong. Recommend one and explain why. No code yet.

Pre-mortem the plan

Power userPlanning · Verification

Ask: "Assume this plan failed in production. What went wrong?" The agent is surprisingly good at attacking a plan it did not just defend.

▸ Details

Starter prompt

Assume the plan in [PLAN_FILE] shipped and caused an incident a week later. List the 5 most likely causes, ranked by likelihood, and the change to the plan that would prevent each one.

Give it a way to check itself

BeginnerVerification

Tell the agent the exact test, lint and type-check commands, and require them green before it says done. An agent with a feedback loop fixes its own mistakes.

▸ Details

Starter prompt

After each change, run [TEST_COMMAND] and [LINT_COMMAND]. Do not report the task as done until both pass. If something fails three times in a row, stop and explain what you tried.

One fast check command

Power userVerification · Team setup

Wrap lint, types and fast unit tests in a single command that runs in about a minute. The cheaper the check, the more often the agent (and you) will run it.

Failing test first

Power userVerification

For bugs, have the agent write a test that reproduces the problem and confirm it fails. Then fix. Now "fixed" means something you can prove.

▸ Details

Starter prompt

Bug: [DESCRIPTION AND STEPS TO REPRODUCE]
1. Write a test that reproduces this bug. Run it and show me it fails.
2. Only then fix the code.
3. Run the test again and the full suite, and show both outputs.

Read the diff, not the summary

BeginnerVerification

The agent's summary is its opinion of what it did; the diff is what it actually did. Review the diff every time, especially the files you didn't expect.

Fresh-eyes reviewer

Power userVerification

Open a new session and ask it to review the diff as a skeptical senior engineer. Without the context of writing it, the agent spots issues it would otherwise defend.

▸ Details

Starter prompt

You are reviewing a pull request you did not write. Review the changes on [BRANCH] against [BASE_BRANCH]. Look for: bugs, missing edge cases, unhandled errors, security issues, and changes outside the stated scope ([SCOPE]). Rank findings by severity. Do not fix anything yet.

Ask for the receipts

BeginnerVerification

When the agent says tests pass, ask for the actual command output. It quickly reveals checks that were skipped, partially run or never run at all.

Watch for test tampering

Power userVerification · Git & safety

Under pressure to get green, an agent may weaken assertions, skip tests or special-case the test input. Scan test file changes with extra suspicion.

Check the UI with your eyes

BeginnerVerification

Passing tests don't mean the page looks right. For UI work, open it yourself, or let the agent capture screenshots if your setup allows it, before calling it done.

One worktree per agent

Power userParallel work · Git & safety

Give each parallel agent its own git worktree and branch. They can build and test at the same time without overwriting each other's files.

▸ Details

Create one worktree per task, each on its own branch.
Start one agent session inside each worktree.
Merge back one branch at a time, running checks after each merge.

Split along file boundaries

Power userParallel work · Planning

Parallel tasks should touch different parts of the codebase. If two tasks edit the same files, run them one after the other and save yourself the merge conflicts.

Background the small chores

BeginnerParallel work

Hand small, well-defined chores (a typo sweep, a dependency bump, a missing test) to a background agent while you focus on the hard problem.

Race two approaches

Power userParallel work · Planning

When you're unsure which design is better, have two agents implement both in separate branches. Comparing working code beats debating hypotheticals.

Scout agent, builder agent

Power userParallel work · Context

Let one session investigate (read code, trace a flow, write findings to a file) while another implements from those findings. Research noise stays out of the builder's context.

▸ Details

Starter prompt

Investigate how [FEATURE OR FLOW] works in this codebase. Do not modify any code. Write your findings to [NOTES_FILE]: entry points, key files, data flow, and anything surprising. Keep it under 50 lines.

Commit before you delegate

BeginnerGit & safety

Start every agent task from a clean working tree. If the result is bad, you throw it away in one command instead of untangling it by hand.

Small commits, readable history

BeginnerGit & safety

Ask the agent to commit after each verified step with a clear message. You get checkpoints to roll back to and a history reviewers can follow.

Keep secrets out of reach

BeginnerGit & safety

Don't leave real credentials in files the agent can read. Use a sample env file with fake values and scoped test accounts for anything it has to run.

Gate the dangerous commands

BeginnerGit & safety · Team setup

Most agents let you decide which actions need your approval. Keep deletes, force pushes, migrations and deploys behind a human yes.

Branch per task, PR per branch

BeginnerGit & safety · Team setup

Agent work goes through the same pull request and review flow as human work. No direct pushes to main, no special lane for AI-written code.

Turn repeat mistakes into rules

BeginnerTeam setup · Context

When the agent makes the same mistake twice, add one line to the instructions file. Over a few weeks the file becomes your team's best onboarding doc.

Grow a team prompt library

Power userTeam setup · Prompting

Save prompts that worked in a shared folder in the repo, with placeholders for the parts that change. Good prompts become team assets instead of personal tricks.

▸ Details

Create a prompts folder in the repo.
Add a prompt only after it worked on a real task.
Review prompt changes in pull requests like any other code.

The coding agent hackbook: 40 techniques to ship faster with AI agents

The 40 hacks

Good hack or bad habit?

Failure modes & fixes

Set up your repo in 20 minutes

Quick check