The Normalization of Inexplicable Failures

Original Article ↗ Hacker News Discussion ↗

Software and connected devices increasingly fail in ways that users and even developers can’t explain, from opaque cloud outages to cryptic errors in modern cars, fostering a culture of “stupid thing sucks” rather than clear ownership and root-cause analysis. Commenters link this shift to probabilistic systems and AI-driven tooling, management pressure for speed over rigor, and reduced emphasis on traditional engineering practices, warning that normalizing such inexplicable failures erodes trust and reliability across the stack. Others argue that with proper evaluation, testing, and constrained use in safety-critical domains, AI can still be a powerful aid rather than a source of chaos.

Scope of “inexplicable failures”

  • Commenters see opaque, un-debuggable failures as increasingly common across:
    • Cloud services and APIs that intermittently 5xx with “just retry” as the norm.
    • Consumer devices (especially cars) showing vague warnings and flaky connectivity with no clear diagnosis.
    • Everyday software/OS behavior where “turn it off and on again” is the de facto fix.
  • Some argue this has always been true; others think “move fast and break things,” continuous deployment, and reduced QA have noticeably worsened it.

Determinism, probabilistic systems, and AI

  • Deterministic systems are praised for predictable failure modes and clear contracts; probabilistic/LLM-based systems are seen as powerful but hard to reason about or guarantee.
  • Concern: normalizing probabilistic behavior in core libraries, infrastructure, and compilers could erode the reliability of the entire stack.
  • Counterpoint: even AI-generated code is still deterministic once written; the real problem is maintainability and design quality, not probability per se.

Engineering culture, quality, and accountability

  • Disagreement over whether “bugs are inevitable”:
    • One side: bugs are largely a business choice; “no bugs” is possible but too expensive for most.
    • Other side: deep stacks and complex distributed systems make some failures effectively unavoidable; design for imperfection and resilience (e.g., chaos testing).
  • Stories of:
    • Overengineering vs YAGNI debates, with edge cases dismissed until they bite.
    • Enterprises papering over systemic issues with cron restarts and tolerance for horrible tail latencies.
  • Several tie “inexplicability” to lack of accountability: blame can be pushed to vendors, clouds, or now “the AI.”

User experience and error reporting

  • Opaque error dialogs (“something went wrong”) are widely criticized.
  • Many would prefer detailed, even technical, messages and proper logging over vague alerts.
  • Minimalist “it just works” design is seen as having an “evil twin”: “it just doesn’t work, and you can’t see why.”

High‑stakes domains and differing tolerances

  • Traditional banking and aviation are cited as domains that still demand low error rates and traceable behavior, though there are counterexamples and consumer-visible banking glitches.
  • Argument that exposure to such domains would raise developers’ standards; others emphasize management incentives (speed, cost) overpower quality concerns.

LLMs, agentic dev, Jev, and evals

  • Many use LLMs heavily and report they:
    • Accelerate development, including tests.
    • Can both introduce and fix bugs quickly, if paired with strong testing and determinism/ reproducibility culture.
  • Worries:
    • “Vibe-coded” OSS and business software: more features, but incoherent UX, performance issues, and difficult-to-debug behaviors.
    • Managers using AI to ship more, faster, normalizing silent 10% failure rates as “good enough.”
  • Classification services like Jev:
    • Some report validating its confidence scores and finding strong, cost-effective performance.
    • Others stress that this validation (evals, benchmarks, A/B tests) is exactly what’s often missing; trusting the tool’s own confidence without independent evals is called out as dangerous.
  • Broad agreement: good evals are hard but essential. Without them, exciting AI demos can conceal mediocre real-world performance and deepen the culture of inexplicable failures.