If you want to know whether artificial intelligence is a gigantic economic bubble, don’t just take pundits’ word for it. Major investors are now moving their money to try to protect themselves from the AI bubble popping.

cross-posted from: https://lemmy.ml/post/54396848

If you want to know whether artificial intelligence is a gigantic economic bubble, don’t just take pundits’ word for it. Major investors are now moving their money to try to protect themselves from the AI bubble popping.

For an industry that we’re told is central to our collective future, the artificial intelligence (AI) industry increasingly seems to be built on a combination of artificially inflated hopes and bad accounting.

The industry’s critics have been raising concerns about its finances for a while: the fact that most of its flagship firms are grossly unprofitable, that they’ve had to jack up their prices to try break even (leading their business customers to pump the brakes on using their products), or that many of the eye-popping investment announcements that are meant to show demand for AI is strong have actually been circular financing — meaning different AI firms cycling money to and from each other.

But none of it has seemed to slow the industry’s boom or the relentless hype machine behind it. Until now, anyway. It used to be that you mostly heard concerns about the industry’s underlying economics in newspapers, blogs, social media posts, and podcasts, and that those concerns went completely unreflected in the markets. But these concerns seem now to have finally bled over into investors’ thinking.

  • dylanmorgan@sh.itjust.works
    18·
    2 days ago

    One early example I heard about slop code being bad was that if you have a process that is repeated, an LLM will not write a function that is broadly scoped so it can handle a significant number of related use cases, it will write different code for each instance, so when that process fails you have no idea which version is responsible. Seems like the kind of thing QA would flag.

    • grue@lemmy.world
      2·
      19 hours ago

      I’ve never known QA evaluations to be design-based, only results-based. They would test each of the cases and reject the code if it failed any of them, but they wouldn’t check for or reject the code just because it was handling them in stupid, non-generalized ways.

      Checking for bad design is more of a team lead code reviewer thing (if it happens at all).

      • eestileib@sh.itjust.works
        2·
        17 hours ago

        Way back in the oughties I worked on a consumer electronics project where our QA guy actually used the product, would come to design reviews, and filed bugs about the UI design confusing the user.

        It was awesome, so of course that job got eliminated as soon as possible.

        • grue@lemmy.world
          1·
          16 hours ago

          I would still call the user-facing look and feel of the UI more of a “result” in the sense I’m using it, though. When I said “design” I was really talking about the internal implementation that someone not looking at the source code would never experience.

          It doesn’t necessarily hurt for QA people to have access to the source code, but they shouldn’t need it to do their job.