Skip to content
Lesson 2 of 12

Anatomy of a Developer Prompt

7 min read

The Five Components

Every effective developer prompt contains the same five components, whether you include them explicitly or not. When you leave components out, the AI fills in the gaps with assumptions -- and assumptions produce generic output. The COCFE framework gives you a checklist to ensure your prompts contain everything the AI needs to produce accurate, usable code.

C -- Context: What project, what stack, what file, what state. This grounds the AI in your specific situation.

O -- Objective: What you want to achieve. Not "fix it" but the specific outcome you need.

C -- Constraints: What NOT to do. Boundaries, limitations, things to avoid.

F -- Format: How you want the output structured. A single function? A full file? Just the diff? An explanation?

E -- Examples: Show, don't tell. An example of the pattern you want followed, the style you expect, the output format you need.

Not every prompt needs all five components. Simple tasks might only need Context and Objective. But complex tasks that consistently produce wrong output are almost always missing one or more of these components.

Context: Grounding the AI

Context is the most commonly missing component in developer prompts. You live inside your project every day -- the AI does not. It needs to know where it is working and what surrounds it.

Bad -- No context:

Create a function to validate email addresses

Good -- With context:

In our Express API (src/utils/validators.ts), create an email validation
function. We use Zod for schema validation throughout the project. The function
should match the pattern of the existing validateUsername() function in the
same file.

Context includes: the file path, the technology stack, the project conventions, related files, and any relevant state (database schema, API contract, existing patterns). Tools like Claude Code automatically read your project files, but explicitly stating the relevant context still improves output because it tells the AI which parts of your project matter for this specific task.

Objective: Being Specific About Outcomes

The objective is what you want the AI to produce. The most common mistake is stating the objective too broadly.

Bad -- Broad objective:

Improve the authentication system

"Improve" is not an objective. It is a direction. Improve how? Faster? More secure? Better error messages? Support more providers?

Good -- Specific objective:

Add rate limiting to the POST /api/auth/login endpoint. After 5 failed
attempts from the same IP within 15 minutes, return a 429 status code with
a Retry-After header. Store attempt counts in our existing Redis instance.

A good objective passes the "done" test: when you read the AI's output, you can clearly determine whether the objective was met or not. If the objective is vague, you cannot tell whether the output is correct.

Constraints: Drawing the Boundaries

Constraints tell the AI what to avoid. They prevent the AI from making assumptions that conflict with your project's needs.

Without constraints:

Add caching to the API responses

The AI might use an in-memory cache, install a new library, modify your response middleware globally, or add cache headers -- any of these could be valid but wrong for your situation.

With constraints:

Add Redis caching to the GET /api/products endpoint. Constraints:
- Use the existing Redis connection from src/lib/redis.ts
- Do NOT install any new packages
- Cache TTL should be configurable via environment variable
- Do not cache responses for authenticated users
- Do not modify the middleware chain, add caching inside the handler

Constraints are especially important for refactoring tasks where you want the AI to change specific things without touching others. Phrases like "do not modify the public API," "keep the existing tests passing," and "do not change the database schema" prevent scope creep in AI output.

Format: Controlling the Output

Format specifies how you want the response structured. Without format guidance, the AI chooses its own structure, which may not match what you need.

Without format:

Explain how our authentication flow works

You might get a 500-word essay when you wanted a bullet list, or a code walkthrough when you wanted a diagram description.

With format:

Explain how our authentication flow works. Format:
- Start with a numbered step-by-step flow (request enters -> ... -> response sent)
- For each step, include the relevant file path
- End with a list of potential failure points at each step
- Keep it under 200 words

Common format specifications for developer prompts:

- "Output only the changed function, not the entire file"
- "Return a complete file I can copy-paste"
- "Show the diff, not the full code"
- "Explain your reasoning before showing the code"
- "Give me 3 alternative approaches with tradeoffs"

Examples: Show, Don't Tell

Examples are the most powerful component and the most underused. Instead of describing what you want, show the AI an instance of it.

Without example:

Create a TypeScript interface for the User API response with proper JSDoc
comments

With example:

Create a TypeScript interface for the User API response. Follow this exact
documentation style from our existing ProductResponse interface:

/**
 * API response for product data.
 * Returned by GET /api/products/:id
 *
 * @example
 * const product: ProductResponse = await api.getProduct("abc-123");
 */
export interface ProductResponse {
  /** Unique product identifier (UUID v4) */
  id: string;
  /** Display name, 1-255 characters */
  name: string;
  /** ISO 8601 creation timestamp */
  createdAt: string;
}

With this example, the AI will match your exact JSDoc style, comment format, and interface structure. Without it, the AI invents its own conventions that may not match your codebase.

The "existing pattern" technique is the most reliable way to get consistent output from AI tools. Instead of describing the pattern you want, point to a file or code block that demonstrates it and say "follow this pattern."

The 1-Sentence Experiment

Here is an exercise that demonstrates the power of context. Take any prompt you have used recently and add exactly one sentence of context. Compare the results.

Original:

Write a React component for a search bar

Plus one sentence:

Write a React component for a search bar. This is for our Next.js 14 app
that uses Tailwind CSS, and the component should follow the same pattern as
our existing TextInput component in src/components/ui/TextInput.tsx.

That single sentence added: the framework (Next.js 14), the styling system (Tailwind), the pattern to follow (TextInput), and the file location. The AI output goes from a generic search bar to one that fits your project.

When Short Prompts Work

Not every task needs a five-component prompt. Short prompts work well for:

  • Simple, unambiguous tasks: "Add a TypeScript type guard for the User interface"
  • Tasks with obvious context: when you are in an interactive session and the AI already has your project loaded
  • Exploratory tasks: "What does this function do?" or "Explain this error message"
  • Standard patterns: "Create an Express GET route for /api/users that returns all users from the database"

The rule of thumb: if there is only one reasonable interpretation of your prompt, keep it short. If there are multiple possible interpretations, add context, constraints, and examples until only one interpretation remains.

Prompt Templates for Common Tasks

Here are starter templates using the COCFE framework that you can adapt:

[Code Generation Template]
Context: In [file_path], using [tech_stack].
Objective: Create [what] that [behavior].
Constraints: [what to avoid, boundaries].
Format: [complete file / function only / diff].
Example: Follow the pattern in [reference_file].

[Bug Fix Template]
Context: In [file_path], [tech_stack], [environment].
Objective: Fix [actual behavior] so that [expected behavior].
Constraints: Do not change [protected areas].
Format: Show the fix with a brief explanation of the root cause.

[Review Template]
Context: [file_path or diff], [project context].
Objective: Review for [specific concerns: security / performance / correctness].
Constraints: Focus only on [scope], ignore [out of scope items].
Format: List issues as: severity, location, description, suggested fix.

As you work through this course, you will develop your own templates tailored to your specific tools, projects, and workflow.