Vibe Coding: Your Tickets Are the Prompt

By Matthew Andrews · October 9, 2026

Swipe through the example, or use the arrows. Select an image to view it at full size.

Vibe Coding Management · Part 6 · Friday synthesis

“I’m not getting any notifications.”

That sounds like a straightforward request. It is also easy to turn into the wrong work.

Before asking a developer or coding agent to build anything, I want to understand what the person expects: “What types of notifications do you expect, and how should they be prioritized so you feel able to manage your work?”

The answer gives us something more useful than a feature name. It tells us what the person needs to accomplish and what makes their work feel manageable.

In this illustrative example, the answer is: “Tell me when something needs my action. Show urgent approvals first, and keep routine updates separate.”

Now the real work begins.

Build the Journey Around the User

Throughout this series, I have argued that faster implementation makes understanding the user more important. Decomposition is how we carry that understanding into the work.

For this example, the journey has four steps:

1. Notice that an item needs my attention.
2. Understand which work needs attention first.
3. Open the item, review it, and make a decision.
4. Confirm the result and see what remains.

These steps describe the user’s experience. They give management and developers a shared way to discuss progress across the system.

A story beginning with “As a user, I need…” can still hide an enormous amount of work. The sentence format alone does not make the scope small. Each story needs an outcome we can demonstrate, and we should keep refining it when it contains several outcomes that need separate decisions or evidence.

Put Requirements Between the Story and the Code

Take one part of the journey: seeing urgent approvals before routine updates.

Before creating implementation tickets, define the expected behavior. Urgent actions appear first. Routine updates remain accessible in a separate group. When an item’s priority changes, the displayed order reflects that change.

Then define how we will check it. Give the user an inbox containing both types of item. Verify the grouping and order. Change an item’s priority and verify the updated result.

Questions remain for the real project: who determines urgency, what happens when priorities tie, and whether users can override the order. Those decisions belong in the requirements. The coder should not have to invent them from a vague request.

Let the Tickets Carry the Prompt Engineering

One user story may require several coordinated implementation tickets.

For the prioritization story, a data ticket might define priority and category fields. A backend ticket might apply the grouping and ordering rules. A UI ticket might present those groups to the user.

Each ticket needs a type, an owner, dependencies, scope, and acceptance evidence. It should link back to the user story and explain how its work contributes to that outcome.

This is what I mean by letting the tickets do the prompt engineering. The context and expected behavior travel with the work, so a developer or coding agent can act on them without reconstructing the intent from scattered conversations.

Technical choices still require judgment. Architecture and safeguards establish the boundaries, while implementation can adapt within them.

Test the Story, Then the Complete Journey

Each story’s implementation tickets should sit inside a testing scope aligned with that story’s user need.

For prioritization, the story-level end-to-end test checks the actual displayed order, priority changes, and access to routine updates across the participating layers. Completing the data, backend, and UI tickets separately does not establish that they work together.

The entire sequence of stories then sits inside a broader journey test. Can an assigned user notice an item, prioritize it, review it, save an authorized decision, and return to an accurate list of remaining work?

That broader test must also cover the relevant handoffs and failure conditions: shared state, role boundaries, retries, duplicate events, and persistence after reopening. The exact cases should follow the system’s risks and requirements.

Keep the User’s Need Visible

Emotional intelligence helps us discover what someone needs to feel capable of doing their work. Careful decomposition preserves that understanding through requirements, implementation, and testing.

That is the management responsibility I see becoming more important with vibe coding: making the user’s intent explicit enough that every ticket contributes to a demonstrable outcome, and every outcome connects to a working journey.

The accompanying five-page carousel walks through this illustrative example and ends with the full decomposition and testing structure.

Subscribe through the blog’s RSS feed for future posts.

Back to Blog