tharant

When you’re digging around in tens to hundreds of PCs each day, the odds of zapping something are higher. I’ve killed a few chips and boards.

Hi, it’s me.

I can find no such requirement in the App Store Guidelines. Or is there anecdotal evidence somewhere?

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.

[0] the ultimate, of course, being profit.

Please stop giving me project ideas. :)

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.

I was hoping for a Desk Set reference; thank you.

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?

There are no parts from the OEs, there are no tools, the packs are not meant to be serviced, and it is SERIOUSLY DANGEROUS work.

The same was true for the ICE vehicle third-party repair industry 100 years ago.

It seems like your objection to BEVs (i.e. they can’t be repaired) is directly refuted by the fact that you yourself repair BEVs. Maybe I’ve misunderstood your argument though.

Are you suggesting that since the third-party EV repair industry is still in its infancy that EVs are therefore objectively bad? If so, how is that perspective different from any other mass-market industrialized consumer product? I remember folks telling me that the iPhone would fail because nobody could make apps for it. Markets change, as evidenced by the fact that you’re now repairing/rebuilding Fiat and GM batteries; that wasn’t a marketable skill two decades ago.

In our content, we don’t generally worry that someone is reading our inner dialogue…

Really? Is that what’s wrong with me? ¯\_(ツ)_/¯

Have you seen the Tesla Model S Plaid, or the Lucid Air Saphire? Heck, even the supercar/hypercar market is slowly becoming predominantly BEV.

Other cloud providers aren't part of PRISM and generally don't receive the same level of concern from the world governments.

Um, Microsoft, Google, Meta, Yahoo, YouTube, Skype, and AOL are/were PRISM Service Providers and I’d argue that they all receive(d) equal (+/- 5%) concern and scrutiny from those world governments.

They can afford to resist legal demands from countries they don't respect because they have nothing to lose from denying them access.

Are you talking about the cloud providers I listed above? From my perspective, those guys all tend to honor the demands of any state that offers a statistically significant percentage of current/potential consumers, regardless of the demand. Perhaps they have some bright spots where they “did the right thing” (like refusing to unlock a device, or refusing to provide access to private data) but by and large they all—including Apple—are subject to the rules of the states within which they operate.

Apple has not demonstrated that they have the willingness to resist this unlawful coercion, even recently.

Ten years ago, Apple refused demands by the FBI to unlock the iPhones of various suspects. Four years ago they did the same during the Pensacola Naval Base shooting investigation. I would guess there’s plenty of other examples but I’ve not been watching that stuff much over the past couple years. Were those instances just cherry-picked for marketing purposes? Maybe, but until someone shows me compelling evidence that Apple is /not/ acting in good faith towards both their consumers and the governments under which they operate, I see no reason to believe that they’re “lying about this one too”.

I do keep a salt-encrusted spoon nearby when reading about these things but that doesn’t mean I refuse to trust someone who has demonstrated what appears to me a good-faith effort to keep my privacy intact. Maybe what Apple is doing with PCC is just security theater; I doubt it but I also recognize that marketing and technology are often in conflict so we must always be cautious. But the important thing, both to me and GP, is that none of the other cloud providers have offered (whether it be sane and intelligent privacy controls or just snake oil-like scams) any solution beyond “encrypt your data before you upload it to the cloud”.

Self-incrimination is about speech.

Seriously? So,what, mutes can’t incriminate themselves?

Even if you wanna stick to that shaky narrative, consider that text messages are speech. Notes to myself are speech. Pictures in my phone are a form of my self-expression—which is speech. Emails? Speech. Voice recordings? Speech. My ChatGPT history? Speech. My Siri interactions? Speech.

The concept of protection against self-incrimination is deeply rooted in protecting our privacy; I don’t see how they can be separated like you seem to have suggesting here.

Millions of people do—and have to—often because it’s the most effective way for a PA intern to be useful. Is the practice wise or ideal or “safe” in terms of security and/or privacy? No, but wisdom, idealism, and safety are far less important than efficiency. And that’s not always a bad thing; not all use-cases require wise, idealistic, and safe security measures.

The new Sonnet 3.5 refused to decode it which is somehow simultaneously encouraging and disappointing; surely it’s just a guardrail implemented via the original system prompt which suggests, to me, that it would be (trivial?) to jailbreak.

Thank you! This information is the kind of information for which I’ve been searching.

That said, l feel like there’s a mutual-exclusivity problem between ‘Start with the "Whole" Picture’ and ‘Break Down the Process’.

For example, how does this from your first suggestion:

explain the end-state you want (even simple features like error handling or specific libraries). If you have ANY achieved method or inclusion for what the end-state should include, you write it out clearly.

not contradict this from your second suggestion:

Instead of expecting it to design an entire feature, ask for components step-by-step

Additionally, you said:

There is a very decent chance that you have to do this across multiple new chats, after 3-5 iterations in, the AI will most likely crash and burn. At that point, you open a new chat, paste in the whole working codebase, and picked up from where you left off in the last chat. You have to do this A LOT.

But IME, by the time the model chokes on one chat, the codebase is already large enough that pasting the whole thing into another chat typically results in my hitting context-window limits. Perhaps, in the kinds of projects I typically work, a good RAG tool would offer better results?

To be clear, right now I’m only discussing my difficulties with the chatbots offered by the model providers—which, for me, is mostly Claude but also a bit of ChatGPT; my experience with Copilot is outdated so it probably deserves another look, and I’ve not yet tried some of the third-party, code-centric apps like aider or cursor that have previously been suggested, though I will soon.

As for your recommended hacks, these look to be helpful; thank you! The only part I find odd is your inclusion of “Write the code in full with no omissions or code comment-blocks or 'GO-HERE' substitutions”; I myself feel like I get far better results when I ask the model to 1) write full code for the methods that are likely to be the kinds of generic CS logic that a junior would know, 2) write stubs for the business logic, then 3) implementing the more complex business logic myself manually. IOW—and IME—they’re really good at writing boilerplate and generating or reasoning about junior-level CS logic. That’s indeed helpful to me, but it’s a far cry from the kinds of “ChatGPT can write entire apps with minimal effort” hype I keep seeing, and it’s only marginally better, IME at least, than what I’ve been able to do with the inline-completion and automatic boilerplate features that have been included in the IDEs I’ve used for over a decade.

It's a labor of love and it's things you learn over time, and it won't happen if you don't put the work in.

Indeed. I do love playing with this stuff and learning more. Thank you again for sharing your knowledge!

I wrote all of this haphazardly in a Google Doc. GPT-4 organized it for me cleanly.

I am regularly impressed at how well these models behave when asked to summarize a document or even when asked to expand a set of my notes into something more coherent; it’s truly remarkable!

That’s why we are seeing less and less innovation and diversity compared to the 1980s to around 2000

You think the pace of innovation has stalled and the tech industry is less diverse than it was 20-50 years ago? Really?

Having cut my teeth on the tech of the late-seventies, that’s not a perspective I share. I have long been impressed with how fast new tech makes it into our grubby little hands. From my perspective, if we were stuck at the pace of innovation present during my early days, well, I think it’s not unlikely we’d still be using feature-phones and WAP gateways so we could tinker with that new mobile-internet stuff everyone’s raving about.