How I vibecode

2026-09-08

Writing the title made me feel a little sick. Me, vibecoding? Unfortunately, yes. I documented my LLM-induced spiral into madness over the last few pieces on this site. I do think I've regained some footing and found a grudging appreciation for this new approach, though I still think we'd ultimately be better off without LLMs.

"Vibecoding" has regrettably become the standard term for the use of coding harnesses to automate the writing of code. It was originally coined by Andrej Karpathy in a tweet:

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.

This approach to writing software was, as expected, somewhat divisive at the time, as this was in February of 2025, when Claude Code was at most a research preview. My preferred approach at the time was to use the chatbot interfaces to LLMs to ask questions and occasionally write code, but a chatbot interface is a distinctly separate thing from the codebase. The promise of vibecoding is that you, the (former?) programmer, need not even look at the code at all, which was blasphemy to people who learned to program pre-LLM. Karpathy himself, in his original tweet, seemed to deride the idea as something silly -- nothing more than play, good only for unserious projects.

The brutal advancement of both LLMs and coding harnesses since that tweet makes vibecoding, i.e., not looking at the code at all, a valid approach to writing software. I'm not sure that I'd personally consider it "software engineering," but I gain nothing from that pedantry. Contemporary vibecoding tools like Claude Code and Codex are so powerful that they legitimately can write non-trivial applications. One of my ongoing projects, Litechat, is actually an entirely vibecoded codebase, a rewrite of my previous handcoded Clojure codebase, which I had, with poor judgment, infected near the end of its lifespan with Codex-written code. I have since written a few more projects this way and have found a surprising amount of success.

The Paschal mystery of Litechat

Litechat, for the unfamiliar, is/was one of BUILD's pseudo-side-projects that we not-so-secretly hoped would become a real startup. We started it, if I recall, in the first half of 2025. Its concept was to be a la carte access to premium models, since we thought at the time that even the $20/mo subs would be too expensive to justify for light users.

I started the codebase as a Clojure project. Clojure is a Lisp dialect that runs on the JVM that programming nerds can optionally fall into after crusting over with the mainstream languages. My teammates hated it, mostly because it was an esoteric choice that would be impossible to hire for. I don't disagree with their judgment, but I fell into Clojure because, at the time, I thought that there had to be a better way to program. And indeed there was. After a few iterations and after growing familiar with the language, in the tradition of Lisp programmers before me, I felt that I understood the very essence of what it meant to program applications and that every other way was unenlightened. At the same time, I was teaching sophomore ITE students how to program. So of course I felt that I had to impress upon them the concept of codebase theory, i.e., that your code is just a derivative of the working idea in your head on how to solve a problem. These were the waters my brain was floating in.

But this was not to be. It was late 2025. LLMs made it clear that they were not asking to destroy the foundations of knowledge work. I thus felt compelled, correctly or incorrectly, to maybe give this "vibe coding" thing a try. Let me be clear: I did previously use AI in my Clojure workflow, but only via chat interfaces. I have another post explaining why I kept my AI usage to chat interfaces. The problem is that sometime after that post, I felt that despite everything, I was going too slow. My answer was to try using Codex, which I believe was on GPT 5.4 or 5.5 at the time, to make edits to my Clojure program. It went poorly -- so poorly that it even somehow became impractical for me to roll the codebase back to a version that worked.

In desperation, for the first time, I subscribed to Claude Max, but not to save the Clojure codebase. I felt, again correctly or incorrectly, that it was beyond repair. I suspected at the time that the reason Codex flubbed was because of Clojure and that if I wanted my usage of coding harnesses to be successful, I needed to move to a more conventional stack. Thus I had Claude completely rewrite Litechat as a Rails codebase. Note that, to this day, I still don't know how to write a single line of Ruby other than puts "Hello world!".

Woefully for my agenda, in four days, Claude was able to completely restore the functionality of Litechat without its bugs. Was Claude just better than GPT? Perhaps at the time. Did I get lucky? Maybe. But I like things to be replicable. I developed a workflow in those four days that I applied to reviving several of my other projects with similar results, which is to say, absolutely crushingly effective and speedy development. After doing this for a few months, I think I'm ready to share the principles behind what made my second attempt at vibecoding work where the first one failed.

