Vibecoding in Practice: How to Guide AI to Precisely Borrow from Open-Source Projects Without Going Off Track

In the practice of AI-assisted programming (Vibecoding), a common need is: you see a well-designed feature in another open-source project and want AI to "borrow" it. But there's an easy trap to fall into—AI tends to "take everything wholesale," importing the entire project's design philosophy rather than precisely extracting the best parts. Based on a hands-on recording by Bilibili creator "破旺来," this article breaks down how to guide AI to correctly borrow from external projects.

What is Vibecoding? Vibecoding is a programming paradigm proposed by OpenAI co-founder Andrej Karpathy in early 2025 that quickly gained popularity. It refers to developers collaborating with AI in a "feeling-driven" way—no longer reviewing code logic line by line, but describing intent in natural language, letting AI generate code, and only verifying whether the results match expectations. This approach dramatically lowers the barrier to programming but also introduces new challenges: AI-generated code often lacks understanding of the overall project architecture, easily producing results that are "locally correct but globally chaotic." Therefore, the core skill of Vibecoding is no longer "knowing how to write code" but "knowing how to guide AI"—how to use precise natural language to constrain AI's behavioral boundaries. Notably, Karpathy himself emphasized when introducing this concept that Vibecoding doesn't mean abandoning engineering judgment, but rather shifting the engineer's attention from "how to write" to "what to write and to what extent"—this meta-level decision-making ability is precisely the core topic of this article.

Starting Point: A Useful Open-Source Audio Editing Tool

The author discovered a small open-source tool called GapGun in a developer community he follows. Its core capability is: after importing audio files, it can quickly trim silent segments in between, enabling efficient podcast/voiceover editing.

GapGun represents the design philosophy of a category of "single-responsibility" localized audio processing tools. Unlike full-featured Digital Audio Workstations (DAWs) such as Adobe Audition and Audacity, these tools solve just one high-frequency pain point—rapid removal of silent segments in spoken content. From a technical implementation perspective, silence detection is typically based on the audio signal's RMS (Root Mean Square) energy value: when a segment's RMS falls below a preset threshold (e.g., -40dB) and its duration exceeds a minimum silence length (e.g., 200ms), that segment is flagged as a silence candidate.

RMS (Root Mean Square) is the core metric for measuring the "perceived loudness" of an audio signal. It's calculated by taking the mean of the squares of all sample points within a time window and then taking the square root. Compared to directly using peak amplitude, RMS is closer to the human ear's subjective perception of volume—because the ear is more sensitive to energy accumulation effects than instantaneous peaks. In practical implementation, silence detection engines typically maintain a sliding window (e.g., 50ms), scanning the entire audio's PCM data in steps, calculating RMS for each window and comparing it to the threshold. Since the computation per window is fixed, the overall algorithm complexity is O(n), where n is the total number of sample points—making it suitable for real-time browser-side processing without server-side computation, achieving a truly localized lightweight editing experience.

Its operational logic is extremely lightweight:

• Left-click to select segments
• Right-click to delete
• Left-click to play, right-click to delete, and other combination operations
• Uses non-destructive mark deletion (right-click to strike through, middle-click to restore)

What is non-destructive editing? The "non-destructive mark deletion" used by GapGun is a classic design philosophy in professional audio/video editing software. Unlike "destructive editing" (which directly modifies the original file), non-destructive editing only overlays an "operation instruction layer" on top of the original material, recording which segments need to be deleted and which need to be kept, while the original file remains completely intact. The advantages of this design are: operations can be undone at any time, no additional storage space is consumed, and adjustments can be made repeatedly before rendering. Professional software like Adobe Premiere and DaVinci Resolve all use this architecture. In lightweight tools, non-destructive editing is typically implemented by maintaining a "timeline marker array"—each right-click operation only writes a deletion marker to the array, and the actual trimming computation is only performed during export.

