A new wave of post-mortems from generative AI builders points to a hard truth: the bottleneck for AI products has almost nothing to do with the model. The same handful of mistakes keep showing up, and they live in the realm of people, process, and product judgment, not GPUs or parameters.
When the tool is wrong for the job
The temptation to slot a large language model into every problem has produced some spectacular misfires. One team proposed pointing an LLM at a typical household's energy use and the hourly power rate, then asking it to draft a schedule that cut bills. Their pilot showed a 30% drop. Solid result, until you ask the obvious follow-up: how does this compare with shifting laundry and EV charging past 10pm, or running a basic optimization routine? Cheaper, deterministic methods like linear programming have been solving variants of this problem for decades. The team never came back with a benchmark. They quietly shelved the product.
The pattern repeats across industries. Telecoms want LLMs to flag anomalies in network traffic. Contact centers want them to forecast call volume. One hospital reportedly asked an LLM to detect malnutrition from intake notes, a use case that should worry any clinician. "We solved the problem" and "we used generative AI" are two different headlines, and too many teams prefer the second one. AI is a tool, not a strategy.
The product is the moat, not the model
With most teams drawing from the same short list of foundation models, the competitive edge lives somewhere else: in the product. That is also where most teams lose.
A team building a meeting-transcript summarizer spent weeks debating whether users preferred three-sentence or five-sentence summaries. User research killed both options. Customers did not want summaries at all. They wanted their own action items, pulled out cleanly. The summary was a proxy for the real need.
A skill-fit chatbot learned an even harder lesson. When users asked whether they were qualified for a role, the honest answer "you are not a fit" was technically correct and commercially useless. People wanted a path forward: here is the gap, here is what to do about it.
Intuit, working on a tax-questions assistant, discovered that users hated typing into a blank chat box. They did not know what to ask, or what the bot could answer. The fix was almost embarrassingly simple. Add three suggested questions above the input. Once users clicked instead of typed, adoption climbed and feedback turned positive.
The 0-to-60 versus 60-to-100 trap
The first usable demo is cheap. The product that survives in production is not.
A team that built an AI assistant reported a familiar curve. They hit roughly 80% of their target experience inside a month, then spent another four months grinding from 80% to 95%, with each additional percentage point taking longer than the last. Hallucinations, edge-case prompts, and quiet regressions in the underlying model kept eating time. The UltraChat paper makes the same point in fewer words: getting from 0 to 60 is easy, getting from 60 to 100 is where the real cost lives.
A second team, building AI sales assistants for ecommerce, ran into tonal drift. Their system prompt asked the bot to sound friendly and confident, and the bot almost never got the balance right. Building a deterministic test suite was effectively impossible because the space of customer queries is infinite.
Underneath the model quality issues sits infrastructure risk. One team reported timeouts on roughly one in ten API calls, and the rest sometimes shifted behavior after a silent model update from the provider. None of this shows up in a demo.
Judges that need judging
LLM-as-a-judge has become the default way to grade AI outputs at scale. It is fast, cheap, and quietly dangerous. The judge is itself a model. It can drift. It can be biased by prompt wording. It can give confidently wrong scores that look like real metrics on a dashboard.
The teams shipping the most reliable products pair automated judges with daily human review. Domain experts work through a slice of outputs every day, anywhere from thirty to a thousand examples. That human signal does three jobs at once: it keeps the judge honest, it surfaces patterns in real user behavior, and it builds the annotation guidelines that can later be reused for fine-tuning.
The annotation guidelines matter as much as the labels. If a human rater cannot follow the rubric, the model will not either. A clean rubric becomes a forcing function for prompt design and, eventually, a training dataset.
Strategy beats crowdsourcing
Early in the enterprise gen AI rush, plenty of leaders punted on strategy. They asked employees for use-case ideas, took the loudest or most convenient, and shipped. The result was an embarrassment of low-value side projects: a thousand text-to-SQL tools, a thousand Slack bots, a billion code plugins, none of them pulling real weight.
Smart employees will optimize for the problems in front of them, not the problems that pay back most. Without a portfolio view, the org ends up with many small wins that add up to no visible return, and the easy conclusion to draw is that AI does not move the needle. That conclusion is wrong, but it is also self-inflicted.
What to watch
The pattern from the past two years is clear. Model quality keeps improving and product quality keeps lagging. Teams that invest in problem selection, UX research, evaluation rigor, and roadmap discipline will pull ahead. Everyone else will keep shipping demos that nobody uses, then blame the technology.