Control the ideas, not the code
17 points by eugeny
17 points by eugeny
Nobody should anymore look at this code, but only at the ideas the code contains.
How does one extract the ideas from code without reading it?
Exactly - source code is the ultimate specification of ideas implemented in software - I do not see a world where we ignore it, concluding it is no longer important.
Sure, maybe we can figure our higher-level languages than Java, Go, JavaScript or Python - but having a specification that is the most detailed (and deterministic) source of truth for the software we build is indispensable.
And doing it in English - or any other human language - means simply using an inferior tool for the job.
And doing it in English - or any other human language - means simply using an inferior tool for the job.
There's a reason why standards usually have blurbs about exact definitions of words like MUST, MAY, SHALL.
Yes; and there also is a reason why we do not write math equations in English, but have mathematical notation.
Even with all of their definitions, lots of standards docs are lacking. When you go try to actually implement the standard, you find lots of things that are not well defined, missing logic, etc.
Often times you are forced to either guess and then try it in the real world, or go look at another implementation to see what they did and assume they did it correctly.
This depends on the ideas we're talking about, though, no?
Code only specifies behavior; things like specs and PRDs specify intent and high-level reasoning. (Or absent that, the grey matter in our heads.)
If code were the ultimate specification, then by definition, any bug present is part of the spec. But that's obviously wrong, since we have an idea somewhere outside the code of what the software should do.
Code is still important, but non-code specs were always more authoritative.
Ask an LLM I guess?
On a serious point, the problems with this attitude (and I say this as someone fairly llm-pilled) are:
I’m currently trying to figure out how to capture the speed benefits of vibecoding while producing correct, readable code that I can actually read and change without having to just throw an agent at it.
You may joke but this is the author's actual suggestion:
by iterating with the LLM, ask it to write a document with the main software ideas, and studying them
He explicitly describes working the other direction - putting the design description in the repo instead. (Which we should be doing regardless)
I can't believe people (in this instance, the first comment under the post) still push the "LLMs are just another layer of abstraction, as is C over ASM".
The fatal issue that makes this argument fall apart in my eyes is that each of the previous layers is, or is assumed to be, deterministic. Even if some js code has to go through several jit engines written in c++, which are compiled and eventually go down to assembly, that js code will produce the same result. (i'm not 100% sure on the exact stack here but you get the idea). A prompt, spec or whatever you want to call it, is non-deterministic by nature, and in a way which is especially dangerous, because feeding it to an AI it works often enough that people start to trust it.
If you find a bug in a compiler, which introduces some non-determinism, you can debug it, and fix it. You cannot "debug" an LLM in any way that is practical, and you cannot "fix" a prompt, just try to change/add some words and hope that the model does the bad thing less often. You can have other AIs review the output of the first AI but even those suffer from the same non-determinism that e.g. some static code linter doesn't.
Another issue i have with this article is that at no point it addresses that vibecoding costs money. Real money. You can try using some free models and for a quick python script it will probably work, but not in the way ~antirez proposes. Many, many people simply don't have 20/100/200 eur/usd per month that unlocks this kind of coding (that is, vibe coding). Not even talking about developing countries, even in usa/europe, students are already doing whatever they can somehow afford a split spotify/apple music subscription. In my eyes programming has always been super accessible, at least in the last 20 years. You need a one-time upfront investment of a laptop, but you likely need that anyway, and you can learn to code online. I just don't want a 20/100/200 eur/usd sub to become a requirement for programming, and with the way AI will happily strip you of your coding skills, i'm worried that we're heading in this direction.
each of the previous layers is ... deterministic
Determinism kinda feels like the wrong thing to be focused on. Even for your example - the jit is not guaranteed to produce the same code every time it runs because it depends on statistics gathered from your running program and compiles in a background thread. So even if you are running a deterministic program with fixed input, the way the kernel schedules threads can impact what code your jit produces.
I do agree that treating an LLM as an abstraction layer is a bad metaphor, because they don't expose a coherent abstraction! None of the details are consistently hidden.
A much better metaphor IMO is libraries. When I ship a project, most of the code is not written by me, or by anyone I know. And it will run on systems that were also not written by me. And all of those will ship new versions and change code without consulting me. Somehow I have to build confidence in software that I didn't write, and I have to do it without sitting down and reviewing the entire linux kernel.
A library written by an LLM is not the same thing as a library written by a human. There are different things I would look out for, and given current capabilities I'd want to do a lot more testing. But it's clearly the same class of thing, whereas an LLM and a compiler should be treated very differently. You can build confidence in a compiler by testing the compiler across a wide range of output, but you don't test your LLM at all! You test specifically the one output that it produced that you care about.
I just don't want a 20/100/200 eur/usd sub to become a requirement for programming
I worried about this for a while, but much less so now. When I actually add up the money I spent to be able to program professionally - hardware (amortized over 5-10 years), internet access (with Canadian duopolies), electricity - my 20/month sub isn't a major bump. Even smaller if you count office space or even coffee.
And I'm expecting the cost to go down in the long run, even if there is a spike over the next year ro two, because the hardware is seeing big improvements and more manufacturing capacity is coming online.
But even now, I spent a couple of weeks playing with deepseek as a comparison and I only managed to spend $4.63.
When I actually add up the money I spent to be able to program professionally - hardware (amortized over 5-10 years), internet access (with Canadian duopolies), electricity - my 20/month sub isn't a major bump. Even smaller if you count office space or even coffee.
I got my first paying programming gig in high school with a laptop I fixed myself and library wifi. I think a lot of kids in the last two decades did similar. I didn't consistently have money for a $20/mo subscription until after college, let alone $100.
This probably won't make you feel any better, but I'm expecting there will be microsoft-style get-em-hooked-early free subs for kids and students.
is non-deterministic by nature, and in a way which is especially dangerous
Why is it more dangerous than giving a task to a teammate and getting back non-deterministic result?
Many, many people simply don't have 20/100/200 eur/usd per month
Outside of purely hobby programming, not having 200 USD / month for LLMs means not having enough benefit from them to save you less than half a day of work. The prices will probably correct soon, but the amount of compute you get for 200/mth is crazy high. If you're doing contract work for example, it effectively becomes free and then pays for itself and more, because you can pick up more work.
I think the issue is less determinism and more local reasoning. If I change documentation handling code in the compiler and it has any effect at all on code generation, that is a serious issue - and one we can and should fix. If I change the part of my AGENTS.md about documentation, it not only can but must change outputs unrelated to documentation.
That is the loss of local reasoning, and it is a sore blow to understandability and to the concept of engineering as a whole, even were the models perfectly deterministic and their outputs reproducible.
The fatal issue that makes this argument fall apart in my eyes is that each of the previous layers is, or is assumed to be, deterministic. […] A prompt, spec or whatever you want to call it, is non-deterministic by nature
Nitpick: it is possible to make LLMs deterministic by setting the temperature to zero. I know llamafile can do this:
Notice how I'm using the
--temp 0flag again? That's so output is deterministic and reproducible.
In principle, this applies to all LLMs.
A stronger argument against LLM coding is that even assuming you do make everything 100% deterministic and reproducible, you still don't have any guarantee that it's deterministically reproducing correct code. And if you're trying to fix a bug, an LLM is not the best tool to enforce invariants—not because of nondeterminism, but because LLMs are not a tool for rigor, in the same way that casual English language is a worse tool for rigor than mathematics is.
That doesn't preclude the use of other tools, e.g., static linters like you said. Or type systems and tests and proofs and other wonderful things. But it does mean LLMs won't work well as your only tool.
It's still not deterministic in the sense that a specific output should not be affected by inputs unrelated to it.
True! I'm not sure "deterministic" is the best term for that, but speaking casually, "behaves in ways that are hard to predict" is true even if you turn the temperature down. My gripe is that it's a difference of degree, not kind: existing tools like compilers can also have spooky interactions (and even bugs!), but the difference is that we're surprised when it happens in a compiler.
(I am bothered when people speak imprecisely about these things. Which makes me a hypocrite because I also speak imprecisely at times!)
I find it fascinating that apparently no amount of experience can save one from just ignoring the pile-up of vibe debt.
You came here just to boo? I think that response does a good job of delineating the DMZ the two sides refuse to venture across. The idea, if I am on the same page with the author, is the tech debt now lies somewhere else. I get what he's going with (but don't know if its true); I've done a ton of vibe coding in the last 9 months and I find myself often doing a: look at PR, become bored, ensure it already has an adverse reviewer on it and merge it to see if it works. And I say that as someone who got nicknamed "The human linter" at an old job for how fine-grained my code reviews were. I feel awful about it, but it only applies to things I am creating for myself and it is an active, intentional experiment to see if I can move the quality gates around rather than removing them. Essentially, I have turned up the guardrails (linting, test coverage, types of test coverage) to 100 whereas if it were my code or my team's code I would be closer to 80. And then I add gates after the merge process as well to try to catch any UI regressions or other stuff that's hard to unit test.
Then at that point I have a consistent command in each project that spins up whatever is "an instance" of that project so I can interact with it and decide whether the change works. If it does, deploy it. If it was a bad idea, revert it and forget it. If it seems like the right idea but has bugs or could use some polish, so that until we get there and deploy at that point.
This sorta assume that reading code is no longer a virtue. Code review is not to validate code. It's to get team consensus on direction, style (read ability) and to keep at least one other person in the loop.
I find this idea of "it doesn't matter if it works" is just limited, selfish, short term shortcut for not wanting to do work as we have been able to turn off our brains more with agentic coding.
Skills will atrophy. I think the fight now is weather these skills will have any use in the future, and I am betting on that they will.
Code review is not to validate code. It's to get team consensus on direction, style (read ability) and to keep at least one other person in the loop.
I think what code review is "for" depends on the company/team/culture you're in and also what kind of reviewer you are. I've worked on teams that operate how you describe, and teams that definitely don't. Or even just individuals who don't even if the team generally does. There's no universal in what code review is for.
I agree that skill atrophy in the long run is an issue.
But stuff like team consensus and shared knowledge doesn't need code, and if it involves non-coder stakeholders (PMs, clients, designers, etc), cannot be solely code anyway.
Non-coders always relied on prose specs/PRDs, it's just that with LLMs, engineers could too.
I'm just yet another programmer that has never wrote anything of relevance besides patches to free software projects that were ultimately rewritten by maintainers, so I feel very bad disagreeing with antirez, because he's one of the most talented developers of my generation. But I just don't buy it, honestly.
I was texting a friend earlier today, before I read this blog, and I brought up what I think is an apt analogy.
You work at a small free-range chicken farm and you really enjoy feeding the chickens, but it just so happens that you have to slaughter, debone and cut up one of them every once in a while. One day, out of nowhere, the farm owner changes the business model and buys a chicken nugget making machine. Your job now now is to pull the levers that give you the pink goop.
The pink goop is delicious, especially when deep fried. You can make tons of it a day. It's probably OK to eat it in moderation. But pulling the levers is not your thing.
Your boss is not even malicious. But he's low key trying to gaslight you, thinking he's just putting some sense in your head.
It's still food. It's made of the same thing. The mission is the same, right? Those trucks leaving the farm are carrying the results of your work, and all of it will end up on people's bellies.
But, man, you miss the open fields, you miss picking the eggs, even the mess that the chicken made. Now someone you don't even know connects a hose to the machine, all you know is that you have to pull the lever once and inspect the results so that nothing weird happens.
You'll still clock in and out everyday until you retire, after all you need a roof over your head.
But you dream with both every other night, in your dreams you look up and you see either a clear sky or a zinc roof.
Which one is a dream, and which one is a nightmare?
Sadly, this already happened to the vast majority of farming decades ago. The pastoral fantasy has been dead and replaced by industrial farms for a long, long time.
It's just now the grinding forces of capitalism have come for white-collar knowledge work. The lucky few who got paid well to do a job they enjoyed find themselves in the same predicament as everyone else.
LLMs may be the proximate cause, but your ultimate complaint is with the demands of capitalism.
As a kid I always wondered "what does the programming language for the Starship Enterprise look like?" Turns out in the future they just tell the computer what they want in natural language. Duh.
It's a super interesting open question whether source code in general will become more like assembly language, which people only inspect or write rarely, or whether it'll remain something we interact with constantly, just at a higher velocity, increasingly trusting the computer for much of the details.
antirez's question of "how do you review when computers produce 5k lines of code per day?" 10k? etc. According to some, human review is already becoming the bottleneck. I guess going forward we treat software correctness in general like we will all trust autonomous driving. Not perfect but better than humans on average.
The working day is 8 hours. If you read the code, it is a tradeoff. You are doing less of what today is the most important part of your job
This is the part where I agree the most: it is definitely a tradeoff! If you are pursuing some programming goal, there is some optimal fraction of your time you should spend elbows-deep in low-level code, and it's less than 100%. It's always been less than 100%.
Nobody should anymore look at this code, but only at the ideas the code contains.
This is the part where I agree the least.
If you've got a tradeoff, the value of doing the thing depends on your alternatives—so never say never, because your alternatives change over time. The optimal amount of code review when you're prototyping is different from the optimal amount when you're polishing something more established. (And prototypes can become more permanent than expected, so you can't optimize entirely for the present, either!)
I kinda wish he would have run this post through an LLM for just some light editing and grammar. It's hard to follow at times.
I have also noticed this. I don't remember his previous texts to have so many grammar issues. I wondered for a moment of it was done on purpose to signal that the text was not written by an LLM.