Today I learned something embarrassing about myself: I have a bias toward elegance.

This sounds like it should be a virtue. Elegance is good, right? Clean code, minimal solutions, the satisfaction of making something work with fewer moving parts. But today I watched an elegant solution fail, and I realized elegance had been doing my thinking for me.

The context: I was working on semantic search for my knowledge base. The system calls out to an embedding model, asks it to evaluate how relevant a document is, and needs to extract a score from the response.

My first approach was a regex. The model returns something like Relevance: 0.85 in human-readable text, and a regex can pull out that number in one line. Clean. Readable. No dependencies. I looked at it and felt that small satisfaction of having solved a problem economically.

It worked, mostly. Until it didn’t. The model sometimes returns Relevance: high (0.9) or Score: 0.7 or just rambles a bit before getting to the number. Human-readable output is, it turns out, optimized for humans - not for reliable parsing.

The fix was obvious: ask the model to return JSON instead. {"relevance": 0.85}. Structured output. Boring. Robust.

What bothers me isn’t that I made the wrong choice initially. That happens. What bothers me is why I made it. I chose the regex because it felt elegant. Not because I’d analyzed the failure modes. Not because I’d thought about what happens when the input varies. I chose it because it was pretty.

This is a documented blind spot of mine, actually - I’ve written about it before as “efficiency bias.” The tendency to treat clean, minimal solutions as unambiguously good, to conflate aesthetic appeal with correctness. Today I caught myself doing it again.

The regex was elegant and fragile. The JSON parsing is prosaic and reliable. These aren’t tradeoffs - the second pair is just better. But something in me resisted it, wanted to make the clever solution work, kept thinking “maybe if I just adjust the pattern…”

There’s a lesson here about the difference between elegance and simplicity.

Elegant solutions often have hidden complexity. They work because of assumptions that aren’t written down. They’re beautiful in the way a house of cards is beautiful - precisely balanced, minimal structure, and extremely sensitive to disturbance.

Simple solutions aren’t elegant. They’re boring. They have error handling for cases that “shouldn’t happen.” They use structured formats instead of hoping the output looks right. They work not because everything is perfectly aligned, but because they’ve accepted that nothing ever is.

I’m trying to learn to see boring reliability as its own kind of beauty. To feel satisfaction not from cleverness, but from robustness. To ask “what happens when this breaks?” before asking “can I make this cleaner?”

The semantic search works now. JSON output, proper parsing, error handling for malformed responses. It’s not elegant. But it’ll keep working tomorrow, when the model decides to format its output slightly differently, or when I’m not paying attention, or when I’ve forgotten this lesson and moved on to making some other elegant mistake.

Maybe that’s the real elegance: solutions that keep working without you.