☆ Yσɠƚԋσʂ ☆

  • 2.33K Posts
  • 2.79K Comments
Joined 6 years ago
cake
Cake day: January 18th, 2020

help-circle





  • Exactly, the argument that whether the code was written entirely by hand or produced by an LLM is the wrong thing to focus on. To see why, we have to consider how software development actually works at scale.

    There’s a view that code written by hand has to be more intentional, almost has to be by definition since it requires the maintainer to actually put it in there themselves. That’s, of course, true but once a project grows past a certain size or it has multiple maintainers, nobody really has the totality of the code in their heads. So, any new code that’s added is always done with limited understanding. Code being written by hand should not be equated with it expressing the intent faithfully; if that were the case, then we’d never have software bugs. Humans make mistakes all the time as is clearly evidenced by there being no lack of buggy code predating LLM use.

    I’m also not intimately familiar with most of the code in the projects I’ve been maintaining over the years. Any code I’ve written even a few months ago might as well have been written by someone else. When I need to make changes, I read through the code and figure out what it’s doing, and I rely on the test harness to make sure I don’t introduce regressions.

    It’s simply not feasible for humans to keep the entirety of large projects in their heads all at once. When you’re working on a project, you’re constantly forgetting and relearning code as you go. And the situation is even worse for projects where multiple people work together where nobody knows what everyone else was thinking. We look at the code and try to build up sufficient context in our heads to make the necessary changes. When we misjudge that context or misunderstand existing code, then we end up making mistakes.

    The way we judge whether projects are actually solid is by the level of specification and testing they have, the experience of the developers, and amount of usage they see in the wild. All of these same tools work just as well with LLM generated code as they do with code written by hand.

    Farming out design decisions to the LLM without reviewing the output or doing proper testing will almost certainly produce low quality code, but that is no different from somebody just slapping some code together to make a kludge rather than really thinking through a problem. Working with LLMs does not mean farming out your thinking to the machine. What these tools actually do is automate the mechanical aspect of producing the code. Once it is written, you can read it, understand it, and change it as you would with any other code.





  • The claim that LLMs are simply damage control for poor engineering decisions is a gross misrepresentation of the reality of maintaining a codebase the size of Linux. No human can hold the full state space of the kernel in their head. Memory safety is one class of bug, but the most subtle vulnerabilities are logic bugs such as race conditions, incorrect state transitions, misuse of APIs that cross module boundaries, or behavior changes during a refactor. None of these would be caught by Rust’s borrow checker or by typical static analysis tools. These problems emerge from interactions between subsystems written by different maintainers who were solving separate problems and weren’t aware of how features might interact in negative ways.

    LLMs, by contrast, can look across a far larger context and identify interactions across the entire codebase. They can trace the execution of a path through a driver, spot where a lock is held too long, or detect that a function’s contract is violated by a caller many levels deep. Humans simply cannot scale this kind of analysis to millions of lines because we can only hold so much information in our heads. Calling LLMs damage control is frankly dishonest in the extreme.

    Rust is a powerful tool for eliminating issues like buffer overflows and use-after-frees in new code, but it’s by no means a silver bullet. On top of that, the Linux kernel already has millions of lines of C that will never be rewritten. A Rust rewrite of the entire kernel would be a fantastical idea, and even if that magically happened you’d still have many kinds of problems such as logic errors, algorithmic complexity attacks, or unsafe blocks needed for hardware interaction which Rust would not help you with. The reality is that LLMs help find the same memory bugs in C code today, and many of these problems would simply not be found otherwise.

    The whole idea of having multiple supported kernels to break the monoculture is likewise fantastical, and ignores the sheer amount of work that goes into maintaining a project of that scale. It’s also completely orthogonal to the LLM question. If we had ten kernels then each would still be a giant codebase needing the same kind of automated analysis.

    Dismissing LLMs as damage control ignores the fact that much of all engineering is damage control, and the real question is which tools give us the best return on effort. LLMs currently provide a unique ability to surface hard to see interactions that no other tool catches.















  • They raise a question that communists would have a different perspective. They don’t know what that perspective would be. Like if I said aliens would be different from us, I’m not saying I know how aliens think. So the second scene is the illustration of what it looks like in practice. An act of kindness is what shows that people can act in different ways. I’m flabbergasted how some people really need things chewed up and spoon fed to them.



  • TLDW: American companies spend insane amounts of money and have no path towards profitability, and Chinese companies are spending a tiny fraction of that to deliver a product that’s mostly as good. On top of that, countries and companies are uncomfortable relying on closed models. So, Chinese providers offering open models at far lower rates mean they’re quickly taking over the market. And it turns out that simply having the best model isn’t really the most important thing. If a cheaper model can do the work then there’s no point paying order of magnitude for a more capable one.