Agentic Coding Best Practices: Ten Habits That Keep Agents on Track

The agentic coding best practices that matter most are the same whichever agent you use. Write the task down before you prompt, with where to look and what done means. Plan before any change that spans several files. Keep each task small enough to finish and check in one session. Give the agent a test or build it can run, and ask for the output as evidence. Keep the instructions file short, clear the context between tasks, and grant only the access the task needs. Then review the diff yourself, keep a person as the gate on merging, and keep every task, plan and result on one shared board rather than in chat histories. The ten habits below explain each one and the setting or prompt that makes it stick.

If you use Claude Code specifically, Claude Code best practices has 25 tool-specific tips. This page is the agent-neutral version: the habits that carry over when a team runs Claude Code, Codex, Copilot and Gemini CLI side by side.

Where these habits come from

Anthropic’s engineering article “Claude Code: Best practices for agentic coding” is what many people search for. Its old address now redirects to Anthropic’s best practices guide↗ (opens in a new tab) in the Claude Code documentation, which rests on one constraint: the context window “fills up fast, and performance degrades as it fills.” GitHub, OpenAI and Google publish similar advice for their agents, and the overlap is large. Where the vendors agree, the habit is probably about agents in general rather than one product.

Before the agent starts

1. Write the task before the prompt

An agent cannot ask the question you forgot to answer, so it guesses. GitHub’s guide to getting the best results from Copilot cloud agent↗ (opens in a new tab) lists what a well-scoped task contains: “A clear description of the problem to be solved or the work required. Complete acceptance criteria on what a good solution looks like. Directions about which files need to be changed.” That is a good template for any agent. Write the symptom, the likely location and what “fixed” looks like; giving an AI agent a task it can finish has examples.

2. Plan first when the change is big

Separate reading and planning from editing. Most agents have a read-only mode for this: plan mode in Claude Code and Gemini CLI, Plan in Copilot and Cursor. Have the agent explore, write a plan, and wait. Read the plan the way you would read a colleague’s design note: what files, what order, what could break. Skip it when the change is obvious. Anthropic’s rule of thumb is that if you could describe the diff in one sentence, you do not need a plan. For larger features, writing the spec first is covered in spec-driven development.

3. Keep tasks small

One task, one session, one reviewable change. A task an agent can finish and verify in one sitting goes better than one it has to hold in its head for hours, because the longer a session runs, the more of its context is old attempts. Split big work before anyone starts, and give each piece its own acceptance check; AI agent task decomposition shows how to cut it. GitHub also lists the work to keep for yourself: complex and broadly scoped tasks, sensitive and critical ones, ambiguous ones, and anything you want to learn by doing.

4. Keep the instructions file short

Every agent reads a standing instructions file: AGENTS.md for most, CLAUDE.md for Claude Code, GEMINI.md for Gemini CLI, .github/copilot-instructions.md for Copilot. The AGENTS.md↗ (opens in a new tab) project describes its file as “a README for agents”, and suggests build and test commands, code style, testing instructions and security considerations. Put there only what the agent cannot work out from the code, and cut any line whose removal would not cause a mistake. A long file is followed less reliably, not more. Examples to copy are in AGENTS.md examples.

While it works

5. Give it a check it can run

This is the habit with the biggest payoff. A test suite, a build, a linter or a screenshot to compare turns “looks done” into pass or fail, and the agent keeps going until it passes. Anthropic’s essay on building effective agents↗ (opens in a new tab) makes the same point about coding in general: “Code solutions are verifiable through automated tests,” and agents “can iterate on solutions using test results as feedback.” For a bug, ask for a failing test that reproduces it first, then the fix. And ask for evidence rather than a claim: the command it ran and what it printed.

Users report checkout fails when the cart has a discount code
and sales tax is zero (orders shipped to Oregon).
Look in src/checkout/totals.ts.
1. Write a failing test that reproduces it.
2. Fix it without changing other tests.
3. Run npm test and paste the output.
Done = the new test passes and nothing else changed.

6. Keep the context clean

Start a fresh session, or clear the current one, between unrelated tasks. Send broad research to a subagent so a hundred file reads do not crowd out the work. And if you have corrected the agent twice on the same point, stop correcting: clear the session and start again with a better prompt that includes what you learned. A clean session with a good prompt beats a long one full of failed attempts. Context engineering for AI agents covers the rest.

7. Grant only the access the task needs

Approve narrowly: an allow rule for npm test removes a prompt you answer twenty times a day, while approving every shell command removes every safeguard. Keep secrets out of files the agent can read. Run unattended or “approve everything” modes only inside a sandbox, a container or a throwaway CI runner. The same goes for tools: an MCP server the agent connects to should give it the smallest role that does the job. The settings for each agent are in security controls for AI coding agents.

After it finishes

8. Review the diff, starting with the tests

Read the change before you read the agent’s summary. Check the list of files against the task, then the test changes, because the quickest way to “all tests pass” is to change the tests. Confirm any new package really exists and is needed. Then read the logic and the edges. Anything you cannot verify, do not ship. Verifying AI-generated work has the checks for code and for everything else an agent produces.

9. Keep a person as the gate

A second agent in a fresh context is a useful first reviewer, because it is not anchored to the reasoning that wrote the code. Tell it to report only problems that affect correctness or the stated requirements; reviewers asked to find gaps usually find some even when the work is sound. Then a person approves the merge. Agents work through pull requests, branch protection applies to them like anyone else, and nobody merges their own agent’s work unread. Human in the loop for AI agents covers where to put the approvals.

10. Keep one board for all the work

Each agent has its own to-do list, and each one lives inside a single session on a single machine. When two agents and three people work on the same product, nobody can see what is in flight, what was tried, or why a choice was made. Put the work on one board that every agent and person reads and updates, and make it part of the routine: read the task before starting, write the plan into it, record how it was tested when finished, and file whatever else the agent noticed as a new task instead of fixing it on the side. Running several agents at once is covered in orchestrating coding agents.

What that looks like on fenbs

fenbs is a task board that people and AI assistants share over MCP at https://fenbs.ai/api/mcp. Each task is a feature, enhancement or bug with a priority from 1 (most urgent) to 10, a note for the problem, a plan for how it will be done, an optional size from XS to XL, and a test status with test notes: tested, partly, failed, or needs owner check for what only a person can confirm. Tasks move through To Do, Next Up, In Progress and Completed, and History records who changed what, including which assistant.

• Habits 1 to 3: the assistant reads the task with fenbs_get_item, writes its plan into the task with fenbs_update_item, and files what it spots but should not fix with fenbs_create_item.
• Habit 5: when it finishes, it sets the test status and notes what it ran; it is instructed never to mark something tested that it did not check.
• Habit 9: a person can pre-approve particular tasks for AI, which an assistant takes with fenbs_next_approved_task and hands back with fenbs_release_task if it cannot finish.
• Standing rules: when an owner decides how something must always be done, it goes on the Decisions and rules page, and every connected AI assistant reads the rules first. The decider is always a person.

What fenbs does not do matters as much here: it has no sprints, no due dates and no settable assignee. It is the shared list of work and what happened to it, not a scheduling tool.