As someone else in comments mentioned though, one alternative strat is to describe your problem to the LLM using pseudocode or napkin code that you at least don't have to link every last inch of to get it to function. And then of course the LLM's reply is going to revolve around an iteration upon the code that you wrote (often with most of that linting done for you for free).

Man.. there are times when trying to debug some error yields no search results and no leads to follow other than "dig through megabytes of the arcane source code with no context of how it's meant to fit together" and if it were possible to have an LLM be able to RAG an entire git repo online and answer questions about it, that would be pretty choice.

I've had basically zero luck with RAG myself so far, especially as I always try to go the local route for better infosec vs relying on cloud solutions like copilot. But trying to tap an LLM to help grok a public github repo wouldn't cover any sensitive data so I wouldn't mind using the cloud for a task like that.

Hmm, I like this idea of "write napkin code and let LLM review/expand". In principle one can probably be quite fast and loose at this stage after all, and as you mention for coders it's often easier to express an idea in napkin code (be that "pseudocode" or real code with just zero effort into correctness as a pilot hole).

I think I'll experiment with this as well.

Both Kerbal Space Program and Outer wilds can sometimes do a good job of driving this point home (especially in OW if you're outside of the ship). It even humbled Thor from PirateSoftware during his stream, which I found hilarious. :D

OTOH I view application installation as a separate skill from $THING_THIS_APP_DOES.

So I would rather the app authors just focus on perfecting their apps, while said apps can then be packaged and distributed in bulk by different sets of people trained to handle those challenges.

What I very certainly do NOT want is:

* Apps automatically checking for updates on startup — since they can't check while they are off — leading to needlessly leaked data crossing the network about exactly when I'm starting up exactly which apps (since they dial home to predictable locations regardless of TLS usage)

* Apps constantly filling systray with their own bespoke updaters (and "accelerators" which just means the app is running 24/7 but minimized to tray ;P )

* App launches updater, updater window says "can't update because app is running". Close app, wait for update, now I have to go hunt down the document I had originally opened the app with. Next time an app launches an updater, I leave it on its splash screen and go to close the app.. naturally that also closes the updater since this time around the one is a sub-process of the other. (I recall earlier versions of Wireshark causing me much grief on these fronts, for example)

* More diverse attack surface area for hackers to infect my PC: instead of trying to juke a distro who has at least some experience and vested interest in defending against poisoning, just juke any single software author less specialized in distribution security and take over their distribution channel instead.

.. either that or they are padding out their training data with scads of relatively inexpensive to produce 3d rendered images</speculation>

Such links might disavow in practice, or might alternately be used as "hey, this email address has a living person at the other end, update the alive status on your spam lists and sell the data point!"

I would only use that wth legitimate companies. Your scenario is no different than spammers who already have "unsubscribe" links.

Well, you can't marry who you never meet. What would it be worth for you to pay a bribe to a time traveler not to go into the past to prevent your parents from ever meeting? ;)

That might be out of concern of bad faith users abusing such a feature, such as folk who actually opt into a newsletter and then feed the results into such a filter.

You can at least "delete" via filter, though.

Grover's?

“Substantially better” is doing the heavy lifting there. Grover’s gets you a sqrt speedup. Double the size of your hash function (SHA512 instead of SHA256) and you’re protected.

I believe 256 bit symmetric keys and hashes are currently recommended because it's double the classically-secure 128 bit.

Because there is a different sqrt speedup concern regarding the birthday paradox / collision resistance. These combine with Grover's to get you a O(N^(1/3)) speedup when finding a collision, making a 256-bit hash have ~85 bits of security against a quantum adversary.

You'd need to switch to a 384 bit hash function to keep a 128-bit security threshold. In practice, this means SHA-512.