← Back to context

Comment by chaos_emergent

3 hours ago

I'm not old enough to have gone through the revolution that was programming languages that got increasingly more abstract and decoupled from the metal, but surely there's a lesson that can be learned from that era?

Those abstractions are deterministic. LLMs are not.

  • Garbage collection and what the JIT decides to do often isn't.

    • I think the more salient point is that going from writing assembler to C still required you to understand a lot about your machine, algorithms, how to debug issues, and in general it demanded problem solving skills.

      LLMs eat away at all of these requirements.

      1 reply →

  • more importantly those abstractions were designed to try to make it easier to reason about what was going on for the author, build additional internal abstractions and to allow a reader to follow along and gain an understand of the structure. unless we believe that we can completely punt on having agency over the codebase, then llm code is only as valuable as it is readable.

    • The dream is that we keep agency, but also give up on reading code, by doing away with code as our level of abstraction and instead having humans edit human-readable spec files (including, say, depicting UIs directly with visual mocks). Like "no code" platforms, but for everything.

      2 replies →