Why I Don’t Vibe Code
72 points by lollipopman
72 points by lollipopman
On a meta note: I feel that this article is a good example of things that are obviously and clearly political (national security policy; anti-fraud policy) which are also obviously and clearly relevant to "improv[ing] the reader's next program."
I quite like this article; probably I will direct people to it when they ask why I don't use LLMs for coding.
I save a lot of these types of posts, in order to help answer that question: "why don't you use LLMs for coding?" I'm annoyed (perhaps with myself?) that I need to keep some archive of "responses" to refer back to.
I'm starting to get to the point where my answer is simply "because I don't want to." Of course, what tends to happen is I'm pressured to answer more "objectively" than that, because I have to argue against "But it's so productive! Don't you see how productive it is? I've never been more productive! Why don't you like productivity? You know, you might not have a job if you aren't more productive..."
Most of the time my answer is pretty simple. I'm too busy coding to spend time vibe coding.
After reading the article, I found it hard to remember what the author’s reasons were from reading the tongue-in-cheek section headings. Here are my summaries of the author’s reasons:
Thanks for extracting this.
I agree with all of these points, yet I’d still use LLMs for dealing with accumulated tech debt that no one is ever going to pay down. That one critical service that no team owns and has poor testing but needs to update its python version and all its libraries. That’s an LLM project, write a bunch of unit tests and refactoring so we can confidently bump the lang and lib versions and get back to solving fun product / design and scaling problems.
Curious who's older, me or Jacob. I know I'm creepier though. I read the whole
Friction is a Gift
message waiting for a tongue in cheek sexual inuendo. None. I was let down. And a bit abashed.
Based on Jacob's description of his temporal relationship to Fred Brooks, I think he and I are close-ish to the same age. I'm likely 5 years older than him.
I'm in my late 40s. One of my professors as an undergraduate introduced me to Fred Brooks in a context where we got to have a conversation, and I count that as one of the greatest (professional) kindnesses anyone ever did for me.
Based on your comment, I suspect you might be just a little younger?
I'm 55. I just figure anyone that committed to Emacs is my age or older (I use vim, but have healthy respect for the way of the ctrl-pinky)
That's a fair guess, and I have no insider knowledge. My guess was solely based on how he talked about Dr. Brooks.
Unrelated: dabbling with evil mode has given me additional respect for emacs. Doom Emacs is a really good vim implementation, thanks to evil mode.
I often find myself doing a close reading, pulling up specific files to look over line by line until I understand their context and the choices their developers made. I know I could just ask an LLM to summarize the project for me and save myself the time, but I’ve found I need this process to really marinate in the code. I need it to not just understand the choices the developers made, but why they made them and how they reflect the constraint or idioms of the language they are using.
I sympathize with this attitude and try to do the same, but I worry that the more code is LLM generated the less this approach remains an option because developer intent and purpose won’t be embedded in there to be learned anymore.
Which is an instance of a broader problem: since professional software development is not an individual activity, what has worked for us before may not work anymore if the majority of our colleagues are going in a different direction.
FWIW I’ve got a lot of mileage out of asking the agent to review the code and suggest a reading order to me.
This is an outstanding post full of software development wisdom. And at the same time, respectfully, I think you're missing something.
LLMs are quite limited in their current state, and yet they have solved math problems human experts had not. This demonstrates that they can, to a limited degree, do the kind of thinking you seem to believe is out of their reach.
Now, to your point, they aren't doing that all the time. All those 1000's of agents cranking out all that code aren't continuously operating at that level. They are I'm sure losing the ability to see the forest for the trees and slathering on thickets of abstractions.
But the capability to do that higher level thinking exists, and it is only reasonable to speculate that it could get better. It's not that essential complexity would go away, but that there are now 2 kinds of intelligent "entities(?)" who have the capability to address it.
For comparison, a while-loop can solve math problems that human experts haven't solved. There is no secret to proof search, merely the complexity of proof search. It is a category error to suppose that thinking is required to prove mathematical statements.
LLMs […] have solved math problems human experts had not.
Which LLM, and which math problem? I can see some kind of neural network do that, same way Alpha zero was so good at playing Go (though I’ve heard blind spot have been found, that reminded me of LLM hallucinations). But an LLM specifically? That sounds quite a bit more surprising.
There are a few recent examples that were pretty convincing to me, a little broader than just math but relevant. I'll go from memory (lol, "lost in the middle" could be an issue), and if I can find it quickly I'll include a link:
Donald Knuth was surprised to find that a problem he had wrestled with recently was materially advanced by Opus 4.6: https://www-cs-faculty.stanford.edu/%7Eknuth/papers/claude-cycles.pdf
An amateur used Chat GPT 5.4 Pro to solve, in one shot, a 60 year old Erdos problem using a method that allegedly no human had thought to apply to the problem: https://www.scientificamerican.com/article/amateur-armed-with-chatgpt-vibe-maths-a-60-year-old-problem/
I am doing a quick Google to refresh my memory on the details, and I see talk of Erdos #1196 and Erdos # 728. These might be related to the same instance or they might be distinct.
I think there was another separate case where Knuth credited AI, but not sure.
Again, all the caveats I acknowledged in the previous response apply: this does not demonstrate that we are in the age where "geniuses in the data center" are recursively improving themselves 24x7. But it illustrates that AI shows some capability at being more than just an accidental complexity reducer.
Hey, did you know you can write a spec / ADR and then run it by e.g. DeepSeek V4 Flash (open weights) that is able to read whole project into context and reason about it? With hugely discounted cached tokens due to more efficient format, too?
So for like 1-5 cents it can check the code against your spec and bring up specific sites that need changing as well as assess impact on dependents, even highlight where the spec is unclear or conflicts with itself given state of the code base.
So that part where you start coding to implement the spec and you run into that edge case you totally forgot about... happens less often?
I did neither. It is intriguing.