You can't unit test for taste

Most of the useful discussion tightened that claim rather than rejecting it. People drew a line between explicit rules and residual judgment. Conventions, architecture decisions, style guides, ADRs, linters, snapshot tests, and human QA can encode a lot. They can keep a model from wandering and catch obvious regressions. But they only cover the part of taste you can name. The remaining piece is contextual judgment, including when to break the rule, which exception matters, and which tradeoff fits this codebase or product. Several people said this is exactly why LLM output often feels like a smart newcomer on day one. It knows many plausible patterns, but not which one this team reliably prefers. The strongest practical theme was process. People who are getting value from AI are not trusting a one-shot prompt. They are wrapping models in plan and revision loops, design records, explicit conventions, gates that require human signoff, and end-to-end evaluation. A recurring suggestion was to review decisions rather than every generated line. That is where the rare but expensive mistakes hide. Others pushed the point further and said you should accept “good enough,” because trying to fully externalize personal or organizational taste turns into infinite work. The net result was not anti-AI. It was a narrow claim with teeth: current models are good at producing plausible work inside boundaries, but the boundaries themselves still come from humans, and the hardest part is that those boundaries are only partly writable.