You’ve Been Vibe Coding Wrong.
A nuanced perspective on the latest trend in software engineering.
This post will be a slight departure from my typical content, but I think it’s an especially important and topical subject to cover. So-called “vibe coding”1—developing a product almost entirely with AI, with little to no hands-on developing—has been absolutely exploding in popularity as of late, and has led to the emergence of multiple billion-dollar startups that allow users to generate software from just a few sentences. It's clear that venture capitalists (and non-technical founders) are confident that this is the direction in which product development is heading. But is this really a lasting trend? Is vibe coding the death of software engineering?
In this article, I’d like to bring in a little bit of nuance to this hype train. While I do strongly believe in the value of using AI-enabled tools to accelerate the development process, I likewise hold the opinion that claims like “software engineering is dead” or that AI can completely automate the process of building a product are ill-informed. As a product engineer, founder, and AI researcher, I feel that I can contribute a unique perspective to this discussion; I hope I can leave you with a grounded, rational view of both the merits and shortcomings of “vibe coding” in today’s software engineering and startup landscapes.
Where (and Why) Vibe Coding Shines
There are an abundance of AI-enabled tools that enable you to build software with just natural language—Lovable, Bolt, v0, etc—that take advantage of the “intelligence” of large language models. These tools represent a genuine breakthrough in lowering the barrier to entry for software creation, making the process more accessible to non-technical founders and streamlining development workflows for experienced engineers alike.
Indeed, as a result of all the code they’ve ingested during training, today’s LLMs can produce full-fledged projects with little to no human intervention. This capability feels like magic, but in fact emerges from specific architectural and training advantages that make LLMs particularly well-suited for certain coding challenges.
I go into detail regarding the technical details of LLMs in previous articles, but to summarize, LLMs’ incredible strength in coding stems from their training on billions of lines of code across diverse repositories. This exposure has equipped them with an extensive knowledge base of programming patterns and solutions. In turn, LLMs can effectively recognize and reproduce common implementation patterns that appear repeatedly across codebases.
These capabilities explain why vibe coding particularly shines in scenarios involving standard components, rapid prototyping, and lowering the technical barrier to entry: the models excel precisely where creativity and innovation aren't the primary bottlenecks, but rather where speed, implementation of established patterns, and accessibility to non-technical users deliver the greatest value.
Where (and Why) Vibe Coding Falls Short
It’s important to note that in the contexts where vibe coding shines, LLMs function less as inventors and more as accelerators, automating the translation of known solutions or implementations into working code. They aren't actually creating anything genuinely innovative, but simply transforming and manipulating its training data to follow instructions to the best of its ability. (For more on the philosophical arguments surrounding this argument, check out my article regarding “stochastic parrots.”)
LLMs are notoriously ill-equipped for abstract reasoning, exhibiting genuine creativity, and overall developing novel ideas. Hence, once your product starts to become genuinely novel and unique—beyond just a run-of-the-mill B2B SaaS or GPT wrapper—these tools show their weaknesses.
Some might argue that these limitations are temporary—that future models will eventually overcome these barriers through more sophisticated architectures, larger training sets, or novel learning approaches. But this optimism overlooks fundamental limitations in how LLMs actually function: these models, regardless of scale, remain sophisticated pattern-matching systems that lack true causal understanding of the domains they work within. They can’t reason from first principles about novel problems, and their “creativity” is fundamentally limited to recombining existing patterns in their training data.
Software engineering is more than just regurgitating tidbits of code and stringing them together; it’s an art that requires intuition and insight into the domain within which you’re working. These very human qualities are next to impossible to replicate with current AI systems because of their inherent limitations. These limitations mean they’ll continue to struggle with truly innovative development challenges that require deep domain intuition, causal reasoning, and genuine invention rather than pattern recognition. As a result, vibe coding can only get you so far in the building process—to “shoot for the moon”, you’ll need to start to turn elsewhere.
The Dangers of Vibe Coding
Not only can “vibe coding” only get you so far, but excessive dependence these tools can have negative consequences for your team and product.
For one, as is the case across the board in most settings, over-reliance on AI tools can lead to a decline in fundamental problem-solving skills and critical thinking. Anecdotally, if you ask most students today that use tools like ChatGPT on a regular basis to help with completing assignments, you will probably hear that they can’t fathom doing this type of work without the assistance of AI. More concretely, a study from the University of Pennsylvania2 found that students who had access to GPT-4 for practice problems initially performed better but later struggled when AI assistance was removed, performing worse on exams than those who never had AI assistance in the first place.
This phenomenon has profound implications for engineering teams embracing AI coding tools. Just as students became reliant on GPT-4 for problem-solving, developers who habitually defer to AI for coding challenges risk atrophying their own technical capabilities. When engineers outsource their thinking to AI systems, these tools essentially become a part of their mind3; like the students in the aforementioned study, they risk developing a cognitive dependency on AI. This dependency manifests in several concerning ways: architectural blind spots, technical debt, and plateaus in innovation.
Moreover, highly experienced senior-level engineers have shared their qualms with “vibe coding” from both a product and team perspective. For instance, Brendan Humphreys, CTO of Canva, argues:
Vibe coding directly undermines peer review processes. Generating vast amounts of code from single prompts effectively DoS attacks reviewers, overwhelming their capacity for meaningful assessment.4
The role of an engineer is not to just ship as much code as quickly as possible, but to thoughtfully craft solutions that balance immediate needs with long-term sustainability. Good engineering involves making deliberate choices about trade-offs, understanding the implications of architectural decisions, and ensuring that what's built today won't become tomorrow's liability.
Unfortunately, vibe coding completely sidesteps this crucial nuance. While AI tools can accelerate certain aspects of development, they cannot replace the judgment, foresight, and contextual awareness that experienced engineers bring to their craft.
So, what now?
After harping on the downsides of AI-driven development tools, you might expect me to advocate for abandoning them entirely. But that is certainly not the case.
In my startup curriculum for developers in LavaLab, the premier startup incubator at the University of Southern California, I encourage founders to utilize these tools to build out an MVP in as little time as possible; the quicker you can launch, the quicker you can validate and iterate on your product, and the quicker you can build a successful endeavor.
However, I also strongly emphasize that tools like v0 or Cursor cannot replace the value a technical co-founder brings to a team. A skilled technical co-founder brings far more than just coding ability—they contribute strategic vision, engineering judgment, and the capacity to innovate beyond what existing patterns can provide. They understand how to evolve systems as requirements change, how to make critical architecture decisions that won't paint the company into a corner, and how to build with both immediate needs and future scalability in mind.
I view AI coding tools as force multipliers rather than replacements. They’re particularly valuable in early stages when validating ideas and exploring product-market fit—in such cases, speed of iteration matters much more than perfect implementation. These tools help founders focus on high-value problems while accelerating routine development tasks. As long as your team uses AI responsibly and avoids over-dependence, it can be an invaluable tool to get a head start in product development.
Advice for Builders
If you want to build or to be a founder, it’s tempting to try to be a jack-of-all-trades. The allure of being a solo-founder can be powerful; however, the challenges of building something meaningful alone are immense. AI tools can create the deceptive impression that you can successfully wear every hat, but this approach is flawed, and can rob you of you and your product’s full potential.
Allow me to offer a contrasting piece of advice: invest in your niche. Whether that be engineering, design, product, growth, etc., become better than the next over-hyped AI product. Make yourself irreplaceable.
By all means, leverage AI to accelerate your workflow and develop your MVP as quickly as possible. But when the time comes, lean on your co-founders or founding engineers to fill in the gaps in your expertise. The most successful products are not built by the most capable prompt engineers, but by the most capable teams.
Bastani, Hamsa and Bastani, Osbert and Sungu, Alp and Ge, Haosen and Kabakcı, Özge and Mariman, Rei, Generative AI Can Harm Learning (July 15, 2024). The Wharton School Research Paper, Available at SSRN: https://ssrn.com/abstract=4895486 or http://dx.doi.org/10.2139/ssrn.4895486
Read more on the “extended mind thesis”, an argument within the real of philosophy of mind that claims the mind extends beyond the brain and body: https://en.wikipedia.org/wiki/Extended_mind_thesis; https://web-archive.southampton.ac.uk/cogprints.org/320/1/extended.html
Read Brendan’s original LinkedIn post.