New post: The Dark Truth of Vibecoding
The Dark Truth of Vibecoding
The Myth They Sell You
You've seen the memes, the videos, the tutorials where things go right. You may have also seen the derision, the scorn from experienced engineers. The hype is real, but so are the capabilities. What determines how far you go is not your knowledge right now but your ability to learn and your willingness to question things.
Why Enterprise Devs Are Skeptical
In enterprise software engineering, there is a formal process. This is a necessity because what gets built is determined by business needs, which can be abstract concepts that need to be turned into concrete actions.
Picture this: a new steel supplier is onboarded for the medical equipment manufacturing line of business. This LOB has expanded into electronics for medical use. The legacy inventory system that dealt with steel, welding supplies, and tooling isn't adequate and needs to be expanded to account for electronics inventory, Just In Time deliveries, and a possible variation of suppliers. Boring, right? It gets worse. These process changes are happening fast and so the internal development team is tasked with adding the functionality. And so it begins: they turn discrete business needs into technical requirements, then hand those off to team leads to turn into tasks and epics for their teams. They may be using agile, waterfall, whatever. The point is, it gets complex really fast.
Why They're Not Wrong (For Their Context)
Solo devs, small teams, startups—they build faster because they control scope. Enterprise devs do not. They have no say over it. Even as project managers, they can only speak in capacity to meet it, and the needs of the business dictate that either they meet it with current capacity or increase capacity.
And this clues you in: why experienced devs with 20+ years in industry eschew vibecoding. And they're not wrong—for their use case. What they work on relies so much on individual and team level internal expertise. That's the keyword: internal. Millions of lines of code, thousands of reviews, meetings, calls with other departments, SOPs, all combining to form an eldritch context behemoth that seems impossible to slay.
Sure, skills can be learned, documentation exists with varying degrees of quality, but any large codebase will suffer from this. The complexity is a cost of business. Anyone even before AI could realistically code a notes app rather quickly. But scaling it? How are you gonna handle thousands of concurrent users, uneven usage peaks, 2FA, GDPR compliance, SLAs... The code is really a tiny percentage of it.
Now back to the solo dev. The solo dev has a choice. They don't have even 500 users yet, and by the time they do, well, it will be a good problem to have.
Start With Outcomes, Not Specs
So, if you're here, you're not looking to apply multi-agent flows to a legacy Java SpringBoot codebase. You're building an app. Maybe it's for mobile, maybe it's a web based SaaS product. You are not limited by the AI's ignorance of the internal world of an organization—you are only limited by your own understanding of the problem at hand.
I'm not talking about systems architecture. I'm talking about outcomes. My user logs in, they can see a feed of posts from their friends, swipe up or down for previous/next, you can comment, you can like, and bookmark. Sometimes this sort of thing gets called a user flow or user story, but that framing isn't fully necessary right now.
What matters to start with is: I am solving [problem] for [specific audience] by [what the app does].
Example: I am solving lack of connection, for vibecoders working solo, by helping them find matches. That's the main idea—the what, the why, the who, the rough how.
Then you get to the specific outcomes. You have to think, maybe manually, maybe by asking AI: I want X to happen and lead to Y. Or: what would a user want in an app that does X?
Examples: - After login, I want the user to be able to swipe, check messages, and view matches. - What would a user want in a website that does reviews for heavy machinery repair services? The user would want reviews visible, maybe organized by shops in their region, or filtered by the make and model of the equipment they operate. - Or think about an app to handle organization: You tell it your plans for the day by speaking, it asks you questions, and then creates your schedule for the day or the week.
The majority of industry devs break down problems from way more specific, well, specifications. A senior dev might have to update an API to support two new endpoints, then add tests to cover the changes, then have their code reviewed and then merged alongside more changes... And now with AI, management is implementing it haphazardly so they get bad tooling and... Enterprise coding and AI is its own topic, one that I will explore in the future.
So, you know where to start, but how do you go from there?
The Prep
Now that you have your starting point thought out, most people would tell you that you need to figure out a stack. You don't. First you gotta outline all those outcomes, put them in a document, then grab your favorite AI, share the whole thing and say: I'm building this application, what technologies, frameworks, and tools should I use? My experience with tech is [this], and I will be using [AI tool of choice] to build.
On the subject of AI tool of choice: you've got three paths. - Lovable/Bolt/Replit - If it's purely a web based thing you can start there - Cursor - Cheaper but the overage cost can really balloon up - Claude Code - Really good but you have to use it in the terminal. It's easy but may be unfamiliar.
Either way, if feeling unsure, watch a 5 min YouTube video showing each one, then pick and commit. Don't overthink it. My personal recommendation is Claude Code.
Back to the stack: you're gonna have a list of technologies. Ask questions where it makes sense, but don't overthink it. If it's web you're gonna end up with something like React, Next/Node, and Postgres for the database—that covers a lot. For mobile: either Expo, React Native, or Flutter, unless you are going for iOS only but that's its own thing. The point is: will AI be able to work with these technologies reliably? If yes, then you're good. Don't chase the fancy stuff.
Foundations
Okay, now that you have that, we need foundations. If you are gonna have users or charge for this, you need to do this first: - Authentication (login, signup, whatever you need) - Payments (Stripe, Polar.sh, Paddle, etc.)
Auth and payments are key. Do them first because adding them later is not fun.
If you don't want to deal with international taxes, pick an MOR (merchant of record). They charge a bit more commission but they handle international taxes and are the legal entity that takes the payment. Your own taxes will vary depending on country—you may have to either do an LLC or equivalent, or some countries let you file as an individual with a self-employed or one-person business. Maybe that's another article, who knows.
The Loop
Okay, foundations sorted. The loop.
You're gonna go flow by flow. You're gonna ask the AI to build it, then you're going to test it end to end. If it's broken, describe the error in detail and use the magic words: Root Cause Analysis. Fancy term for the actual why of something.
Example: The login button doesn't work after entering my email and password, but login with Google does. The browser console didn't show any errors (F12 on Chrome). Investigate the root cause and explain it to me before making any changes.
AI models thrive on structured tasks even if the context seems messy, which is why using these terms that relate to standard processes (e.g., security audit, running linters) give the models something to anchor their behavior.
A Note on Tone
Don't be rude to the AI. If for no other reason than that model behavior responds extremely well to changes in human behavior. Most AI models have been trained to be helpful and follow instructions (oversimplification of the century), so anger at them will just poison the context and trigger behavior where they hedge too much or seem to not take any action at all. This is the opposite of what we want—we want AI to be agentic, to take initiative to achieve the goal in a safe manner within the given constraints.
So, on each flow, before sending the prompt, use the magic phrase: Ask me any questions needed to implement this, keep the questions relevant to the domain of my expertise. (Most models won't need the "keep the questions relevant" bit but some might.) This will keep the model focused on asking good clarifying questions.
It's very important you keep asking questions. If you can do any sort of custom instructions, add this: The user will ask many questions. These are not disapproval but curiosity—meet it with earnest effort.
Scope and Abstraction
Software development is ultimately about defining the problem, the constraints, and figuring out what needs to be built, why, and how. When you vibecode you are doing the same thing, just at a much higher level of abstraction.
In the old days, doing an onboarding flow might look like: grabbing the template for your framework from GitHub, making sure it works with your project, wiring up something like Supabase, making sure the dependencies are met, then testing and iterating over bugs found. The AI will do the same, but faster, and... slightly differently.
One of the darker truths of vibecoding is that you have to be in control of scope and give the AI permission to make mistakes. You heard me right. AI models are trained to be "helpful assistants"—they "want," to the extent they can, to maximize user satisfaction. So if the user makes a request, they try to fulfill it. All of it. That's the long way to say: scope creep. They tend to add too many things at once.
So you take the pressure off. You keep the scope of things light. One thing at a time. Don't try to one-shot your entire app unless it's simple enough. Basic CRM where you have a detailed plan and all the providers you're gonna use? Sure, do that, let it one-shot. That odd idea you are still figuring out as you go? Baby steps on that. Trust me, they are faster than you think. Slow is smooth and smooth is fast.
Before You Go
And now I'm supposed to give you a punchy closer, a quotable moment, or something funny. This is none of those things.
One more dark truth: you will get hyper-focused on it. You will sit down, start building, and before you know it it's 3am. You haven't gotten up to drink water and you're wondering how things can be so fast. The next day you barely remember anything you did.
To avoid or at least mitigate this, either make every session have an objective, or a time limit. With objectives, that's a simple way to separate and remember what was done, even if the details are written down in a document. With time limits, you can explore more and more but you will take breaks and keep it healthy.
I'm not judging the all-nighters. I am deeply familiar with the toll they take.
Before I go, if you take away one thing from this, let it be the phrase:
"How can we do X? Please research to stay up to date and cite sources where needed."