Vibe Coding: Decide What Must Stay True

By Matthew Andrews · October 8, 2026

Vibe Coding Management · Part 5

Technical implementation should provide safeguards without becoming doctrine. But that raises a management question: which decisions can a developer or coding agent change, and which require a conversation first?

If every decision needs permission, the team loses room to solve problems. If every decision is negotiable, a small feature can quietly become a redesign of the system.

I think the practical answer is to make the reason behind each constraint visible.

Consider a hypothetical document export feature. A user wants to download a copy of their own records. A coding agent proposes a different library to produce the file.

That proposal could be a routine implementation choice. It becomes a different decision if the library sends those records to an outside service, changes who can access them, or creates a new ongoing cost.

The feature request has not changed. The consequences have.

For this kind of work, I would separate the instructions into three categories.

What Must Stay True

These are the conditions the solution must preserve. In the export example, a person must only receive records they are authorized to access. A change must not silently expose private records to another service.

The reason belongs beside the rule. “Keep this access check” is easier to misunderstand than “This check prevents one customer from downloading another customer’s records.”

That explanation also helps a developer recognize when a proposed shortcut crosses the boundary, even if the shortcut looks different from the failure we originally anticipated.

What We Have Chosen for Now

Some constraints exist because the team has made a practical operating decision. Perhaps the application already has a supported export library, and using it avoids adding another dependency to maintain.

I would describe that as the current choice, explain why it exists, and identify who can approve an alternative.

This keeps a decision from becoming permanent simply because nobody remembers its origin. It also prevents a coding agent from treating an established choice as disposable just because another option is easier for the current task.

What the Implementer Can Decide

The developer still needs room to work. Within the agreed boundaries, they might choose how to organize a helper function or simplify duplicated logic.

That freedom should be explicit. Otherwise, the team can spend as much time asking about harmless details as it spends discussing consequential changes.

The boundary is the effect of the choice. A change that alters shared behavior, access, cost, or the team’s ability to maintain the system deserves a wider review than a change contained within the assigned feature.

When someone proposes crossing that boundary, I would ask for a short explanation:

• What problem does the current approach prevent us from solving?
• Which existing constraint would change, and why?
• Who or what else would be affected?
• Can we try the alternative in isolation and return to the current approach if it fails?

For the export example, “The new library is easier” would not answer those questions. “The current library cannot produce the required accessible document format; here are the alternatives and their consequences” gives the team something useful to decide.

This is also where management needs technical judgment. Some implementation details are part of the protection itself. We cannot replace every precise technical rule with a broad statement of intent and assume the result will be safe.

My aim is to make that precision purposeful. Where a specific implementation is required, explain what depends on it. Where another approach is acceptable, say what must remain true for that approach to qualify.

Leading technical teams has made me care about whether people understand why a process exists. With AI-assisted development, that reasoning needs to travel with the instructions.

A useful requirement should leave the implementer knowing where they have freedom, where they need a decision, and what they are responsible for preserving.

Subscribe to the blog’s RSS feed for future posts in the Vibe Coding Management series.

Back to Blog