|
|
|
|
|
|
by DesaiAshu
78 days ago
|
|
|
We crossed a threshold in the past couple months where I'm not sure I'd agree that "libraries other devs depend on" is the right cutoff for LLMs. In many cases, LLMs will write more concise, faster, and more accurate code. Not by one-shooting, but through a deeper search of possibility space - not dissimilar to how stockfish and other pre-llm search algorithms worked Modern harnesses are systems built with LLMs as one of many building blocks (incl. regex, test suites, linters). If it can be measured and verified, there's a good chance LLMs will optimize it This is not a new concept. Humans stopped writing "artful" assembly many years ago, because Lattner and others made it much more efficient to rely on LLVM than hand-optimizing assembly It's also been demonstrated in other domains within Google (4x4 matmul, silicon photonics, protein folding) Interface heavy apps are not purely about objective function, they are about feel, comfort, usability - those apps will benefit heavily from humans. But subcomponents of these apps (eg. an algorithm to route packets efficiently) can often be better solved (somewhat objectively) by LLM-based solvers or other forms of RL. However, writing assembly for the sake of art sounds rather interesting in an 2026. Many of my favorite musicians and DJs are driving a resurgence in vinyl to help balance the computed future - and I think that's a great thing |
|
|
if it really were fuzzing and finding different candidate spaces, then I'd expect it to be good at things like dynamic programming, where I've only seen it fail. usually i see it get stuck in a bad solution and just thrashes around in that minima. these are problems where we can construct a verifiable test space, and it will eventually wind up with a solution, but one that is thousands of lines long and uses no structure of the problem space