The hidden costs of LLM problem-solving

It’s well-known that LLM usage has changed communication in lots of ways: From slop grenades to automated emails, the erosion of real communication is there for all to see.

I’ve noticed another trend: instead of receiving emails that ask “how do we solve this problem?”, there’s an increasing tendency to say “can you implement X, Y and Z?”

In other words: instead of opening up a conversation where expertise can be leveraged, collaborators are being asked to implement a prescribed solution.

In many examples I’ve seen, it’s clear that the ‘solution’ has been generated by an LLM. Even if it’s not openly stated, there are many unmistakable tells – a combination of tone, unusual technical detail and format leave little doubt.

How we got here is totally understandable. LLMs appear to offer expertise, so people consult them to solve issues in areas outside of their domain. But relaying this output as a solution is a flawed approach and introduces lots of risks.

Bad suggestions

The most common issue I see is that the LLMs solutions are inappropriate, or won’t solve the underlying problem. And that’s before you get onto hallucinating features or documentation.

But the main issue is that LLMs miss context. They’re simply unaware of the considerations that led to an a decision or implementation. It doesn’t help that they’re also built to appease, and therefore unlikely to drill down to discover underlying issues.

The result is often a suggestion that looks ok on the surface, but breaks down under the most minor interrogation.

Friction

Unpicking an LLM’s solution also introduces friction. Beyond the initial assessment of what does or doesn’t work, there’s additional work in explaining why an approach isn’t appropriate.

This isn’t a new scenario for professionals to navigate: it’s normal for people to make suggestions and there to be some back-and-forth over what the right approach is. What’s different is the frequency of suggestions, especially when they seem plausible but ultimately don’t work.

I think this is where the biggest hidden costs lie. An LLM can generate an infinite number of suggestions for free, but working out what’s useful from that can take a significant amount of time. It’s inefficient and counterproductive.

If most requests are instructions to implement an inappropriate change, there’s a risk to the collaboration morale, too. The receiver has to push back, having started on the back foot. Neither of which are great for collaboration.

Shifting perspective

This isn’t to say that AI tools can’t be used positively in a collaborative environment. I had a good experience recently with a client who used Claude to visualise something they were struggling to articulate.

Two things contributed to this being useful:

1. They clearly stated it was LLM output (transparency is good)
2. Instead of directing me to implement the output, they asked a simple question: “is there anything of use here?”

I still needed to do a lot of work to unpack Claude’s output – there were lots of unusable, impractical or inappropriate elements. But this simple shift in perspective got things off to a much more constructive start.

I don’t use LLM tools as part of my workflow, but understand they’ve become a common part of many people’s setups. If we can normalise being transparent around the source of output and frame it as a conversation starter, that could reduce some of the hidden costs in using LLMs this way.