4 Advanced Vibe Coding Tips to Stop AI from Making Your Code Worse with Every Edit

Many people using AI programming tools have experienced this: the AI performs well at the start of a conversation, but as the conversation grows longer, the code quality actually gets worse and bugs multiply. This isn't just an illusion—there's an underlying logic behind it. This article shares 4 battle-tested advanced Vibe Coding tips to help you solve this problem at its root.

What is Vibe Coding? This concept was coined by OpenAI co-founder Andrej Karpathy in early 2025. It refers to a programming paradigm where developers describe requirements in natural language, rely entirely on AI to generate code, and write almost no code themselves. It dramatically lowers the barrier to programming, but also brings new challenges: developers need to learn how to effectively "steer" AI, rather than being led by it.

Tip 1: Commit to Git Frequently, Roll Back Decisively

This is the most important yet most easily overlooked habit. Many people don't do version control when coding with AI, and when the code gets broken, they have no choice but to start over. The right approach is to establish a clear commit strategy:

When NOT to commit? When AI has just finished writing code and you haven't tested it yet. Code quality is unknown at this point, and committing prematurely will only pollute your version history.

When to roll back decisively? When testing reveals the AI got it completely wrong and failed to implement your requirements at all. Don't hesitate—don't try to patch things up on a broken foundation. Roll back and let the AI start fresh.

When SHOULD you commit? When you find the core functionality is mostly implemented, with perhaps a few minor bugs remaining. The key is judging the difficulty of fixing those bugs—if the bugs are small, just let AI fix them directly. But if you're unsure how much work the fix will require, it's best to commit first to preserve the basic functionality you've already achieved.

Here's a very important detail: Write clearly in your commit message what functionality has been implemented and what bugs remain unfixed. This way, when rolling back, you can precisely locate key checkpoints in your version history.

There's also an advanced technique: if you and AI went back and forth many times to fix a bug, don't directly commit that patch-ridden code. The right approach is to have AI summarize the fix, then roll back to a clean state and let AI apply the fix all at once.

The purpose of this approach is to fundamentally control the accumulation of Technical Debt. Technical debt is a classic concept in software engineering, introduced by Ward Cunningham in 1992 as a metaphor for non-standard implementations adopted for short-term rapid delivery—like taking on debt that you'll need to repay at a higher cost in the future. In AI programming scenarios, technical debt accumulates far faster than in traditional development: as AI repeatedly patches bugs, it introduces redundant logic, duplicate code, and contradictory implementations. This "junk code" snowballs, making subsequent development increasingly difficult. Rolling back to a clean state and applying the fix all at once is actively paying down this debt, rather than letting it compound.

Tip 2: Clear Context Regularly, Give AI a Fresh Start

The core of this tip lies in understanding the token economics behind AI programming tools.

All AI coding products charge by token behind the scenes. This means there's a natural conflict of interest between the platform and users: you want AI to use enough tokens to deeply understand and solve problems, while the platform wants to conserve tokens. To this end, platforms employ various engineering techniques to compress context.

To understand this issue, you first need to grasp two basic concepts. Tokens are the fundamental units that large language models use to process text, roughly corresponding to half a word in English or one character in Chinese. Context Window is the maximum number of tokens a model can process in a single inference, currently ranging from tens of thousands to hundreds of thousands for mainstream models. When conversation history exceeds the window limit, platforms use truncation, summary compression, and other engineering techniques to "trim" the context—this process inevitably loses detailed information, causing AI's understanding of earlier code structure and requirements to gradually blur. This is precisely the root cause of why code gets worse as conversations go longer.

The solution is simple: when you find a problem can't be solved, decisively clear the context and start a fresh conversation. Save your precious context space for the most important task at hand.

How Many Issues Per Conversation?

This is something many people struggle with. The criteria mainly come down to two factors:

1. Problem difficulty: For complex, large problems, having AI focus on just one task at a time will noticeably improve performance.
2. Problem relevance and scope: If several problems are small in scope and related to each other, they can be grouped together. Because every time AI starts solving a problem, it first needs to read code and analyze—all of which consumes tokens. Solving multiple small problems in one analysis session is more efficient than handling them separately.

Put simply, each independent conversation has fixed token overhead. Bundling small problems amortizes this cost, while large problems must be handled individually to ensure quality.

Tip 3: Modularize Your Code, Limit AI's Modification Scope

This tip seems simple, but it dramatically improves your speed at catching problems.

Divide your code into clear modules by functionality, and have AI work only within a specific module each time. For example, when you're modifying the user management module, if you notice AI went off and changed code in the database module, you'll immediately recognize something is wrong.

The benefits of modularization go beyond catching AI's "boundary violations"—more importantly:

• Narrow AI's focus, reducing unnecessary token consumption
• Lower the risk of breaking other features, as each module is relatively independent
• Facilitate rollback and version management, with precision down to the module level

This is essentially the application of the Separation of Concerns (SoC) principle from software engineering to AI programming scenarios. This principle was proposed by Edsger Dijkstra in 1974, with the core idea of decomposing programs into modules with singular functionality and mutual independence, each responsible for one clear concern. In AI programming scenarios, this principle takes on new practical significance: AI models' Attention Mechanism can more accurately understand contextual relationships and generate higher-quality code modifications with fewer side effects when working with limited scope and clear boundaries. AI, like human developers, performs best when focused on a limited scope.

Tip 4: Use Screenshots to Let AI "See" Your Requirements

The last tip is small but remarkably effective in UI development scenarios: send screenshots directly to the AI coding agent.

When you can't clearly describe the interface effect you want in words, a reference screenshot is worth a thousand words. A more advanced approach is:

1. Take a full-page screenshot of the website you want to reference
2. Use another LLM to produce a detailed style summary of the screenshot (colors, fonts, layout, spacing, etc.)
3. Provide both the screenshot and the style summary together to the AI coding agent

Why does this work better? It comes down to how large models are trained. Large language models learn patterns through pre-training on massive internet data, which means model outputs naturally regress toward the "average level" in the training data—the statistically most common solutions. This phenomenon is known in machine learning as "Regression to the Mean." In UI design, the internet is flooded with functional but visually mediocre interfaces, so without specific visual references, AI-generated interfaces tend to lack design quality. If you want a polished, distinctive interface, you must be very specific about what it should look like—the combination of screenshots plus style summaries is precisely how you break this "gravitational pull," shifting AI's output from the mediocre mean toward what you actually want.

Summary

The core philosophy of these 4 tips can be distilled into one sentence: Don't treat AI as an omnipotent magic wand—instead, use it like you'd manage a highly capable but direction-needing junior developer.

• Use Git for version management to protect existing progress
• Control context length to keep AI "lucid"