This "Lazy Evaluation" philosophy is also widely used in functional programming: accumulate operation descriptions first, then evaluate all at once when results are actually needed, saving intermediate computation overhead while preserving complete operation history for undo/replay. Lazy Evaluation was first systematically articulated by computer scientists Peter Henderson and James H. Morris in a 1976 paper, and was later adopted by purely functional languages like Haskell as their default evaluation strategy. Its core philosophy is "expressions are not evaluated when bound, but only when the result is actually consumed," allowing programs to safely operate on conceptually "infinite data structures" since only the accessed portions are actually computed. In the audio editing scenario, this philosophy manifests specifically as: all deletion, trimming, and volume adjustment operations only append descriptors to an operation queue, and only when the user clicks "Export" does the engine traverse the operation queue, performing batch processing on the original PCM data to generate the final audio file. This "accumulate intent → batch execute" pattern, compared to the "immediately modify data on each operation" approach, not only avoids massive memory consumption from intermediate audio data states but also naturally supports multi-step undo, since each "intent descriptor" is reversible.

This design philosophy of "ultra-lightweight local editing + multi-row waveforms + non-destructive markers" closely aligned with the audio project the author was developing. So he decided to have AI incorporate this interaction design into his own project.

AI's First Response: Taking Everything Wholesale

The author first pulled down GapGun's complete code and had AI understand the project. To its credit, AI didn't immediately modify code but first produced a research and planning document—first organizing the project's technical architecture and interaction logic, then providing an upgrade plan for the audio module. This reflects the good habit of AI agents to "plan first, execute later."

But problems quickly emerged. After comparing the two projects, AI's proposed plan was to "make comprehensive changes, fully aligning with GapGun":

• Differences between local arbitrary files vs. the project's own files
• Differences in trimming logic
• Differences in waveform display
• Differences in the bottom timeline

AI tried to eliminate all these differences, making the author's project adapt to all of GapGun's designs. This is a typical cognitive bias in Vibecoding: AI defaults "borrow" to mean "replicate" rather than "integrate."

Why does AI "take everything wholesale"? The root cause of AI's deviation when interpreting "borrow" instructions lies in how large language models reason within context. When AI is asked to "reference Project A to improve Project B," it simultaneously loads both projects' code in the context window and tends to seek the "maximum alignment" solution—because in training data, this often corresponds to "complete refactoring tasks." AI lacks natural perception of "primary-secondary relationships"; it cannot autonomously determine which project is the "subject" and which is the "reference material" unless the developer explicitly states it. This is why in Vibecoding practice, "role setting" and "boundary declaration" are among the most critical Prompt Engineering techniques—clearly establishing the primary-secondary relationship before the task begins can significantly reduce AI's "overreach."

The deeper reason lies in large language models' training objective: models are optimized to "maximize prediction accuracy of the next token," which makes them naturally inclined to generate "complete, self-consistent" output. When two codebases appear simultaneously in context, the model treats "eliminating differences and unifying style" as the solution most consistent with "completeness" expectations. This is directly contrary to human engineers' intuition—experienced engineers prioritize protecting the existing system's stability and making only minimal necessary changes. This engineering intuition corresponds to a principle in software engineering: YAGNI (You Aren't Gonna Need It), proposed by Ron Jeffries, advocate of Extreme Programming (XP) methodology, meaning "don't write code for features you don't currently need." The core insight behind YAGNI is: the cost of predicting future needs often exceeds the cost of implementing them when actually needed, and prematurely introduced "reserved capabilities" increase system complexity, reduce maintainability, and consume engineering resources that could be used for current highest-priority needs. YAGNI and the "minimize changes principle" together form two defensive lines against over-engineering: the former constrains feature scope, the latter constrains change magnitude. In Vibecoding, both principles need to be explicitly stated by humans rather than relying on AI to infer them—because AI's "completeness preference" systematically violates both.

The Key Course Correction: Centering Your Own Project

The author immediately called a halt and performed a principled course correction. He explicitly told AI:

"I don't want to completely use the GapGun project. I just want our project to have better interaction capabilities. Center on our current project, and use this project's superior interactions and related logic as material to transform our project, rather than making our project adapt to another project."

