Any best practices about the balance between vibe-coding and openspec workflow？

[postbird]

There is a confusion for me during the practice.

How should I balance the vibe coding and the spec coding based on openspec?

For example, I create a proposal, and apply it, then I get the first version A, but I find I need to add or adjust some functions or UI display, and the first thought is directly let AI coding tool to implement (then it take me into vibe coding again).

I think it will might broke the specs, or should I create a new proposal to solve it?

I find there are some instructions in openspec/Agents.md, but I am not sure what's the best practice about my scenario.

Skip proposal for:
- Bug fixes (restore intended behavior)
- Typos, formatting, comments
- Dependency updates (non-breaking)
- Configuration changes
- Tests for existing behavior

[real-lazy-coder]

Right or wrong, here's my approach. I utilize specs when implementing features. When I'm making adjustments, I will usually just make the adjustments myself or prompt AI to do it. I always create a new branch for these. Then I prompt AI to update an specs based on the changes in the branch.

You'll need to thoroughly evaluate the changes to any specs. I've found good success with this strategy, but I'm certain there are other/better ways.

I recommend trying a few different approaches and see what works best for your workflow.

[CaseyRo]

Since I'm a product owner in my daily profession, all I do is "write" (or let AI write..) specs.

The decision on the professional side usually is:

• A feature = a change that has a significant impact on the (end) users experience.
• A fix = a change that has no, to little impact on the (end) users experience.

In some business cases it could also be about money, storypoints (usually fixes are not scoped/estimated, features are) or impact on other resources (e.g. design or testing)

Long story short, I create a feature once I see the vibe coding doesn't work out, or I can't reasonably expect/calculate the change in my head from all perspectives. The more complicated a project gets, the more features I write (or I decide to split it into new micro services)

[real-lazy-coder]

great insights! thanks for sharing