Skip to content
AIupick

Guide for developers · 18 jobs

AI for developers: coding agents, costs and safe hand-offs

If you already use completion and chat, the next step is agents that read the repository, run commands and open pull requests. Whether that saves time depends less on the model than on the setup. The first part works with any coding agent; the Claude Code and Codex parts go into the commands, files and settings of each, from their official docs.

  1. Any coding agent

    01

    Give the agent a task it can prove it finished

    Agents fail on "improve this" and succeed on tasks that end in a check: a failing test that must pass, a command whose output must change. Write the proof into the task, and the agent keeps going until it is done instead of stopping when it looks done.

    Example

    "Fix the date parser for ISO week dates. Done means npm test -- dates passes, including the new test for 2026-W01. Do not change the tests." The agent runs the test until it passes and pastes the output; you review a 30-line diff instead of a guess.

    How to do it

    1. 1Before you hand it over, write or point to the check: the failing test, or the command and its expected output.
    2. 2Give it the task with the prompt on this page, including the files it may change and the ones it may not.
    3. 3Let it run the check itself and paste the final output.
    4. 4Review the diff like a colleague's pull request; a passing check starts the review, it does not end it.

    Built in

    Prompt to copy

    Task: [change].
Done means: [test or command] passes and prints [expected output]. Run it before you finish and paste the result.
You may change: [paths]. Do not change: [paths], the dependencies, or the tests.
If you cannot make it pass, stop and explain why instead of working around the check.

    Where it goes wrong

    • Agents sometimes make a test pass by weakening it. Forbid changing tests, and look for it in the diff.
    • A task too big for one check is too big for one hand-off. Split it.
  2. 02

    Run tasks in the cloud while you work on something else

    Cloud agents work on your repository in their own environment and come back with changes to review, so several tasks run while you do something else. That pays off only for well-specified tasks; vague ones come back as large diffs you have to unpick.

    Example

    Three small tasks before lunch: upgrade one dependency, add a missing database index, fix a flaky test. Each goes to a cloud agent with its own check, and in the afternoon you review three pull requests instead of switching context three times.

    How to do it

    1. 1Pick the one next to your code: Codex Cloud, the Copilot cloud agent on GitHub, or Claude Code on the web.
    2. 2Make sure its environment can install your dependencies and run your tests; without them the agent is guessing.
    3. 3Send small, independent tasks, each with its own check, as in the job above.
    4. 4Let an automatic reviewer read each pull request first, then review it yourself.

    Built in

    Prompt to copy

    In this repository: [task].
Context: [where in the code, related issue].
Done when: [test or command] passes in your environment; put its output in the pull request description.
Keep the pull request under [n] changed lines. If it needs more, stop and propose how to split it.

    Where it goes wrong

    • Tests that need secrets or services you did not set up are skipped or fail. A green run without them proves little.
    • Several agents on related code produce pull requests that conflict. Keep parallel tasks in separate areas.
  3. 03

    Make the checks run without you

    Do not spend review time on what a machine can check. Hooks run your formatter, linter and tests after every change the agent makes, and a review bot reads each pull request before you do. Your review is then about design, not typos.

    Example

    A hook runs the formatter and the unit tests after every edit. The agent's change breaks two tests; it sees the failure in the hook output and fixes it before you look. The review bot then flags one unhandled error case, and that one you decide.

    How to do it

    1. 1Put your build, test and lint commands in the instructions file your agent reads at the start of every session; each agent's docs name the file.
    2. 2In Claude Code, add hooks that run the formatter and the tests after each edit, so the agent sees failures and fixes them.
    3. 3Have a bot review every pull request: turn on Automatic review in Codex, or request Copilot as a reviewer.
    4. 4When the agent makes a mistake twice, turn it into a test or a rule in the instructions file.

    Built in

    Prompt to copy

    Read this repository and write the instructions file for coding agents:
