Stop Confusing Vibe Coding with Context Engineering
We live in an age where most people barely read past the headlines. Quick to react, slower to reflect, even slower to understand. This is especially dangerous as AI hurtles forward. Even those working at the frontier can barely keep up. When AI is being crammed into everything imaginable, it's a classic sign of a bubble. And amid all this noise, clarity becomes essential. That’s why naming things matters. Definitions are the scalpel we use to cut through the fog. They bring intellectual precision to an otherwise shapeless buzz, helping us isolate signal from the surrounding noise.
So let’s pause and understand the difference between Vibe Coding and Context Engineering.
The Origins of Vibe Coding
Back in 2021, I led a small team in partnership with OpenAI to reimagine how Codex models could become more interactive. Transforming ChatGPT into a true pair programmer. OpenAI had started to realize that GPT was getting good at writing and debugging code, so making it a pair programmer felt like the obvious next step. Even then, we knew that pasting code snippets into a chat window and bouncing back to the Developer IDE made for a terrible user experience.
The real breakthrough came when Cursor and Windsurf revealed how having a copilot inside an IDE could transform the way we write code. Within just a few months, Cursor became so effective that everyone at the forefront of AI started using it. We’d ask the Cursor chat a question, and because it indexed the codebase and built deeper context, its responses became impressively accurate. Unintentionally, most programmers experimenting with this new paradigm began to trust the AI’s answers. Often without truly reading the code it generated. But it wasn’t until Andrej Karpathy gave it a name: “Vibe Coding” that the phenomenon really took off. Here’s the full tweet that defined vibe coding.
“There's a new kind of coding I call "vibe coding", where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.”
“I don’t read diffs anymore. I Accept All.”
“When I get error messages I just copy paste them in with no comment, usually that fixes it.”
Notice the behavior of the human-in-the-loop that Karpathy describes. “I don’t read diffs anymore,” which is remarkable, given he’s one of the world’s most talented programmers. “I Accept All,” referring to edits and changes in the code. “When I get error messages, I just copy and paste them.” All of this shows that the human-in-the-loop is paying less attention to how the code is structured or written and focusing more on what the code actually produces—the outcome. The first app Karpathy vibe coded and shared was MenuGen, a restaurant menu analyzer.
This style of “vibe coding” inspired platforms like Lovable, Bolt, and Base44. They aimed to simplify and democratize coding. Abstracting away much of the process so anyone could create software using natural language, no programming background required. The vision was clear: let your imagination set the limits. However, despite the remarkable capabilities of this technology, it’s not yet ready for such unrestricted use. Many hoped GPT-5 would “save us,” that it would deliver a groundbreaking model with reasoning strong enough to seamlessly orchestrate agents and generate top-notch code. But that didn’t happen. As a result, “vibe coding” simply using natural language to conjure up anything often leads to chaos if the user doesn’t truly understand what the model is doing. A prime example is Sara Dietschy, a computer science graduate who left programming for a successful YouTube career, struggling to build a website.
“I’m a broken person. The moment my vibe coded project needs to get into the real world, everything breaks. This is insane. I’m so defeated…” — Sarah Deitchy
While Dietschy was eventually successful in vibe coding after several days of back and forth, this video illustrates one big thing. If you don’t know what the heck you’re doing, there’s a very high chance you’re going to get frustrated easily and give up early. Most don’t go beyond a certain effort threshold. Many do give up because it takes an incredible amount of grit to get the model to do what you want this way. Even for me, as a professional who intimately understands model capabilities, coding this way is a waste of talent and time. It abandons method for momentum and ends up compounding frustration instead of accelerating progress. It’s also a very stupid way of writing code. It’s like taking a very large piece of a problem, which is what most people do who have never written a line of code before, brute force Lovable to build their entire vision in a few prompts. While Lovable is excellent at providing that instant gratification and a feeling of joy that you made something happen, which can be addictive and infectious, that feeling is fleeting as you begin to make anything real in it that you can share, and more so when you don’t have the fundamental system design skills.
Enter Context Engineering
As you can imagine, with everything being so new things are constantly changing but let me frame this in a way that the non-programmer vibe coding audiences will understand. When you work with Lovable or v0, you’re giving it either very large problems (also called prompts) like “Build me a personal finance app,” or extremely small tasks like “Change this button color to green.” You are inadvertently switching between contexts. While humans are incredible at switching between contexts, or at least recognizing when the context of a conversation has gone from “Let’s catch up for coffee” to “We need to talk.” In most cases, the LLMs are not. So whether you’re building a finance dashboard or a bunch of agents that need to be orchestrated together, it’s your job to provide them with the right context. That involves a great deal of up front effort. Where you curate that context in order to get the best out of the model. Without getting too technical, here’s how I do it in my day-to-day.
I curate all the essentials of the project up front using a very good and expensive frontier model - GPT5, Opus, Grok Heavy (Vibe coding platforms shy away from such compute power because their business model will become unsustainable). This includes goals of the project, requirements docs, architecture design, tasks and sub-tasks, success criteria, test outcomes (qualitative and quantitative). I build this up to a sufficient level of complexity and progress. Only then will I take things inside Cursor/VSCode to start building software. Because I’ve built up all this “context” up front, and broken the problem down into achievable chunks, all I have to do with Cursor/VSCode and Agent Mode turned on, is get it to achieve a given outcome. Both Cursor and VSCode have gotten exceptionally good at using all this information to build up enough context around the problem it is trying to solve at any given time and achieve very high levels of success. This is when as a human-in-the-loop I kick back and just let Cursor/VSCode drive, because I am effectively getting the model to measure itself on the outcomes I defined. This entirely automated way still feels like what Karpathy describes as vibe coding but because I fundamentally know what I am doing, I am able to achieve in less than six weeks some very complex projects built end-to-end. Something I simply won’t be able to achieve if I used Lovable. Here’s Karpathy’s definition of Context Engineering.
“Context Engineering is the delicate art and science of filling the context window with just the right information for the next step.” — Karpathy
A Tale of Two Paradigms
When you look at GitHub Spark and Google’s Firebase Studio, the way they’re approaching how apps are built while still adopting the vibe coding philosophy of abstraction is radically different. They’re investing heavily in establishing guidelines early on in the process to continue to provide that feeling of instant gratification. While once the app has been built, they can rely on their multi-modal prowess to ensure making changes to the app is seamless. The people who are adopting this approach see high levels of success in their outcomes. This is how more than 25% of startups in the current YC cohort use AI to write more than 95% of their code. It’s emblematic of a broader shift: AI is lowering technical barriers, enabling tiny founding teams to move fast while staying small for longer. The solo founder is the new startup team—armed with models, vision, and velocity. All powered with the “Context Engineering” methodology.
So when founders come to me with ideas they’ve built, the thing I’m looking for inherently is what kind of technical ability they have. It’s easy to decipher this, once you understand how they’re building things daily. Are they simply hacking together a prototype using “vibe coding” or are they using “context engineering” to build up their architecture.
I also see this discrepancy at work. PMs and Designers come up to me all the time with things they’ve “vibe coded” in Lovable or Replit. In these disciplines, you’re judging the idea with the inherent assumption that none of what they’ve built can ever be reusable or shipped. It’s very hard to use a purely vibe coded app and take it to production because the code written is a pandora’s box and no self-respecting developer will be able to or willing to adopt that code. This is one of the main reasons why vibe coded things get such a bad rap amidst engineers.
Why Enterprise Pilots Fail
This could very well be the reason why so many enterprise pilots fail. What Lovable et al. do is provide a superficial notion of speed where an executive could vibe code something they’re excited about, but then when they have to actually turn that into the reality of shipping things live, the same old systems of record kick in creating this tension between assumed complexity and the reality of the nature of shipping high-quality proficient and secure code. Earlier this month, the MIT Media Lab/Project NANDA released a new report that found that 95% of investments in gen AI have produced zero returns. It argues that while individuals are successfully adopting gen AI tools that increase their productivity, such results aren’t measurable at a P&L level, and companies are struggling with enterprise-wide deployments. Its authors found that most spending on AI experiments goes to sales and marketing initiatives, despite the fact that back-end transformations tend to produce the biggest ROI. As someone who has led and architected large scale Digital Transformation projects, I’ve seen first hand how leaders get excited about a technology, get the entire company to either crowdsource ideas or run experiments, eventually falling into the trap of hype with no real sight of delivering value. This is likely happening at every large enterprise today where executives are seeing this new shiny object called AI and the speed at which people can spin up prototypes in Lovable and getting all excited and giddy when someone shows them a hacked together front end representing a sliver of an idea. Then when they have to take this idea to the market the reality sets in because existing systems aren’t architected or built that way. In the enterprise, security and architecture aren't optional—they're gospel. You can’t just throw around a Lovable prototype built in an unbridled way that doesn’t adhere to how code runs in large scale enterprises.
“If you want to make anything real and share it with the world, building something end-to-end using vibe coding isn’t possible.” — Sarah Deitchy
Final Word
Vibe Coding is just that. Vibes. I vibe code all the time. But not without Context Engineering the entirety of the problem first. Vibe Coding in a well defined Context is the correct way to vibe code. Because building up the context up front, allows you to extract the best out of the model and saves me a great deal of headache through the process. Vibe Coding is like throwing darts blindfolded and hoping for precision. It may occasionally land, but rarely where it matters. The paradigm is completely different and the mechanisms are completely different. Context Engineering requires a level of discipline most don’t have with knowledge of a craft most don’t understand. The benefit of vibe coding is experimentation, speed, and proving an idea. It’s the new Figma prototype that helps people not just visualize an idea but get a feel for it. But if you want to make something real, you can't fuel that kind of creativity on vibes alone. You need to engineer context.
Some amazing talks on Context Engineering:
The New Code, by Sean Grove of OpenAI
Context Engineering, by Hammad Bashir of Chroma
What is Context Engineering, by Tina Huang
