Prompting AI Coding Agents the Right Way

Here's how most developers use an AI coding agent. They open a chat window and type something like "add a dark mode toggle to the settings page." The agent produces something. It kind of works. There are rough edges. The developer spends the next twenty minutes going back and forth patching things up.

Then they decide the model isn't that good.

The model is fine. The prompt is the problem.

The Uncomfortable Reality of Vague Prompts

Every ambiguity in your prompt is a decision the model makes without you. Should the dark mode preference persist across sessions? Does it need to respect the OS-level setting? Where does the preference get stored, in localStorage, a user profile in the database, or a cookie? Which component library is in use, and how does theming work inside it?

You didn't say. So the model guesses. Sometimes it guesses right. Often it doesn't. Then you have code that works in one environment and breaks in another, or a component that ignores the user's existing preference.

This is an information problem.

The Technique: Let the Agent Build Its Own Prompt

Here's what serious teams building AI-assisted development workflows have figured out. The model knows what it needs to do a task well better than most developers know how to ask for it.

It has processed an enormous volume of well-specified engineering tasks, so it knows what a complete feature request looks like and what a vague bug report usually leaves out. The trick is to make it tell you what's missing before you ask it to do anything.

The flow looks like this:

1. Describe your goal loosely: just enough for the agent to understand the problem space
2. Ask what it would need to do it properly: "What information would you need to complete this task well? What ambiguities should I clarify? What should I specify that I haven't?"
3. Fill in the gaps: answer its questions, provide the context it asked for
4. Now give it the task: either incorporate its questions into your prompt, or ask it to rewrite your original request into a complete specification, then approve and execute

That last step is optional but valuable. You can ask the agent: "Based on my answers, rewrite my original request as a complete task specification." What you get back is a prompt that the model itself considers complete enough to execute well. Then you submit that prompt as the actual task.

Some people now call this reverse prompt engineering for task execution. The model shows what a perfect prompt would contain, and you work from that.

Example 1: Building a Feature

Let's say you want to add a dark mode toggle to a settings page. Here's how the two approaches play out.

The naive approach:

"Add a dark mode toggle to the settings page."

The agent produces a component with a hardcoded toggle, stores the preference in component state so it resets on refresh, skips the existing theme system, and uses inline styles instead of your CSS variables or theme tokens.

You spend the next hour fixing it.

The reverse prompt approach:

You start with the same sentence, then ask: "Before you start, what would you need to know to implement this properly? What should I clarify?"

The agent responds with something like:

• Where should the preference be persisted (localStorage, database, cookie)?
• Is there an existing theme system (next-themes, CSS variables, Tailwind dark: variant)?
• Should the toggle respect the user's OS-level dark mode preference as a default?
• Where in the settings page should this live? Is there an existing "Appearance" section?
• Should the preference sync across sessions if the user is logged in?

You answer these questions. You tell it the app uses next-themes, preferences are stored in the user's profile via an existing PATCH /users/me endpoint, and there's already an "Appearance" section in the settings page with other toggles that follow a specific component pattern.

Now the agent has what it needs. The implementation it produces connects to the right theme provider, uses the existing API, matches the existing UI pattern, and handles the OS preference fallback. You don't need to fix anything.

Example 2: Fixing a Bug

Bug reports are where vague prompting causes the most damage. A model that lacks context produces confident, wrong code.

Imagine someone files a bug: "The login button sometimes doesn't work."

The naive approach: You paste that into your agent. It starts scanning authentication code, spots a suspicious async/await pattern, decides that's probably it, rewrites the function, and opens a PR. The bug is still there. The function it changed was unrelated.

The reverse prompt approach:

You give the agent the bug report and ask: "What would you need to know to diagnose this effectively? What questions would a senior engineer ask before touching any code?"

It responds:

• What does "doesn't work" mean: the button doesn't respond to clicks, the click fires but nothing happens, or an error is shown?
• Is this reproducible reliably or intermittent? Any pattern (specific browser, network conditions, user state)?
• Are there any console errors or network requests failing when it happens?
• Which component handles the button click, and which service handles the authentication?
• Has this always been broken or did it regress recently? If a regression, what changed?

You go back to the person who filed the bug, get the answers. It is intermittent and only shows up after the user has been on the page for more than ten minutes. There are no console errors, but the network request never fires. That is a completely different bug. The likely cause is a token expiry issue or a stale closure in an event handler.

You give the agent that information, and now it goes to the right place. It finds a useCallback with a stale dependency that captures an auth token from the initial render. The fix is one targeted change.

Why This Works

The reason most AI-assisted coding feels like a negotiation is that the initial prompt leaves too many decisions to the model. You go back and forth refining the output over several rounds. Each round of revision is you correcting a guess the model made because you didn't specify.

Reverse prompting collapses most of those rounds into one upfront conversation. The model's questions tell you exactly which decisions it would have made on its own. You make them instead. The output comes out right the first time because it had complete information.

There's also a secondary benefit. The questions the model asks are a checklist. If you use the same technique consistently for similar tasks, like adding new settings or fixing auth bugs, the questions start to look familiar. Over time, you learn to include those details in your prompts without being asked, and your baseline prompt quality improves.

A Few Practical Notes

This technique works best with agents that have tool use and file access, like Cursor or GitHub Copilot in agent mode. An agent that can read your codebase asks much more specific questions than one working blind.

The two-turn flow (what do you need -> here it is -> now do the task) does add a step. For small, clearly-defined tasks it's overkill. But for anything that touches multiple files or integrates with existing systems, it consistently produces better results than going straight to the implementation.

And the generated specification from step 3 is worth saving. It's a reusable template. The next time someone needs to add a setting that persists to the user profile, you already have a well-specified prompt for it.

The Bigger Point

The way most developers prompt coding agents is optimized for speed at the expense of quality. A quick sentence in, a mediocre output out, then ten minutes of cleanup. This repeats dozens of times a day.

The reverse prompting approach flips that tradeoff. You spend a little more time upfront making sure the model has what it needs. In return, the output lands closer to what you wanted, and you spend less time fixing it.

The best prompt for a task is the one the model tells you it needs.