alt Hacker NewsThe bottleneck was never the code
Comments
I’ve been saying for decades that the “hard problem” of programming isn’t curly brackets or any of that shit, it’s figuring out what you actually want, in enough detail that you can explain it to a computer.
The amount of detail required is less these days and the computer is better at interpreting handwavey explanations but the principle still applies.
For me it was. Solo entrepreneurs are the ones who profit the most from AI assisted development.
One of the most full of bullshit phrases that nevertheless gets parroted all the time, specially by clueless AI bros. If that's the case, then why programmers invested so many years creating high-level langs, debuggers, syntax higlighting, intellisense, libraries, and a myriad of other tools in order to make programming easier? You guessed it: it's because programming is actually super hard and thus a real bottleneck, and will always be.
I swear AI has made this entire industry crazy.
Here's Robert Martin saying non-determinism in AI is ok:
https://x.com/i/status/2044440457422549407
Who wants a non-deterministic banking app?
If thats true, I am sure some C-suite manager knows this already. Assuming management knows what they do, after all, they're getting payed for this. The time where engineer are trying to educate people above them should be over. Management gets payed for the big decisions. If they tank the company, so be it. I no longer care.
It seems like so many developers know this, yet here we are. SV pushing this AI slop economy. More code! Faster! Less testing! Less understanding! It's what we NEED!
> What may save us it that agents are unreasonably good at reading exhaustively. An agent will read every PR comment, every closed issue, every commit message, every stale design doc ...
> Not just “this module exists,” but “this module is weird because the migration had to preserve old behavior,” or “this benchmark matters because a previous optimization silently changed the distribution.”
The thesis here is that an LLM will document code better than a human (although based on human artifacts), since churning through huge quantities of text is what they are good at.
A few thoughts:
1) Yes, an LLM may be able to pull comments out of commits and PR comments and put them back in the code where they belong, but I question how often a developer too lazy to put a vital comment in the code would put it in a commit message instead!
2) "The truth is in the code" has always been true, and will always remain true. If the comments differ from the code, the code defines the truth. Pulling comments from stale external documentation and putting them in the code does more harm than good.
3) Comments that can be auto-generated from the code don't add much value (lda #1; add one to the accumulator).
4) Comments about the purpose or motivation of the code, distinct from 3), such as the "we had to preserve backwards compatibility" example, or "this code does this non-obvious tricky thing because ...", are where the value is, but the LLM is highly unlikely to be able to discern any unwritten motivation by itself. If the human developer left a comment somewhere then great (assuming it is still relevant)
Most of the discussion we see about LLM coding is how fast it can churn out thousands of LOC on a greenfield project, or how good they can be at finding bugs, but neither of these are very relevant to the main job of developers which is maintaining and extending existing codebases. It would be lovely if most projects were greenfield, but they are not.
In any large project that has been maintained over a few years or more, there will inevitably be an ever growing accumulation of bug fixes and patches for specific issues that have been discovered in production, likely poorly documented and out of sync with any original documentation that may have existed (which anyway tends to be more idealistic and architectural in nature, not capturing these types of post-deployment detail and special cases).
The natural tendency of an LLM is to want to rewrite code to match the statistics of what it was trained on, and they need to be reigned in via prompting to resist this and not touch more code than is minimally needed for what is being asked. Of course asking an LLM to do something is a bit like asking a dog to do something - sometimes it will, and sometimes it won't. I expect over the next few years we'll be experiencing, and reading about, more and more cases where LLMs have introduced bugs and regressions into mature code bases because of this - rewriting code that should have been left alone. The general rule is that if you are tempted to rewrite something you better first understand why it was there, coded the way it is, in the first place.
I can't help but compare the current state of "AI" (LLMs) to the early days of things like computer speech recognition or language translation when they were considered amazing, and everyone was gushing about them, but at the end of the day the accuracy still wasn't good enough to make them very useful - that would take another 10-20 years.
Another historical lesson/perspective would be expert systems which at the time were considered as AI and the future of machine intelligence (the Japanese "5th generation systems" were going to take over the world, CYC promised to offer human level intelligence), but in retrospect were far less important. It won't be until we move on from LLMs to something more brain-like, deserving to be called AGI, that LLMs will be put in their historical perspective.
At the moment DeepMind seems to be the only one of the big labs admitting/recognizing that scaling LLMs isn't going to achieve AGI and that "a few more transformer-level breakthroughs" are needed. Hassabis has however talked about LLMs (GPTs) still being a part of what they are envisaging, which one could either regard as a pragmatic stepping stone to real AGI, or perhaps that they are not being ambitious enough - building something that still needs to be spoon-fed language rather than being capable of learning it from scratch.
The bottleneck was ALWAYS the code, which is why everything was built around it.
This is the key line right here:
> Negotiating, agreeing, communicating the shared picture of what we are building has become the work. And it’s just as hard as it was.
But if software (via code) is what we ultimately produce and sell, how did we get here? The main reason is the following lemma:
Lemma A: "The loss of fidelity of what can fit in any one person's head scales superlinearly (exponentially?) as the scope of work scales up." Or more colloquially: "It is impossible to fit a large scope of work in any one person's head." This is largely because any non-trivial task is a fractal of smaller dependencies.
The chain of logic to today's situation is then obvious:
1. Writing code requires humans who are slow and expensive.
2. To do large things we need large groups of humans.
3. As the number of humans grows (like beyond 5? 10?) it becomes impossible to keep them aligned, largely because Lemma A.
4. We need to coordinate these humans, so: enter managers!
5. But even a manager can't manage too many people and coordinate with all other managers because, again, Lemma A. Enter hierarchy!
6. As the size of the organization grows, so does the coordination overhead (exponentially, if Google AI overview is to be believed) until as,that quote surmises, the majority of the work is just that.
7. Coordination costs (or "Conway Overhead" as I call them) are very well understood in the literature, but this also brings in undesirable dynamics like bureaucracy, politics, organizational metrics (also due to Lemma A, but now triggering GoodHart's law!) and eventually territorial disputes and empire-building. Lots of friction and subtle mis-alignments.
As you can see the overhead scales superlinearly with the number of leaf workers added. And for the same reason, once the leaf workers are decimated because one worker can now do the work of a whole team, the entire organizational overhead above that is gone, which is also a superlinear change! Assume a conservative 2:1 reduction in ICs and a 1:5 manager:reportee ratio, a simplistic hierarchy that was:
1 CEO -> 5 VPs -> 25 Dirs -> 125 Managers -> 625 ICs
now becomes something like:
1 CEO -> 12 SVPs -> 60 Sr. Managers -> 310 Sr. ICs.
Not only did that eliminate 300 ICs (mostly junior I suspect) it took out 60 managers and removed an entire layer of Directors from the hierarchy! Worse, the leaf-layer will probably get decimated 5:1 not 2:1, and this will also eliminate coordination-specific roles like Program Managers. The rest of the hierarchy is much fewer but mostly more experienced (or politically savvy) people. They will be paid more, but not superlinearly more, of course, what do you think this is, socialism?
It's very much a pyramid scheme of cards built on that one bottleneck. And this bottleneck applies for pretty much all knowledge work. Once that bottleneck opens up, everything collapses. This is why I fear that the coming job changes are going to be much more disruptive that people realize, something I'm extra concerned about as a parent of high-schoolers.
Before going to work, we're fed algorithms and data structures and how they are the bottlenecks that makes wasteful use and here's how to utilize them; only to naively know from hard stories that the actual bottleneck is always from the people, the H-factor, except this time H stands for human.
Insane amount of bureaucracy, paperworks, and how we are missing deadlines so we write shit code that the quick and dirty solutions were never replaced.
Algorithms and data structures therefore are more like helping you utilize the machine economy better, but it doesn't have any meaningful impact on the social aspect of it. That's a hard lesson I had to learn from my two previous job, though now I'm considering starting my own small business just to make a little bit of living enough to survive.
But now my ADHD kicked in and is still lazy and I had so many concerns whether the market validation is great, how to deal with situations if I broke customers stuff, how to gain (and hopefully not regain) trust if any bad things ever happen, what if I want to go vacation and suddenly the server broke and got code zero (the highest level of alert I termed internally, when you had alertmanager flashing everything red, network storage is down, corruption happened) during a trip to Bahamas.
I'm still in the watershed of thinking really to do this or not, but the job market is filled with ghost jobs that are not worth my time either, I'm basically "dead locked" right now and had to make a decision quick.
Either choice is fucked for me, as I started to notice after going to work, despite I got some really interesting ideas in tech, but I'm not a charismatic person so I can't really make those idea to fruition, because no one wants to listen to me and implement it together, so I'm pretty sure it is impossible for me to be a great leader (tech lead probably, but CEO level of leadership and coordinator and manipulate the grand scheme of thing, nah, I pretty much can't do).
Now the problem is, even if I'm pretty sure to get fucked, you should choose the one that inflicts minimum pain to you. So far having my own business seems like a less painful to die and bankrupt, and I'm preparing to sell off some of my stuff to get a last dip of my fortunes and have fun. Will see how it looks. Bankruptcy is nothingburger in this modern society perhaps.
Now you see how the bottlenecks can't even be the code anymore and even goes beyond code, despite having the same core template: I don't even have to code, to repeat the same "quick and dirty" kind of mindset in another domain, in another instance. That's something LLM, heck not even AGI can solve: decision-making based on situations with limited time and resources, and it can be personal or organizational or even structural.
This is very much not going to be solvable by a bunch of lines and statements and expressions, but it really need some time to dig in and compromise. Pick your kool-aid and drink it
[flagged]
[flagged]
[dead]
[dead]
[flagged]
[flagged]
[flagged]
[dead]
[dead]
I cringe every time I read the word "load-bearing" in an article.
the tediousness of keeping documentation up to date and the natural tendency towards small attention spans has always come up as a tax on organizational efficiency: complicated org structures, legibility exercises, communication tollgates etc. there is real value in reducing the friction in the former so that the latter becomes less of a burden.
at the same time, context poisoning is a real cognitive problem for humans too and I can't tell you the number of times I've seen irrelevant details become a drag on execution. my fear is that having too much context will only cause bikeshedding and a revisiting of prior decisions.
frankly, our organizational structures were already pretty good at creating mechanisms for eliciting the right implicit context at large scales. it is possible that we're just going to come up with the same mechanisms from first principles...