This course correction statement is very worth studying. It contains three layers:

1. Clarify the core: Our own project is the subject
2. Clarify the positioning: The external project is only "material" and "reference"
3. Clarify the boundaries: What can be borrowed and what explicitly doesn't need to be borrowed

After receiving this instruction, AI reorganized its understanding of the business logic, distinguished between "borrowable" and "not needed" parts, and reformulated its plan. This demonstrates that—in Vibecoding, human judgment and boundary-setting are more important than letting AI freely improvise.

Why is the primary-secondary declaration in prompts so effective? In Prompt Engineering research, the "Anchoring Effect" is a key mechanism influencing model output direction. When "X as the subject" appears explicitly in the prompt, the model sets X's corresponding codebase as the reference frame for reasoning, and all subsequent difference analysis proceeds from "how to introduce Y's features without breaking X's existing structure" rather than "how to make X and Y converge."

The anchoring effect was originally proposed by psychologists Amos Tversky and Daniel Kahneman in their 1974 cognitive bias research, describing humans' tendency to over-rely on the first piece of information received (the "anchor") when making judgments. Their classic experiment showed: when subjects first saw a random number and were then asked to estimate an unknown quantity (such as the proportion of African nations in the UN), their estimates were significantly pulled toward that random number—even when they knew it was randomly generated. Kahneman later received the 2002 Nobel Prize in Economics for this series of research on human judgment and decision-making. Large language models replicate this mechanism to some extent: information that appears first in the prompt and is explicitly marked as the "subject" becomes the anchor for the model's subsequent reasoning, significantly influencing the directionality of its generation strategy. This works even better when combined with Chain-of-Thought (CoT) prompting techniques—first have AI output its understanding summary of both projects, have humans confirm the primary-secondary relationship and borrowing scope, then allow AI to enter the code generation phase. This "understand → confirm → execute" three-stage workflow is one of the most effective structures for reducing "directional errors" in Vibecoding. CoT was proposed by the Google Research team in 2022, with its core idea being to guide the model to explicitly output intermediate reasoning steps, decomposing complex tasks into verifiable sub-steps, thereby significantly improving model accuracy on complex reasoning tasks—in the Vibecoding scenario, this means having AI "explain what it plans to do" before writing code, giving humans a window to review and correct. In practice, an effective CoT trigger phrase is: "Before starting to modify any code, please list the files and functions you plan to change, along with the rationale for each change, and wait for my confirmation before executing." This single sentence can switch AI from "immediate execution mode" to "plan first, confirm later mode," dramatically reducing the probability of directional errors.

Implementation: A Dedicated Page for Audio Editing

After the course correction, the author proposed a more specific architectural decision. Since the current project's page had very weak editing capabilities (basically only synthesis, no editing), if the full editing interaction from GapGun were to be introduced, the existing page layout simply couldn't accommodate it.

So the author decided: create a dedicated page to host all audio editing functionality.

Why make it a separate page? Extracting audio editing functionality into a dedicated page is essentially an architectural refactoring based on "Separation of Concerns." This principle was proposed by computer science pioneer Edsger Dijkstra in his 1974 paper "On the role of scientific thought" and is one of the most fundamental design philosophies in modern software engineering: each module is responsible for only one thing, and modules communicate through clearly defined interfaces rather than interpenetrating each other. In software engineering, when a functional module's complexity exceeds the current page's capacity, isolating it is standard practice. Multi-track editing involves synchronized rendering of multiple independent timelines—dialogue, BGM, ambient sound—requiring audio buffer management, waveform visualization, timeline alignment, and other computationally intensive tasks.