1. The exact commands to install, build, test, lint and format.
2. The project layout in 10 lines or fewer.
3. Conventions newcomers get wrong here, with one example each.
4. What an agent must never do here, for example change migrations or edit generated files.
Only list commands you ran successfully; mark the rest "not verified".

    Where it goes wrong

    • An instructions file with commands that no longer work teaches the agent to ignore it. Re-run them when the setup changes.
    • Review bots make confident mistakes too. Treat their comments as suggestions.
  4. 04

    Connect the agent to your tools, with the least access

    An agent is only as good as what it can see: issues, docs, logs, the database schema. MCP connects those, but every connection is access, and text it reads from outside can carry instructions. Start read-only and widen only when a task needs it.

    Example

    The agent reads issue 482 from the tracker, finds the stack trace in the logs and checks the library's docs, then names the file at fault, all through read-only tokens. The fix it writes in your repository, where you review it as usual.

    How to do it

    1. 1List what you paste into chats most often, such as issues, error logs, docs or the schema. Connect those first.
    2. 2Add the official MCP server for each, with a token that can only read. In Gemini CLI, an extension can bundle the MCP server and its setup.
    3. 3Give it a task that needs them and check that it called the right one.
    4. 4Every few weeks, remove the servers you no longer use.

    Built in

    Prompt to copy

    Before you change anything: read issue [id] in the tracker, find the error in the logs, and check the docs for [library].
Say what each one told you and which file you think is at fault.
Do not write to any connected tool.

    Where it goes wrong

    • A web page, issue or document can contain text written to steer the agent. Do not give write access to tools that read content from outside.
    • Tokens in config files leak. Use the client's secret storage or environment variables, never the repository.
  5. 05

    Choose between a subscription and paying per token

    Agent sessions read files and run many steps, so they use many more tokens than a chat. Price a typical week of your own use before you choose: a subscription caps hands-on use, per-token billing lets you cap each automated run.

    Example

    A week of daily agent use comes to about 40 million input and 3 million output tokens. Priced on the API prices page at the model you use, compare that with a month of the subscription. If the subscription is lower and its limits fit your week, take it, and keep a capped API key for CI.

    How to do it

    1. 1Check what you already pay for: ChatGPT plans include Codex, and Claude's paid plans include Claude Code.
    2. 2Note the token use of a few typical sessions where your agent shows it.
    3. 3Price that use on our API prices page and compare it with the subscription.
    4. 4For automation and CI, use API keys with a spending limit so a loop cannot run up a bill.

    Built in

    Prompt to copy

    Here is my usage from [n] typical sessions: [tokens in and out]. I work about [days] days a week.
Estimate my monthly cost per token at these prices: [paste from the API prices page].
Compare it with a subscription at [price] a month. Show the arithmetic so I can check it.

    Where it goes wrong

    • Subscriptions have usage limits too. Hitting one mid-task costs time; check the limit, not only the price.
    • The model changes the bill more than anything else. Compare at the model you actually use.

  6. Claude Code

    06

    Give every session the same start with CLAUDE.md

    If you explain your build commands and conventions at the start of every session, you are doing what CLAUDE.md is for. Claude reads it at the start of every session; keep it short and true, and the same mistakes stop coming back.

    Example

    A repository where Claude kept running npm test instead of the project's pnpm test:unit, and kept editing generated files. Two lines in CLAUDE.md, the right command and "never edit src/gen/", and both mistakes stop.

    How to do it

    1. 1Run /init in the repository: it analyses the codebase and writes a starter CLAUDE.md, or suggests improvements to the one you have.
    2. 2Keep team rules, such as build and test commands and coding standards, in ./CLAUDE.md and commit it. Your own preferences go in ~/.claude/CLAUDE.md for every project, or CLAUDE.local.md for this one.
    3. 3Point to longer documents instead of pasting them in: @path/to/file imports another file at launch.
    4. 4Each time Claude gets the same thing wrong twice, add the one line that would have prevented it.

    Prompt to copy

    Read this repository and improve CLAUDE.md. Keep it under 60 lines:
