What is Vibe Coding?

Vibe coding blog post

Introduction

With interest in vibe coding exploding recently, Twilio is actively exploring how we adapt everything from our product offerings to our documentation to meet the shifting landscape. We're excited about how developers can use the tools built on top of large language models (LLMs) to kickstart their application development but cautious about the practicality at scale of this new approach. We've already seen builders prompting tools like Claude Code, Copilot, Cursor, Codex, and more to test our APIs and spin up prototypes, using human language more than traditional code as input.

This style of programming, coined "vibe coding" by AI researcher Andrej Karpathy, has permeated the programming landscape and is here to stay. Whatever you want to call it, vibe coding will be a great partner for every builder, whether they consider themselves a programmer or not. This post will cover what vibe coding is, when we recommend using these tools, and a look at what we see as the vibe coding pros and cons in July 2025.

Google Trends: "vibe coding"

What is Vibe Coding?

Vibe coding is when you prompt an LLM to write code for you using plain language. You may tell a tool like Cursor to "create a Twilio Voice application that plays an MP3 when you call a phone number" instead of following a step-by-step tutorial.

Vibe coding tools can create an entire application from scratch or help edit smaller sections of an existing application. These tools can help with everything from application code, tests, documentation, bug fixes, refactoring, and more. In Karpathy's words, vibe coding is when you "see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works."

Vibe coding is not a discerning form of programming, rather a way to rely heavily on whatever the model suggests. Karpathy says "I 'Accept All' always, I don't read the diffs anymore". Instead of searching the code for CSS properties or using the browser dev tools, you prompt the LLM to increase the side nav's border-width and hope for the best. It's not precise, it's vibes.

Good use cases for vibe coding

Karpathy specifically calls out throwaway weekend projects as a good use case for vibe coding, while AI execs are quick to recommend writing all of your code with AI. As of today, I don't recommend vibe coding for production applications – I go into more detail below – but there are several use cases where vibe coding works great.

1. Vibe coding is great for prototyping

Have an idea you want to show someone before investing time in it? Humans are visual and experiential learners, and having a prototype is a great way to discuss the pros and cons of a potential solution. With vibe coding tools, you can get a mostly-working example application up and running in hours if not minutes.

Watch my colleague Brent spin up a prototype of a Twilio Voice application using Claude Code in just a few minutes.

2. Vibe coding is great for trying new tools and APIs

Have you ever wanted to create a call center that only plays Hall & Oates songs ? Or experiment with something new like real time conversational AI over a voice call ? Twilio has great developer documentation, but, historically, you would still need to follow a tutorial before you can see our APIs in action.

Live test applications are great, but what happens when you want to remix Callin' Oates to play Steely Dan instead? Vibe coding a sample application with an API like Twilio's gives you a quick win that can be easily customized for your exact use case, building an understanding of customization options and capabilities of an API. Using vibe coding for this kind of learning and exploration can speed up overall development time and reduce your barriers to entry.

3. Vibe coding is great for building one-off tools and side projects

Speaking of voice bots, I was building a voice-based ConversationRelay application at a coffee shop recently and needed a way to test it without annoying other patrons. I vibe coded a quick text interface that I used to test my web socket server implementation. Could I have done this with a few Google searches and some HTML? Of course. But the vibe coded version took me 2 minutes and didn't derail me from where I wanted to keep my mental focus: on the web socket server implementation, not the testing interface.

Vibe coding is also great when you want a hyperspecific app that doesn't need production-scale and probably isn't worth spending a lot of time or money on. Maybe you want a hotline for when soccer practice is going to be cancelled based on the weather forecast or a simple website that shows your favorite local spots for visitors. These examples are low-stakes ways you could use vibe coding to make your life easier without spending a lot of effort.

The limits and challenges of vibe coding

There are currently many risks of using vibe coding beyond a prototype or low-risk side project. Avoid using vibe coding for production applications, given the challenges with complexity, maintainability, security, and accuracy.

1. Vibe coding increases complexity and adds maintainability challenges

