• MalReynolds@slrpnk.net
    link
    fedilink
    English
    arrow-up
    0
    ·
    2 days ago

    You know what’s harder than debugging? Maintenance, especially of someone else’s code, keeping up to date with security exploits, revamping UX etc. which is why github is full of write only (as in never read, never changed) slop projects. That’s a critical part of a software project with any lifespan.

    And then there’s integrating new functionality.

    Without a solid architecture (which AI sucks at), strict code readability standards (ditto, but improving) and nuanced reviewing of potential additions to the codebase (ditto) what you get is a spagettified mess. It ends up costing more to maintain and improve than just starting fresh.

    The promise of the AI bros was that by the time you needed to maintain or extend, you could just get the next version of Claude or whatever to do it, as it’s capabilities would have improved. That was a lie, and LLMs have hit a logarithmic wall where throwing more compute and bigger training sets at it produces diminishing returns. No AGI for you (unless some genius finds a new architecture). Frameworks / harnesses are still improving, but there’s only so far that can go.

    The amount of technical debt that has been racked up by the last two years of AI coding is staggering to contemplate, and the industry will be dealing the fallout for years. Companies will collapse, and god help you if you’ve used it liberally in a codebase as large as an OS - looking at you Microslop.

    • Yaky@slrpnk.net
      link
      fedilink
      English
      arrow-up
      0
      ·
      2 days ago

      As someone said a long time ago (way before the LLM craze) “bad developers love new projects, they can write terrible code, take praise and zero responsibility, then toss it to the maintenance (actual) team who has to deal with it”.

      (Context: in at least 2 companies I worked at, it was a common practice to have a “development team”, usually with knowledge of latest tools and frameworks, but very little knowledge of processes or industry, and an “application team” that maintains the software long-term, and deals with the processes and users directly)