1. The exact commands to build, test and lint.
2. The layout in a few lines.
3. Conventions a newcomer gets wrong here.
4. Files and folders never to edit.
Remove anything no longer true. Mark commands you did not run as "not verified".

    Where it goes wrong

    • Everything in CLAUDE.md is loaded every session and takes up context. Move details into files it imports.
    • Instructions that are no longer true are worse than none. Check the commands again when the setup changes.

    From the official docs: Claude Code docs: How Claude remembers your project

  7. 07

    Plan first, then let it edit

    For a change across many files, the expensive mistake is a wrong approach, not a wrong line. In plan mode Claude researches and writes a plan without editing your source files; you correct the plan, then approve it.

    Example

    Moving authentication from cookies to tokens across 14 files. The first plan forgets the mobile client; you point it out, the plan gains a step, and only then does Claude edit anything.

    How to do it

    1. 1Press Shift+Tab until the status bar shows plan mode on, or start your prompt with /plan.
    2. 2Describe the change and what must not change. Claude may still run commands to explore, but it does not edit files while it plans.
    3. 3Read the plan like a design note: a wrong file, a missing case, too large a change. Ask for changes until it is right, then approve it.
    4. 4Before the next, unrelated task, start fresh with /clear.

    Prompt to copy

    /plan Change [what] so that [goal]. Constraints: [what must not change].
