BoilerPrompt

How to Prompt Agentic Coding Tools: Why 100 Words Beat 500

By Sidhant Sinha on

The first thing most engineers do when an AI coding agent gives them bad output is write a longer prompt. More context, more instructions, more edge cases spelled out in advance. It feels rigorous. It is usually the wrong move.

For agentic tools, meaning Cursor's Agent mode, Claude Code, Windsurf, and GitHub Copilot's agent features, the pattern that consistently produces better results is the opposite: a short, direct prompt, roughly 60 to 160 words, with concrete constraints and an explicit verification step. Not because these tools need things dumbed down. Because they are agents, and agents fail differently than chat models do.

This is the core method behind every agentic prompt in the BoilerPrompt library. Here is why it works and how to apply it.

Why long prompts underperform

Three mechanisms, all observable in day-to-day use.

Instruction dilution

Every instruction in a prompt competes with every other instruction for the model's attention. A 500-word prompt with twenty requirements does not get twenty requirements followed. It gets a dozen followed well, a few followed partially, and a few silently dropped, and you do not get to choose which ones land in which bucket. The constraint you actually care about ("do not touch the migration files") carries the same nominal weight as the filler you wrote on autopilot ("use descriptive variable names").

Cut the prompt to four or five instructions and each one gets real weight. When everything in the prompt matters, the agent treats everything in the prompt as mattering. Mega-prompts fail not because they contain wrong information but because they bury the load-bearing sentences under decoration.

The agent plans its own steps

A chat model works only from what you paste into it, so long prompts made sense there. An agent reads your repo. It greps for the relevant module, opens files, runs commands, and builds its own plan from what it actually finds. That changes what your prompt is for.

When you dictate a ten-step implementation route, you are planning from memory of your codebase, and your memory is worse than the agent's live view of it. Your step three references a helper that got refactored away last month. Now the agent has a dilemma: follow the wrong plan or quietly deviate from it. Both happen, and both waste a round trip.

So specify the destination, not the route. Say what must be true when the work is done, which files are in bounds, and which decisions are already made. Let the agent find the path. The route is the part agents are genuinely good at. The destination is the part only you know.

Verification closes the loop

The highest-leverage sentence in an agentic prompt is the one that tells the agent how to check its own work. "Run the auth tests and fix failures before reporting back" turns one-shot generation into a loop: write, run, read the failure, fix, run again. Without it, you are the test runner, and every cycle through you costs minutes instead of seconds.

The second-highest-leverage sentence is "list every file you changed." Agents sometimes wander. A changed-files list is a cheap audit: if you asked for a change to one route and the list shows six files, you know to look before you commit anything.

Long prompts almost never include either sentence. They spend the word budget on adjectives instead.

Anatomy of a good agentic prompt

Four parts, in roughly this order.

Outcome. What is true when the work is done. One or two sentences, concrete enough that another engineer could check it. "Rate limiting on the login endpoint: 5 failed attempts per IP per 15 minutes, then 429."

Scope. Which files or modules are in bounds, and explicitly what is out of bounds. Scope is your main defense against the agent refactoring things you never asked about.

Constraints. The decisions you have already made and will not delegate: which dependencies are allowed, which existing utilities to reuse, what the API shape must be. Only include constraints you genuinely hold. Every one you add dilutes the rest.

Verification. The command to run, the output to show, the changed-files list. This is the part most prompt collections online skip, and it is the part that does the most work.

Write those four parts plainly and you will land in the 60-160 word range without trying. If you are far under it, your outcome is probably vague. If you are far over it, you are probably prescribing the route.

A rewrite, bad to good

Here is a condensed version of a mega-prompt pattern that shows up in almost every scraped prompt list:

You are a world-class senior software engineer with 15 years of
experience in authentication systems, security, and scalable
architecture. I need you to implement rate limiting for our login
endpoint. First, some context on our stack: we use Next.js with the
App Router, TypeScript in strict mode, Redis for caching, and we
deploy to Vercel. Security is extremely important to us, so please
follow industry best practices and OWASP guidelines throughout. The
implementation should be clean, maintainable, well-documented, and
production-ready. Here is how I want you to approach it: first,
create a new utility file for the rate limiter. Then import it into
the login route. Then add configuration options so we can tune the
limits later. Also add logging so we can monitor abuse patterns.
Make sure everything is fully testable and follows SOLID principles...

It continues for another 300 words. Read it again and notice what is missing: the actual limit. The one number that defines the feature never appears. Meanwhile:

  • The role-play preamble adds nothing. The tool is already a coding agent.
  • The stack context is discoverable. The agent can read package.json faster than you can describe it.
  • "Clean, maintainable, production-ready" is unfalsifiable. No agent changes its behavior on adjectives.
  • The step-by-step route pre-empts planning the agent does better with the repo open in front of it.
  • There is no verification step, so the first draft is the final draft.

Here is the rewrite, written for Cursor's Agent mode:

Add rate limiting to POST /api/auth/login in
src/app/api/auth/login/route.ts.

- 5 failed attempts per IP per 15 minutes. After that, respond 429
  with a Retry-After header.
- Use the existing Redis client from src/lib/redis.ts. No new
  dependencies.
- Put the limiter in a new src/lib/rate-limit.ts so other routes can
  reuse it later. Do not touch middleware or the other auth routes.

When done: run the auth test suite, fix any failures, then list every
file you changed and show me the 429 response body.

Under 100 words. Every line is checkable. The agent knows the target, the boundaries, the reuse rule, and how to prove the work is done. If the test run fails, it fixes and reruns before you ever see the result. If the changed-files list contains a surprise, you catch it in five seconds.

Same task, different tool

Short-with-verification is the constant. The phrasing shifts because the interfaces differ.

Cursor runs in the editor with your codebase indexed, so file paths and @-mentions do the scoping. Claude Code is a terminal agent that runs commands itself, which means the verification step should be literal shell commands:

The login route has no rate limiting. Add it.

- 5 failed attempts per IP per 15 minutes, then 429 with a
  Retry-After header.
- Reuse the Redis client in src/lib/redis.ts. No new packages.
- New helper in src/lib/rate-limit.ts, wire it into the login
  route, touch nothing else.

Run npm test -- auth and fix failures before reporting back. Finish
with git diff --stat so I can audit exactly what changed.

GitHub Copilot's Edits mode is file-scoped in VS Code: you attach the route file and the Redis client to the working set, so the scope section moves out of the prompt and into the UI, and the prompt shrinks to outcome, constraints, and verification. Windsurf's Cascade behaves closest to Cursor, and the same structure carries over nearly unchanged.

This is why a single prompt pasted into four tools gives you four different levels of quality. The structure transfers. The wording should not.

When longer prompts are right

None of this applies to app builders. Tools like v0, Lovable, Bolt, and Replit Agent generate a whole app from your description, and there is no existing codebase for the agent to explore. Everything the builder knows about your product comes from the prompt, so discovery is off the table and specification has to fill the gap.

There, fuller structured specs win: 150 to 320 words covering screens, the data model, key behaviors, and the empty and error states most people forget. The skill is not "write short" or "write long." It is matching the prompt to how the tool acquires context. Agentic tools read your repo, so you write short and constrain. Builders read only your prompt, so you write complete and structure it.

Steal a starting point instead

The fastest way to internalize this structure is to use prompts that already follow it. Every prompt on BoilerPrompt is built on the outcome-scope-constraints-verification pattern, phrased for the specific tool, and free to copy. Start with the Cursor prompts or the Claude Code hub, pick the task closest to yours, and adjust the details in the customizer.