3 ms·
The right move is this, turned to 11. Velocity or one-shot capability isn't the move. It's making stuff that used to be traumatic just...normal now. Google fu
by selridge 8mo ago
The right move is this, turned to 11.
Velocity or one-shot capability isn't the move. It's making stuff that used to be traumatic just...normal now.
Google fucking vibe-coded their x86 -> ARM ISA changeover. It never would have been done without agents. Not like "google did it X% faster." Google would have let that sit forever because the labor economics of the problem were backwards.
That doesn't MATTER anymore. If you have some scratch, some halfway decent engineers, and a clear idea, you can build stuff that was just infeasible or impossible. all it takes is time and care.
Some people have figured this out and are moving now.
- theturtletalks 8mo agoExactly, if the engineers know where to look for the solution in open-source code and point the AI there, it will get them there. Even if the language or the tech stack are different, AI is excellent at finding the seams, those spots where a feature connects to the underlying tech stack, and figuring out how the feature is really implemented, and bringing that over.
- jrumbut 8mo ago> Google would have let that sit forever because the labor economics of the problem were backwards. This has been how all previous innovations that made software easier to make turned out. People found more and more uses for software and that does seem to be playing out again.
- selridge 8mo agoI really don't think we're living in a "linearly interpolate from past behavior" kinda situation. https://arxiv.org/abs/2510.14928 https://arxiv.org/abs/2510.14928 Just read some of that. It's not long. This IS NOT the past telescoping into the future. Some new shit is afoot.
- est31 8mo agoI think something like an x86 -> ARM change is perfect example of something where LLM assisted coding shines. lots of busywork (i.e. smaller tasks that don't require lots of context of the other existing tasks), nothing totally novel to do (they don't have to write another borg or spanner), easy to verify, and 'translation'. LLMs are quite good at human language translation, why should they be bad at translating from one inline assembly language to another?
- selridge 8mo agoYeah. Lots of busywork where if you had to assign it to a human you would need to find someone with deep technical expertise plus inordinate, unflagging attention to detail. You couldn’t pass it off to a batch of summer interns. It would have needed to be done by an engineer with some real experience. And there is no way in the world you could hire enough to do it, for almost any money.
- mattmanser 8mo agoYou've missed the subtlety here. LLMs don't have attention to detail. This project had extremely comprehensive, easily verifiable, tests. So the LLM could be as sloppy as they usually arez they just had to keep redoing their work until the code actually worked.
- salawat 8mo agoWho wrote the tests?
- bigbuppo 8mo agoThe meat wrote the tests. As I've been telling you, they're made out of meat.
- selridge 8mo agoAnd how does the answer to your question bear on the claim I’m making?
- salawat 8mo agoIf you're trying to automate all coding activity, writing tests is coding activity. Arguably the greater fraction of effort between implementation, and verifying said implementation. If the only thing making your problem space tractable for the automation to be able to replace the lesser half of coding activity is an authored test suite you couldn't generate via your automation, then you really need to admit that. "Did you check?" is the most expensive question, and one of the most feared in my experience in tech circles. Spent quite a few years as a dedicated tester once I developed the knack for it. Everybody gangsta til it's time to prove the damn thing works.
- seg_lol 8mo agoGoogle3 was already PPC clean when they did that. Not as impressive as made out to be.