List the files you will touch, the order of the changes, the test that proves each step, and anything you are unsure about. Do not edit anything until I approve.

    Where it goes wrong

    • A plan that touches more files than you expected is the warning sign. Ask why before you approve.
    • Plan mode still runs commands to explore. It does not make an unfamiliar repository safe to run.

    From the official docs: Claude Code docs: Choose a permission mode · Claude Code docs: Commands · Claude Code docs: Best practices

  8. 08

    Stop approving the same command fifty times

    Approving every test run by hand trains you to click yes without reading. Allow the safe, repeated commands once in the project's settings, deny the dangerous ones, and keep the prompts for everything else.

    Example

    A team allows its test and lint commands and denies reading .env files in the shared project settings. The prompts drop to the few commands worth reading, and no one's session can open the keys.

    How to do it

    1. 1Open /permissions to see every rule and which settings file it comes from.
    2. 2Put the team's rules in .claude/settings.json and commit it. Personal rules go in ~/.claude/settings.json or .claude/settings.local.json.
    3. 3Rules are checked deny first, then ask, then allow, so one deny rule beats any allow.
    4. 4Switch modes with Shift+Tab: acceptEdits approves file edits in the working directory. bypassPermissions turns off prompts and safety checks; the docs say to use it only in isolated containers or VMs without internet access.

    Prompt to copy

    Look at the commands you ran in this session. Propose permission rules for .claude/settings.json: allow the read-only and test commands we use every day, deny anything that reads secrets or deletes outside the project, and leave everything else to ask. Explain each rule in one line.

    Where it goes wrong

    • An allow rule that matches any command is the same as no prompts. Allow exact commands.
    • Rules in .claude/settings.json apply to the whole team once committed. Review them like code.

    From the official docs: Claude Code docs: Configure permissions · Claude Code docs: Settings files and precedence · Claude Code docs: Choose a permission mode

  9. 09

    Keep each session focused

    A session that has carried three unrelated tasks still has all three in its context, and it shows. Clear between tasks, compact long ones with a focus, and let subagents do wide searches in their own context.

    Example

    After fixing a bug, you ask for a refactor in the same session and it keeps following the bug's old workaround. /clear and one sentence of context, and it does not.

    How to do it

    1. 1Between unrelated tasks, /clear starts a new conversation with empty context.
    2. 2In a long task, /compact with a focus, for example "/compact keep the plan and the failing test", summarises what came before.
    3. 3Hand wide searches to a subagent: each runs in its own context window, so only its answer comes back to your session.
    4. 4Claude Code also compacts on its own near the limit; compacting yourself at a good moment keeps what you choose.

    Built in

    Prompt to copy

    /compact Keep: the goal, the plan, the files changed so far, and the test that still fails. Drop the exploration.

    Where it goes wrong

    • /clear forgets the conversation. Anything you will need again belongs in CLAUDE.md first.
    • A subagent's answer is all you get back. Ask it for file paths and line numbers, not only conclusions.

    From the official docs: Claude Code docs: Commands · Claude Code docs: Best practices · Claude Code docs: Create custom subagents

  10. 10

    Run two tasks at once without collisions

    Two sessions in one checkout edit the same files under each other. claude --worktree gives each session its own copy on its own branch, so a refactor and a bug fix can run side by side.

    Example

    A dependency upgrade in one worktree and a UI fix in another, both running while you review a third pull request. Neither session sees the other's half-finished files.

    How to do it

    1. 1Start each session with claude --worktree <name> (or -w). It creates a git worktree under .claude/worktrees/<name>/ on the branch worktree-<name>.
    2. 2Add .claude/worktrees/ to .gitignore, as the docs recommend.
    3. 3Give each session one task with its own check, so you can review them one by one.
    4. 4Review and merge each branch like any other pull request.

    Prompt to copy

    You are working in a worktree on branch worktree-[name]. Task: [one change]. Done when: [test or command] passes. Commit on this branch only; do not merge or rebase other branches.

    Where it goes wrong

    • Each worktree is its own folder, so dependencies and build output are not shared. Install in each.
    • Two tasks that touch the same files still conflict when you merge, worktree or not.

    From the official docs: Claude Code docs: Run parallel sessions with worktrees

  11. 11

    Undo a wrong turn with rewind

    When a session goes wrong, asking Claude to undo its own changes often adds a second mess. Rewind restores the conversation, the code or both to a point before the mistake. It cannot undo what shell commands did, so commit before risky steps.

    Example

    A refactor that went in the wrong direction three prompts ago. Rewinding to before it restores the files and the conversation, and you rephrase the request instead of arguing the code back.

    How to do it

    1. 1Press Esc twice on an empty prompt, or type /rewind (/checkpoint and /undo also work).
    2. 2Pick the point before things went wrong and restore the conversation, the code, or both.
    3. 3Know the limits: files changed by shell commands such as rm, mv or cp are not restored, and neither are edits made outside Claude Code or in another session.
    4. 4Commit before risky steps. Checkpoints are for quick recovery inside a session, not a replacement for git.

    Prompt to copy

    Before you start, commit the current state with the message "checkpoint before [task]". Then [task]. Ask me before any command that deletes or moves files.

    Where it goes wrong

    • Rewind does not bring back a file a command deleted. Only git does.
    • Edits you made by hand in the meantime are not captured either. Commit them before you rewind.

    From the official docs: Claude Code docs: Checkpointing · Claude Code docs: Commands

  12. 12

    Run it from scripts and CI

    The same agent runs without a chat: claude -p takes a prompt, does the work and exits with a status your script can check. In CI, --bare skips your local hooks, skills, MCP servers and CLAUDE.md, so a run behaves the same everywhere.

    Example

    A nightly job runs claude -p with "update the changelog from today's merged pull requests" and --output-format json, and fails the build when the exit status is not 0, so a broken run is noticed the next morning.

    How to do it

    1. 1claude -p "..." runs non-interactively. --output-format json or stream-json gives output a script can parse.
    2. 2It exits 0 on success and non-zero on failure, so CI can branch on it.
    3. 3Add --bare in CI for runs that do not depend on local setup.
    4. 4For pull requests, /install-github-app sets up Claude Code GitHub Actions (github.com repositories only); then mention @claude in a pull request or issue comment.

    Prompt to copy

    claude -p "Read the diff against main. List every change that adds a dependency, touches authentication or changes a database migration, as JSON: {\"files\": [], \"reason\": \"\"}. Return an empty list if there are none." --output-format json

    Where it goes wrong

    • A script runs with the permissions you give it. Give CI the least it needs.
    • /install-github-app works only with repositories on github.com.

    From the official docs: Claude Code docs: Run Claude Code programmatically · Claude Code docs: GitHub Actions

  13. Codex

    13

    AGENTS.md: the instructions every Codex task starts from

    Codex reads AGENTS.md before doing any work, from your global file down to the folder it works in. Write the commands and rules once, close to the code they apply to, and the closest file wins.

    Example

    A repository with a web app and a payments service. The root AGENTS.md holds the shared commands; payments/AGENTS.md adds "never change currency rounding without a test". Work in payments/ follows both, and the closer file wins where they differ.

    How to do it

    1. 1Run /init in the CLI to write a starter AGENTS.md in the current folder.
    2. 2Put personal guidance in ~/.codex/AGENTS.md and project rules in the repository. A subfolder can have its own file; files closer to where Codex works win.
    3. 3Keep the files short: their combined size is capped, 32 KiB by default.
    4. 4Add a "## Code Review Rules" section: Codex's reviews on GitHub follow it.

    Prompt to copy

    Read this repository and write AGENTS.md:
