Thinking this brilliant Balaji Srinivasan ism is that merging is hard . I think he meqnt it broadly, including with a merge in traffic patterns and companies and ideas. I wonder if he had code in mind. Linus Torvalds decided to build a version control system that made it easier to fork and code but if not used cautiously, you will spend an afternoon resolving merge conflicts. Maybe blindly merging and letting tests save you is like trusting an LLM tool to write code for you? But kind of that’s the thing, trusting an LLM’s diff is accepting a merge in a way and merging is hard.
There is this concept that most compromises suck and you can end up , like in the intersection ∩ in set theory in a kind of hell , where everyone is stuck at the top of a mountain , where it is quite crowded and unstable. You’ll likely fall off! But if you have no compromise , you get a set theory Union a , ∪ , just live as neighboring ideas in peace, perfectly ambivalent . Sure there is enough space for everyone but no one touches no one talks so it is mutually exclusive and quite lonely.
Idea mergers are hard because they require trade offs. Maybe thats why in capitalism, there are so many startup idea forks.
But also mind melds are beautiful when they happen. This is not a compromise but a reconciliation. A interleaving where egos are put to the side and the best ideas win.
Even when we disregard that code gen is only useful if the time it takes you to create the spec and overhead of fixing tge bugs, is less than just doing it yourself , you get the code dysphoria, too. code bugs of code you dont recognize. you dont idenyify with this code. it is alien.
Infinite forks in that non deterministic monkeys on typewriters world
So many paths though we must Always Be Constraining, to get some traction on a problem.
…
The mundanity vs the novelty
I like the point of view [2] here, use LLMs for the mundane not the novel. His statement was about slop and the lower quality that is slowing teams down who suffer from the new bugs and reduced quality. But I suspect he would agree with the new effect of now people only having a shallow understanding of the code. Abstraction is of course a part of code but writing underneath the abstraction gives you depth of understanding. It is like the difference between writing then synthesizing , vs writing a prompt or conversing with a coding agent and receiving an artifact no one looks at. The act of learning and gaining experience is perhaps mysterious but when it comes easy and you didnt roll up your sleeves, there is no scar tissue, it is just passive knowledge.
For the mundane, there are so many great places Code Gen can shine here. Migrations. Can be well defined and you often need to do the same thing over and over again. Like a function signature update in your code, that happens in many places. Or youre using an sdk that has moved modules around forcing you to follow along if you want to take advantage of the new version (sci-kit learn has rearranged imputation I recall off the top of my head).
A similar use case is porting legacy code, from one language to another say. Or a distillation in the same language.