Thread

The problem is not AI code, but not knowing about system architecture or intent

388 points · 240 comments · zazuke

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've been working on a project to solve this: <a href="https://www.archme.io" rel="nofollow">https://www.archme.io if you want to know my thoughts on the right abstraction
1. applfanboysbgon · 1790625499 · focus · HN ↗
  You can immediately tell someone has absolutely no fucking clue what they're talking about and dismiss everything they say as soon as they say "solved coding". You must write the most heinous code imaginable if you think LLMs are better, or even anywhere near, what a competent professional can produce. So funny to listen to terrible coders talk up terrible code.
  In the first place, what does it even mean to say that code is the "wrong abstraction" for the work we do? You can't actually abstract away reality. Maybe you wish we could, that programming computers wasn't about contending with physical constraints. But it is. It will never not be important to have control over what the hardware is actually doing. Abstractions are temporary conveniences, not a replacement for understanding what is being abstracted away.
  1. bengold14 · 1790650547 · focus · HN ↗
    Thanks my friend - I'm not an AI evangelist but I think it's pretty clear that AI codes very well at this point. So well that I'd hazard a guess that most software engineers don't write code anymore. Sure, maybe a professional could do better if they spent way more time on it, but it has always been a tradeoff we programmers have had to make. Getting things done + technical debt or writing the perfect code and over optimizing. And LLMs write working code, so the rest is just semantics on that scale.
    Code being the wrong abstraction is similar to assembly being the wrong abstraction if you're trying to write a web browser game. Sure it's possible to do it and yes, you may end up with more optimized code, but it's not necessary and much slower to do that. Just use Javascript.
    And now, people are building larger applications & functions quicker, and it no longer makes sense time-wise to look at Javascript for-loops when understanding the work. And that's because those for-loops are generally correct, if maybe a bit under optimized. Instead, engineers need a new layer of abstraction, to understand what the code is doing without having to read each line.
    applfanboysbgon · 1790654807 · focus · HN ↗
    LLMs are faster until the technical debt comes due, at which point all supposed productivity gains evaporate and you're now 10x slower than doing anything by hand. They have a use if the debt never comes due, eg. for one-off scripts or for prototypes you will responsibly dispose of. The debt does come due in production, very quickly.
    LLMs write code that compiles, which they accomplish mostly by robotically attempting the task and repeatedly fixing compile errors in a loop. That's a very narrow definition of "code that works", and I would argue it is the starting point, not the finish line. My definition of code that works is more like: secure, stable, maintainable, efficient, performant, effectively bug-free, with an ergonomic interface. LLMs fail on every single fucking count. I routinely observe generated code that leaves trivial 10x or 100x gains on the table, while having severe deficiencies in every measurable approach.
    Given that you talk about assembly as a bogeyman, though, I gather that you're from the generation of "software engineer" who was already writing insecure, unstable, unmaintainable, 100x inefficient, 100x non-performant, bug-ridden JS for everything. LLMs can replace this class of people, it's true.

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.