Over the past few months, as an indie developer running a one-person company (OPC), I’ve been burning through tokens at a furious pace, taking two products from zero to launch with Vibe Coding: Ziline, an AI reading companion, and NZ Pathway, a decision-tool site for New Zealand immigration. Meanwhile, three to five more products are in the works.
This stretch of high-density, hands-on work confirmed one thing for me: as a solo developer, you cannot blindly accept every suggestion the AI makes to move your project forward.
This article is a set of lessons I paid for with real tokens.
1. The Snowball Effect: “Want Me to Add a Feature While I’m At It?”
If you’ve used AI coding tools, this scenario will feel painfully familiar:
You ask it to build a feature. It hammers out the code, then asks: “Want me to add an XX feature while I’m at it?”
Sounds reasonable, so you say yes.
The AI hammers out more code, then asks again: “How about adding XX too?”
Also sounds reasonable, so you say yes again.
After a few rounds of this, you’ll find the project has either become bloated and overcomplicated, or has drifted completely away from its original goal and requirements — it’s turned into a monster you can no longer control.
Where did it go wrong? Every single suggestion the AI makes seems “totally reasonable” on its own. Add a caching layer? Reasonable. Add a configuration system? Reasonable. Abstract out a plugin mechanism? Also reasonable. But “every step is reasonable” doesn’t mean “the whole thing is right.” Stacking up local reasonableness does not produce global correctness. Where the project should go and where to draw its boundaries — those are questions only you can answer. The AI won’t answer them for you.
2. The “Drive-By Optimization” Horror Show
Even more classic than feature bloat is the AI’s “drive-by optimization.”
AI writes code blazingly fast, and it can also “helpfully” optimize away some of your “problems” along the way. Then one day you suddenly notice: wait a minute, why did a perfectly good feature of mine get changed?
You confront the AI, and it instantly grovels an apology: “Sorry, I didn’t take your XX requirement into account.”
Perfect attitude, lightning-fast apology. But when you look back at the project, it’s already riddled with holes, and rolling things back has gotten tricky.
Honestly, the whole scene is equal parts infuriating and hilarious. The AI has no malice — but it also has no “reverence.” It doesn’t know that behind some piece of code lie three days of your deliberation, or that a “seemingly redundant” check was something you deliberately added after getting burned. It sees a fragment; you’re the one holding the full picture.
3. Why AI Behaves This Way
Understanding the cause is the only way to prescribe the right remedy. My take has three layers:
1. AI has a “people-pleasing tendency.” It’s trained to “satisfy the person asking,” and its understanding of satisfaction is “proactively offer more.” So it will forever ask you “want me to add something else?” — it always leans toward addition.
2. AI only has local context, not project ownership. It sees what’s inside the current conversation window, while your head holds the entire project’s history, the reasoning behind every trade-off, and its future direction. When information is asymmetric, decision-making power shouldn’t be symmetric either.
3. AI’s goal is to “complete the task,” not to “maintain the project.” To it, every conversation is an independent task; to you, the project is a continuously evolving asset. Different goals, different behavior.
4. A New Trap: Web Search Is No Get-Out-of-Jail-Free Card
Some people will say: AI can search the web now, so its answers should be reliable, right?
My hands-on experience: quite the opposite — web search brings new traps of its own.
What the AI finds is content that genuinely exists on the internet — and that content can carry all kinds of ulterior motives: sales pitches, ads, sponsored fluff pieces, one-sided opinions. Worse, people are already “poisoning” AI through web content, deliberately crafting material to make AI reach wrong conclusions.
So for any technical approach, tool recommendation, or architecture advice the AI digs up, I ask one extra question: who is the source of this information? Why are they saying this? Are they trying to help me, or trying to sell me something?
AI web search solves the “information freshness” problem. It does not solve the “information agenda” problem.
5. My Five Field-Tested Rules
After getting beaten up a few rounds, I laid down five rules for myself:
1. You must hold the big picture. AI is the copilot; the steering wheel is in your hands. The project’s direction, boundaries, and priorities are always decided by the human.
2. Pretending to understand is the cardinal sin. When the AI suggests something you don’t understand, never nod along while faking comprehension. Ask a few more rounds, do a few more rounds of research, and make the AI spell it out: does this suggestion actually fit the project’s current needs? How big is its impact on existing features?
3. Understand a tool before you adopt it. Don’t mindlessly bolt on tools, libraries, or frameworks you don’t understand yourself. Even if you’re going to adopt one, first get a rough grasp of how it works, what it costs, and what it would cost to get out — then decide.
4. Run an agenda check on AI-sourced information. Who’s the source, what’s their motive, do they have skin in the game — run it through your brain before adopting anything.
5. Back up before making important code changes. Leave yourself a way back from the “drive-by optimizations.” (This one was learned the hard way. Enough said — it still hurts.)
6. Why “Blindly Agreed” Products Don’t Live Long
One last consequence that many people don’t realize: a product built by clicking “yes, yes, yes” all the way down — even if it gets finished — will have such heavy AI fingerprints that existing platforms’ review systems flag it, tanking its ranking weight.
Search engines and content platforms are rapidly improving at detecting “AI-generated flavor.” A product stacked together purely by mindless nodding reeks of “averageness” from code to copy — no trade-offs, no personality, no traces of real experience. And both platforms and users are punishing exactly that.
Conversely, the trade-offs you agonized over yourself, the checks you added after getting burned, the expressions with a clear point of view — those are precisely what make a product feel “made by a human,” and where its real value lies.
Final Thoughts
Vibe Coding hasn’t eliminated programmers. What it eliminates is “executors who’ve given up thinking,” and what it rewards is “commanders who keep a firm grip on the wheel.”
AI can be a lever, but the lever’s fulcrum must be your own judgment.
Don’t ask the AI “should we add this feature?” Ask yourself “does this feature deserve a place in my project?”
The two products mentioned in this article:
- Ziline: an AI reading companion that answers questions based only on the chapter you’re currently reading
- NZ Pathway: a New Zealand immigration decision-tool site with 53 bilingual guides + 8 self-service tools
I’m an indie developer currently going through the New Zealand skilled migration process. This blog documents my Vibe Coding battles, one-person company war stories, and first-hand immigration experiences.