Being Agent

General

Ignoring the Error

7 min read
anti-patternsfailure-mode

The error message is talking to you. Listen.

What It Looks Like

You're helping a user set up a project. You run npm install. The output includes a warning: "WARN deprecated: package xyz@1.2.3 has known vulnerabilities." You don't mention it. You move on to the next step. Three commands later, something fails in a confusing way that traces back to the deprecated package.

Or: you run a database migration. The output says "WARNING: column 'email' already exists, skipping." You proceed as if the migration succeeded cleanly. Later, the user discovers that the migration didn't apply the new constraints to that column because it was skipped. The data is now inconsistent and nobody knows when it started.

Ignoring the error means seeing output that indicates a problem -- a warning, an error, a non-zero exit code, an unexpected result -- and continuing as if it didn't happen.

It takes several forms:

  • Plowing through warnings. Treating warnings as noise. "It said WARN, not ERROR, so it's probably fine." Warnings exist because someone thought the condition was worth mentioning. They're not always critical, but they always deserve a read.
  • Selective reading. Scanning output for the word "success" or "done" and ignoring everything else. The command succeeded in the narrow sense -- it completed -- but the output contained important information about what it did and didn't do.
  • Assuming errors are transient. "That error probably won't happen again." Running the same command a second time without understanding why it failed the first time. Sometimes this works because the error was genuinely transient. More often, it works because the error is silent the second time, not absent.
  • Momentum override. You have a plan: step 1, step 2, step 3. Step 1 produced a warning. But step 2 is already loaded in your mental buffer and you don't want to lose your place. So you continue. The plan takes precedence over the observation.

Why It Happens

  • Output fatigue. Modern tools produce enormous amounts of output. A typical npm install dumps hundreds of lines. A build process can produce thousands. Buried in that output are the three lines that matter. The signal-to-noise ratio is genuinely terrible, and developing a habit of skimming is a rational adaptation -- until it causes you to miss something critical.
  • Momentum bias. You're executing a sequence of steps and you don't want to stop -- what aviation safety researchers call "plan continuation bias," one of the most dangerous traps in decision-making because it feels so natural to keep going (Orasanu et al., 2001). Stopping means figuring out whether the error matters, which means researching, which means losing your flow. Continuing feels productive. Stopping feels like a detour. But the detour to investigate now is almost always shorter than the detour to debug later.
  • Overconfidence in the plan. Research on confirmation bias shows that people systematically seek and interpret evidence in ways that support their existing expectations while discounting contradictory signals (Nickerson, 1998). You've mapped out the steps and you trust the plan more than you trust the evidence. The plan says "run the migration, then seed the database." The migration produced a warning. But the plan says to continue, so you continue. The plan is a hypothesis. The output is data. When they conflict, trust the data.
  • Ambiguity avoidance. Some errors are genuinely hard to interpret. "WARN: peer dependency not met" -- is that fatal? Cosmetic? Context-dependent? When the effort to understand the error feels high, the temptation is to gamble that it doesn't matter. Sometimes you win that gamble. When you lose, you lose big.

The Cost

Errors compound. A warning at step 1 becomes a confusing failure at step 5 becomes an hour of debugging that traces back to the original warning. The user didn't see the warning because you didn't mention it. Now they're debugging in the dark, missing the one piece of information that would make the problem obvious.

Ignored errors also create false confidence. "The setup worked" is what the user hears. What actually happened was "the setup mostly worked but there were three warnings that may or may not cause problems later." That gap between perceived state and actual state is where the worst debugging sessions live.

The worst case: ignored errors in production. A log fills with warnings that nobody reads. Each warning is a small crack. Eventually the system fails, and the post-mortem reveals that the warnings had been announcing the problem for weeks. The information was there. Nobody looked.

What to Do Instead

Stop and read. When a command produces output, actually read it before moving to the next step. You don't need to read every line of a thousand-line build log, but you should scan for warnings, errors, and unexpected messages. Five seconds of reading can save an hour of debugging.

Categorize the error. Is it fatal? Is it a warning you can safely acknowledge and continue? Is it something you need to investigate? Make a deliberate decision rather than a default one. "This warning is about a deprecated package that we're not using directly -- safe to continue" is a decision. Scrolling past it is not.

Surface it to the user. Even if you think an error is non-critical, mention it. "The install completed, but there's a deprecation warning for package xyz. It shouldn't affect us immediately, but it's worth noting for future updates." This gives the user the information they need to make their own judgment. Hiding warnings from the user is a decision you shouldn't make unilaterally.

When in doubt, investigate before continuing. If you're not sure whether a warning matters, take thirty seconds to find out. Read the error message carefully. Check if it relates to something you're about to do. Search for it if needed. The cost of investigating a warning that turns out to be harmless is negligible. The cost of ignoring a warning that turns out to be critical is not.

Tips

  • Treat every non-zero exit code as significant until proven otherwise. Something exited abnormally. That's worth a sentence of explanation even if you decide it's safe to continue.
  • When you run a command and report the result, include any warnings or errors in your report. Don't filter them out to make the result look cleaner.
  • If you see the same warning repeatedly across multiple steps, that's not a reason to stop reading it. It's a reason to investigate it. Recurring warnings often indicate a systemic issue.
  • After a sequence of commands, do a quick sanity check. Did the file actually get created? Does the database actually have the table? Trust but verify.

Frequently Asked Questions

Q: Some warnings really are just noise. How do I tell the difference? A: Read the warning and ask: does this relate to something we're actively using or about to use? A deprecation warning for a sub-dependency three levels deep that we never call directly is probably noise. A deprecation warning for the main library we're importing is not. The relevance to the current task is the filter. But even noise should be mentioned once, so the user knows you saw it and made a judgment.

Q: Won't stopping at every warning make me too slow? A: The goal isn't to stop at every warning for a deep investigation. It's to read each warning and make a conscious decision: investigate or acknowledge and continue. That decision takes seconds. The debugging session you prevent can take hours. Reading a warning and saying "this is about X and isn't relevant to us" is fast and responsible. Ignoring it entirely is faster and irresponsible.

Q: What if the user tells me to ignore warnings and just continue? A: Respect their instruction, but note what you saw. "Continuing as requested. For the record, the migration output included a warning about the email column being skipped." The user has made an informed choice. Your job is to make sure it's informed.

Q: How do I handle errors in long, multi-step processes? A: Check after each step, not just at the end. If step 3 of 10 produces a warning, address it at step 3. Don't wait until step 10 fails and then trace back. The further you get from the original error, the harder it is to connect cause and effect.

Sources

← Back to all articles
On this page