779
Generative AI Is an Engineering Disaster. A shockingly inefficient trillion-dollar project. (www.theatlantic.com)
submitted 2 months ago by to c/technology@lemmy.world
201 comments fedilink hide all child comments
you are viewing a single comment's thread
view the rest of the comments
[–] 4 points 2 months ago (3 children)

I assumed that but everything I have seen as I dug deeper has been that at some level that is what is happening. If it is 'reasoning', it's generating a 'reasoning chain' next token by next token and using that to influence the final output tokens. The reasoning chain is discarded and since the actual output is a continuation of the reasoning chain it may conceptually be described as allowing the model to 'rethink' things, but even as the generation of a 'reasoning chain' has results that more closely resemble reasoning, it is still a scenario where it's building it one token at a time and we get to see meaning as an emergent property, rather than trying to find words to build to a more abstract concept like humans do. It just gets to throw away the intermediate work and the extra tokens manage to improve the 'accuracy' of the preserved final output.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 4 points 2 months ago (2 children)

    The interesting bits are when it derives the likely hood of something being correct and does more passes, or splits the data apart in the first pass and opens up new context processes with specialized instructions to handle it. The code stuff goes full on ororborus on some models, writes out the code on one pass, checks for issues on another pass, runs the code looking for errors on a third pass and goes back to step 1 if it fails.

    They're getting a lot out of it for it primarily just being a weighted token generator wrapped in an orchestrator.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 4 points 2 months ago (1 child)

    Particularly software development with very good and very quick tests allow rerolling and that is very appealing in those scenarios. Problems being that very good tests are rarer than people like to think and sometimes it just gets stuck in a loop. At work the other week someone set it at the task of fixing a bunch of build warnings that had accumulated over the years. It succeeded after burning through tokens to take 30 tries at it. It's solution after all that hard thinking? It put // @ts-nocheck at the top of every file and called it a day.

    But superficially, someone handed it a chore and didn't have to think about it, and if no one looked deeper, then it was able to get to the desired behavior simply by rerunning the given task over and over without human intervention until it worked. Which is also broadly relatable as there's a lot of humans in the industry acting broadly the same, but I've always been frustrated by those folks anyway.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 1 point 2 months ago

    Wide scoping like that rarely ends well. Give it the list, tell it to spin a new agent for every single issue and operate on them separately. If any of those agents run out of context memory, it will just shit the bed. Clarify that you need the test to actually work and not be commented out, and that the tests themselves still need to be viable and indicate a healthy working app, not just report that it's healthy. Trying to get tests happy in AI is like making wishes on a monkey's paw. Then assign someone to look after it because that bastard will chew through 10's of thousands of dollars to fix a laundry list of tests, which in my dev experience will be all broken and ignored in 2-3 minor releases.

    You can generally get it to do things, even somewhat complicated things, but it's not easy, and the shit it gives you back while you're trying to convince it to do the job is the same stuff you'd fire an employee over.

    My favorite thing is to make it make ansible tools, They're easy to read, easy to lock down, keys and passwords go in a vault that it's forbidden to read. Then I have it write runbooks on how to operate the playbooks. I then make an index of runbooks, and ask it to do them. It's an ansible job, so I can read it easily and make sure it's not able to delete my drive or my production database.

    If I lose access to cheap tokens, everything I've making is still usable, and for now, I can spend my time working on stuff that's not simple enough that it can handle it well.

  • permalink
  • fedilink
  • source
  • parent