AI pisze 60 % kodu Airbnb, lecz większą zmianą są krótsze przekazania

CTO Airbnb Ahmad Al-Dahle mówi, że AI tworzy obecnie 60 % kodu firmy, liczba dostarczonych funkcji i ulepszeń wzrosła rok do roku prawie o 80 %, a średnia przepustowość pull requestów na inżyniera zwiększyła się około 1,6 raza. Dane pochodzą z jego rozmowy z Latent Space i pokazują skalę zmiany wewnętrznej, ale nie są niezależnym dowodem jakości oprogramowania.

Kod zastąpił część dokumentów, a prototyp skrócił przekazania

Według Al-Dahle Airbnb zmieniło kolejność pracy zespołów produktu, designu i engineeringu. Zamiast długiego łańcucha wymagań, projektu w Figmie, implementacji i testów zespoły wcześniej przechodzą do prototypu. Kod staje się głównym artefaktem wspólnego myślenia.

Zmiana obejmuje też operacje. Obsługa klienta była pierwszym wdrożeniem AI widocznym dla użytkowników, a agenci rozwiązują dziś samodzielnie mniej więcej połowę zgłoszeń. Wyniki firmy za drugi kwartał podawały prawie 45 %. Airbnb celowo nie przekazuje automatyzacji spraw związanych z bezpieczeństwem.

Everest przenosi doświadczenie jednego zespołu do kolejnego projektu

Wewnętrzny graf kontekstowy Everest wykorzystuje LLM, embeddings i AI retrieval, aby łączyć wiedzę o organizacji i codebase. Airbnb podaje, że usługę dostaw zakupów budowano 8 do 9 miesięcy, natomiast podobna integracja transferów lotniskowych zajęła około 6 tygodni. Drugi zespół mógł wykorzystać doświadczenia zapisane w Everest.

To ważniejsza lekcja produktowa niż udział kodu stworzonego przez AI. Wartość pojawia się, gdy firma zapisuje kontekst, prowadzi evals dla każdego use case i dobiera model pod względem kosztu, jakości i latencji. Airbnb uruchamia co najmniej 10 dostosowanych modeli i przyjmuje inny kompromis dla wyszukiwania niż dla kodu lub wsparcia.

Procent wygenerowanego kodu nie liczy błędów na produkcji

Wskaźniki 60 %, 80 % i 1,6 raza podał CTO prowadzący tę transformację. Wywiad nie publikuje metodologii pomiaru ani wspólnej grupy kontrolnej. Więcej pull requestów może oznaczać większą wydajność, mniejsze zmiany albo więcej poprawek. Bez danych o incydentach, rollbackach i czasie review jakość pozostaje niewiadomą.

Al-Dahle sam wskazuje kolejne ryzyko: młodsi inżynierowie mogą stracić część doświadczeń, z których rodzi się osąd. Airbnb wymaga więc, aby każdy inżynier umiał wyjaśnić kod w pull requeście, nawet jeśli stworzyła go AI.

Agenci on-call sprawdzą, czy kontekst staje się odpowiedzialnością

Airbnb zaczyna używać asynchronicznych agentów w kontenerach uruchamianych przez zdarzenia monitoringu. Agent może przeprowadzić triage incydentu, zaproponować pull request lub zamknąć fałszywy alarm. W tym miejscu Everest i evals trafiają na zadania o wyższej stawce.

Warto śledzić incydenty wywołane zmianami AI, czas ludzkiego review, odrzucone pull requesty i wyniki obsługi według typu problemu. Wzrost przepustowości ma znaczenie tylko wtedy, gdy za nim nie rośnie kolejka napraw.

Werdykt Lilith

Airbnb postawiło AI dokładnie między prototypem a produkcją, a 60 % to tylko numer na drzwiach. W środku liczy się to, czy inżynier wyjaśni każdy pull request, a nocny agent on-call zostawi po sobie czytelny ślad.