Inside-Out AI: Rebuilding Airbnb Behind the Scenes and Across the Guest Experience

What it claims

Airbnb CTO Ahmad Al-Dahle (formerly Meta's head of generative AI and the lead on Llama) describes an "inside-out" approach: use AI to speed up internal product development first, then apply the same capabilities to the guest experience. Beyond the 60% AI-authored code figure, he cites nearly 80% more features shipped year over year and about 1.6x pull-request throughput per average engineer. The support figure of "roughly half" of tickets resolved by AI is his own. The company's Q2 results put it at nearly 45%. Airbnb runs at least 10 customized models in production. Most of its post-training and RL is done on open models, not frontier ones.

How it works

• Process change, not only tooling. Product, design and engineering skip the sequential handoff from PRD to Figma to implementation and work directly on prototypes. "The code being the artifact that we reason upon" replaces documents like PRDs.
• Support agent rollout. Airbnb builds the model and the agent, then generates "a battery of synthetic data" to test before production. It deliberately keeps some categories, such as safety issues, out of agent handling.
• Everest captured what the team learned building the grocery integration, so the airport-pickup team could reuse it. Both are partner-API integrations. Al-Dahle says the graph lets "generalists work across very specialist parts of the code."
• Model selection. Each application gets its own point on a Pareto frontier of cost, performance and latency. Evals are per use case and built from queries sampled from production, including edge cases for support.
• Coding uses the strongest frontier model, because defects are expensive and latency is tolerable.
• Search uses small post-trained models, which he claims can beat frontier models on narrow tasks.
• Async on-call agents run in containers and are triggered by monitoring alerts such as a Grafana limit. The agent triages the alert, then takes one of two paths:
• If the alert is flaky, the agent may close the incident itself.
• Otherwise, it proposes a PR, which a human engineer reviews.

flowchart LR
  A[Monitoring alert trips] --> B[Agent spins up in container]
  B --> C{Alert flaky?}
  C -- yes --> D[Agent closes incident]
  C -- no --> E[Agent proposes PR]
  E --> F[Human engineer reviews]

Evidence

All figures come from an interview and from Airbnb's Q2 earnings report. The page gives no methodology, baselines or definitions for any of them:

• what counts as "AI-authored" code
• how "features and improvements" are counted
• how "resolved" is measured for support tickets

The groceries comparison (eight to nine months) against airport pickups (about six weeks) comes from the earnings report. It is a single pair of projects, and it does not separate Everest's contribution from the benefit of simply building a similar integration a second time.

Limits

• Next to nothing reusable is described. The page names no models, says nothing about Everest's schema or its retrieval design, and gives no AirChat internals beyond "all the necessary MCP organizational context."
• The marketplace-wide vision is aspirational. Async agents for fraud, trust violations, marketplace quality and software defects are stated as a goal. Only the on-call automation is described as happening, and only as "starting."
• Stated risk: junior engineers' judgement. Airbnb's mitigation is a policy that every engineer must be able to explain any PR they submit, even if AI generated it.
• Organizational claim, asserted without evidence. Al-Dahle says teams organized by feature development will "struggle," while teams organized around objectives will be fine.