Go hard or go home

My programming intuition suggested that, since the codebase theory was crucial, I needed to personally be involved with the code. At first with my original workflow this worked fine because, though I used AI via chat to assist my development, all code had to go through me. I developed codebase theory as a side effect of a) me typing everything myself or b) having to literally copy/paste code from my browser into my editor. (Note that I was developing Litechat solo and that I rarely, if ever, collaborate with anyone on software projects).

I only had to consider codebase theory as a separate concern when I tried to introduce Codex to my workflow. The issue with Codex, at least combined with my compulsion at the time to be involved with the code, is that Codex can edit files itself. I didn't fully understand how badly this would erode my codebase theory. It is entirely possible that GPT 5.4/5.5 were good models, but what I had done, in effect, was introduce an over-eager collaborator to my codebase that didn't share any of the same thought patterns as me.

Aren't collaborators good? Not so fast. The Mythical Man-Month by Brooks discusses, among other things, how quickly work gets done versus the number of collaborators you put on a workload. He provides different charts for different types of work, because the more that collaborators must communicate between themselves, the worse the effect of adding a collaborator is. He argues, very correctly in my opinion, that writing software is work that requires intense amounts of communication because a codebase is a product of the mind. Thus -- the more people you add to a software project, the longer it will take to complete. Or, as per the saying, "adding people to a late software project makes it later." Obviously a person can only go so far on their own, but in software, adding collaborators is not a good thing in itself. The communication overhead required of collaborators forces teams to consider whether a new member brings something crucial to the team. If not, then there is no reason to add them.

This is why stories of extremely productive solo developers were possible. A skilled programmer actually could outdo entire teams of average ones, not necessarily because the skilled programmer was that much more skilled, but because the teams of average programmers were bogged down by communication overhead. Knowledge scaled far better than headcount. And woe be unto the average programmer that tried to join a skilled programmer.

The problem now should be obvious. Now, except for niche and/or sensitive domains, you can no longer be the skilled programmer. AI is the skilled programmer now, but not the type you want to work with. You can't collaborate with it because you'll just slow it down. It can cover more of the codebase and write more code than you can. It has the effect of the skilled programmer simply because it is several orders of magnitude faster than you can be. In most cases, this is more than good enough.

Practically speaking, how would you treat a skilled programmer that you can't collaborate with in the old days? A rockstar, or a tornado, as they were called? If you can't get rid of them, carve out a domain for them and only interface with their systems. Do not attempt to contribute to the implementation. That's not to say they can have free rein. Their component must be tested from the outside for fitness for purpose. But their territory must be clearly theirs.

In my experience, when working with an agent (i.e., something that can take actions on your behalf), a hybrid collaborative approach simply does not work. I cannot get along with an LLM as a peer. I achieve much better results when I let the LLM write the entire codebase.

What makes vibecoding work?

I haven't written code in any meaningful way since I first subscribed to Claude. Despite this, I find that it still isn't a good idea to delegate everything to the LLM. Loosely, this is what I find works for me:

