Embrace Vibe Coding, Know Its Limits

Cross-posted from staffordwilliams.com.

Earlier in the year I discovered an agentic workflow that enabled what was later termed vibe coding. The discovery was initially alarming and made me question the future. However, a couple months later I find the future of vibe coding to be very bright for both non-programmers and seasoned programmers alike.

What is vibe coding?

Agentic workflows and tool use allow the creation of software with a much lower barrier to entry than ever before. Depending on the configuration a user no longer needs to know the underlying programming language, the libraries or frameworks used, and in some cases they don't even need to know how to install (or have these items installed) on their local machine. Instead of writing or reviewing code, the user interacts with an AI agent using natural language to describe the desired outcome. They inspect the outcome that the underlying software produces, and, if necessary, iterate with the AI agent until the outcome meets their expectations.

Improvements to Large Language Models (LLMs), and the supporting tech, has made this approach possible since at least 2023. But, it was early 2025 that Andrej Karpathy coined the term 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...

There are a lot of mixed feelings about AI-assisted coding already and with vibe coding thrown in the mix it's difficult to know what supporters, or detractors, are speaking to when sharing their opinions. When I first discovered it for myself, it was alarming - if I could just talk to the AI using natural language and it was right most of the time, why do I need to look at the code it produces?

What does this mean for the future of programming and the value of my expertise in software development? Is there a future where programmers are not needed to build complex software? To investigate further I integrated these new tools into my own daily workflows and a couple months later I find the future of vibe coding to be very bright for both non-programmers and seasoned programmers alike.

Improved capability for non-programmers

The best software systems I've built codify subject matter expertise into automations and interfaces that enhance both efficiency and capabilities for their users. These systems enable people to accomplish more in less time, or expand participation by lowering the barrier to entry in otherwise complex domains. Creating these systems requires inspection of the current state, questioning of future desires, and an incremental build approach that gets changes into production quickly and sustainably.

The demand for software solutions vastly exceeds the supply of programmers. This pushes motivated non-programmers to create their own automations — either through improved manual workflows or by adopting accessible tools like no/low-code platforms or elaborate Excel configurations. These homegrown solutions can be deployed, modified, or abandoned without specialized software expertise. Some can evolve into business-critical systems, but their growing importance often coincides with declining reliability and maintainability.

For these determined individuals, vibe coding dramatically lowers the barrier to entry. Their capability is improved and not only can they achieve more than before, they can do it much faster. This will result in a huge increase in systems built by people without software development expertise. Consequently, we'll see more experiments, less focus on tedious work, and more effort directed toward meaningful and innovative solutions as these tools are leveraged.

The limits of vibe coding

While the possibilities are now quicker and more accessible, these solutions still have an upper limit and they don't scale. Successful systems often experience increased load over time, requiring changes to infrastructure and software architecture to maintain performance. These systems also experience increased responsibility and complexity, necessitating processes to scale what may have started as a one-person initiative into a team or organizational-level collaboration. While vibe coding can excel in creating low-complexity, MVP-style software, its application to much larger and complex systems can be disastrous.

Letting an AI agent loose on a larger system has a number of disadvantages. Firstly, it's expensive - large codebases mean more tokens, though eventually the rate of decline of cost per token should solve for this. Secondly, just finding the right place to make changes in a large codebase is problematic for LLMs and this is exacerbated when modules are disorganized, tightly-coupled across the codebase, and absent of test coverage or documentation. These two issues feed off each other - the easier it is for the agent to get lost or break stuff in the codebase, the more tokens it's going to gobble up trying to fix it, possibly getting stuck in a loop of making things worse.

For an existing codebase the better approach is to guide the LLM where a change should be made and how the change should be made. The where is generally a reference to a specific file and the location within that file. The how could be via your prompt, by including other file references as examples, by some convention or rule that's present in your codebase (or otherwise appended the prompt), but probably a combination of these. This however requires a level of expertise in the codebase and a desire to maintain or improve that expertise over time. This level of attachment to the code is definitely not vibe coding.

For the experienced developer

Forgetting that the code exists is not just for the beginner. As the novice can yolo their way into more complicated systems than ever before, so too can the experienced developer leverage vibe coding to quickly prototype and test ideas. Rather than extend an existing codebase to support some experimental feature, why not vibe code a proof of concept or a prototype that can be used to validate the idea? Creating small automations or tools to help with otherwise tedious tasks is very quick when you're certain of the outcome you want but don't care about the language or framework used to achieve it.

Software developed in this way requires you to have a different relationship with the code. If you're not focusing on the code itself, it becomes like a build artifact. What matters instead is the prompt. Consider version controlling your prompts, and when the generated code produces an outcome that needs changing, delete the code, update the prompt, and regenerate. Over time, you'll develop an understanding of how prompt engineering drastically affects your vibe coding output.

Not for collaborative projects

Just be certain to keep vibe coding out of code you contribute to collaborative projects. Without a clear understanding of the codebase and the conventions used within it, the AI agent is likely to produce code that is inconsistent with the rest of the codebase. This can lead to a lot of wasted time in code review, or worse, a lot of wasted time in debugging and fixing issues that arise from volumes of inconsistent code.

Code that is to be peer reviewed should not be direct from an LLM and requires self-review first. Code-assist technology enables you to produce more, faster, but it's still your responsibility to maintain quality. Don't allow vibe coding behaviours or output to slip into your pull requests, requiring your peers to review the code for you.

Ultimately vibe coding achieves fast, prototype-level results which sometimes feel spectacular - especially when you'd otherwise lacked the capability or time to build something. But when quality matters and the code cannot be ignored, prefer other code-assist workflows over vibe coding.

Photo by Валерия on Unsplash