Prompting Techniques

Once you have a sensible workflow, the next question is how to interact with the agent within it. Good prompting is less about writing massive instructions and more about giving the right kind of guidance at the right time. With a good prompt, the agent can often find the right answers on its own.

This page collects tactics for different moments in engineering work.

Clarify the task first

Many prompting failures begin before the agent writes a single line of code. If the task is underspecified, framed too narrowly, or missing the right reference points, the agent may confidently optimize for the wrong thing. These techniques help you align on intent before execution begins.

Frame first, then implement

If the task is vague, do not jump straight to architecture. First, ask the agent for a short framing brief covering the problem, desired outcome, non-goals, options, and open questions with owners.

A false certainty that the agent knows your intent is a common failure mode. Ask the agent to separate facts, assumptions, and preferences, then review whether its understanding is correct. You can include this snippet in your prompt:

Interview me relentlessly about every aspect of this plan until we reach a
shared understanding. Walk down each branch of the design tree, resolving
dependencies between decisions one-by-one.

Source: grill-me skill Matt Pocock. 2026-02-25

Socratic prompting

TL;DR: Instead of giving the answer, ask questions that lead the agent to reach it on its own. Example: Rather than “The bug is in the condition,” ask “What are the assumptions?”, “Is this condition always true?”, and “What happens for the edge case?” The goal is to surface assumptions, check logic, and arrive at the conclusion through the agent’s own reasoning.

Source: Prompting best practices Anthropic.

Underprompting

Intentionally omit some element of the prompt so that:

1. The agent explores that area more thoroughly in its own way.
2. You can see what is missing in AGENTS.md, the codebase, or the docs based on what the agent tried to read.

Document knowledge

TL;DR: If a fact should survive a reset, handoff, or future task, ask the agent to write it into the repository instead of leaving it in chat. Treat AGENTS.md as a short map. Treat repository-local Markdown as the system of record.

This works well for architecture notes, domain terminology, debugging discoveries, migration constraints, and execution plans. A small, focused document is usually better than one giant instruction file. The goal is not “more docs”. The goal is making the right knowledge discoverable, versioned, and loadable on demand.

Sources:

• Knowledge Document - Augmented Coding Patterns Lada Kesseler. 2025-10-20
• Harness engineering: leveraging Codex in an agent-first world OpenAI. 2026-02-11

Borrowing from other code

If you know you are working on a problem that has been solved somewhere else, tell your agent to find and borrow the solution.

• If this is open-source code, you can tell it to clone it into /tmp.
• There is also mcp.grep.app if you are just looking for code snippets.
• Beware of legal (copyright) concerns!

Depending on the codebase, a useful pattern is to have several golden files that the agent can use as references.

• For example, if you have a component library, tell the agent to follow the implementation of the ui/Button.tsx component.
• If you are doing repetitive module refactoring, make the changes in one golden module, then ask the agent to reproduce them in other modules.

👏 +1

…

Steer the execution

Once the task is clear, the next job is to keep execution on useful rails without micromanaging every action. That does not require a human to watch every step. Much of this can be automated too.

Red/green TDD

TL;DR: Write tests first, confirm they fail (red), then implement until they pass (green). This is a strong fit for coding agents because it reduces broken or unused code and builds a robust test suite.

Source: Red/green TDD Simon Willison. 2026-02-23

Knowledge checkpoint

TL;DR: After planning but before implementation, checkpoint the plan in the repo and consider committing it. That preserves the expensive part, the planning and explanation, while making failed implementation attempts cheap to retry.

Ask the agent to extract the agreed plan into a short Markdown file, commit that file as a checkpoint, and only then start coding. If the implementation goes sideways, reset to the checkpoint and try again without redoing the planning work. This is especially useful when a model is overeager to jump straight into code before the plan is stable.

For example:

We have the plan. Before you implement, write the agreed approach to a
short Markdown file in the repository. Keep it concise and action-oriented.
Then make a git commit as a checkpoint. Only after that, start implementation.
If the implementation attempt fails, reset to the checkpoint and try again from
the saved plan.

Source: Knowledge Checkpoint - Augmented Coding Patterns Lada Kesseler. 2025-10-01

Parallel implementations

TL;DR: When the task has multiple plausible solutions or a high chance of failure, branch from one checkpoint and let several implementations race in parallel. This works especially well when the work involves some degree of creativity, such as interface design.

The pattern is:

1. Create a checkpoint with the plan and a Git commit.
2. Fork into parallel workspaces, for example with Git worktrees. Alternatively, you can spawn multiple subagents and tell each one to write to a different file.
3. Launch multiple implementations from the same starting point.
4. Review the results side by side.
5. Keep the best version or combine the strongest parts.

Source: Parallel Implementations - Augmented Coding Patterns Lada Kesseler. 2025-10-01

👏 +1

…

When text and code are not enough

Sometimes the fastest way to explain a problem is not another painfully typed paragraph. Other forms of communication can be valuable too.

Multimodal input

Screenshot a bug or broken UI in your app. Or record a short video of something changing over time. Drop it into the prompt and say “fix it”. You can even add arrows and annotations in your screenshot tool. Frontier models handle multimodal input very well.

Put a human in the loop

Ask the agent to prepare a step-by-step reproduction of a complex manual flow: what to click, and in what order. You perform the steps, such as logging in to the browser with your account, report back, and the agent continues or verifies. Think of it as augmented manual QA: the agent scripts the scenario, and the human does the sensitive or interactive parts.

Just talk to it

If typing is tiring, you can use your voice instead. Some coding agents have built-in voice dictation features. Similar options are also built into operating systems, like Dictation on macOS, Voice Typing on Windows, and many third-party apps for all platforms.

Interactive playgrounds

When exploring a new topic, prototyping an algorithm, or sketching a component, tell the agent to build an interactive playground. It can explain the concept visually and expose quick controls for fine-tuning parameters.

Take a look at these utilities:

• Playground Claude Plugin Anthropic.
• Introducing Showboat and Rodney, so agents can demo what they’ve built Simon Willison. 2026-02-10
• Feedback Loopable Lewis Metcalf. 2026-02-05

👏 +1

…

Your exoskeleton

Some prompting patterns are less about a single task and more about extending your reach as an engineer. They turn the agent into an exoskeleton around your normal workflow: surfacing understanding, handling mechanical work, and exploring unfamiliar systems.

Walkthroughs

TL;DR: You can tell your agent to explain to you in human language what happens in the code, or you can ask it to help you review its work by showcasing it. Example prompt:

Read the source and then plan a linear walkthrough of the code that explains how
it all works in detail. Then create a walkthrough.md file in the repo and build
the walkthrough in there, using Mermaid diagrams and commentary notes or whatever
you need. Include snippets of code you are talking about.

Sources:

• Linear walkthroughs Simon Willison. 2026-02-25
• Shareable Walkthroughs Amp. 2026-01-29

Models are good at Git

You can tell your agent:

1. To make a commit.
2. To create a branch/worktree or check out some repo to /tmp.
3. To submit a PR.
4. To merge/rebase and fix conflicts (make sure to back up, or ask the agent to use git reflog in bad scenarios).
5. To use the gh CLI to read issues/PR comments or GitHub Actions logs.

Reverse engineer

Agents are surprisingly good at reverse engineering apps. Minified or compiled code is not a major cognitive burden for them, and they know many useful tools in this area.

Try pointing your agent at a website or Android APK that contains something you want to mimic. At first, you may need to interactively install tools that the agent wants to use.

Issue pinpointer

Got a huge log file, maybe a screenshot, and need to identify the bug? Paste everything you have into your agent prompt and tell it to find the exact log lines itself.

👏 +1

…