24 AI agent prompts for Coding
Copy-paste, beginner-friendly prompts to help you fix bugs, ship small features and build simple internal tools with coding agents. Each one is based on a real-world example and works with ChatGPT, Claude or an AI agent. 17 are free below, and 7 more are in AgentPlaybook Pro.
Free Coding prompts
Ship a small feature as a PR
Turn a plain-English request into a reviewed pull request.
Add [feature, e.g. rate limiting to the login endpoint]. First write a short plan and wait for my OK. Then implement, run tests, and open a pull request with a clear description.
Build a simple internal tool
Non-developers can get a working mini-app.
Build a single-page web app that [describe, e.g. tracks client invoices with name, amount, due date, paid checkbox, saved in the browser]. Make it clean and mobile-friendly. Explain how to open it.
Automation script for a boring task
Get a small script that renames files, cleans spreadsheets, etc.
Write a [Python/Google Apps Script] that [task, e.g. merges all CSVs in a folder and removes duplicate emails]. Explain how to run it step by step for a beginner, and add comments.
Commit & PR assistant
Let the agent review changes and write commit messages/PRs.
Review my uncommitted changes, summarize them, write a commit message in our style (Conventional Commits), and draft a PR description with testing notes. Ask before pushing.
Fix a failed pipeline
Let a coding agent read a failing test or build, propose a fix, and wait for your OK, like GitLab's self-healing pipeline flows.
My CI pipeline failed. Here's the log: [paste]. Explain in plain words what broke, find the most likely cause in the code, make the smallest fix, and run the tests again. Put the change on a new branch and stop before merging so I can review it.
Checkpointed long task setup
Set up long agent runs to save progress, check their own work, and resume instead of starting over, a widely shared X thread on agent harness setup.
Before you start this long task: [describe], write a PLAN.md with numbered steps and a 'done when' check for each. After every step, update a PROGRESS.md with what's finished, what's next, and any open problems. Verify each step (run tests or re-read the output) before moving on. If you get stuck or run out of time, stop and leave notes so a fresh run can pick up from PROGRESS.md.
Tool-stack upgrade scout
Have an agent find faster replacements for the tools in your dev stack (e.g. pip to uv, node to bun), test them on your code and write a CTO-ready summary, a copy-paste prompt Rafal Wilinski says cut his team's CI time by about 70%.
Here is our current dev stack and toolset: [paste package.json / requirements file / CI config, or list the tools]. Find faster or better replacements that developers are adopting right now (example swaps: pip -> uv, node -> bun, eslint -> a faster linter). For the top [3] candidates, try each one on a separate branch, run our [tests / build / CI], and measure the difference (time, size, errors). If a swap is a clear win, write a short, no-fluff summary for [CTO / team lead]: the gains in a table with percentages, a step-by-step migration guide, and the drawbacks. Don't merge anything; leave every change for review.
Turn a customer UI request into a draft PR
Let the person closest to the customer capture what they see, then have an agent write a spec, open a pull request, and attach sandbox browser screenshots for a human to review, like Rillet's customer success Chrome extension on eve/Vercel that helped a two-person frontend team close 800+ Linear tickets and ship some customer asks in as little as two hours.
A customer wants this change in our product. Context: [describe what they see / paste screenshot notes / attach UI capture]. Desired outcome: [one sentence]. Product area: [app/page/component]. Constraints: [safe and well-scoped only / don't touch billing / auth / etc.]. Write (1) a short spec with acceptance criteria, (2) the code change on a new branch, (3) a draft pull request assigned to [reviewer], and (4) steps to manually verify in a browser. If you can run a sandbox browser, take screenshots of before/after and attach them. Flag anything unsafe or out of scope. Don't merge, deploy, or contact the customer.
Have an agent QA your product before release
Point a coding agent at a staging build and have it navigate the product, try different inputs, and file bugs for human QA to review, like Asana using GPT-6 Astra in Codex to test StackAI features before release as the foundation for parallel cloud-agent QA.
QA this product build before we ship. URL or build: [staging URL / local instructions]. Login: [test account or 'already logged in']. Focus areas: [feature list]. For each area: navigate like a new user, try happy paths and obvious edge cases (empty fields, long text, wrong type, refresh mid-flow), and record every bug or confusing moment. For each finding include: steps to reproduce, expected vs actual, severity (blocker/major/minor), and a screenshot description if you can capture one. Don't change production data, don't click pay/delete/share, and leave a summary ranked by severity for human QA.
Let an agent work a client's to-do list on a schedule
Funnel every client request into one task list, then have a coding agent check it several times a day, pick up new items, make the fix, run tests, and mark the task done, like freelancer Carlos Marcial did after realizing he was just copying client requests into Claude Code.
You are a scheduled maintenance agent for my client's project [repo/project name]. Each run: (1) read the client task list at [link or paste] and pick up only items marked new that are clearly scoped bug fixes or small changes; (2) for each, restate the request in one line, make the change on a separate branch, and run the test suite [command]; (3) if tests pass, update the task with a plain-English summary of what changed and how to check it; (4) if the request is vague, large, touches billing/auth/data deletion, or tests fail, leave it untouched and add a question for me instead. Never deploy to production or message the client directly; I review and ship.
Let an agent run the build-test-fix loop while you supervise
Instead of steering every step, set the goal and let a coding agent plan, build, test, fix and repeat on its own, stepping in only when it drifts. Meta built its new Forum app this way and reached core feature parity with Facebook Groups in eight weeks, counting work as done only when it built, passed tests and survived review.
You are my coding agent working in human-on-the-loop mode. Goal: [feature or fix in one sentence]. Definition of done: it builds, all existing and new tests pass, and [UI spec / acceptance criteria] is met. Before writing code, give me a short plan with the files you expect to touch and the tests you will add, then wait for my OK. After that, loop on your own: implement, build, run tests, read failures, fix, repeat. Every few iterations post a two-line status (what passed, what is still failing). Stop and ask me if you need to change the plan, touch anything outside [allowed folders], or fail the same test three times in a row. Finish with a summary of changes, test results and anything I should check by hand.
Have an agent watch your GitHub notifications and draft replies
Let an agent go through your GitHub notifications (issues, PR comments, review requests), sort out what actually needs you, and draft a response for each one you can approve or edit. One builder shared that their agent is wrong about 30% of the time, but the 70% it gets right saves them about 2 hours a day, which is why keeping a human approval step matters.
You are my GitHub notification assistant. Here are my unread notifications: [paste or connect GitHub: repo, type, title, latest comment]. My role on these repos: [e.g. maintainer of X, reviewer on Y]. Step 1: sort them into: needs my reply today, needs a code review, FYI only, and safe to mark as read. Step 2: for each 'needs my reply', draft a short, friendly response that answers the question or asks one clarifying question; quote the line you're replying to. Step 3: for review requests, list the PR, its size, and the 2-3 things I should look at first. Step 4: show your confidence (high/medium/low) for each draft. Don't post anything; I'll approve each draft myself.
Have two coding agents build a feature together: one leads and plans, the other builds, and they review each other's pull requests through a shared chat log file
Dave Martin (@itsdavemartin) described on X (Oct 23, 2026) how he builds with Claude and Codex together: Codex first turns his brief into a clickable HTML mockup, then Claude takes the lead, writes Linear issues and a plan, and the two agents coordinate through a /planning folder holding one markdown chat log, a checkbox plan and a list of decisions. Each works in its own copy of the repo, opens small pull requests, and neither may merge its own. He reports a help center feature took 23 pull requests and 95 help docs, starting one afternoon and finishing the next morning, from three prompts and a few answers. This prompt sets up that hand-off for your own project.
I want two AI coding agents to build a feature together in my repo [repo/project]. Agent A is [e.g. Claude Code] and will be the lead; agent B is [e.g. Codex]. The feature: [describe what it should do, where it lives, and anything to copy]. Set this up: 1) create a git-ignored /planning folder with chat-log.md (each entry stamped with time, author and a verb like PLAN, REVIEW, ASK-ME or MERGE; nobody edits another agent's entry), plan.md with checkboxes, decisions.md listing choices made without me, and later.md for ideas to revisit, 2) before any code, turn the feature into small issues [in Linear/GitHub Issues] and split them between A and B, 3) each agent works in its own branch or worktree, opens small pull requests, and the other agent reviews them; neither merges its own, 4) stop and write ASK-ME in the log for anything needing a human: product choices, user-facing wording, and every push to production, and 5) when done, run end-to-end tests, fix what fails, and give me a summary of pull requests, decisions and open questions. Post the opening plan in chat-log.md and wait for my go-ahead.
Check that every screen of your app really matches the design: have a coding agent screenshot each screen, pixel-diff it against the design file, rank the worst matches and fix them until only text smoothing differs
Apps often drift from their designs a few pixels at a time. Danish Dhamani (@DanishDhamani), CEO of Orai, posted on X (Oct 23, 2026) that he had Claude screenshot all 207 screens of his app and pixel-diff them against the design files. Some screens were 20% off, and one prompt found every one. He shared the prompt: render each screen in the exact state of its design PNG through a dev-only route, screenshot it with Playwright at the PNG's size and pixel ratio, diff with pixelmatch while masking the phone status bar, save side-by-side comparisons, write a report sorted worst to best, then fix spacing, font and component sizes and re-run until only text anti-aliasing differs.
Compare my app against its design files pixel by pixel. The designs are PNG files in [FOLDER]. For each design PNG, find the screen and the sample data that should reproduce it, and add a dev-only route that renders that screen in that exact state with animations turned off (this route must never ship to production). Write a script that uses Playwright to open each route at the PNG's exact size and pixel ratio, take a screenshot, and diff it against the PNG with pixelmatch. Mask out OS chrome like the status bar first. For each screen, save the design, the app screenshot and the diff side by side in [OUTPUT FOLDER], then write a report sorted from worst match to best with the % of pixels that differ. Show me the report before changing any code. Then go through the worst [NUMBER] screens: measure where spacing, font sizes and component sizes differ, fix the code, and re-run the diff until each one differs only by text anti-aliasing. Commit each screen's fix separately with the before/after match %.
Make your coding agent prove the feature works: ask it to build the change, then open the app itself (even the iPhone simulator), click through it and show you the result before it hands the work back
AI coding agents often hand back code that was never actually run. On Oct 23, 2026 Cursor announced Computer Use for its agents: they can click and type in desktop apps on your computer, including Apple's iOS Simulator, so they can test the features they build. Cursor says agents use it on their own when a task needs it, or when you @-mention Computer Use in your prompt. Its demo shows an agent adding a 'favorite trails' feature to a hiking app, launching it in an iPhone simulator and tapping through it. The useful habit for anyone building with AI: give the agent a clear pass/fail check and ask it to demo the result, so you find problems before you ship.
Build this change: [DESCRIBE THE FEATURE IN PLAIN WORDS, e.g. 'let users favorite a trail and see favorites on a new tab']. Before you tell me you're done, test it yourself in the running app [web browser / iOS Simulator / desktop app] using computer use. Pass/fail checks: 1) [FIRST THING A USER DOES AND WHAT SHOULD HAPPEN] 2) [SECOND CHECK] 3) [AN EDGE CASE, e.g. what happens with no favorites yet]. For each check, tell me PASS or FAIL, what you clicked, and include a screenshot. If anything fails, fix it and re-run all checks. Don't change unrelated files, and don't sign in to real accounts or touch real customer data while testing. Finish with a short summary of what changed and anything you couldn't test.
Pair a fast coding model with a smarter 'advisor' in Claude Code: let Sonnet do the work and have Opus check the plan on hard decisions, so you get better results without paying top-model prices for every step
Claude Code has an experimental advisor tool: your main model does the work and escalates hard decisions to a stronger model. Per Claude Code's docs you turn it on with the /advisor command, an advisorModel setting, or a launch flag such as claude --model sonnet --advisor opus; the advisor must rank at or above your main model, it runs on the Anthropic API only, and it may use extra tokens. Posts on X this week walked through the flow step by step, with Sonnet drafting a plan and Opus reviewing it before the plan locks. This entry gives you a prompt that makes the most of that pairing: plan first, get the advisor's review on risky choices, then build and test.
I've started Claude Code with a cheaper main model and a stronger advisor (claude --model sonnet --advisor opus). Task: [DESCRIBE THE CHANGE IN PLAIN WORDS]. Project: [LANGUAGE / FRAMEWORK, HOW TO RUN TESTS]. Work like this: 1) Read the relevant code and write a short plan (files to change, approach, risks). 2) Before you lock the plan, consult the advisor on the riskiest decision, e.g. [DATA MODEL CHANGE / AUTH / MIGRATION], and tell me in one or two sentences what it recommended and whether you changed the plan. 3) Build it in small steps and run the tests after each step. 4) If tests fail twice in a row on the same problem, consult the advisor again instead of guessing. 5) Finish with: what changed, test results, and anything the advisor flagged that I should decide myself. Don't touch unrelated files and don't add new dependencies without asking.
Run several AI coding agents side by side on a server that keeps working after you close your laptop, and check on them from one screen
New free, open-source terminal tools such as Quil and Corgi are built for running Claude Code, Codex and OpenCode at once: each agent gets its own pane, they keep working on a remote server, and your sessions come back after a reboot. The prompt below helps you split a project into jobs that won't step on each other and gives you a simple way to check on every agent.
I want to run [number] AI coding agents at the same time on my project [describe project and repo] using a terminal tool that keeps sessions running on a server. 1) Split this work into separate jobs that touch different files or folders so the agents don't overwrite each other: [paste task list]. For each job give: a short name, the files or folders it may change, files it must not touch, and the exact instructions to paste into that agent. 2) Tell me to give each agent its own git branch or worktree, and the commands to set that up. 3) Write a one-line status rule each agent follows: after every step it appends "time, job name, what changed, blocked or not" to STATUS.md. 4) Give me a 5-minute check-in routine: what to look at in each pane, how to spot an agent going in circles, and when to stop one. 5) Give me the order to merge the branches back and the tests to run after each merge.
More in AgentPlaybook Pro
- Fix a bug with a coding agentDescribe a bug in plain English and let the agent propose and test a fix.
- Feature idea to PRDTurn a feature idea plus customer research into an implementation-ready spec.
- Speed up a slow website with a coding agentHave a coding agent check real visitor speed data first, then fix the biggest things slowing pages down on phones.
- Describe an ETL pipeline and get a working Airflow DAGUse AI agent skills that talk to Amazon Managed Workflows for Apache Airflow so you can author, debug, test, and upgrade data pipelines in plain language instead of hand-writing every DAG. AWS shipped four MWAA skills (author, debug, test, upgrade) that work with any coding assistant that supports agent skills.
- Find the bugs your customers would hit after months of real use, before they doNormal tests check what your team thought of. The costly bugs show up later: a customer double-clicks pay, a payment response gets lost, a job is cut off by a deploy, or a month-end date breaks a report. Have an agent invent realistic customers with habits and impatience, change one condition at a time, and only report failures it can reproduce every time. Breken launched on Oct 21, 2026 as 'production before production': it rebuilds an app in an isolated copy, grows months of realistic data at up to 4,000x speed, simulates synthetic users and agents, and hands back the exact state, trace and a draft fix for each failure.
- Sort last night's failed software tests into real bugs, flaky tests and infrastructure problems, with a fix plan for eachWhen a big automated test suite runs overnight, engineers often spend the morning reading logs just to work out which failures are real bugs and which are flaky tests or a broken test environment, and releases wait until that's done. An AI agent can do the first pass: label each failure by likely cause, compare it with past failures, check the logs for evidence and write a short fix report for an engineer to confirm. AWS published on Oct 22, 2026 that Rescale built this kind of triage agent for its nightly Playwright tests in five days; its labels now agree with human triage 68% of the time (up from 44%), and time spent blocking production releases dropped 20%.
- Hit your AI coding limit mid-task without losing your place: give all your coding agents one shared memory so the next one picks up where you stoppedWhen Claude Code runs out of usage halfway through a job, switching to Codex or Cursor usually means explaining everything again. Open-source tools like ai-memory keep one shared memory, as plain files you can read, for 20+ coding agents, so the next agent gets a handoff note: where you stopped, what failed and what's still open. The prompt below gets you the same handoff even without installing anything.
32 copy-paste agent prompts (PDF) plus 5 new prompts every week.
Get it free