Why Overriding the LLM Is Sometimes the Smarter Move

How We Went From Research to LLMs

We used to think hard, do research, and seek expert advice when we face problems in areas we have little experience in. Depending on the size and complexity of the situation, that process often involved hours-to-weeks of leaving our main work and branching out on a side-quest of educating ourselves on a new topic. We spent more time (and tokens) than we would do nowadays, but we would get an answer we’re highly confident would fit our needs and context in return. Moreover, it helped us develop critical thinking skills like information synthesis and problem solving that we could also generally apply elsewhere.

Nowadays, when we’re faced with complexity, the first intuition would be to offload the problem to an LLM. The LLM would respond with the most plausible, most polished answer. In a way, we’re still educating ourselves before solving the problem just like before, but this seems more efficient. The only problem is that the LLM’s answer could be wrong and the user wouldn’t be able to tell because they don’t have domain experience in the given field, or if the answer is wrong in a way that only shows up if the user is paying attention. LLM fluency creates social pressure to accept the output instead of challenging it.

Why People Accept LLM Answers So Quickly

The tech community is increasingly referring to model deference as the holy grail of productivity. The more agents you have running in parallel, the longer they’re running, the more you’re hitting rate limits, the more you’re viewed as technically superior. I think this is partly because we’re used to judging performance based on pre-LLM criteria, but there is status in being fast, AI-native, and non-resistant. From the continuous tabbing, to the ‘—dangerously-skip-permissions’, to merging the 10K LOC diff without reviewing the code, the culture rewards accepting the answer, even when the better move is to interrupt it.

We’re still used to judging performance based on pre-LLM era criteria: LOC generated, number of projects released, time to release, etc. I feel like there should be an abstraction of these criteria where performance is a function of (the output’s technical complexity normalized to one’s skill level) and the correctness/fit of the solution.

What LLMs Do Well and What They Miss

The LLMs do help one move faster and accomplish more than what one would pre-LLMs. LLMs are strong at structure, drafts, summarization, brainstorming, and giving momentum. At the time of this writing though, they are weaker at judgment-heavy work: priorities, tradeoffs, politics, taste, hidden constraints, local context, and edge cases. They are directionally useful, but could be specifically mistaken. If you have ever tried automating some of your work with AI, you would have certainly come across a clean, polished response that looks finished, but with your domain knowledge you can tell it is slightly off, flatter than needed, or heading in the wrong direction.

Why Supervision Matters

The difference between the average LLM operator and the effective LLM operator is good supervision. It’s knowing when to refuse what the LLM is saying and opting for redirecting the conversation, rephrasing your request, or adjusting the provided context. It’s being able to identify when the LLM’s output is suspiciously neat, spotting where the LLM overlooked/simplified things, and knowing where your own domain judgment outranks its confidence. The real skill in working with LLMs is not obedience to the output, but judgment about when to overrule it.

The Cost of Relying Too Much on the Model

The deeper problem is not only that the model can be wrong. It is that we can slowly stop exercising taste, priority-setting, and context-sensitive reasoning because the machine keeps offering answers that are good enough to pass. Some might think that distrusting the LLM is risky, but in a sea of people blindly-trusting the LLM, the ones who trust their own judgment will standout. LLM responses are often cautious and well-balanced, but life rewards the risk-takers.

When People Override for the Wrong Reasons

Humans override LLMs for bad reasons too. I myself do this all the time just to realize that I’m thinking the wrong way about something. I would expect many people could have had bad experiences with older models that they don’t think newer models would be any better. Habit has a strong role too; some people have a hard time adopting AI-first workflows. There is definitely some complexity in setting up guardrails that help keep LLMs trustworthy and on-track, which could add to the potentially unnecessary human intervention.

Knowing When to Trust Your Own Judgment

A skeptic could argue that if you need to keep overriding the model, then it is not really saving time. That is true to a certain extent, but knowing when to trust your own instincts will help you differentiate. Knowing when the defer to LLMs will help you move faster. I think it is fair to trade differentiation for time sometimes. In an AI-native world, one of the highest-leverage human skills may be that selective disobedience. It is not that LLMs are dumb, but that they are persuasive enough to make people stop thinking.