The bug that doesn’t fail any test
Karl Tryggvason has been building In the Long Run, an app that projects your accumulated Strava mileage onto famous long-distance routes around the world. Think: your training log, plotted against the Pacific Crest Trail or a Trans-Europe path. The mileage becomes progress.
He wanted the routes to feel alive. Not just lines on a map — places, landmarks, the small historical detours that make a thousand-mile run feel like more than a thousand miles.
The problem: he doesn’t know most of these places. A route spanning continents has thousands of points he’s never visited. He needed a data source.
He couldn’t find one that fit. So he asked an LLM.
The first pass came back as a list of museums. Every city: one museum, one paragraph. Technically correct. No hallucinations. No factual errors. No broken formatting.
The output was also deeply boring.
“Correct” and “good” are not the same predicate
Programmers have a comfortable worldview. Write a function, write a test, run CI. The signals are mostly objective. Does it compile. Does the test pass. Does coverage clear the bar. Is the response under the latency budget.
Karl’s situation breaks that worldview in a particular way: every observable signal the LLM produced was green. Grammar: fine. Facts: fine. Length: fine. Tone: fine.
And it was still boring.
He tried, in his head, to write a test for “boring.” A few angles:
- Detect tired phrases like “must-see” or “world-famous” → the model learns to swap them
- Force sentence-length variance → the model rotates sentence templates
- Use another LLM as a judge → the judge’s taste is just the training distribution’s mean, which is exactly what failed in the first pass
Every attempt to automate taste is another model imitating taste. Imitation is not taste.
Why two “taste skills” are trending at the same time
The radar picked up a parallel signal the same week:
Leonxlnx/taste-skill— GitHub monthly leaderboard #11, 31,799 stars gained in a month (51,053 total). The repo description: “gives your AI good taste. stops the AI from generating boring, generic slop.”hardikpandya/stop-slop— monthly #18, 8,227 stars gained in a month (12,462 total). Description: “a skill file for removing AI tells from prose.”
Combined, 63,000+ stars. Same project from two angles: package taste as a resource so prompts don’t go in naked.
These don’t contradict Karl’s story. They reinforce it.
The tool layer is working on “make AI less average.” Give it a style. Give it banned phrases. Give it preferences.
The essay layer is admitting “some of this only humans can do.” When the tools are maxed out, judgment still falls back to a person.
stop-slop solves “AI prose sounds like AI.” It does not solve “is this POI interesting.” The second question needs domain knowledge plus personal preference plus project fit. There’s no training set that covers the combination directly.
Three things you can’t write a test for
Extrapolating from Karl’s case, developers today are facing three kinds of “untestable” judgment at once.
1. Taste. Is this good. Is it worth it. How does it compare to the alternatives. taste-skill gaining 31k stars in a month shows the demand is enormous — and the repo itself admits it “stops the AI from generating boring, generic slop.” It blocks “boring.” It does not block “wrong for this project.”
2. Value. Should this be shown to the user. Should this button live here. Does this flow treat people as people, or as inputs. No ground truth exists. The right answer is “for these users, in this product, in this context.” That’s not a test. That’s a stance.
3. Responsibility. Will this change hurt someone. Who maintains this code in ten years. Once we commit, can the team still turn around. The first two require judgment. The third requires someone willing to own the consequences.
CI can’t run these. Code review can’t run these. LLM-as-judge can’t run these — because the judge is also a model, with the same blind spot.
After the tools are maxed out, what’s left is people
Back to Karl’s story. How did he actually solve it?
He didn’t find a better tool. He didn’t iterate on the prompt. He didn’t switch to a larger model. He found people who had actually run those routes and asked them to pick POIs by hand. He needed someone willing to stand behind the picks — not a rule that filters for “good.”
The AI’s role in his stack: draft, aggregate, first-pass triage for unfamiliar territory. The last gate had to be human — someone willing to say “this one’s not interesting, swap it.”
That’s the real point of “You can’t unit test for taste.” The AI era doesn’t have a capability shortage. It has a shortage of people willing to own judgment.
Tools can list ten thousand options. Which one. Why this one. What happens to the nine thousand nine hundred and ninety-nine we didn’t pick. None of that is testable.
One line for engineers. One line for everyone using AI.
For engineers: when you say “I’ll review this PR,” you’re not reviewing the count of bugs. You’re reviewing whether anyone cared about this change. If your review produces the same result the AI would on its own, your review is a tax with no benefit.
For product, content, and anyone using AI at work: when the model hands you something “correct,” follow up with “why this one and not the others.” If you can answer that clearly, you’ve exercised taste. If you can’t, either the tool needs upgrading, or the judgment needs a different owner.
Karl’s piece hit 254 points and 117 comments on HN (as of June 26, 11:00 +08:00) because it named something everyone feels but few say out loud: everyone is rushing to make AI act human, but nobody wants to admit that the most human part — being willing to say “this isn’t fun” — is still something AI can’t supply.
stop-slop gained 8k stars this month. taste-skill gained 31k. Added together, that’s not a complaint about AI writing like AI. That’s people trying to fix it. But the part tools can fix has a ceiling. The part above that ceiling will stay scarce for a while.