Paul LoveOne type of problem I’ve run into with LLMs is what I call (in my head, mostly) a “plausible solution error”.
I dive into solving a problem that I feel should be straightforward. My initial ask is quickly formed. I get some suggested pathways back, pick the best-sounding one and start down it. After a while, I realise I’ve fallen into a complexity rabbit hole and have to reverse out. So these are solutions that look plausible but turn out to be… not that.
For example, a few months ago I tried to get Nix provisioning a Raspberry Pi with an adblocker. This felt like something that should be feasible and I’d been meaning to have a play with Nix for a while, so I decided to make this my first proper attempt at going hands-off with an LLM. It failed badly. I wasted most of a good weekend running repeated and extended OS compilations before eventually flaming out from the complexity. I should have taken a step back and considered whether using a Raspberry Pi as an adblocker made any sense in the first place. Spoiler: not really, no. In the end, I figured out that my router had a setting to enable AdGuard DNS. This was a fairly coarse solution, but I turned it on as a temporary measure while I thought through how to set up a more flexible system with NextDNS and Tailscale.
Yesterday, I ended up making a similar error while trying to get Microsoft Teams to play nicely with Google Workspace. I spent the best part of a day messing with email routing across two systems before accidentally killing email deliverability for a couple of hours. Oops.
The fault is ultimately mine, I think. In the past I would have read around a subject and come up with a few alternatives before starting out: research, plan, then act. But the sense of power and speed from AI means I am much less likely to do that, and unwarranted confidence leads me to skip specifying guardrails like “keep the solution as simple as possible”. I challenge responses on a tactical level, but don’t really think to challenge on a strategic level, because I already feel committed to a path. Classic sunk cost fallacy.
So really this is a note-to-self. Before you start: figure out the constraints, entertain a range of approaches and look closely at trade-offs between them. And keep trying to remember that for the most part, a model will answer the question that was asked, confidently and in detail, and will rarely ask if the original question was the right one.