From a technical implementation perspective, browser-side audio processing relies on the Web Audio API—a W3C-standardized native audio processing interface supporting Audio Node Graph architecture. The Web Audio API was drafted by W3C in 2011 and became an official W3C Recommendation in 2021, now supported by all major browsers. Its core design philosophy directly maps the signal routing logic of analog-era mixing consoles: developers connect various functional nodes (such as source nodes AudioBufferSourceNode, gain nodes GainNode, analyzer nodes AnalyserNode, effect nodes ConvolverNode, etc.) into a directed acyclic graph, where audio signals flow from source nodes to destination nodes, passing through each node's digital signal processing, finally converging at AudioContext.destination for output. This is completely isomorphic to the physical signal chain on analog mixing consoles: "input channel → EQ → compressor → fader → bus → master output," allowing developers with analog audio engineering backgrounds to directly transfer their mental model from hardware mixing consoles to API usage. When implementing multi-track playback, each track corresponds to an independent AudioBufferSourceNode, volume is controlled via GainNode, and everything converges to DestinationNode for output; waveform visualization relies on AnalyserNode's time-domain data (obtained via the getByteTimeDomainData() method) rendered in real-time to Canvas, typically driven by a requestAnimationFrame render loop to ensure smooth 60fps refresh. These operations involve extensive ArrayBuffer memory management and continuously running animation loops, and if mixed with the main application's React/Vue state tree, they easily cause performance bottlenecks and state pollution. Concentrating this logic in a dedicated page not only achieves state isolation but also reserves expansion space for future introduction of real-time mixing, audio effects, and other advanced features. This "isolate first, extend later" strategy is also a concrete manifestation of incremental development in the Vibecoding context.

In this dedicated page, all audio editing capabilities need to be abstracted into it, including:

• Current BGM
• Future ambient sounds, sound effects, etc.

For the page design, the author had AI follow his existing frontend design specifications rather than copying GapGun's interface style.

Final Form: Multi-Track Editing Interface

The final audio editing page retained the project's original characteristics while incorporating the borrowed interaction capabilities:

• Left-side conversation area: Clicking different conversations allows independent adjustment of each sentence
• Full-text editing: A new feature where selecting different sentences jumps to the corresponding timeline node
• Multi-track support: Including dialogue, BGM, ambient sound, and a final mixed playback preview

This marks the project's formal entry into the multi-track processing phase, unifying previously scattered audio editing capabilities into a dedicated interface. The introduction of multi-track architecture also means the project's data model layer needs to upgrade from "single audio file path" to "track object array"—each track object containing type (dialogue/BGM/ambient), volume curve, silence marker list, and other properties.

In actual engineering, track objects are typically stored in JSON format, containing fields such as trackId, type (dialogue/BGM/ambient), sourceUrl, volume (0-1 float), keyframes (keyframe array), muteRanges (silence marker list), etc. This flat JSON structure is convenient for frontend state management (such as Redux/Zustand immutable state trees), facilitates data exchange with backend APIs, and naturally supports version control system diff comparisons. This evolution of data structure is precisely where the expansion interfaces reserved by the "dedicated page first, extend capabilities later" strategy come into play.

Notably, the multi-track data model design itself is also an important engineering decision. In actual implementation, volume curves are typically stored as "keyframe arrays"—each keyframe records a timestamp and corresponding volume value, and the playback engine performs linear or Bézier interpolation between two keyframes to achieve smooth fade-in/fade-out effects. This keyframe interpolation mechanism is completely identical in principle to tweening in animation—essentially filling continuous intermediate values between discrete control points using mathematical functions. Bézier curves were developed by French engineer Pierre Bézier in the 1960s for Renault's car body design, later introduced into computer graphics, becoming the foundational tool for vector graphics and animation interpolation. They are now widely used in CSS animation's cubic-bezier easing functions and audio editor envelope curve designs. The silence marker list corresponds to the "non-destructive editing" philosophy mentioned earlier: each marker records start and end timestamps, and during export the engine traverses the marker list, skipping marked time segments and concatenating remaining segments to generate the final audio file.

