A little about vibe-coding and its challenges

1. First Encounter: Entering Vibe Coding

Not long ago, I accidentally stumbled upon a video where a developer created a whole application using artificial intelligence in just a few minutes. The service was called bolt.new. And, as you might guess, I decided to try this beast myself.

The first impressions were, to be honest, very inspiring. You give a command — you get code. Like in the dreams of a young developer: without meetings, reviews, and evening calls from the project manager. But, as in fairy tales, everything was going well… until a certain point.

When the need arose to change something in the code, problems began. Bolt quickly “eats” tokens, and with finding and fixing bugs, to put it mildly, it has issues. As a result, it is a great tool for a quick MVP, but not for support or scaling. Thus began my vibe coding epic.

2. Plan B: Copilot and Heartache

After the first disappointment, I moved the development to a local computer. Turned on VS Code, connected Copilot — and back to the fight. By default, it works with the GPT-4.1 model. For simple tasks, it writes, comments, helps. Everything looks good.

But when I asked it to do something serious — like analyze several files and work out logic — everything started to fall apart. Errors, inconsistency, a code cocktail of glitches. It became clear: the problem is in the limited context. In "agent" mode, the model can't handle a large amount of data.

I switched to Claude Sonnet 3.7 — and this was better. Hope appeared. Then I found out that there is Sonnet 4 — and that's when the magic really started: the model wrote code, checked linters, and corrected its own mistakes, ran scripts in the terminal… But — yes, you guessed it — the tokens ran out.... And the world turned gray again.

3. Cursor: Second Attempt at Magic

After another fiasco, when the tokens ran out and the soul was empty, I didn't give up. I decided: “Enough of this mockery!” And went to download Cursor. Bought the PRO version and immediately — into the fray.

Cursor, in combination with Sonnet-4 + Max (extends context), worked fine. Not as glossy as Copilot, but effective enough. Started creating an app: one file, another, a third… Everything was going well. Until it became clear — even with Max, the model starts to “forget”: loses context, deletes important parts of the code, forgets the logic of the previous iteration. But for now — a worrying, but not critical signal.

It became critical… the next day. You won't believe it — the tokens ran out again! I used them up in two days on a 10-screen app. It felt like watching my salary just turn into emptiness. But I didn't give up! Bought Cursor Pro+ and continued (salary - goodbye). Because vibe coding — it's like that.

4. Moment of Truth: Architecture or Chaos

When the app began to look like something alive, I decided to conduct a code review myself. And — horror! Each screen was a separate “planet,” no templates, all elements duplicated, as if some mysterious force decided to show me what hell for a UI designer is. Each separate screen, although it was similar to the previous one, wasn't.

Ordinary things — like offsets or margins — had to be corrected manually on each screen. Asking the model to do it automatically was pointless. It corrected in one place and simultaneously broke in another. At this moment, I realized my main mistake: I didn't work out the app's architecture from the very beginning.

In essence, I continued to work as a “senior training a junior model on the fly”: “No! This is a separate component! Here — we'll take out styles! Don't put four components in one file!” (there were files over 1000 lines). And this, of course, knocked me off track a bit.

5. Recommendations: How Not to Drown in Vibe

After all these twists and turns, I decided — I need to share my experience. Here are some tips for those who want to vibe-code but not get bogged down:

• 1. Create a structure. Immediately determine what the folders and files will look like.
• 2. Check styles. After each iteration, monitor consistency.
• 3. Extract components. If something repeats — into a separate file! But specify exactly where.
• 4. One task — one prompt. Otherwise, you'll get a mess.
• 5. Patience is key. Sometimes the model sees a mistake and fixes it itself. Don't rush.
• 6. Commit is your friend. If something works — fix it. The next step can break everything.
• 7. Reset context. Starting a new feature? Create a new chat. And don't forget about git commit!

And most importantly, don't lose control over money. These beasts love to eat tokens like a hungry student — pizza. Before you know it — it's all over. Again.

6. Conclusions: Without Professionals — No Magic

After all that's been experienced, one thing became completely clear: at the moment, without professionals, artificial intelligence is not capable of creating truly high-quality products. Yes, AI significantly speeds up development, performs a lot of routine work, helps "splash out" an MVP in record time. But it all works only on the condition that there is a person nearby who knows what they are doing.

Without proper management, models lose context, repeat themselves, make "random" architectural decisions — and the result resembles code monkeys who might, with some probability, write a book. Therefore, as paradoxical as it may sound, to not write code — you still need to understand it well.

In the future, obviously, we will write less and less code manually. But to truly efficiently use AI, we must learn to think like engineers and manage the process — not just "talk to the bot."

And yes, damn, the tokens ran out again. But now at least you'll know what to do next.