1. The exact commands to install, build, test and lint.
2. The layout in a few lines.
3. Conventions a newcomer gets wrong here.
4. A "## Code Review Rules" section with what a reviewer must always flag.
Only list commands you ran successfully; mark the rest "not verified".

    Where it goes wrong

    • Long files work against you: the combined size is capped at 32 KiB by default.
    • A subfolder file that contradicts the root one without saying so confuses people as much as Codex. Say what it overrides.

    From the official docs: Codex docs: AGENTS.md · Codex docs: CLI commands · Codex docs: GitHub integration

  14. 14

    Decide how much Codex may do on its own

    The permission mode decides what Codex does without asking. Ask for approval works inside the workspace and pauses before going beyond it; Full access removes the sandbox and the questions. Choose per task, not once for good.

    Example

    Reading an unfamiliar repository in read-only, then switching to Ask for approval to fix one bug. Codex edits inside the repository but stops to ask before reaching beyond it.

    How to do it

    1. 1In the CLI, /permissions switches the mode, and /status shows the approval policy and writable folders in effect.
    2. 2Ask for approval, the recommended default, edits and runs commands inside the workspace and pauses before going beyond it.
    3. 3Approve for me keeps the same sandbox but sends approval requests to automatic review instead of to you.
    4. 4Full access removes the file system and network limits. The docs add a caution; keep it for environments you can throw away.

    Prompt to copy

    Before you start, run /status and tell me the approval policy and the writable folders. Then [task]. Ask before any command that needs the network or writes outside this repository.

    Where it goes wrong

    • With Approve for me, no person reads each request. Use it where a wrong action is cheap to undo.
    • Full access applies to the whole machine, not only the repository.

    From the official docs: Codex docs: Permission modes · Codex docs: Sandboxing · Codex docs: Approvals and security · Codex docs: CLI commands

  15. 15

    Run Codex from scripts and CI

    codex exec runs a task without the chat: progress goes to stderr and only the final message to stdout, so a script can use the answer. It starts read-only; give it write access only when the job needs it.

    Example

    A release script runs codex exec with "write release notes from the commits since the last tag" and saves stdout to RELEASE.md. Read-only is enough, because the script writes the file itself.

    How to do it

    1. 1codex exec "..." runs non-interactively and defaults to a read-only sandbox.
    2. 2Add --sandbox workspace-write when it must edit files; --full-auto is deprecated.
    3. 3--json emits a JSON Lines stream of events for scripts that need every step.
    4. 4In GitHub Actions, openai/codex-action@v1 runs codex exec for you.

    Prompt to copy

    codex exec "Read the changes since tag [v1.2.0]. Write release notes grouped as Added, Changed and Fixed: one line per change, in words a user understands, no commit hashes."

    Where it goes wrong

    • Older guides still use --full-auto. It is deprecated; use --sandbox workspace-write.
    • A job that only reads should stay read-only, in CI too.

    From the official docs: Codex docs: Non-interactive mode · Codex docs: GitHub Action

  16. 16

    Get a review before you push

    Codex reviews your working tree, a branch or a pull request. On GitHub it flags only the most serious issues, P0 and P1, so its comments are worth reading. Run it before you push, and let it review every pull request.

    Example

    Before pushing a migration, /review flags that the new column has no default, so existing rows would fail. One minute before the push instead of a failed deploy.

    How to do it

    1. 1/review in the CLI reviews your working tree. codex review does the same without the chat, against a base branch, a commit or uncommitted changes.
    2. 2On GitHub, comment @codex review on a pull request.
    3. 3Turn on automatic reviews under Personal preferences in Codex settings; then no comment is needed.
    4. 4Write your team's rules in a "## Code Review Rules" section of AGENTS.md.

    Built in

    Prompt to copy

    ## Code Review Rules