This data structure design also makes Undo/Redo functionality natural to implement—simply maintain an operation history stack, push an "inverse operation descriptor" for each operation, and pop and execute the inverse operation on undo, without needing to reload the original audio file. This pattern is known in software engineering as the Command Pattern, one of the 23 classic design patterns documented in the "Design Patterns" book, specifically designed to encapsulate operations as objects to support undo, redo, operation queues, and other advanced functions. The essence of the Command Pattern is "operations as first-class citizens": each user action is no longer a direct function call but is encapsulated as a command object with execute() and undo() methods, pushed onto the history stack. This allows arbitrarily complex operation sequences to be precisely replayed or reversed without rebuilding the entire application state—in the audio editing scenario, this means users can undo silence marking operations at any step without reloading or re-analyzing the original audio file.

Core Lesson: Maintaining Boundaries When Borrowing from External Projects

The greatest value of this hands-on experience isn't what features were built, but the important Vibecoding principle it reveals:

When you see a well-designed project and pull it in for reference, AI will "take everything wholesale"—whether you want it or not, it will incorporate everything.

Therefore, what humans need to do is precisely define the scope of borrowing. In this case, only two things were truly worth borrowing:

1. Multi-row editing capability
2. Mouse shortcut operation logic

As for everything else, it can be set aside for now. External projects didn't "grow" from your own project; many aspects are naturally incompatible. Blindly aligning completely with them will actually destroy your project's consistency.

The Engineering Philosophy of "Material Library Thinking" Treating external projects as "decomposable material libraries" rather than "blueprints to replicate" closely aligns with the software engineering principle of "Composition over Inheritance." This principle was first systematically articulated by the Gang of Four (GoF)—Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides—in their 1994 book Design Patterns: Elements of Reusable Object-Oriented Software, and was later incorporated into the core principles of object-oriented design. In object-oriented design, inheritance introduces strong coupling—subclasses must inherit all characteristics of the parent class, including unwanted parts, and any changes to the parent class may cascade to all subclasses, forming the so-called "Fragile Base Class Problem"; composition allows developers to precisely select needed behavioral modules, assembling functionality through interfaces rather than inheritance relationships, keeping modules loosely coupled and independently evolvable and replaceable. A classic example of the "Fragile Base Class Problem" is Java's early Stack class inheriting from Vector: because it inherited all of Vector's public methods, users of Stack could bypass the stack's LIFO constraint and directly call Vector's random access methods to manipulate the underlying array, breaking the data structure's semantics—this is precisely the typical cost of including an "entire class" in the dependency chain rather than "precisely selecting needed capabilities."

"Borrowing" in Vibecoding is essentially a composition operation: extracting specific interaction patterns or algorithm logic from external projects and embedding them in your own architecture in a loosely coupled manner, rather than establishing strong dependencies. This way of thinking requires developers to complete "functional decomposition" before initiating the borrowing task—decomposing the target project into several independent capability modules, clearly marking "needed" and "not needed," then passing this list as constraints to AI. In practice, a "capability matrix" method can be used: the horizontal axis lists all functional modules of the target project, and the vertical axis marks two dimensions: "interaction innovation" and "architectural coupling." Modules with high interaction innovation + low architectural coupling are the "golden zone" most worth borrowing; modules with low interaction innovation + high architectural coupling should be explicitly excluded. This "functional decomposition checklist" can serve directly as the beginning of the prompt, for example: "The following are the specific capabilities I need to borrow from the reference project: [list]; the following are parts I explicitly don't need: [list]; please provide a minimal implementation plan only for the parts to be borrowed, without changing my existing project architecture." This structured constraint declaration can suppress AI's "wholesale" tendency to the minimum. Worth noting is that "functional decomposition" itself is a skill requiring deliberate practice—it requires developers to have sufficiently deep understanding of the target project to identify which parts are "core interaction innovations" and which are "implementation details that exist to accommodate its own architecture." This ability to distinguish is precisely one of the most core competitive advantages for engineers in the Vibecoding era.

Conclusion: When borrowing from external projects, always center on your own project, treat external designs as decomposable "material libraries," take only the modules you need, and use your own architecture to receive and transform them. This is the correct approach to "learning from others' strengths" in Vibecoding.

Key Takeaways