Vibe Coding: When the Need Changes, Follow the Change

By Matthew Andrews · October 10, 2026

Vibe Coding Management · Part 7

A ticket can be complete and still describe a requirement the user no longer needs.

Yesterday, I wrote about carrying user intent through stories, requirements, implementation tickets, and testing. That structure has to stay useful after someone learns something new.

As OmniMint’s founder and CTO, I think this is an important management question for AI-assisted development: when the requirement changes, how do we keep the work and its evidence aligned?

Start With What Changed for the User

Continue the illustrative notification workflow from the previous article. We originally wanted urgent approvals to appear first. During a review, the user adds: “If I hand an approval to someone else, I need to know it is still being handled.”

That introduces a new need: visibility after a handoff. Jumping straight to a reassignment button would leave important questions unanswered. Does the original reviewer retain access? Who can make the decision? What should each person see after the transfer?

I would write down the changed need and resolve those decisions before treating the request as ready for implementation.

Trace the Consequences

The change may reach beyond the ticket where the conversation started. In this example, it could affect assignment data, permissions, notifications, the review screen, and the record of who made a decision.

I would use the existing journey to find those connections. For each affected story, identify what behavior changes, which tickets depend on it, and who coordinates the update. Keep unaffected work intact.

This is also the point to make a scope decision. A newly discovered need can be included now or deliberately deferred. Either way, the team needs a visible decision instead of different people working from different assumptions.

Keep the History and Revisit the Proof

A passing test answers a particular question about a particular version of the system. It may still provide useful evidence after a change, but we need to check whether it covers the revised requirement.

The original prioritization test might remain valid. The reassignment flow needs additional evidence: the new reviewer can act, the previous reviewer has the intended visibility, and both see the correct result after reopening.

I would preserve the earlier result and mark the affected behavior as needing verification. That makes the uncertainty visible without erasing completed work or pretending an old test proved a new requirement.

The broader journey also needs a check wherever the change crosses its boundaries. Can the user still notice the work, understand its priority, reach an authorized decision, and see what remains after reassignment?

Use a Short Change Review

For each material change, I would ask:

1. What changed in the user’s need, and why?
2. Which stories, decisions, and dependencies does that affect?
3. Are we including it now or deferring it, and who owns that decision?
4. Which evidence still applies, and what must be demonstrated again?
5. Have the affected tickets and the complete journey been updated together?

The review should be proportionate to the change. A wording adjustment and a change in who can approve work do not need the same depth of investigation.

If tickets are going to carry the prompt engineering, keeping them current is part of the job. Faster implementation only helps when the instructions still describe the outcome we intend to deliver.

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

Back to Blog