RAG-powered Q&A shipped and delivered value. The pattern — chunk documents, embed them, retrieve relevant chunks for a query, feed them to an LLM with the question — works reliably in production when implemented carefully, and the "carefully" part is about chunking strategy, prompt engineering, and evaluation, not about exotic architecture. The systems that shipped successfully all share a common trait: they treat the LLM as a component in a larger system, not as the entire system. The LLM generates text; the surrounding system handles retrieval, citation, verification, and user feedback. That architectural modesty — the LLM is a function, not a product — is what separates the systems that work from the systems that don't.

Code generation shipped and delivered value, but not in the way the hype predicted. The prediction was that AI would write entire applications from prompts; the reality is that AI writes fragments — functions, tests, boilerplate — that a human reviews, integrates, and modifies. That's still valuable (the fragments are a productivity multiplier for engineers who can evaluate them), but it's a tool for engineers, not a replacement for them. The products that tried to replace engineers — "describe your app and we'll build it" — failed, because the gap between generated code and production-ready code is larger than the demos suggested, and closing that gap requires the engineering judgment that the tools were supposed to replace.

Anomaly detection shipped and delivered value, and it's the AI application that surprised me the most by being more useful than I expected. Simple statistical models — rolling averages, standard deviation thresholds — flag anomalies that humans miss, and the notification loop (anomaly detected, human notified, human investigates) is tight enough that false positives are a minor annoyance rather than a system-killer. The lesson is that "AI" doesn't have to mean "LLM" — the simpler machine learning techniques, applied to the right problems, deliver value that's more reliable and more maintainable than the LLM-based approaches that get more attention.

Fully autonomous agents were hype. The vision was that you'd give an AI agent a goal and it would autonomously break the goal into steps, execute each step, and deliver the result. In practice, agents are unreliable in ways that make them unsuitable for production: they get stuck in loops, they make incorrect assumptions about the environment, they produce confident-sounding wrong answers, and the failure modes are hard to predict or debug. The agents that work in demos work because the demo is a controlled environment; in production, where the environment is messy and the stakes are real, the unreliability becomes unacceptable. The fix — having a human in the loop for every agent action — negates most of the autonomy that was supposed to be the point.

AI-generated reports were hype, for the reason I described in the AI-in-ERP case study: 80% correct isn't good enough when the 20% wrong requires a full review. The economics don't work: generating a report that's 80% correct and reviewing it to find the 20% wrong takes longer than writing the report from scratch, because reviewing requires reading every word while writing only requires producing each word. The products that shipped AI report generation either pivoted to AI-assisted report generation (the AI drafts, the human edits) or failed. The assisted version is useful; the autonomous version isn't, and the difference is whether the AI is positioned as a tool or as a replacement.

I'd stop building AI features that don't have a fallback. The pattern of "we'll add AI and it'll be magical" without a clear non-AI path is a recipe for features that get used once and abandoned. Every AI feature should answer the question: what does the user do when the AI is wrong? If the answer is "nothing, because there's no way to override or correct the AI," the feature isn't ready for production. The human override isn't a nice-to-have; it's the mechanism that makes the feature trustworthy enough to use, and without trust, the feature is dead on arrival regardless of how impressive the underlying model is.

I'd also stop building AI features that compete on model quality rather than on system quality. The models are commoditizing — the difference between the best model and the third-best model is smaller than the difference between a well-designed system and a poorly-designed one, and it's shrinking. The competitive advantage isn't in having the best model; it's in having the best data pipeline, the best retrieval, the best evaluation, the best user feedback loop. The teams that invest in the system around the model will outperform the teams that obsess over the model itself, because the system is where the value compounds and the model is where it doesn't. That lesson — system over model — is the one I'd take into the next cycle of AI development, and it's the one I'd recommend to anyone building AI features in 2026 and beyond.