.png)
10 hours ago
1
There’s a weird kind of magic to vibe coding.
You sit down with an idea, open your favorite AI tool, and suddenly you’re deep in a rabbit hole of code you didn’t plan for, solving problems you didn’t anticipate, and adding features you never asked for.
And somehow, it feels like progress.
But vibe coding isn’t software engineering. It’s improvisational jazz with a very confident saxophone player who doesn’t always follow your sheet music. Here’s a survival manual if you, like me, find yourself jamming with your AI co-pilot a little too often.
1. Vibe Coding Is Fast, You Are Human
AI writes code way faster than you can understand its implications. You’ll blink and have 300 lines of code half of which you don’t remember asking for.
Commit often. Use version control religiously. Treat each finished piece as a checkpoint.
Also, test incrementally. You can ask the AI to write test cases but don’t rely on them blindly. That’s like letting a student grade their own exam. You’re better off keeping tight control over functionality checks, one test at a time.
“If you’re still YOLO’ing in a vibe coding session, you’re one mistaken Enter away from tragedy.”
At times you may want to go back and cherry pick things, with git in picture it will be a lot more streamlined then just restore checkpoints options in AI IDE’s.
2. Minimalism is Your Only Defense
AI loves to over-engineer. Left unchecked, it will introduce extra classes, new helper functions, and even third-party libraries you never heard of.
Keep prompts minimal and explicitly constrain output:
- “Don’t use external libraries.”
- “Write clean, modular functions.”
- “Keep it under 50 lines.”
Minimalism makes code easier to validate, test, and roll back.
But minimalism isn’t just about lines of code. It’s also about design choices:
- When building a program, think hard about what is really needed.
- Many attacks happen because there’s something valuable to protect. What if you didn’t store that data in the first place?
- Ask yourself: Do I need this user data? Do I want to store this information? Do I even need usernames or passwords?
“During SBOMPlay’s development, I decided I didn’t want to handle client data at all. So I shifted processing to the client side. With no sensitive data to protect, I could release the tool freely.”
Avoid unnecessary complexity. Build login systems only when you truly need them. Most early-stage tools don’t. And when you truly do you’re probably past vibe coding territory and into AI-assisted engineering.
3. Make Small, Boring Requests
Avoid sweeping requests like “rewrite the whole service.” Instead:
- Ask it to summarize what’s currently there.
- Confirm that the summary is correct.
- Make one change at a time.
- Confirm again.
If you find a bug, don’t list 5 things to fix. Fix one. Test it. Then fix the next.
AI is not your senior developer. It’s a very enthusiastic intern with bad memory and no sleep.
4. Readme-First Thinking
Before you even start coding, use an AI (LLM/SLM) like ChatGPT or Claude to brainstorm your idea. Then ask it to write a proper README.md for the project - like you’d put it on GitHub.
Manually review this README. Clean it up. Clarify fuzzy spots.
This document becomes your source of truth.
When you move to an auto-coding tool (like Cursor or simmilar), feed it the README first and remind it to refer back to it often.
“A README is not documentation. It’s a contract between your brain and the hallucination engine.”
Also: regenerate the README or a summary whenever you reach a milestone. Treat it as a checkpoint. Pause. Reflect. Ask yourself, Is this still the project I meant to build?
If not, you now have the clarity to pivot.
5. Define Non-Negotiables (Especially Security)
You must tell the AI what not to do.
In your README or first prompt, define your red lines:
- No logging of credentials
- Use parameterized SQL queries
- Validate user input
AI optimizes for “works,” not “safe.” Without rules, you’ll get happy-path code with serious blind spots.
Be paranoid. It helps.
6. Context Is a Luxury, Not a Guarantee
LLMs have a memory - and it’s terrible.
Even with 100k context windows, the models forget, distort, and skip. Never assume your AI remembers what you said 20 prompts ago.
Treat each session as a new dev joining the team. Always:
- Feed the README and related files
- Ask it to summarise the understanding
- Clarify what you want done in this thread
After a big discussion or a feature creation hit reset, create a fresh chat. make a good context and then work on specific feature.
7. Don’t Fear a Reset
If the codebase starts to rot - unexpected bugs, features you didn’t ask for, confusion piling up - don’t force it back on track manually.
Start a fresh session.
- Feed in the original README or summary.
- Say: “Extract features A, B, C only. Ignore the rest.”
Let the old mess inform the new build - but don’t drag it all forward.
8. End-to-End Testing Is Boring. Do It Anyway.
Every new feature has a non-zero chance of breaking old features. And AI loves breaking things silently.
Keep testing end-to-end. No shortcuts. No vibes. Just slow, boring sanity.
And yes, you’ll have to do it repeatedly.
Final Thought: AI Is a Multiplier
Here’s the most honest thing I can say:
“AI is a multiplier. If you’re a +1 programmer, it can make you a +10. But if you’re at -1, you’re just amplifying bad decisions at scale.”
AI doesn’t make you better. It makes you more. More productive, more chaotic, more dangerous, more brilliant - depending entirely on how you use it.
Use it wisely. Use it deliberately. And keep version control open.
<selfpromotion>
</selfpromotion>
