I created BoltRead as a 100% vibecoded app (I've never even looked at the code). The following is a personal retrospective on how this app development felt relative to other LLM assisted development I have done.
I have tried vibe coding in at least 3 different ways.
Specs as far as the eye can see
At first I wrote a system that had specs (markdown files) where there is a 1 to 1 mapping between each spec to a matching python module. I only ever edited the spec, treating the code itself as opaque. It kind of worked, though I realized how distinct the difference between a spec that communicates intent and a spec that specifies detail really is. I had a nagging suspicion that the amount of code necessary to properly spec software may be greater than or equal to the actual cost of writing the software itself. So what am I doing here?
Mental Health: Not Good Bob (Tedious) (I am a PM now)
Productivity: 2x un-augmented productivity (these are guesses)?
Bicyle of the mind
From this, I felt that maybe I need to stay closer to the code. I decided to use the LLM as an assistant that only helps with filling in boring functions, doing research, remembering libraries for me, or just acting as a rubber ducky. I basically called Clauade from within emacs, having contextual conversations with the LLM about the code I was writing. This worked (though I never wrote anything more then small snippets of Elisp with it). I did do more active and engaged learning doing things this way, though I suspect that I was actually moving slower than I theoretically could have.
Mental Health: Actually, quite fun. Probably the most fun I have had with an LLM only partner.
Productivity: 1.2x un-augmented productivity (progress is slower, but understanding is greater)?
Jesus Claude, take the wheel
I'm currently experimenting with a 100% vibe coded project https://boltread.com. I drive it through interaction on the terminal, letting it create "specs" that act more as records of decisions than actual specs (like writing your test after you write the code). I find the temptation to get out of the outside critic mode and into just looking at the code is quite strong. I have resisted it to date (I want to experiment with what it feels like to be a vibe coder who cannot program), to judge if I realistically need to be concerned about displacement of Software Engineering. I am trying to see it with the eyes of someone who cannot program. This approach to development is frustrating. Like many, I find getting something 80% right with an LLM is relatively easy, but the last 20% are exponentially challenging. The project seems to get closer and closer to what I want, but it is like shaping mud, you can put detail into something, but it won't stay that way over time; its sharp detail will be reduced to smooth curves as you switch to putting detail elsewhere. I am not 100% sure on how to deal with that issue. I know I could manually fix many of the issues I have with this project, but how do I then stop the project from rewriting that manual work at some future date?
Mental Health: Certainly better than spec driven development. It is like pair programming, but with a partner who does not really learn.
Productivity: 3x un-augmented productivity (partially reflects the improvement in models)?
Retrospective
My current thoughts is that we have failed to actually find a good way of switching from the "macro" (vibbed) to the "micro" (hand coded) process of LLM development. It's almost like we need modules (blast chambers?) for different parts of any software project. Where we can switch to doing things by hand (or at least with more intent) when necessary, and doing things by vibe when not. Striking a balance that nets the greater output is quite challenging, and it may not even be that there is an optimal intersection. I'm floating the belief that vibe coding may be a shortcut that moves development forward, but does so at the cost of future flexibility in the software. I wonder if there may be a future where software teams mix the notion of technical debt and vibe coding as being the same thing? A sort of realization that, yes, we can move faster with LLMs, but the cost of doing so may be that software will become more brittle and inflexible the more we "juice" our development with them. I wonder if there will be roving programmers who come into organizations and rewrite large parts of a system to match what the LLM is doing functionally, but do so in a way that actually reduces the incidental complexity of the sytem?
Of course, this is my view of LLM development with current models. It is always possible that future models will be capable of working without slowly (and sometimes quickly) making a mess of the system. We will see.