I’ve been building an office golf pool with Claude Code. It’s called Pin High Duel, and the mechanics are simple: take the tournament field, split the golfers into groups, and everybody picks one golfer from each group. The pool creator gets to pick how many groups are in the pool.  Best combined finish wins.

The interesting engineering question is hiding in the middle of that sentence: how do you split a field of golfers, usually 156, into fair groups?

Claude Code was happily off building a model for it. Multiple modes, balancing logic, handling for every conceivable edge case. It worked. It was tested. It was more code than the problem deserved, and I could not have told you that yet, because I hadn’t really looked.

Then, as I was reviewing the PR, decades of pattern matching tapped me on the shoulder, and I typed one sentence: it should be field divided by picks with a max of 10 [golfers per group].

The reply came back instantly: “That’s a cleaner spec than what I built – and it actually simplifies the code into one formula instead of two modes.” Each group holds field divided by picks golfers, capped at 10, and the last group takes whatever’s left. One formula no matter how many groups your pool is set up for. The two modes and all of their edge cases just evaporated.

(The pool is real, by the way. You can play here: pinhighduel.com. Bring your bracket instincts, and until I get Stripe configured you can set up a pool and play for free!)

Recognizing simple is easy, finding it is hard

That exchange stuck with me, and not as a gotcha about AI. Claude did nothing wrong. It built exactly what I asked for, quickly and correctly. And notice what happened when I offered the simpler shape: it recognized it instantly, called it cleaner than its own work, and rewrote without a flinch. Recognizing simple is easy. Finding simple is the hard part.

Finding it is a skill that takes decades, and it did not come from coding. It is the skill of bringing the simple out of the complex, and it shows up everywhere: in math, in code, in org design, in test harnesses (in personal life!). The brute force version of each of those exists and mostly works. More terms, more branches, more boxes, more cases. The elegant version does the same job with less, and getting there is never the first draft.

It is not a common skill in people either, let’s be honest. But right now it looks like one of the telling differences between AI capability and human experience. The tools generate. Experience removes excess until the statue appears.

The shorter email

One of my mentors, Joe Austin, had a line I’ve used for years: “I would have written a shorter email, but I didn’t have the time.” (The joke is older than email, Pascal usually gets the credit, but Joe is the one who made it stick for me.)

I use it constantly because it names something true: short is not the lazy version, short is the expensive version. Getting a message, a design, or a function down to its core essential bits without losing the context takes thought, wisdom, experience, and time. The long version is what you produce on the way to understanding. The short version is what you produce after working through it.

Volume is now free

Here is why this matters more today than it did five years ago. With vibe coding and tools like Claude Code, GitHub Copilot, and Cursor, writing volumes of code has become incredibly easy. Volume is now free. Anyone can produce ten thousand working lines before lunch, and a lot of it will even be good.

Which means the scarce skill has flipped. It used to be hard to produce and easy to want less. Now it is easy to produce, and the rare, senior level move is the subtraction: the person who looks at the two modes and the balancing logic and says, quietly, it should be field divided by picks with a max of 10.

There is something amazing about the simplest solution that actually works. It is beautiful in a way that sprawling, technically correct code never is, closer to artwork than engineering. You know it when you see it, the same way Claude knew it when I typed it.

The tools will keep getting better, and honestly, I expect they will learn some of this. But today? Hold on to the people who can delete. They will write you a shorter function, if you give them the time.