Retire the Abstractions
hazyresearch.stanford.edu
Retire the Abstractions
1–10 of 53 posts
Re: Retire the Abstractions
#2it sounds like a bad abstraction. ime llms are really bad at reasoning through efficiency and utilization problems. they fail at scheduling and bin-packing for the same reason. it's actually difficult, multivariate, and not great.
i would be shocked if a well designed framework were less efficient than "bespoke" clankercode for low-level work
Re: Retire the Abstractions
#3it sounds like a bad abstraction. ime llms are really bad at reasoning through efficiency and utilization problems. they fail at scheduling and bin-packing for the same reason. it's actually difficult, multivariate, and not great. i would be shocked if a well designed framework were less efficient than "bespoke" clankercode for low-level work
This is probably true. Today. But I think we're finding the problems LLMs are solving to be both paradoxically predictable but surprising at the same time. Not saying you're wrong, but scheduling and bin-packing seem like cards that will eventually fall to a bespoke prompt.
Re: Retire the Abstractions
#4it sounds like a bad abstraction. ime llms are really bad at reasoning through efficiency and utilization problems. they fail at scheduling and bin-packing for the same reason. it's actually difficult, multivariate, and not great. i would be shocked if a well designed framework were less efficient than "bespoke" clankercode for low-level work
I mean, the post was written by a Stanford CS lab, so I'm inclined to believe that they know what they're talking about and are not just bad at creating abstractions.
Re: Retire the Abstractions
#5agents are unlike humans in many ways but they have their own limitations. it's magical thinking to believe that they are able to cope with zero software abstractions, especially as a codebase increases in size and complexity
and today's agents increase codebase size and complexity much faster than humans do via traditional software engineering methods, so this is likely to hit a wall faster than if human software teams were to do this experiment.
Re: Retire the Abstractions
#6[deleted]
Re: Retire the Abstractions
#7it sounds like a bad abstraction. ime llms are really bad at reasoning through efficiency and utilization problems. they fail at scheduling and bin-packing for the same reason. it's actually difficult, multivariate, and not great. i would be shocked if a well designed framework were less efficient than "bespoke" clankercode for low-level work
I mean, the post was written by a Stanford CS lab, so I'm inclined to believe that they know what they're talking about and are not just bad at creating abstractions.
why?
Re: Retire the Abstractions
#8When will we learn?
Re: Retire the Abstractions
#9it sounds like a bad abstraction. ime llms are really bad at reasoning through efficiency and utilization problems. they fail at scheduling and bin-packing for the same reason. it's actually difficult, multivariate, and not great. i would be shocked if a well designed framework were less efficient than "bespoke" clankercode for low-level work
I mean, the post was written by a Stanford CS lab, so I'm inclined to believe that they know what they're talking about and are not just bad at creating abstractions.
[deleted]
Re: Retire the Abstractions
#10it sounds like a bad abstraction. ime llms are really bad at reasoning through efficiency and utilization problems. they fail at scheduling and bin-packing for the same reason. it's actually difficult, multivariate, and not great. i would be shocked if a well designed framework were less efficient than "bespoke" clankercode for low-level work
I mean, the post was written by a Stanford CS lab, so I'm inclined to believe that they know what they're talking about and are not just bad at creating abstractions.
I know nothing about the PhD candidate and professor who co-authored this, but I don't think this statement makes sense in general.
Typically CS labs at universities contain people who have not spent a significant amount of time exposed to large industry codebases and the corresponding complexity. I think the post would have more credibility coming from e.g. the platforms team at a tech company with a monorepo.