I have a confession to make... I am not a vibe coder. I thought I was. It was true at first when I wrote my first blog on this website. However, as I have come to learn, instead of being a Vibe Coder, I am an AI-Assisted developer. Calling myself a vibe coder was fun, but not technically correct. Here's my take on the difference.
Origins of Vibe Coding
Andrej Karpathy, an AI researcher, coined the term:
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. It's possible because the LLMs (e.g. Cursor Composer w Sonnet) are getting too good. Also I just talk to Composer with SuperWhisper so I barely even touch the keyboard. I ask for the dumbest things like "decrease the padding on the sidebar by half" because I'm too lazy to find it. 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. Sometimes the LLMs can't fix a bug so I just work around it or ask for random changes until it goes away. It's not too bad for throwaway weekend projects, but still quite amusing. I'm building a project or webapp, but it's not really coding - I just see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works. -- Andrej Karpathy (@karpathy), February 2, 2025
This is the official definition. Some key pieces I see from this original Tweet:
- Fully give in to the vibes 🤘
- Forget the code even exists
- "Accept All" always
- Copy paste error messages with no comment while debugging
- When AI can't solve a bug, work around it.
- It mostly works.
Now, this means, the point of vibe coding is just to build something. No real greater plan, in fact you must remain flexible for when you inevitably hit the problems that the LLM, alone cannot solve. Also, don't look at the code at all, forget it even exists. And don't apply your own problem solving, just copy paste errors. 😎
Vibe Coding Use Cases
Vibe coding has its place. It's great for rapid prototyping. By not caring about the code, you can build something tangible to showcase some technology, very quickly. It's unlikely to be compliant, scalable, maintainable, or secure, but it will exist -- at least in a form.
Use vibe coding for:
- Small tools that you do not need to maintain long-term. Think scripts, or static analysis tools.
- Initial prototyping of new business ideas. Lets you test something real with people.
- Communicating ideas to other builders. Helpful to showcase something rather than just using mocks.
AI-Assisted Development
AI Assisted Development is as it sounds, using AI within the software development process. This means you, the software developer, own the end deliverable of code. It's yours: you modify it, you review it, and you are responsible for it.
This is my preference for development as someone with a strong ownership drive. While I might have started briefly for a few days in total vibe coding land, I quickly realized the model's ability to write code degrades across big, bad code bases. LLMs don't reason like a human would; it pattern matches across its training set and context. As I continued to not care about my codebase, the performance was getting worse in model latency and increased bugginess of the end software. I ultimately had to refactor the code to use better systems and needed to read the many thousands of lines produced by AI. In software development, you make a lot of decisions at all points in time and are constantly problem solving. By offloading this to the LLM, you are inviting chaos given they don't have a strong point of view or vision for the entirety of the software you are building, they are predicting the next token based on the prior tokens. There is a strong preference towards new code rather than rewriting existing code to do a new thing, leading to lots of repetition and inconsistent behaviors in the software. This makes sense since without purpose-built context management systems, the LLM starts fresh every session. It's ultimately up to you, the developer, to enforce standards.
AI Assisted development is also not limited to code. You can write design docs using AI or in conjunction with AI. I frequently will have AI poke ideas in my designs and offer me alternatives. And when having AI write a design on its own, I always state the goals of that sub-system and any suggestions I have for how to accomplish it along with a "Make no assumptions" clause if my own plan is not well defined. This puts you in the middle of the language model loop. That's the core point of AI-Assisted Development in my eyes. It's helpful in all parts of Software development, but it needs a human engineer to review outputs and guide the software development in addition to taking responsibility of the software.
Vibe Coding Tools vs AI-Assisted tools
While lots of tools enable you to vibe code, since it's primarily a mindset, some tools are more suited towards this kind of mindset. A non-inclusive list:
- LLM Clients like ChatGPT, Claude.ai, or Gemini. Useful for one-off tools and scripts, but limited context management for application development.
- Repl.it - Prompt to deployed app.
- Lovable - Application development from just prompts
- Bolt - Figma to Code
- V0 - Vercel tool with a focus on security (and Next.js, of course)
Now, these are great for prototyping and seeing your product become real. They also push you towards a pure vibe coded design philosophy by abstracting away the code that is produced and in some cases, owning the deployments of this, too.
Other tools can be used for pure vibe coding or human-in-the-loop AI-Assisted development. These include:
- Claude Code - my personal favorite CLI based tool works with Claude models.
- IDEs like Kiro or Cursor. These are full integrated development environments with AI chat as a core feature and allow multiple LLM Providers
- Codex - OpenAI's coding tool
- Antigravity - Google's IDE for coding
- Opencode - open source alternative to CLI based tools enabling local LLM in addition to hosted versions.
Now with these, you own the code, fully and are responsible for it. That might be true on some of the other tools, too, but I put these in a different category because they require deeper knowledge of software development to use. At a minimum you have to use CLI and set these up, manage deployments of the software (which can be vibe-coded, but you must know to do this), and you have much more control over the way context is managed and what is produced. The prompt in these cases becomes less important than in full-on vibe code software since these tools need you to break down problems for maximum effectiveness. You can still use them to vibe code prototypes, but they are well suited to all aspects of software development, from writing requirements, coding, debugging, reviewing, and deployments.
My Uses of AI in Software
I will be continuing to do AI-Assisted software development for my own projects and offer this to my clients. This enables my software business to provide a lot of value for a much lower price than a traditional agency. I end up needing to read, understand, change, and oftentimes, entirely rewrite the code produced by the models. All that said, it is still faster than writing everything by hand. I approach software development with a lens towards privacy, security, and long term maintainability in code, architecture, and sustainable tech for the specifics of the business or problem at hand. These are not things that coding assistants do reliably.
I also use Anthropic's Claude Code as my provider for everything serious as it allows me to store no data for future training and Claude code is best in class for context management in a codebase. I personally like their approach to building these tools, and being able to swap between Haiku and Sonnet is easy and helpful to manage token usage and latency. Opus is even more powerful than Sonnet, but I never have needed it for code. Properly scoping my tasks, understanding what I am looking for, and reviewing outputs based on my decade of experience at Amazon across a variety of tech stacks (including new business development) enable great use of AI. AI then can write all the code I don't want to write. I bring all the engineering rigor and experience building products and integrating these to existing systems.
2026 Experimentation
In the future, I plan to do more experimentation with local LLMs and open source tools like opencode which I have toyed around with a bit. I think to become totally productive with these, I will need another set of hardware to run the decoder models off my M3 mac since the more capable models open source models are slow for me which is a big advantage to using a hosted model provider. I think long term, these will become useful and we are just in the beginning stages of applying them well. For the meantime, it's hard to beat Claude Code from amongst the software I have tried which is only a fraction of the ones I listed above.
Agents & Context Management
I want to experiment more with the context management tools that exist now, built to work alongside or within LLM Clients. This includes MCP servers, skills, and general text-based rule management. I've written about one of my MCP based projects to enable Scryfall within language model clients. I have built other MCP servers and Claude skills that I use from time to time on very large codebases. I will write something more on this in the future. What specifically excites me in this space is the ability to build interoperable tools that work with different types of AI clients to do deterministic actions. MCP is pretty widely adopted standard amongst the large agents, and skills seem like they are being adopted beyond just Anthropic models. In these systems, the model itself becomes more of an orchestrator. This is a core concept to Agents that many people are excited about and I am seeing a lot of predictions for the future deployment of these in 2026. I am not quite so bullish. In the end, I do think humans are the only layer that can maintain responsibility and thus should always be in the loop in some capacity. I do agree that agents will be used in human-in-the-loop systems, but not fully autonomous for anything serious. Maybe my opinion here will change, but I am doubtful, looking towards the next year in tech. It's easy to build something that works 80% of the time. Much harder to ensure full accuracy and maintain responsibility.
Vibe Coding Helped Me
Vibe coding helped me to rediscover the possibilities that writing software brings. I spent half a year without thinking at all about software development, opting to build products out of various types of clay while practicing wheel-thrown functional pottery. I show my work on my Instagram, if you are curious. Pure vibe coding for a couple days brought me back, helping me to rediscover the joy of building with code. And the limitations of vibe-coding, helped to make me a software developer again. I am very thankful to my friends who showed me what they built by vibe coding which inspired me to try, bringing me back out of my post-Amazon burnout.
The Future of Coding
I think both AI Assisted software development and vibe coding are here to stay. Vibe coding enables anyone to build anything. It just might only sort of work and may not be very secure or maintainable in the long term. Downsides aside, it can communicate your ideas to others including potential customers to use the software and collaborators who can build and maintain such systems. There is a world where these pure vibe coding tools usher in an era where anyone can build disposable software where the maintenance is not important and security might not be as vital. We might be here for some things, but certainly not where privacy, security, and long-term use are important. For these reasons, I still stand by the notion that we need even more software developers in the future. Until then, I will continue doing AI-Assisted software development and continue to experiment with new ways to use these tools, automating the tedious parts of my work, allowing me to focus where I can provide the most value.
No matter where you are on the spectrum of builders, from vibe-coder to no-ai-tooling software developer, there is room in this world for us all. Keep on building!