YouTube2Blog

Why Most AI Products Fail: Lessons from 50+ AI Deployments at OpenAI, Google & Amazon

A bilingual blog article converted from YouTube video

Why Most AI Products Fail: Lessons from 50+ AI Deployments at OpenAI, Google & Amazon

Lenny's Podcast

Feb 10, 2026
Lenny's Podcast11 min

Why Most AI Products Fail: Lessons from 50+ AI Deployments at OpenAI, Google & Amazon

Having worked on over 50 AI product deployments across major companies like Amazon, Data Bricks, OpenAI, and Google, my co-presenter Kiti Bottom and I (Aishwaria Raanti) have gained a crucial insight: building AI products is fundamentally different from traditional software. We've witnessed a reduction in skepticism over the past year, with many companies now rethinking their user experiences and workflows. This shift involves deconstructing and reconstructing processes to build successful AI products. However, execution remains a significant challenge because the field is only a few years old, lacking established playbooks. The AI product lifecycle, both pre- and post-deployment, differs from traditional software, demanding tighter collaboration and shared feedback loops among product managers, engineers, and data teams.

The Fundamental Differences of AI Products

While there are similarities between building AI and traditional software systems, two core distinctions fundamentally alter the product development approach.

Non-Determinism

The first difference most people tend to ignore is non-determinism. In traditional software, you interact with a well-mapped, predictable decision engine or workflow. For example, booking a flight on a travel website follows a consistent path, even if the flight options change.

With AI products, this predictability is largely replaced by a fluid, natural language interface. This means:

  • Input Side: Users can communicate their intentions in countless ways, making their behavior hard to predict.
  • Output Side: The underlying LLM is a non-deterministic, probabilistic API that acts as a black box. Its responses are highly sensitive to prompt phrasing, making the output surface unpredictable.

"You don't know how the user might behave with your product and you also don't know how the LLM might respond to that."

We are essentially working with an unpredictable input, output, and process. While this fluidity is beautiful because it lowers the bar for users (they can be as natural as with humans), it simultaneously complicates ensuring that user intent is rightly communicated and translated into deterministic outcomes with non-deterministic technology.

The Agency-Control Trade-Off

The second critical difference is the agency-control trade-off. There's a strong obsession with building autonomous agents that can perform tasks for you. However, every time you hand over decision-making capabilities or autonomy to an agentic system, you relinquish a degree of control.

"Every time you hand over decision-m capabilities to agentic systems, you're kind of relinquishing some amount of control on your end."

This means that an AI agent must earn your trust and prove its reliability before it can be given significant decision-making power. Instead of starting with fully autonomous agents, it's akin to training for a half-marathon by gradually building up, rather than attempting the full distance on day one. This deliberate approach, starting with minimal impact and more human control, allows teams to gain confidence in AI capabilities before gradually increasing agency.

AI product development lifecycle showing different stages

The "Continuous Calibration, Continuous Development" Framework

These fundamental differences necessitate a new product development methodology. We advocate for a "continuous calibration, continuous development" framework, which involves building step-by-step:

  1. Start with high human control and low AI agency.
  2. Gradually increase AI agency as you gain confidence in its behavior and reliability.

This approach forces a "problem-first" mindset, preventing teams from getting lost in the complexities of the solution and instead focusing on the core problem they are trying to solve. It's particularly important given that a significant number of enterprises (around 74-75%) cite reliability as their biggest problem, hindering the deployment of customer-facing AI products due to perceived risks.

Here are some examples of this progression:

  • Customer Support Agent:
    • V1 (High Control, Low Agency): The AI acts as a suggestion engine for human support agents, who provide feedback on its utility.
    • V2: The AI directly provides answers to customers, but with human oversight or easy escalation paths.
    • V3 (Low Control, High Agency): The AI autonomously performs actions like issuing refunds or raising feature requests, having built up trust.

"If you start all with all of this on day one, it's incredibly hard to control the complexity. So we recommend like you know building step by step and then increasing it."

  • Insurance Pre-authorization:

    • AI can handle low-hanging fruit like blood tests or MRI pre-authorizations where approval criteria are clearer.
    • High-risk cases, such as invasive surgeries, remain strictly human-in-the-loop.
    • Crucially, all human actions should be logged to create a "flywheel" for continuous system improvement.
  • Coding Assistant:

    • V1: Suggests inline code completions and boilerplate snippets.
    • V2: Generates larger code blocks (e.g., tests, refactors) for human review.
    • V3: Applies changes and opens pull requests autonomously.
  • Marketing Assistant:

    • V1: Drafts emails or social media copy.
    • V2: Builds and runs multi-step marketing campaigns.
    • V3: Launches, A/B tests, and auto-optimizes campaigns across various channels.

Limiting autonomy is vital not just for managing complexity but also for mitigating risks. Uncontrolled AI agents can cause significant damage, such as corrupting databases, sending unintended communications, or falling victim to prompt injection and jailbreaking attacks, which remain persistent challenges.

A framework illustrating continuous calibration of AI products

Patterns for Successful AI Product Development

Successful companies building AI products often exhibit a "success triangle" built on three dimensions: great leaders, a good culture, and technical progress.

Great Leaders are Hands-On and Vulnerable

Leaders must actively re-learn their intuitions, as AI fundamentally changes long-held assumptions. This requires vulnerability and a willingness to acknowledge that prior expertise might not directly translate.

  • Example: Gajen, the CEO of Rackspace, famously blocked 4-6 AM daily for "catching up with AI." During this time, he'd consume AI news, listen to podcasts, and engage with experts to rebuild his understanding.

