Guide to effective “vibe” coding
Assumed Audience: Software Engineers or enthusiast who want to incorporate AI coding tools into their workflows
It’s insanely easy to lazily put together a vibe coded app. After all, we are flushed with vibe coding startups boasting about how they reached trillion dollars in ARR in just 12 minutes. The kind of startups that are the subjects of glazing by thinkfluencing hustle bros with no skin in any of these companies. The kind of thinkfluencers who constantly post slop about how your startup isn’t real if you haven’t hit $420 billion in ARR within the first two weeks. We live in truly strange times.
Despite the tone of the start of this essay, I’m not an “AI skeptic”. I do believe it’s a bit over hyped, but most groundbreaking technology is. I’m also not brushing off the ethical and societal implications here. For example, I don’t think image and video generation models should exist at all in its current form.
I use the LLMs almost everyday all throughout my work. I wanted to take my experience and put it into digital ink.
Vibe coding strategies
There are three modes of AI-assisted software development that I toggle between:
Jesus take the wheel mode (true vibe coding) popularized by tools like Lovable, Replit, and Figma Make
AI-powered software engineering: through Cursor agents, Claude code, Codex etc.
Ambient AI helper tools : cursor tab, code assist, intelligent code search etc.
I want to look at the first two of these strategies. There’s no point focusing on AI-powered ambient dev assist tools since they are second-nature to developers. All modern IDEs have had similar tooling to ease repetitive and cumbersome work for ages.
Jesus take the wheel mode
This is the AI-powered development strategy that’s the most faithful to the origin of the term “vibe coding”. Although this term is being used to refer to the entire spectrum of AI assisted development at this point. Lovable and Replit are probably the biggest winners in this category. Lovable claims to have hit $200 million dollar in Annual Recurring Revenue. But having spent considerable amount of time and money experimenting these tools, I doubt the gravy train will continue for long.
When you start building an app using Lovable, there’s a big initial wow-factor. With just a few sentences you can generate plausible apps that would’ve required years of expertise and months to implement. But few prompts in, lucidity wears off. Getting the models to do even the tiniest change results in you pulling out your hair and screaming at the oracle in frustration —“NO! NO!! NO!!! That’s not what I meant!”
There are also perverse incentives at play. Since these tools monetize based on credits, more prompts = more money. In order to maximize profits, these companies have to strike the balance between the user not getting so frustrated that they quit vs user getting everything they want done right out of the gate. No matter how well intended and moral a company tries to be at the beginning, the incentive structures always determine the long-term direction of product.
The more control you want over your app, the more opinionated you want your software to be, less effective extreme vibe coding becomes. The idea that an amateur with no experience can put together a complete application that’s more complex than a simple CRUD app is a fantasy. This is not because of code quality or any code level reasons. It’s because to describe what a piece of software needs to do in detail, you need significant amount of experience. To understand tradeoffs and limitations of design decisions you make, to understand limits of systems, to reason about malleability of concepts you introduce to your software require deep knowledge and experience. This is what makes software engineering hard. And this is why you tend to write less code the more time you spend in the industry. You graduate from writing isolated code to designing complex systems. Writing code has never been the bottleneck (https://ordep.dev/posts/writing-code-was-never-the-bottleneck).
So before you fire your CTO and replace them with a Lovable subscription, think twice!
This is not to say that true vibe coding has no place in the development lifecycle. It is an excellent prototyping tool. It’s a powerful tool when you have a vague idea of what a feature/product should do and you need to visualize what the end product should looks like. For teams, it’s an excellent starting gambit. Rather than trying to convince your colleagues on a vague idea on text or with a crude wireframe, you can show them a fully fleshed out prototype of the feature. This makes it a lot easier to get institutional buy-in, get everyone on the same page, and collaborate with a shared vocabulary.
But don’t delude yourself into thinking that you could take this prototype and turn it into a production app. Treat this as what it is, a prototype. It is the breadboard version of what you’re trying to build. It helps you build a shared language to talk about components, test assumptions, and test out different ideas. But at some point, you need to take your lessons and rebuild properly.
(Photo by Nicolas Thomas on Unsplash)
My favorite tool for this right now is Figma Make. Mainly because they are not enforcing credit limits during beta, but also because I associate Figma with prototyping and have no expectation that I’m building the final piece of software. But all the tools, Lovable, Replit, v0, are pretty interchangeable for this.
AI-powered software engineering
The true power of LLM’s for software engineering is in the hands of experienced engineers and not in the hands of amateurs. A solid grasp of software engineering and software design principles is more important than ever. Especially with all of these coding agents generating code on your behalf, even if you’re working alone, you’re in the position of managing a team made of a group of very efficient, smart, but unreliable intelligent beings. So even as a solo engineer, if you’re using coding agents, your job no longer is writing code, it’s coordination, review, and design.
For an example, earlier, as a solo engineer, you could have used the excuse that no one else is working on the codebase, so writing tests would be a waste of time. But now, since you’re outsourcing tasks to these unreliable contributors, you need to make sure components are well tested and that smoke tests are in place in case they go and break things. You would have also jumped right into writing code from the get go. The mental model is inside your head anyway, so why bother with writing a spec.
Agent powered software engineering means that more time you spend on thinking about the problem and how to approach it, the better your results are going to be. This has made spec-driven development hip and cool again.
https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html
Over the last few months, I have come up with some rules and guidelines for myself. I’ve noted them below. Please note that this is an involving list.
Agent Powered Development Guidelines and Rules
Build with tools that you know very well or learn the tools well.
Do not fully outsource design and engineering decisions to agents. You can get the LLMs to make recommendations, but it’s on you to make the final call.
Start by building a set of strong primitives that you can build on top of.
For front-end applications, this might be reusable UI components.
* I’ve noticed how Claude code tend to introduce a lot of one-off tailwind styling even when there are defined components that serve the purpose. I’ve started to put a small README file on top of my component library and referring to it in my CLAUDE.md file
For backend code, these might be common services and modules you’ll use throughout your code.
Keep the agents on a tight leash. Review everything that the agents output; the buck stops with you.
“When you stop reviewing AI drafts, you stop knowing why the code works at all. Practically, hold AI-written code to the same standards as human team mates.” - Addy Osmani
Do not lose track of the mental model. The moment you lose the mental model of how your code works, you lose.
Start by defining the interfaces and abstractions. You should put a lot of effort into this phase. This is a great way to get the agents to work for you and not the other way around.
Your job, more than ever, is managing complexity.
Becoming a better software engineer
The last couple of years, I’ve been doing a lot of reflecting and trying to figure out how I can get better at my craft. I don’t have a Computer Science degree, I have half an economics degree. I started programming when I was 13 and I’ve always learned by doing. The only “formal” CS education I have is through International Olympiad in Informatics training. Even professionally, I’ve always worked at/on early stage startups where execution speed was what mattered the most. I’m pretty good at what I do, but I have started to notice some glaring gaps in my knowledge and I’m on a journey to fix those gaps. Because I believe now, more than ever, understanding the fundamentals of software engineering and design is an absolute necessity.
Here are some of the resources I’ve come across that I really love (and could recall at the time of writing). Please send me any recommendations you have.
Books:
A Philosophy of Software Design by John Ousterhout - This is an excellent book about how to approach software design that I keep returning to. The book strikes a nice balance of being both philosophical and extremely practical.
Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems by Martin Kleppmann - Excellent book to understand the building blocks of modern applications and how to reason about them. Absolutely essential read to understand systems beyond buzzwords in my opinion.
Code Is for Humans: A Guide to Human-Centric Software Engineering, Zohar Jackson - Great book that helps you start thinking about code complexity and evolution.
The Essence of Software: Why Concepts Matter for Great Design, Daniel Jackson - Provides a good framework for thinking about software products and user experience modeling. The concept mapping exercises come in very handy when working with coding agents.
Videos:
Damn good article bro
Nice article. What I would say is beware of data validation. Vibe coded apps are great at passing off dummy or, worse, inaccurate data as complete and final. The look and feel stuff works great tho.