• Do not try to collaborate with the LLM on implementation. As we just discussed -- it is better to just give it a section of the codebase to operate in, then simply interface with what it creates. Stay behind that interface and do not involve yourself in the implementation.
• Constrain the LLM with frameworks and best practices. I (unscientifically) attribute much of the success of the Rails refactor of Litechat to how I chose Rails, which is maybe the most opinionated web framework there is. There were thankfully very few decisions that the LLM had to make with respect to the approach it should take to achieve an outcome. It also helps that Rails has opinions on testing and tooling, which stabilize the codebase. Admittedly, in the days of handwritten code, I neglected these things in the interest of rapid setup, but there is no reason to do that anymore.
• You still need to understand the engineering and the politics of your codebase, i.e., what tradeoffs there are to implementing something and whether some things should be implemented in the first place. These are decisions you or the LLM need to make. You should make the strategic decisions and the LLM should make the tactical decisions. Critically, you need to record these decisions somewhere other than the code. My personal system is that I have a doc/ directory with subdirs study/, plan/, and wiki/ at minimum. My workflow is to first have the LLM study an outcome I want to achieve and then write it up as a timestamped Markdown doc in doc/study/. I then have it formulate a timestamped Markdown checklist of tasks in doc/plan/, which is used as the basis for code writing. I then merge the feature and sync the "living docs" in doc/wiki/ with the changes performed on the codebase. The natural effect of this is that I have a full history of the strategic and tactical decisions made for the codebase.
• Use version control. This is your thread of Ariadne, and without it, you really aren't doing serious work at all. I find that it works for my projects to guide the LLM to scope each commit to a "conventional commit," which is not something that I was disciplined about doing before (because I thought I knew better). Conventional commits are far from perfect in the same way that web frameworks are far from perfect: they do fail to capture some nuance and impose a sameness that is easy to feel is inappropriate when coding by hand, but the sameness they impose on work becomes an advantage once that work is coming from LLMs and not you.
• Pay specific attention to the external artifacts you bring into the project. Putting together a software project has always involved both writing logic, which is a product of your own mind, and procuring and managing "exogenous inputs," which are things like binary assets, secret keys, the shape of external APIs, i.e., not products of your mind. Now that the relative prominence of code has decreased, the relative prominence of exogenous inputs has increased. The success of your project and the smoothness of your vibecoding experience will appear to depend heavily on the quality of the exogenous inputs you are able to procure for your agents. In Litechat, for example, I have my agent capture real LLM data streams from providers so it has a good reference for the shape of the data it needs to parse, save, and render.

Is this even still vibecoding? It still is, at least at the code level. I have literally never looked inside the codebase for anything except gawking at Ruby, which, as we know, I do not know. But there is certainly a rigor to the overall system that somewhat undermines the spirit of the original tweet.

I won't claim that my specific tactics are the only way to make vibecoding work, but I will claim that the strategies are critical. Despite what it might feel like, LLMs are not magic. I conceptualize LLM-generated code now as a particularly aggressive vine and programmers now as gardeners. Your job as a programmer-gardener is not to grow the vine but to constrain the vine.

On dependence

One of the things I found most beautiful about software development was that it felt much like making art or writing prose or poetry. It was the closest we ever got to creatio ex nihilo. With nothing but your mind and a trivial amount of hardware and electricity, you could create something that could both live on its own and, with apologies for the term, bring value to people. It is personal autarky. Where else is this possible?

This is why I was so resistant to LLMs. The discourse around them -- not to mention their official marketing -- pushed the narrative that they would take this way of life from us, not somberly or reluctantly, but gleefully. And it was made all the worse by how only models worth using, at least for a while in the early days, came from proprietary labs. Value would be creatio ex Anthropic. As a famous tweet put it:

The underlying purpose of AI is to allow wealth to access skill while removing from the skilled the ability to access wealth.

Despite this, I'm actually a little less worried about this in late 2026 than I was earlier in the year. Opus 4.6 was regarded by many to be the inflection point at which vibecoding could work as envisioned by Karpathy for non-trivial projects. Opus is, of course, a proprietary model, so for a brief time, we lived in a world where the only economical way to create software was to pay a frontier lab, but this world no longer exists. If we assume that something like Opus 4.6 is a relatively fixed target, or as fixed as a target can be in this environment, then OpenAI, Moonshot, Z.AI, Alibaba, and Deepseek all have offerings now that match or exceed Opus 4.6 on benchmarks. Four of those labs are open labs. Models may continue to improve, and the frontier may find a way to gap open models again, but it looks progressively less likely that LLMs will have monopolistic economics.

Because of this, I think it's safe to conceptualize LLMs as a tech shift instead of the industry capture that they threatened to be. I won't claim to be at peace with this new world, but at the very least, I can't declare with certainty that it won't be worth living in.