"Leaders have to get back to being hands-on... You must be comfortable with the fact that your intuitions might not be right and you probably are the dumbest person in the room and you want to learn from everyone."

This top-down approach is crucial because it ensures leadership buy-in and prevents misaligned expectations or skepticism that can hinder bottom-up innovation.

Foster a Culture of Empowerment

Many companies, especially large enterprises, face a "fear of missing out" (FOMO) culture that can inadvertently lead to fear among employees of being replaced by AI. This is counterproductive, as subject matter experts are invaluable in guiding AI behavior.

Instead, companies should cultivate a culture of empowerment, framing AI as a tool for augmentation. The goal is to help employees "10x what you're doing," rather than fearing job displacement. AI often opens up new opportunities, allowing employees to focus on higher-value tasks and expand their impact.

Obsession with Workflows and Building Flywheels

Technically successful teams are deeply obsessed with understanding their existing workflows. They don't just "slap an AI agent" onto a problem but instead meticulously identify which parts of a workflow are ripe for AI augmentation versus those that require human-in-the-loop interventions or deterministic code.

They iterate quickly, building systems that don't compromise the customer experience but provide sufficient data to estimate AI behavior. The focus is on building "flywheels" for continuous improvement:

"It's not about being the first company to have an agent among your competitors. It's about have you built the right flywheels in place so that you can improve over time."

This means being skeptical of promises like "one-click agents" that claim immediate, significant gains. Enterprise data and infrastructure are often messy, requiring 4-6 months of dedicated work even with the best data layers to see substantial ROI from AI in critical workflows. Investing in pipelines that learn and evolve over time is far more effective than seeking out-of-the-box solutions.

A visual showing the balance between human control and AI agency

The Role of Evals in AI Development

The debate around "evals vs. vibes" or "evals vs. production monitoring" often creates a false dichotomy. Both are critical and serve distinct purposes in ensuring AI product reliability.

  • Evals: These are curated datasets that reflect trusted product thinking. They test specific behaviors, edge cases, or critical failure modes that your AI agent should or should not do.
  • Production Monitoring: This involves deploying your application and tracking how customers use it in the wild. It uses key metrics, explicit feedback (e.g., thumbs up/down), and implicit signals (e.g., users regenerating an answer in a chatbot) to understand real-world performance. With AI agents, this monitoring needs to be far more granular.

The ideal workflow integrates both:

  1. Initial Testing: Before deployment, perform basic testing using evaluation datasets to ensure fundamental functionality and avoid known failure modes.
  2. Real-World Discovery: Use production monitoring to identify unexpected issues or emerging failure patterns that you couldn't predict upfront.
  3. Targeted Improvement: When a new failure mode is discovered via monitoring, create a specific evaluation dataset for it.
  4. Iterate: Make changes (to tools, prompts, models), re-test with your updated evals (to prevent regression), deploy, and continue monitoring.

"Eval are important, production monitoring is important but this notion of only one of them is going to solve things for you that is completely dismissible in my opinion."

The Semantic Diffusion of "Evals"

The term "evals" has become a victim of "semantic diffusion," where its meaning has been diluted by various interpretations. It's used to refer to error analysis, expert notes, LLM judges, and even external benchmarks. This can lead to confusion. While everyone agrees on the need for an actionable feedback loop for AI products, how this is implemented varies greatly depending on the application. For complex use cases, relying solely on LLM judges can be impractical as new failure patterns continuously emerge. In such scenarios, focusing on user signals and quick fixes, while checking for regressions, often makes more sense.

"Don't be obsessed with prescriptions. They're going to change."

OpenAI's Codex Approach

At OpenAI, the Codex team adopts a balanced approach, integrating both robust evals and extensive customer feedback. Coding agents are unique due to their high customizability for engineers, making it nearly impossible to build comprehensive evaluation datasets for every possible interaction or integration.

  • Core Evals: Specific evaluations are maintained to ensure that core product functionality is not broken by new changes.
  • Customer-Centric Monitoring: Extreme care is taken to understand how customers use the product. For instance, with a code review product, A/B testing identifies whether changes find the right mistakes and how users react. Implicit signals, like users switching off the product due to incorrect suggestions, are closely monitored.
  • "Vibes" and Community Engagement: Engineers also rely on "vibes" during development and actively engage on social media to understand user problems and fix them quickly. When new models are launched, engineers perform "custom evals," testing against a list of hard problems and observing overall product behavior.

"I don't think like if anybody's coming and saying that like my I have this concrete set of evas that I can like bet my life on and then I don't need to think about anything else like it it's not going to work."

Actionable Takeaways

To build successful AI products and avoid common pitfalls, consider these actionable strategies:

  • Acknowledge AI's Unique Nature: Embrace the non-deterministic input/output and the agency-control trade-off inherent in AI products from the very beginning of your design process.
  • Implement "Continuous Calibration": Start with high human control and low AI agency. Incrementally increase AI's autonomy only as trust and reliability are proven through real-world performance and feedback.
  • Cultivate Leadership & Culture: Ensure leaders are hands-on, willing to relearn intuitions, and champion a culture that empowers employees to augment their work with AI rather than fearing replacement.
  • Be Workflow-Obsessed, Not Tech-Obsessed: Deeply understand your existing workflows to apply AI strategically. Focus on building robust feedback loops and "flywheels" for continuous improvement, and be wary of "one-click" solutions for complex problems.
  • Integrate Evals and Monitoring: Utilize both targeted evaluation datasets (for known issues and core functionality) and granular production monitoring (for discovering emergent problems and real-world behavior) to create a comprehensive system for AI product reliability and improvement.