Prompt Engineering Through Requirements

By Matthew Andrews · October 5, 2026

Vibe Coding Management · Part 2

The prompt starts before you open the chat window.

It starts when someone explains what they need, and another person decides what that means.

I think that is where much of the real work in AI-assisted development now lives. We spend time discussing how to phrase instructions for a coding agent. But a well-written prompt can still produce the wrong feature if the requirement behind it is incomplete.

Through technical leadership and workflow automation, I have learned to ask what someone is trying to accomplish before deciding what to build. When AI can turn an instruction into software quickly, that question becomes even more important.

A User Story Is a Starting Point

Consider this requirement:

As a manager, I need a reporting dashboard so I can track progress.

It sounds reasonable. It identifies a person, a feature, and a purpose.

But what should a coding agent build?

A chart showing completed tasks? A list of overdue projects? A summary of blocked work? A percentage that looks reassuring while hiding the fact that a critical user capability still does not work?

Each could satisfy some interpretation of that sentence.

The missing information is the decision the manager needs to make.

A more useful starting point might be:

Before my weekly review, I need to identify which promised user outcomes are blocked, understand what is preventing them, and know who can resolve the next step.

Now we have something meaningful to break down.

Decompose the Decision

Yesterday, I wrote about keeping decomposition connected to the user. Here is how I would put that into practice.

For this reporting example, the manager needs to:

• Find the outcomes that require attention.
• Understand why each outcome is blocked.
• Identify the next action and its owner.
• Recognize when the information is too old to trust.

Each increment describes something a person can understand or do. Each can also be demonstrated.

That distinction matters. “Create a status component” describes implementation work. “Let the manager distinguish blocked work from work that has not started” describes the result that implementation must produce.

We still need technical work. But we should be able to trace it back to a reason the user cares.

Turn the Requirement Into a Working Prompt

For a hypothetical reporting feature, I would start with a prompt like this:

User and situation: A manager is preparing for a weekly review and needs to understand which promised user outcomes require intervention.

Build this increment: Show blocked outcomes with their blocker, next action, responsible owner, and the time the information was last updated.

Expected behavior: The manager can open an outcome, understand what prevents progress, and return to the same list without losing their place.

Uncertainty and failure: If an owner or next action is missing, say so explicitly. If information cannot be loaded, distinguish that failure from a successful result showing no blocked outcomes.

Safeguards: Follow the application’s existing access rules and interface conventions. Do not expose information the signed-in user cannot otherwise access.

Completion evidence: Demonstrate a blocked outcome, missing information, an empty result, and a loading failure. Show that opening an outcome and returning preserves the manager’s place.

Before implementation: Identify unresolved questions that would materially change the user’s experience.

This is not a universal template. It is an example of how a requirement can carry the context, boundaries, and evidence that a coding agent needs.

The important part is that we have described what success means before asking the system to produce it.

Give the Implementation Room to Move

I do not think every requirement should prescribe the internal implementation.

Some technical decisions are real constraints: security boundaries, compatibility, accessibility, or an established architectural requirement. Those belong in the prompt.

Other decisions are choices the developer or coding agent can investigate.

My preference is to be precise about the user’s outcome and explicit about the safeguards, while leaving room to propose how to achieve them.

That flexibility only works when the outcome is clear enough to evaluate.

Understanding Comes Before Wording

A user may ask for a dashboard because they feel unprepared in meetings. They may ask for notifications because they are afraid of missing something important.

We should not assume those motivations. We need to ask, listen, and check our understanding.

That is where emotional intelligence becomes practical engineering work. It helps us discover the need behind the requested feature and translate it without losing its meaning.

For managers, reviewing prompts should therefore include reviewing the requirements inside them.

Can we explain who benefits? What changes for that person? What happens when something goes wrong? What evidence would convince us that the need has been met?

In my view, prompt engineering begins with those answers.

Follow the Vibe Coding Management series by subscribing to the blog’s RSS feed.

Back to Blog