Thread

1. bengold14 · 1790612793 · focus · HN ↗

   I see this everyday. The problem is code is the wrong abstraction for the work we do. LLMs have solved coding, but they haven't solved systems, collaboration or system maintenance.

   Edit: Since I seem to have touched a nerve - I&#x27;ve been working on a project to solve this: <a href="https:&#x2F;&#x2F;www.archme.io" rel="nofollow">https:&#x2F;&#x2F;www.archme.io if you want to know my thoughts on the right abstraction

   1. jplusequalt · 1790614151 · focus · HN ↗

      &gt;The problem is code is the wrong abstraction for the work we do

      My team recently spent two weeks on a wild goose chase trying to figure out why TensorFlow Lite was generating nonsensical OpenCL kernels. Well it turns out that LLVM had a few bugs in the RISC-V assembly for our platform that was leading to silent garbage. It took combing through assembly dumps, hexdumps, a lot of pain staking debugging, and going through the TensorFlow Lite source code to to track this down.

      In your opinion, if code is the wrong abstraction to be working at, how do you approach this scenario?

      1. bengold14 · 1790615694 · focus · HN ↗

         Fair question - IMO it&#x27;s the wrong abstraction for building and collaborating on a new product with a team.

         To your point, it&#x27;s not the wrong abstraction for solving code level bugs. Just like python is not the right abstraction for solving memory corruption or pointer mis-alignments.

Unofficial Hacker News client; not affiliated with Y Combinator.