- Flag any change to authentication or permissions.
- Flag database migrations without a way back.
- Flag new dependencies and say whether they are needed.
- Ignore formatting; the linter handles it.

    Where it goes wrong

    • GitHub reviews flag only P0 and P1 issues. No comment does not mean the design is right.
    • A review is a second opinion, not a test run. Keep the tests.

    From the official docs: Codex docs: CLI commands · Codex docs: GitHub integration

  17. 17

    Hand tasks to Codex Cloud

    Codex Cloud keeps working while your computer sleeps, each task in its own workspace made from an environment you set up once. With a proper environment it can install, build and test; without one it guesses.

    Example

    Four small refactors sent with codex cloud exec before a meeting, each in its own workspace from the same environment. For the trickiest you asked for three attempts and keep the best; afterwards you review four diffs.

    How to do it

    1. 1Create an environment with the repositories, dependencies, tools and access settings tasks need. New environments record an install script and a start skill.
    2. 2Set internet access per environment: package managers only, chosen domains, or everything.
    3. 3Start tasks from ChatGPT, from the IDE extension for longer jobs, or from the terminal with codex cloud exec; --attempts 1-4 asks for several attempts to compare.
    4. 4Code Review and the GitHub and Linear integrations still run on the older Codex Cloud (Legacy), which OpenAI plans to retire.

    Built in

    Prompt to copy

    codex cloud exec --attempts 3 "Task: [change]. Context: [files]. Done when [test] passes in this environment. Keep the diff under [n] lines."

    Where it goes wrong

    • Unrestricted internet lets a task reach any site, including pages written to steer it. Allow only what the job needs.
    • If the install script is missing, the tests may not have run. Check that a task actually ran them.

    From the official docs: Codex docs: Cloud environments · Codex docs: CLI commands · Codex docs: IDE extension

  18. 18

    Set Codex up once: config, profiles and MCP

    If you change the model and settings by hand every session, put them in config.toml. Codex reads ~/.codex/config.toml every time, project settings in trusted projects, and a profile switches a whole set at once.

    Example

    A "deep" profile with high reasoning effort for design questions, and the default for quick fixes. codex --profile deep before an architecture question; plain codex for everything else.

    How to do it

    1. 1Set the default model and reasoning effort in ~/.codex/config.toml (model and model_reasoning_effort). The CLI and the IDE extension share it.
    2. 2Make a profile as its own file, ~/.codex/<name>.config.toml, and start with --profile <name>.
    3. 3Add MCP servers with codex mcp add <name> -- <command>; each becomes an [mcp_servers.<name>] table, and /mcp lists the active ones.
    4. 4/status shows what is in effect, and codex resume --last picks up the latest session in this folder.

    Prompt to copy

    Read ~/.codex/config.toml and this project's .codex/config.toml. Tell me the model, reasoning effort, sandbox and MCP servers in effect, which file each comes from, and anything that conflicts.

    Where it goes wrong

    • Project settings load only for trusted projects. If one seems ignored, check that first.
    • Profiles are separate files now. Guides that put [profiles.name] inside config.toml are out of date.

    From the official docs: Codex docs: MCP · Codex docs: Config basics · Codex docs: Advanced config · Codex docs: CLI commands

Rules for developers

  • Never paste secrets, keys or customer data into a prompt; keep them out of indexed folders.
  • Run agents on a branch with permissions that ask before commands; review every diff.
  • Run the tests yourself before merging what an agent wrote.
  • Set a spending limit on any API key an agent uses.

Go deeper

Esc
↑ ↓ to moveEnter to open