When the Answer Isn’t the Problem

I used to keep cheatsheets for vim, bash, regex, and git. Needed roughly in that order.

These weren’t about memorization. Nobody serious ever thought expertise was knowing the exact syntax for a global substitute or the precise incantation for a destructive git command. The cheatsheets were maps that evolved over time as my knowledge grew. They told you what was possible, what was reversible, and what could ruin your weekend.

Over time, those paper cheatsheets gave way to Google. We used to talk about “google-fu,” but that was always a misnomer. It wasn’t about typing keywords efficiently. It was about knowing how to frame a question. Senior developers weren’t better because they knew more answers, they were better because they understood the shape of the problem space. They knew what kinds of answers might plausibly exist.

There’s a bit of Meno’s paradox hiding in there. If you know what you’re looking for, you don’t really need to inquire. But if you don’t know, you wouldn’t recognize the answer even if you stumbled across it. Effective searching requires partial understanding. You have to know what an answer would look like.

That’s how we bridged development and operations for a long time. We never expected individuals to know everything on either side. What we expected was judgment. We expected people to know which commands were sharp, which ones were safe, and which ones demanded backups, staging environments, or a second cup of coffee before proceeding.

Now we’ve crossed a different threshold.

With coding agents, we’re no longer just searching for answers. We’re letting models generate solutions for us. That changes the risk profile in a subtle but important way. The danger isn’t simply that the answer might be wrong. It’s that we don’t understand how the answer was produced or why this solution over another?

I was talking to someone recently about a fuzzy matching application they’d built. It worked. It produced reasonable results. It was, as they put it, “100 percent vibe coded.”

As we talked, it became clear they didn’t actually know how it was doing the matching. Was it making LLM calls? Was it using a Python library? If it was a library, which one? Was it deterministic? Was it probabilistic? Would it behave the same way tomorrow with the same inputs? What were the cost characteristics? The failure modes?

These aren’t pedantic questions. They’re foundational. They determine whether you can reason about the system at all.

We’ve always written code we didn’t fully understand. We’ve always depended on libraries whose internals we couldn’t re-derive. But those libraries came with names and names mattered. Levenshtein distance. Jaro-Winkler. TF-IDF. Even if you didn’t know the math, you knew the kind of thing you were invoking. The name anchored the behavior to a tradition, a set of assumptions, a family of known tradeoffs.

LLM-mediated generation can erase that anchoring. If you’re not deep in the implementation details, you lack even category. Is this logic? Is it statistics? Is it pattern matching? Is it stochastic suggestion dressed up as inference? Without knowing that, you can’t reason about reversibility. You can’t reason about cost. You can’t reason about failure. You don’t even know which commands can ruin your weekend anymore.

This is where I think seniority actually lives, and always has. Senior engineers were never defined by recall or typing speed, or god forbid, lines of code. They were defined by their internal risk models. They knew when an answer felt too easy. They knew which switches not to flip without backups. They knew when to stop and ask: what system am I actually invoking here?

In a world of coding agents, that skill becomes more important, not less. The expertise shifts from “can I write this” to “do I understand the provenance and shape of what just got written.” You don’t need to implement fuzzy matching from scratch, but you do need to know whether you’re relying on a deterministic algorithm or a probabilistic model with opaque behavior.

If there’s a new cheatsheet worth keeping, it isn’t syntax. It’s questions:

Is this deterministic?
Is it reversible?
Is it bounded in cost and time?
Does it degrade gracefully?
Can I explain its failure modes to someone else?

If you can’t answer those, the model didn’t save you time. It just moved the risk somewhere you can’t see. And unseen risk has always been the most dangerous kind.