Sure, the model would not “know” about your example, but that’s not the point; the penultimate[0] goal is for the model to figure out the method signature on its own just like a human dev might leverage her own knowledge and experience to infer that method signature. Intelligence isn’t just rote memorization.
> In the very narrow fields where I have a deep understanding, LLM output is mostly garbage
> Thus I have to assume that for any topic I do not fully understand - which is the vast majority of human knowledge - it is worse than useless, it is actively misleading.
Why do you have to make that assumption? An expert arborist likely won’t know much about tuning GC parameters for the JVM but that won’t make them “worse than useless” or “actively misleading” when discussing other topics, and especially not when it comes to the stuff that’s relatively tangential to their domain.
I think the difference we have is that I don’t expect the models to be experts in any domain nor do I expect them to always provide factual content; the library can provide factual content—if you know how to use it right.
> A use-case that can be carefully considered requires more knowledge about the use-case than the LLM
I would tend to agree with that assertion…
> it requires you to understand the specific model's training and happy paths
But I strongly disagree with that assertion; I know nothing of commercial models’ training corpus, methodology, or even their system prompts; I only know how to use them as a tool for various use-cases.
> it requires more time to make it output the thing you want than just doing it yourself.
And I strongly disagree with that one too. As long as the thing you want it to output is rooted in relatively mainstream or well-known concepts, it’s objectively much faster than you/we are; maybe it’s more expensive but it’s also crazy fast—which is the point of all tools—and the precision/accuracy of most speedy tools can be often deferred until a later step in the process.
> If you don't know enough about the subject or the model, you will get confident garbage
Once you step outside their comfort zone (their training), well, yah… they do all tend to be unduly confident in their responses—I’d argue however that it is a trait they learned from us; we really like to be confident even when we’re wrong and that trait is borne out dramatically across the internet sources on which a lot of these models were trained.
It sounds like the engineer may have little/no experience with concurrency; a lot of folks (myself included) sometime struggle with how various systems handle concurrency/parallelism and their side effects. Perhaps this is an opportunity for you to “show not tell” them how to do it.
But I think my point still holds—it’s not the tool that should be blamed; the engineer just needs to better understand the tool and how/when to use it appropriately.
Of course, our toolboxes just keep filling up with new tools which makes it difficult to remember how to use ‘em all.
In my experience, and for use-cases that are carefully considered, language models are not confidently wrong a majority of the time. The trick is understanding the tool and using it appropriately—thus the “carefully considered” approach to identifying use-cases that can provide value.
I don’t know for certain (he’s no longer around) but I suspect he did. The prevalence of folks who nowadays believe that Gen-AI makes everything worse suggests to me that not much has changed since his time.
I get it; I’m not an AI evangelist and I get frustrated with the slop too; Gen-AI (and many of the tools we’ve enjoyed over the past few millennia) was/is lauded as “The” singular tool that makes everything better; no tool can fulfill that role yet we always try to shoehorn our problems into a shape that fits the tool. We just need to use the correct tools for the job; in my mind, the only problem right now is that we have a really capable tool and have identified some really valuable use-cases for that tool yet we also keep trying to use it for (what I believe are, given current capabilities) use-cases that don’t fit the tool.
We’ll figure it out but, in the meantime, while I don’t like to generalize that a tech or its use-cases are objectively good/bad, I do tend to have an optimistic outlook for most tech—Gen-AI included.
> I really fear that a number of engineers are going to us GPT to avoid thinking. They view it as a shortcut to problem solve and it isn't.
How is this sentiment not different from my grandfather’s sentiment that calculators and computers (and probably his grandfather’s view of industrialization) are a shortcut to avoid work? From my perspective most tools are used as a shortcut to avoid work; that’s kinda the while point—to give us room to think about/work on other stuff.
Again, is it possible you and the other party have (perhaps significantly) different mental models of the domain—or maybe different perspectives of the issues involved? I get that folks can be contrarian (sadly, contrariness is probably my defining trait) but it seems unlikely that someone would argue that you’re wrong by using output they didn’t read. I see impedance mismatches regularly yet folks seem often to assume laziness/apathy/stupidity/pride is the reason for the mismatch. Best advice I ever received is “Assume folks are acting rationally, with good intention, and with a willingness to understand others.” — which for some reason, in my contrarian mind, fits oddly nicely with Hanlon’s razor but I tend to make weird connections like that.
Is it possible that what happened was an impedance mismatch between you and the engineer such that they couldn’t grok what you told them but ChatGPT was able to describe it in a manner they could understand? Real-life experts (myself included, though I don’t claim to be an expert in much) sometimes have difficulty explaining domain-specific concepts to other folks; it’s not a flaw in anyone, folks just have different ways of assembling mental models.
This is one reason I see to be optimistic about some of the hype around LLMs—folks will have to learn how to write high quality specifications and documentation in order to get good results from a language model; society desperately needs better documentation!
> As for not merging the PR - why are you entitled to have a PR merged?
I didn’t get entitlement vibes from the comment; I think the author believes the PR could have wide benefit, and believes that others support his position, thus the post to HN.
I don’t mean to be preach-y; I’m learning to interpret others by using a kinder mental model of society. Wish me luck!
Although the practicality of what you described towards the end of your original comment conceptually demonstrates an MoE-like architecture, the fact that you explicitly mentioned not understanding why larger models are smarter and then proceeded to try to couch-engineer a new, smaller architecture suggests that you were in fact not aware of the MoE architecture and thus the ELI5 LEGO approach was reasonably helpful. I’ve read your question carefully many times, and I’ve read others’ comments in the thread; you seem frustrated that folks aren’t answering your questions when in fact they have been answered — albeit not in the way you seem to want; how can we fix this?
> What expanded scope in new TVs is actually something I would care for?
I think this is the crux of our confusion; you may not desire the expanded functionality but others certainly do. You can suggest that manufacturers force unwanted functionality onto consumers but I have trouble accepting that premise unless admit our own complicity; maybe I’m part of that problem though.
> Owning a TV is something one should be able to do for over 10 years.
Again, that’s your preference and the choice you’ve already made; I choose to not set arbitrary time limits but instead make decisions on purchasing new TVs (and other non-essential products) depending on the available technologies and toys—and, of course, the girth (if any) of my wallet . We have different preferences, we make decisions based on those preferences, yet—as far as I can tell—we are both satisfied with our choices; why complain about a system capable of implementing a bug that doesn’t affect us?
> Can you guarantee that most of the nice features on your TV will work more than 10 years from now?
Almost certainly I can. There are both massive and minuscule communities, aftermarket solutions, and DIY makers/hackers/activists that focus on all kinds of technologies and products dating back over a hundred years. The original iPod is 25 years old and yet there are still folks making firmware updates for it. The Commodore 64 has a multitude of projects, products, communities, and marketplaces to keep the product alive — nearly fifty years after it was released! There are literally thousands of examples. Interestingly, and calling back to my original point, these kinds of secondary markets are only possible because of those products’ use of a combination of quality underlying hardware and user-updatable/modifiable software—well, and that nerds like us dig breaking things.
I get your frustration with bugs but, what TVs (or any other consumer electronic product) aren’t reliant upon software for basic system control nowadays? Hardware isn’t inherently bug-free and the “quality” of old hardware is usually due to its narrow scope of functionality; the ability to (theoretically trivially) modify software means that hardware can/does become better/more capable. I see so many folks complain that software makes everything worse but I also see so many products that become more capable due to regular software updates. It seems like we can either build things that are “reliable” yet limited in functionality, or we can build things that are “buggy” but capable of evolving with expanded functionality.
Sigh. It didn’t take 100 years to grow the ICE repair industry and I imagine you know that; I suspect you’re just being stubbornly argumentative for the sake of vanity.
There’s already a fledgling industry of third-party repair shops for BEVs—which you can attest to first hand. BEVs are not “disposable” like you claim—as evidenced, again, by your own experience of repairing BEVs.
You’ve suggested, in other threads, that BEVs are not designed for repair; every professional and shade-tree mechanic I’ve ever known (myself included) has used that same complaint (“engineers are idiots; they don’t think about repairs”) against ICE vehicles for decades yet the ICE repair industry is still massive and, importantly, constantly evolving—new tools, new aftermarket parts that are better/more reliable than OE, the sharing of knowledge so others can learn how to be safe, etc. This is how industries grow. The notion that all the support infrastructure must be in place before a product can be considered useful or reliable is absurd; we live in a world that iterates and evolves quickly.
Is the Fiat “totaled” or will you be able to repair it? What about the Bolt?
You’ve complained that working on the Fiat is difficult and poorly documented; have you seen what it takes to replace the oil-pan gasket on modern trucks? You have to remove the entire cab! I know well the frustration of working on products that have poor service documentation or seem to be engineered only for production with no consideration for service but that doesn’t mean a product has no viability or is unreliable; in fact, the opposite often seems to be the case—difficult to repair products seem to have better longevity and are therefore more likely to be viable.
I’m willing to admit I might be wrong about BEVs while it feels like you’ve already decided they’re utterly useless; why take such a hard-line stance?