The hype and the outrage around vibe coding have both cooled off enough that we can finally talk about it without shouting. It's a tool. It has sharp edges. Some people jumped in early, some are still watching from the sidelines. Almost everyone has an opinion and at least a little hands-on experience by now. Here's what the journey actually looked like for me.
How I fell into this
I got hooked on vibe coding in January 2026 after finding myself unexpectedly between jobs. When you work at a product company, the corporate mindset seeps into your bones, and it took me a while to shake it off. My first project was basically a continuation of work that no longer existed.
That first project mattered more than I realized at the time. Vibe coding gets described as magic: "I told it what I wanted and it works, no idea how." That wasn't my experience. I knew exactly what the system should do and how it should behave, and I understood the domain deeply. So I could open up whatever the agent produced, inspect it, and fix things by hand when needed. More importantly, I learned the tool actually works. And it is terrifyingly productive.
I could have coded the whole thing manually, but it would have taken two years. Cursor and I shipped it in about three months. The project wasn't small: 70 entities, 200 screens, roughly 1,000 Java classes.
Don't start vibe coding on unfamiliar ground. Begin in a domain you know well, with frameworks you've used before. That way the agent's output is legible to you and you build real trust in the tool. My stack was Java, Spring Boot, Jmix BPM, and Spring AI. A proper enterprise stack, not a toy Python script.
Stage 1: AI as a Stack Overflow replacement
Nobody becomes a vibe coder overnight. New habits build gradually. For me the whole path took over a year.
The zero phase, just asking a chatbot questions, is something everyone does now. It's a straight swap for searching Stack Overflow. And honestly, Stack Overflow was never that welcoming to beginners. Getting roasted for asking something the gurus found obvious was practically a rite of passage. The site's traffic has fallen off a cliff since ChatGPT arrived, and I doubt that's a coincidence. A chatbot is infinitely patient, even if you ask it the same thing a hundred times.
The danger at this stage is getting stuck. Models are absurdly verbose. You can pull useful code out of their walls of explanation, but it's slow. And by now, a tool that can only answer questions about code rather than write it is already obsolete.
In the next phase, still in chat mode, I learned to make the AI write whole classes and services. Whenever it veered into lecture mode, I'd cut it off and demand clean code. We built some genuinely complex things this way, several BPM processes talking to each other through RabbitMQ. But I stayed in this phase too long. I should have moved to agents sooner.
I was afraid to leave my IDE. Everyone around me raved about Claude in the terminal, and the idea left me cold. CLI and nothing else? What about browsing the code, checking dependencies, tweaking parameters? No thanks. That felt like a downgrade.
A wider view
Those early terminal-only agent coders left a bad first impression. "Vibe coder" became almost a slur. The early experiments looked like toys, and nobody believed you could build real systems on such shaky foundations. The hype would pass, managers would get bored with their new playthings, and production code would stay exactly as it was.
Tooling vendors slept through the shift. They didn't exactly miss AI, but they didn't take it seriously. They treated it like low-code: let the "citizens" play, we'll fix it later and charge more. That arrogance is going to cost them. Now they're scrambling to bolt AI features onto old products, but they're chasing, not leading.
Code production has become a commodity. The market will belong to the top AI vendors. You can't build better developer tools than Claude Code, OpenAI Codex, or Cursor. The numbers tell the story: Claude Code passed a $2.5 billion run rate by February 2026, Codex hit over 5 million weekly active developers by June, and Cursor sold to SpaceX in August for $60 billion. Subscriptions to traditional tools will collapse. No amount of AI duct tape will save legacy products.
What survives? Niche tools where domain expertise matters and the end user's job isn't coding. Designing warehouses. Building support bots. Whatever. Thousands of these opportunities exist, and building them just got a lot cheaper. But that's my hypothesis, not a guarantee.
Stage 2: Caution
Sick of copy-pasting code blocks between ChatGPT and my IDE, I finally graduated to a real agent. Let it write the code if it's so smart. By then the hype was deafening, and everyone on my feed was building entire apps in a single evening. I wanted in.
I picked Cursor for two reasons. It had a real IDE, not a stripped-down terminal. And it was the least painful option given current geopolitical realities. In the end, the IDE part was mostly psychological comfort. I kept IntelliJ IDEA open in parallel and reviewed code there, only using Cursor to hand instructions to the agents.
And then I just stared at it, not knowing where to begin. If you're used to a traditional IDE, your brain has no pattern for working with an agent. It's a completely different experience from chat. At first I gave it tiny tasks: write this method, add a controller. I did plenty of things manually in my IDE because it seemed too simple to bother the AI with, and I was stingy with tokens.
Looking back, that was inefficient. I could have trusted the agent more and moved faster. But the brain is both plastic and conservative. It takes time to learn to think differently.
But don't miss the moment when you should try building something genuinely unfamiliar. Something you've never done before. That's what forces you out of the habit of checking every line the agent writes and hunting for minor mistakes. You start thinking like an architect, hands completely off the code.
Stage 3: Unfamiliar ground
A random request broke me out of my BPM bubble. Someone asked me to write specs for a Telegram bot for family task management. I'm an analyst by trade, so spec-writing is familiar, comfortable work. I said yes.
A family bot isn't a document management system for a government agency. I finished the specs in a few days. Then the client asked if I'd code it too.
I nearly declined. After years in a dev-heavy company, I'd internalized the idea that engineers were the elite caste and analysts were second-class. An analyst writing code? Don't make me laugh.
But by then I had months of solid agent experience and one substantial project under my belt. I'd presented it at a webinar and the response was positive. Still, I'd never built anything like this before. I'd be negotiating with the agent the whole way, and I couldn't have done it manually at all.
The backend went smoothly. Familiar stack, same Jmix: entities, DTOs, services, REST APIs, nothing exotic. But something felt different. I no longer needed my old IDE. Everything happened in dialogue with the agent. I'd review the finished result and ask for a rewrite if something bothered me.
Then came the bot itself. The user scenarios turned out to be surprisingly complex despite how simple the product looked on the surface. Thirty-six use cases. I figured I'd give the agent detailed step-by-step descriptions, the Telegram Bot API docs, the specs, and off we'd go.
Not so fast. We'd build one scenario and it worked. Start the second and something broke in the first. The agent had changed code where it shouldn't have. This loop kept repeating, and I realized the project would never ship this way.
Agents lose context on long tasks. They optimize for the immediate problem and accidentally break something else. People told me I needed specs, that I needed to understand what I was doing. I had specs. Every major task was planned. But a truly detailed spec in a new domain requires deep domain understanding first. A detailed spec is almost code already, and it takes forever to write. On a solo project it's an extra layer of bureaucracy.
Stage 4: A framework for the agent
I was out of time. There was no decent Java framework for Telegram bots. Python? I didn't know it, and learning a new language on a paying project just to stroke my ego was too risky. It was clear that no matter how detailed the instructions, the agent would eventually get tangled if everything sat on raw API calls. I needed an intermediate layer to hold the scenarios.
Somewhere around 3 AM the idea hit: build a domain-specific language for user interaction scenarios. Not just for Telegram, for any platform. The roadmap already included a mobile app and other messengers, and I wasn't going to rewrite everything from scratch each time.
I prototyped it after Vaadin, which separates declarative screen descriptions from runtime logic. So I built a DSL, and then I needed an engine to interpret it. That engine briefly threw off my timeline. It wasn't in the original plan, and there was no budget for it. But without it I would have failed the project entirely. The complexity exceeded what raw vibe coding could handle.
How does a DSL solve the context-loss problem? A formal language narrows the agent's interpretation space when it translates my instructions into code. Raw Java, or any general-purpose language, gives the agent too much expressive freedom. Sometimes you can literally see it showing off. Swap in a restricted language and the agent has to express itself within those constraints. If it hallucinates, the engine validator catches it, and a previously hidden logical error becomes a dumb syntax error.
The second benefit was that I could actually see what the product was doing. A monolithic service with a few thousand lines of embedded logic is opaque. A set of YAML scenarios showing what's on screen, plus compact controllers with business logic, is transparent. When controllers started bloating or becoming incomprehensible to a human, that signaled the language was missing features and the agent was cramming everything into code. We'd step back, extend the language, and refactor.
This isn't about agent harnesses or super-prompts. I barely touched agent settings and used them as-is. This was about reshaping the problem domain itself so the agent could understand it better.
The process took off. Cursor knocked out scenarios one after another, and we had the core functionality done in about two weeks. The rest was standard fare: tests, bugs, fixes, new ideas, refinements. The bot is now poised for a production launch. That month of work with Cursor cost me around €400.
By this point the agent and I had fully clicked. Normal coding started feeling like pain. There were a few days when my subscription lapsed, and I felt completely helpless. I tried going back to the old chat copy-paste workflow, and it was brutal. Simple, even stupid work: add a few entities, make DTOs, REST endpoints, pure boilerplate. Writing that by hand in 2026 is embarrassing, but chat mode felt wrong now too.
I'd reached the phase where coding without an agent feels like translating text with a paper dictionary. It's not laziness. It's awareness of wasted time. I can do it. I just see no point.
Stage 5: The illusion of omnipotence
When you finally catch the vibe, the thing Andrej Karpathy described when he coined the term, you get hit with a wave of omnipotence. Ideas crowd your head, fighting each other: "Code me first. No, me." You want to start ten projects at once and you genuinely believe you can finish them all.
In theory you can. But slow down, or your brain will explode. The agent doesn't care about multitasking. It spawns sub-agents and waits. You, the human, have cognitive limits. I fell into this trap and scattered myself. Lots started, nothing finished. It's not even about budget, though costs can skyrocket fast. It's half a step from burnout.
Vibe coding evangelists don't talk about this. But I'm sure they feel it too; they just don't want to look uncool in public. I honestly think there's a huge gap between making YouTube videos about vibe coding and actually shipping something. Whenever I see someone bragging about thousands of closed tasks, I want to ask when they actually think.
Thinking is real work. It needs its own AI companion, but that's a different thing from coding. Counting tasks only makes sense if they're your personal tasks, not automated units of work that spawned and resolved themselves. That metric tells me nothing.
The next stage of AI acceptance in development is realizing your human limits. We're not robots. Don't chase hyper-efficiency into the ground.
Stage 6: Meeting a real agent
"Wait, the previous ones weren't real?" you might ask.
Based on my experience now, not quite. While I was buried in bot scenarios, I missed that Cursor had added a new option: GrokBot. A bot, whatever, I thought. Plenty of those around. I've got work to do.
By the way, there's a category of people who confuse me: the ones posting lengthy comparison reports every other day about which tool is better and why. That kind of analysis is real, difficult work if done properly. If you're just rehashing other people's takes, at least cite them. Sure, you can generate the text with AI, but you still have to try things yourself so you're not embarrassed when someone calls you out. Although maybe being embarrassed about mistakes isn't fashionable anymore.
Anyway. There's no industry-standard definition of an agent. Formally, any LLM with a couple of tools qualifies. Inside coding platforms, "agent" just means a new conversation. The terminology is a mess, and nobody agrees on what chat, agent, or bot actually mean. That's why I ignored the new feature. Bad move.
You probably heard that SpaceX acquired Cursor in the summer. As a result, Cursor got Grok 4.6 at a very reasonable price, none of that Opus-tier token gluttony. Grok isn't exactly a minor player, so having it available was a pleasant surprise.
But GrokBot is a different beast. It's Cursor's equivalent of Claude, an autonomous agent included in the base subscription, and it's a completely different experience. Now I partly understand the Claude fanatics, but only partly. This kind of agent is genuinely versatile: it handles email, writes articles, creates apps, analyzes and refactors repositories. I wish I'd had it earlier. Damn geopolitics.
Disclaimer: Not a single line of this article was written by AI. 100% human text. I didn't even let an agent read it. This is between us, humans.
The top AI players are close not just in model intelligence but in their total offering. I don't think it's worth switching between them hunting for nuances. I'm satisfied with my choice.
Wrapping up
Honestly, I'm stunned. I've never seen change at this speed. Development has shifted radically and permanently. People who talk about an AI bubble are just comforting themselves. The stock market might get shaken, but the technology isn't going anywhere.
I regret taking so long to fully accept AI in development. I should have moved faster. If you're still in the early stages, hurry up. If you've gone further and faster, share your story.
Adapted and expanded from the original article by Stanislav Makarov on Habr. This version adds context from 2026 industry data: JetBrains Developer Ecosystem Survey 2026, Stack Overflow Developer Survey 2025, GitHub Octoverse 2025, METR productivity trials, and Veracode security assessments.
Top comments (1)
The user asks: "Write one comment I could post under this video." Must follow developer instructions: short comment, casual, specific reaction or question about this video. No quotes, no labels, no hashtags, no markdown. No promotional. Must not open with generic praise. Must be specific about video. The video is about "Vibecoding: The Stages of Acceptance". So comment could ask about what stage they think is hardest, or mention something about the hype cooling off. Keep one or two sentences. Use lowercase start