AI Reality Check: Why Everyone Isn't Using AI for Everything

Gabriel Weinberg, founder of DuckDuckGo, recently published a post titled "No, everyone is not using AI for everything" that struck a nerve on Hacker News, racking up 91 points and 56 comments. The argument: AI consumption is widespread but far from universal, especially for tasks requiring reliability, speed, and nuance. The HN community largely agrees, and they have the scars to prove it.

The Hacker News Reality Check on AI Overhype

Weinberg's core argument is simple: people consume AI (ChatGPT, GitHub Copilot, AI Overviews) at scale, but that doesn't mean they use it for everything. Many tasks are still better served by deterministic systems—simple, predictable, and efficient. For nuanced decisions, users fall back to traditional interfaces. AI is a supplement, not a replacement.

The HN thread is full of real-world failure stories. One commenter wrote:

I've noticed several companies replacing deterministic systems in their support flows with an LLM version that is slower and worse. Many interfaces simply aren't better with AI added.

Another shared a sobering experience with LLM-generated code:

I'm realizing how truly bad the code it wrote was. I mean, terrible. That's jarring, because it did a great job with #1 [backend].

The sentiment: AI works great in some areas but fails spectacularly in others.

Real-World Failures of LLMs in Production

Weinberg is right: consumption is not adoption, and certainly not effective use. LLMs excel at exploration, brainstorming, and code generation in well-understood domains (like PHP backend), but crumble under high-stakes tasks (like native iOS UI code). A developer using Copilot to draft a function is not the same as a company building a customer support pipeline around a chatbot with no fallback.

The implicit trade-off: flexibility vs. correctness. Deterministic systems (well-written search index, hand-crafted rule engine) are predictable and debuggable. LLMs are probabilistic, introducing failure modes that are hard to catch until production. Many teams are silently rolling back AI features after discovering latency, cost, or quality issues.

When to Stick with Deterministic Systems

If you're building software today, resist the hype and ask: "Is this task better with AI or without?" For many problems, the answer is still "without." Consider customer support: instead of an LLM chatbot that hallucinates, a deterministic FAQ search with fuzzy matching can be faster, cheaper, and more accurate.

# Simple deterministic FAQ search (pseudo-code)
def find_answer(query):
    faq = {
        "return policy": "We accept returns within 30 days.",
        "shipping cost": "Free shipping on orders over $50."
    }
    for key, answer in faq.items():
        if key in query.lower():
            return answer
    return "Please contact support."

This isn't sexy, but it works. For code generation, GitHub Copilot recommends treating suggestions as a starting point, not a final answer. Adult supervision is mandatory.

Lessons for Builders: Measure Failure Modes

If you replace a deterministic system with an LLM, set up a circuit breaker that falls back to the deterministic path when confidence is low or latency spikes. Tools like LangChain's fallback help, but the simplest approach is a feature flag with a kill switch.

The Verdict: Trust Boring Code

Yes, you should care—if you're a developer or product manager evaluating where to insert AI. No, if you're building a prototype where failure is cheap. AI is a powerful tool, but not a magic wand. The most successful builders know when to not use it. As the HN thread reminds us: many problems are best solved by boring, deterministic code. Trust the boring code, and use AI only where it demonstrably improves the outcome.