The only bug-free code is no code, and vibe coding produces a lot of code. The sheer volume of code created by an LLM can quickly balloon beyond comprehension. Even with the best prompting, LLMs and Agents might not be concerned with simplicity or the amount of generated code. Ten files is nothing to a computer, but after a few commits it’s possible no developer can grasp the complexity of a project.

As Karpathy notes in the original definition, "I 'Accept All' always, I don't read the diffs anymore. When I get error messages I just copy paste them in with no comment, usually that fixes it. The code grows beyond my usual comprehension, I'd have to really read through it for a while."

This lack of understanding is fine for a low-stakes weekend project, but you can see the problem: imagine being on call for ‘Accept All’-ed code from a vibe coding session. If I'm woken up in the middle of the night because something's not working in a production application, I want to be able to understand the necessary fix. I've been on call for code I don't understand before and it's a bad experience! But not only does vibe coding make code comprehension harder, it's not like I can escalate to Sam Altman and go back to sleep.

2. Vibe coding introduces security and compliance risks

When code isn't well understood and difficult to maintain, there are more ways for security vulnerabilities to emerge. Preventing PII exposure and other data security aren't always top of mind in these applications. We've already seen vibe coding tools acknowledge that security is a big concern and I'm confident we'll see more reports of issues as even more vibe coded applications gain traction.

High stakes industries like healthcare and financial services will want to be wary of this kind of "accept all suggestions" vibe coding: imagine defending this behavior in front of a congressional committee after your application experiences a cybersecurity breach.

Even in enterprise applications, LLMs can continue to be resources for generating code and debugging applications, as long as they have the right amount of oversight. Using guardrails like linters, code reviews, and end-to-end testing will continue to be essential for application security, uptime, and usability. Some LLM-generated code and oversight isn't vibe coding though, that’s something different.

For more on LLM security, OWASP introduced a new LLM Top 10.

3. Vibe coding can produce incorrect code

The simplest limitation of vibe coding is sometimes the stuff just doesn't work. Karpathy does talk about using vibe coding to fix bugs and errors, but in my experience that's only gotten me so far. Even ChatGPT didn't produce accurate code for using streaming tool calls for OpenAI's own Node SDK. I had to do the old fashioned thing and read and reference the API documentation.

Vibe coding may also produce outdated recommendations. New tools or best practices might not be included in the model training depending on what you're using and trying to accomplish. It’s not that the new ideas aren’t good, it’s that these models can only train on content at a point in time.

There are several ways you can improve your LLM assisted coding experiences, like adding explicit references to documentation. Tilde Thurium has more tips for how to turbocharge your productivity in the AI code editor Cursor on the LaunchDarkly blog.

The future of vibe coding and LLM coding assistants

These days, I'm usually building sample apps and documentation that will be used to train the models powering any vibe coding. While an LLM can provide a lot of assistance with some types of work: think generating outlines, boilerplate, and testing interfaces, I'll continue to heavily supervise any LLM generated suggestions… if not write things from scratch. Enterprise grade applications and primary sources for developer tools deserve the extra layer of attention to ensure we're creating strong foundations for the rest of the web.

Vibe coding might be seen as yet another level of abstraction over lower level tools, something developers are used to. I'm certainly glad abstractions like programming languages were invented so I never had to learn how to write assembly or worry about things like memory allocation outside of the classroom (at least for web development). And while you can certainly still introduce bugs in any type of code, there are still a lot of opportunities to introduce guardrails to vibe coding to make application development easier and safer. But once you add enough guardrails and checks, maybe that’s no longer vibe coding.

For now, LLMs are a great partner for prototyping and exploration, but still require close human supervision to prevent serious issues. Vibe coding might be great for your "throwaway weekend projects", but I would think twice before shipping anything to production. I want to treat this all with a healthy amount of skepticism, but will be glad to look back in a year and laugh at the way we used to work.

Kelley works on the developer relations team at Twilio and has over a decade of experience as a software engineer. Prior to working in software she traded live cattle futures, planned art fairs, designed promotional posters for a regional beer distributor, and had several other jobs that probably can't be replaced by AI.