The hard problem with hard problems

For reasons that are neither here nor there, I’ve been getting Claude Code to write a solar system simulation for me recently. It keeps getting it wrong, and I’ve kept getting incandescently angry at it for this.¹

Dave pointed out to me recently that, in Claude’s defence, gravity simulation is actually a very hard problem that very clever people struggle with. I fully agreed with this, but also don’t consider it relevant.

One of the ways you can tell it’s not relevant is that the actual gravity simulation is done in REBOUND which, as far as I know, is written entirely by humans. It was originally written by Claude, but I was also worried about it getting that right, so I replaced it, and none of the problems went away.

The actual problem that I keep getting angry about Claude with is that it keeps cheating - sneaking in shortcuts where it violates the laws of physics, sometimes because it’s too hard for it to do the right thing but usually because it made some stupid mistake it’s covering up, or writing tests that don’t actually test the problems I’m pointing out to it and then claiming that the problem is fixed. The problem is not that it’s getting it wrong, it’s that it’s not trying to get it right.

When a coding agent does things like this our running joke² on Discord is “Oh, so it can replace human engineers”.

It’s very tempting though to just stop there and go “Oh well, I guess this problem is too hard for an LLM”. Some problems genuinely are. But the thing is, although it’s being given a hard problem, it’s not the hard problem it’s stuck on. What it needs here is not to be smarter, but to be better shepherded through the basic processes of software engineering.³

This isn’t a problem we see only with LLMs, it’s a problem all over the place.

A previous organisation I worked at was… quite dysfunctional. It had many positive features, but it also was a total mess where I was often amazed that anyone ever got anything done. I used to ha-ha-only-serious joke that this was a result of its two biggest problems:

1. The biggest problem was that it had grown too rapidly.

2. The second biggest problem is that it could blame everything else it was doing wrong on the first biggest problem.

Depending on how grumpy I was on a given day, I might reverse the order of the two.

Many of that organisation’s problems were legitimately caused by their rapid growth. Keeping an organisation functional during rapid growth is legitimately a hard problem.⁴ Also many of that organisation’s problems were straightforward unforced errors caused by e.g. bad policies or inadequate adminstration,⁵ but instead of being treated as addressable they just said “Yup we sure have grown a lot crazy how nothing works properly any more”.

You see this over and over again in a lot of projects. People try to do something legitimately hard, and also fail. This is the expected result when trying to do something hard, so the hardness of the problem acts as an emotional shield against failure: You don’t have to feel bad about failing, you were just trying to do something hard.⁶

This conflates two claims:

1. I tried to do something hard and I failed.

2. I tried to do something hard and as a result I failed.

I could⁷ try to make a soufflé. This is supposedly a hard cooking task. I will likely fail at it, at least the first time. This is because it’s hard. But if I try to make it out of cabbage, the reason I failed to make a soufflé is not that soufflé is hard.

This is, obviously, a ridiculous example, but I don’t find many of the other examples I run into in practice much less ridiculous. People engaged in hard problems often over-focus on the hard problem, because that is where they expect to fail, and as a result neglect basic housekeeping and maintenance tasks. I don’t want to cite specific examples because they’re a little too pointed, but for example I’ve seen software projects which are trying to solve hard problems which have completely inadequate testing and that are constantly bogged down by bugs as a result, or where the basic foundations of the project are garbage in a way that means that you have to be hundred times as clever to achieve basic things.⁸

There are a variety of reasons why this happens and ways that it can. I don’t want to diagnose them all, because that’s not the hard problem with hard problems.

The hard problem with hard problems is noticing that the reason you’re struggling isn’t that the problem is hard.

When you notice this, you can diagnose the specific problem you’re actually running into, and fix it. Your problem will still be hard, but it will no longer be unnecessarily hard.

When you don’t notice this, you will probably fail to solve your problem, and then you’ll have an excuse for your failure which prevents you from learning from it, which is much worse than merely failing.

1. Truer words have never been spoken than Kelsey Piper’s “Vibecoding is like having a genius at your beck and call and also yelling at your printer”

2. Started by Aria

3. One of the reasons that I’ve been writing less recently is that I’ve gotten a bit obsessed with little vibe coding projects like this btw, and part of that is because it’s been interesting creating novel things, and part of it is that the process of how to get a computer to be a better software engineer is really interesting.

4. Good thing I don’t have that problem any more and haven’t joined a company about to experience rapid growth.

Shit.

5. Does “inadequate administration” mean that there wasn’t enough, or that the administration staff who were there were personally inadequate?

Yes.

6. Probably you shouldn’t feel particularly bad about failing. Most of the time failure shouldn’t feel bad. You learned something! Good job. It’s reasonable to feel disappointed, but you shouldn’t feel guilty unless you genuinely fucked up.

7. I wouldn’t, but I could.

8. Which you often then feel great about achieving. There’s a real problem, particularly in programming, where by making your life much harder for no good reason you give yourself a great sense of accomplishment when achieving relatively basic tasks.

My somewhat cynical take is that this is the reason for the popularity of a lot of unusual tools and programming languages. e.g. it often seems like the popularity of Haskell is because it turns mundane tasks into a beautiful puzzle to solve.

The result of this is that it is often hard to get people to let go of ways in which they’ve made their life needlessly difficult, because a lot of what they enjoyed about the status quo was that difficulty.