Vibe Coding in Practice: Why You Should Choose Reuse When AI Offers Two Solutions

The Problem: A Mysterious Bug Where the Frontend Won't Refresh

While using AI-assisted coding (Vibe Coding) to develop a script and dialogue editing system, a developer encountered a classic frontend state synchronization issue: after modifying dialogue lines, the backend logs confirmed the data had been updated, but the frontend interface didn't refresh, causing the "Single Line Synthesis" button to fail to appear. Yet when modifications were made through other means (such as performance annotation updates), the frontend refreshed normally and displayed the synthesis button just fine.

This type of problem is extremely common in modern Single Page Application (SPA) development. In reactive frameworks like React and Vue, UI rendering depends entirely on state changes — the framework only triggers a re-render when state is properly updated. The root cause is often this: the data has indeed been updated in the backend or local storage, but the frontend's reactive state tree hasn't been notified of the change, leaving the UI stuck on the old state. This is what's known as a "data flow break" — the data changed, but the view doesn't know about it.

After having the AI explain the issue in "business language," the essence of the problem surfaced: saving performance annotations triggers a UI refresh, but saving dialogue modifications is missing this refresh step. Without a refresh, the button naturally doesn't appear, and users assume their changes didn't take effect.

This is a very common frontend state management problem, but the two fix proposals the AI offered next are what this article is really about.

The Two Solutions from AI: Quick Patch vs. Abstract Reuse

Solution A: Minimal Changes, Just Patch the Frontend Logic

Solution A's approach was very straightforward — don't touch the backend, just add a refresh operation in the callback after dialogue is saved successfully. The change footprint is minimal, requiring modifications in only three places, with virtually zero risk.

This is the classic "symmetric logic" approach: see how it's done elsewhere, copy the same pattern. Fast, safe, and it works.

Solution B: Extract a Common Function, Unify the Refresh Entry Point

Solution B takes a more "engineering-minded" approach — it abstracts the refresh logic from both the performance annotation update and the dialogue save into a common function. Every scenario that needs to trigger "frontend refresh + display synthesis button" calls this single entry point.

This approach follows the DRY principle (Don't Repeat Yourself) in software engineering. The DRY principle was introduced by Andy Hunt and Dave Thomas in The Pragmatic Programmer, emphasizing that every piece of knowledge in a system should have a single, unambiguous, authoritative representation. The harm of duplicate code isn't just code bloat — it creates "implicit coupling." These scattered copies are logically related, but the code structure doesn't reveal that relationship. When requirements change, developers must rely on memory to find all copies and modify them one by one.

The trade-off is a larger change footprint, more files involved, and a higher risk of introducing regression bugs.

Why You Must Choose Solution B in Vibe Coding

The developer chose Solution B without hesitation, for three reasons — each worth careful consideration:

1. Future Requirements Will Inevitably Reproduce the Same Pattern

Dialogue modification needs a refresh — but what about line-by-line editing? Polyphonic character adjustments? Subsequent performance parameter tweaks? Every operation involving content changes needs the same "save → refresh → display synthesis button" flow. If you use Solution A's approach and write a separate copy each time, the codebase will balloon rapidly.

2. Future Process Changes Only Require Modifying One Place

If the refresh process itself needs adjustment down the road (say, adding a loading animation, a success notification, or changing the synthesis button's display logic), a common function means you only need to change one place. This is a direct embodiment of the Single Responsibility Principle — a module should have only one reason to change. By consolidating the responsibility of "refreshing the frontend after content changes" into a single function, the reason for change and the location of change achieve a one-to-one correspondence, dramatically reducing maintenance costs.

With duplicate code scattered in four places, you'd need to modify all four — and you'll almost certainly miss one.

3. Missing One Is Planting a Landmine

The consequences of missing a copy don't surface immediately. They'll quietly trigger in some inconspicuous scenario, producing those maddening "occasionally appears, hard to reproduce" bugs. In software engineering, these are called regression bugs, and their probability is directly proportional to code coupling and duplication. Every piece of unabstracted duplicate code is a form of "technical debt" — it causes no problems today but accrues interest with every future modification. Martin Fowler calls this the "Design Stamina Hypothesis": good design seems unnecessary in the short term but significantly reduces the cost of change in the medium to long term. The debugging cost of such bugs far exceeds the cost of spending an extra half hour on abstraction upfront.

Key Architectural Decision Principles in Vibe Coding

This case reveals a critically important decision principle in AI-assisted coding: when AI gives you multiple solutions, prioritize the more abstract, more consolidated one.

First, let's understand how Vibe Coding works. Vibe Coding is a concept proposed in 2024 by Andrej Karpathy, former OpenAI researcher and Tesla AI Director. It refers to a development model where developers describe requirements in natural language and let AI generate the code. In this model, the developer's role shifts from "code writer" to "requirements describer" and "solution decision-maker." Developers don't need to write code line by line, but they need the ability to judge the quality of AI-generated solutions — an ability that is essentially architectural decision-making and engineering judgment.

Specifically:

• Choose the "single responsibility" solution: One function should have one entry point, and one change should only require modifying one place. This is a direct embodiment of the Single Responsibility Principle in software engineering.
• Watch out for over-coupling: Abstraction doesn't mean cramming everything together. If two processes are only superficially similar but fundamentally different, forcing them together will create even bigger problems. The criterion is: do these scenarios truly share the same business semantics? In this case, "trigger a frontend refresh and display the synthesis entry point after content changes" is clearly a unified business semantic.
• Trade short-term risk for long-term gain: Solution B has a larger change footprint and higher risk right now, but it lays the foundation for the project's long-term maintainability. In Vibe Coding, AI can help you quickly implement Solution B's code, so the actual time cost difference isn't as large as you might imagine.

Practical Advice for Vibe Coding Practitioners

1. Have AI explain the problem in business language: When AI gives you a pile of technical details you can't understand, simply ask it to "explain this to me in business language." Understanding the essence of the problem matters more than understanding code details.
2. Always ask "how do you plan to fix this": Don't let AI jump straight into coding. Have it present solutions first and explain the trade-offs. Your role is the decision-maker, not the executor.
3. Reuse-first principle: When you find the same logic being written a second time, you should consider abstraction. When AI gives you a "quick patch" and an "abstract reuse" option, unless the project is about to be deprecated, choose the latter. This aligns with Kent Beck's "Rule of Three": when the same code appears a third time, it should be abstracted into a reusable component. In AI-assisted development, where code generation is extremely fast, this threshold can even be lowered to the second occurrence.
4. Use debug keywords to trigger investigation: Setting specific skill trigger words in your prompts (like "debug" in this example) can put AI into a more systematic problem investigation mode. This is essentially a Prompt Engineering technique — using structured instruction design to guide AI toward more targeted analysis rather than generic advice.

Conclusion: Architectural Decision-Making in the AI Era

In the era of AI-assisted coding, the speed of writing code is no longer the bottleneck — making the right architectural decisions is. AI excels at giving you multiple viable solutions, but choosing which solution and understanding why requires human engineering judgment.

The core of this judgment lies in understanding the long-term evolution patterns of software systems. Frederick Brooks pointed out in The Mythical Man-Month that the essential difficulty of software isn't in construction but in design — deciding what the system should do and how its parts should collaborate. AI has dramatically reduced the cost of construction, but the importance of design decisions has been amplified as a result. When code generation becomes cheap, choosing what kind of code to generate becomes the real competitive advantage.

Remember this core Vibe Coding principle: whenever AI gives you a "fast but scattered" option and a "slower but consolidated" option, choose the latter. The extra ten minutes you spend today will save you ten hours of debugging in the future.