La AI escribe el 60 % del código de Airbnb, pero el cambio está en los relevos

El CTO de Airbnb, Ahmad Al-Dahle, afirma que la AI crea ya el 60 % del código de la empresa, que las funciones y mejoras entregadas crecieron casi un 80 % interanual y que el flujo medio de pull requests por ingeniero subió unas 1,6 veces. Son cifras aportadas en su entrevista con Latent Space y muestran la escala del cambio interno, no una prueba independiente de calidad.

El código sustituyó documentos y los prototipos acortaron relevos

Según Al-Dahle, Airbnb cambió la secuencia de trabajo entre producto, diseño e ingeniería. En lugar de encadenar requisitos, diseño en Figma, implementación y pruebas, los equipos pasan antes a un prototipo. El código se convierte en el artefacto central sobre el que razonan juntos.

La transformación llega a operaciones. Atención al cliente fue el primer despliegue de AI visible para usuarios, y el CTO asegura que los agentes resuelven por sí solos aproximadamente la mitad de los casos. Los resultados del segundo trimestre situaban la cifra cerca del 45 %. Airbnb excluye deliberadamente los asuntos de seguridad.

Everest lleva la experiencia de un equipo al proyecto siguiente

El grafo de contexto interno Everest usa LLM, embeddings y AI retrieval para conectar conocimiento de la organización y la codebase. Airbnb dice que el servicio de compra de alimentos requirió entre 8 y 9 meses, mientras la integración similar de traslados al aeropuerto tardó unas 6 semanas. El segundo equipo reutilizó aprendizajes capturados en Everest.

Esta lección importa más que el porcentaje de código creado por AI. El valor aparece cuando la empresa captura contexto, ejecuta evals por caso de uso y selecciona modelos por coste, rendimiento y latencia. Airbnb opera al menos 10 modelos personalizados y acepta un equilibrio diferente para búsqueda, código y soporte.

El porcentaje de código generado no cuenta defectos en producción

Las cifras del 60 %, 80 % y 1,6 veces proceden del CTO que dirige el cambio. La entrevista no publica metodología ni un grupo de control común. Más pull requests pueden significar más producción, cambios menores o más correcciones. Sin datos de incidentes, rollbacks y tiempo de review, la calidad sigue abierta.

Al-Dahle reconoce otro riesgo: los ingenieros júnior pueden perder parte de la experiencia que forma el criterio. Por eso Airbnb exige que cada ingeniero pueda explicar el código de un pull request aunque lo haya generado la AI.

Los agentes on-call medirán si el contexto crea responsabilidad

Airbnb empieza a usar agentes asíncronos en contenedores activados por eventos de monitorización. Un agente puede clasificar un incidente, proponer un pull request o cerrar una alerta defectuosa. Ahí Everest y los evals afrontarán trabajo de mayor riesgo.

Conviene medir incidentes causados por cambios de AI, tiempo de review humano, pull requests rechazados y resultados de soporte por tipo de problema. La mejora de flujo solo vale si detrás no crece la cola de reparaciones.

El veredicto de Lilith

Airbnb ha sentado a la AI entre el prototipo y producción, y el 60 % es solo el número de la puerta. Dentro importa si un ingeniero explica cada pull request y el agente on-call nocturno deja un rastro legible.