Były założyciel technologiczny Meta przedstawia trzy rzeczy, które każdy CTO musi zrobić przed wdrożeniem AI

James Everingham kierował działami inżynieryjnymi w jednych z najbardziej zaawansowanych firm na świecie, w tym w Meta. Obecnie jest dyrektorem generalnym i współzałożycielem Guild.ai — płaszczyzny sterowania agentami AI, która zapewnia organizacjom jedno miejsce do wdrażania, zarządzania, monitorowania i optymalizowania każdego agenta działającego na produkcji.

Spotkaliśmy się z Jamesem, aby dowiedzieć się, jak AI zmienia przepływy pracy w inżynierii oraz co zespoły inżynieryjne muszą zmienić, zanim AI będzie można skutecznie zintegrować. Oto, co nam powiedział.

Od Meta do startupu AI

Jestem dyrektorem generalnym i współzałożycielem Guild.ai, płaszczyzny sterowania agentami AI, która zapewnia organizacjom jedno miejsce do wdrażania, zarządzania, monitorowania i optymalizowania każdego agenta działającego na produkcji. Zebraliśmy 44 mln USD w ramach rundy serii A prowadzonej przez Google Ventures, z udziałem NFX, Acrew, Scribble Ventures, Khosla Ventures i Webb Investment Network. Nasz zespół liczy około 35 osób i ma siedzibę w San Francisco.

Wcześniej byłem wiceprezesem ds. inżynierii w Meta DevInfra, gdzie tworzyłem i rozwijałem podstawowe narzędzia, usługi oraz platformy deweloperskie napędzające produkty Meta. Mój zespół zbudował pierwszego wewnętrznego agenta AI w Meta, co natychmiast wpłynęło na sposób, w jaki inżynierowie Meta korzystali z narzędzi AI. Podczas pracy w Meta współtworzyłem również Diem i pełniłem funkcję dyrektora ds. inżynierii w Instagramie.

W trakcie 40-letniej kariery jako menedżer, przedsiębiorca i twórca technologii kierowałem wieloma światowej klasy zespołami inżynieryjnymi. W Yahoo byłem wiceprezesem ds. inżynierii odpowiedzialnym za właściwości medialne Yahoo po przejęciu przez firmę Luminate — założonej przeze mnie firmy zajmującej się interaktywną technologią obrazów. Wcześniej kierowałem zespołami w Oracle, Netscape Communications, Tellme (przejętej przez Microsoft) oraz w kilku własnych firmach.

Jak AI pomogło znieść coroczne zamrożenie kodu w Meta

Kiedy pracowałem w Meta, wykorzystaliśmy model ryzyka AI, aby znieść coroczne zamrożenie kodu.

Wcześniej Meta zamrażała bazę kodu co roku od połowy grudnia do stycznia, ponieważ był to okres największego ruchu w jej produktach. Przez lata, aby uniknąć incydentów na produkcji w najbardziej ryzykownych tygodniach, nikt nie wdrażał zmian. Było to bezpieczne, ale jednocześnie zatrzymywało produktywność całej firmy na ponad miesiąc.

Mój zespół stworzył i udostępnił jako oprogramowanie o otwartym kodzie źródłowym system Diff Risk Score oparty na dużym modelu językowym (LLM), który ocenia prawdopodobieństwo, że różnica w kodzie doprowadzi do awarii na produkcji. Zamiast traktować każdą zmianę jako równie niebezpieczną w okresie zamrożenia, model przeprowadzał segregację ryzyka. Przypisywał każdej różnicy ciągły wynik ryzyka, dostrojony pod kątem wysokiej czułości — na przykład oznaczając 10% różnic, a jednocześnie wychwytując 60% zmian, które faktycznie powodują incydenty. Model pozwalał wdrażać różnice niskiego ryzyka nawet w czasie zamrożenia, ale wstrzymywał te, które oznaczył jako ryzykowne.

W rezultacie zamrożenie nie jest już rozwiązaniem typu „wszystko albo nic”. Diff Risk Score umożliwia też firmie Meta rozpoczęcie całkowitego usuwania zamrożenia kodu — inżynierowie odzyskują tygodnie w swoich kalendarzach, które wcześniej były martwym czasem, bez rezygnowania z zabezpieczenia zapewnianego przez zamrożenie.

To dobry przykład mojej szerszej filozofii: nie narzucajcie inżynierom odgórnego polecenia stosowania AI, zapewnijcie im infrastrukturę — scentralizowaną platformę, sygnał ryzyka i płaszczyznę sterowania — a następnie pozwólcie im samodzielnie znaleźć sposób na uzyskanie największych korzyści.

Dlaczego ludzie muszą umieć wyjaśnić kod, zanim trafi on na produkcję

Jeśli nie potrafisz tego wyjaśnić, nie możesz tego wdrożyć.

Intensywnie korzystam z narzędzi AI, aby przyspieszać pracę, ale radzę inżynierom, by zawsze wymagali walidacji, zanim cokolwiek trafi na produkcję. AI nie zastępuje osądu inżynierskiego — zapewnia inżynierom większe możliwości stosowania tego osądu na dużą skalę.

AI dostarcza obecnie informacji przy ocenie ryzyka, a także podczas wyszukiwania narzędzi i odkrywania przepływów pracy.

Obszary, w których ludzie są najlepsi:

• Ład korporacyjny i zabezpieczenia dotyczące samych agentów: Gdy zespoły głęboko osadzają modele rozumujące i agentów w infrastrukturze, szybko dostrzegają problemy z ładem — liczba agentów rośnie szybciej, niż ktokolwiek przewidywał, a budżety znikają z dnia na dzień. Wokół niedeterministycznych agentów potrzebna jest taka sama warstwa ładu, jaką zastosowalibyście wobec ludzi korzystających z tej infrastruktury — oznacza to, że ludzie nadal ustalają limity budżetowe, granice dostępu i wymagania dotyczące audytu.
• Strategia wdrażania: Nie można nakazać korzystania z narzędzi AI — użycie zdobyte zaufaniem jest skuteczniejsze niż użycie wymuszone, ponieważ nakazy prowadzą do powierzchownego wdrożenia. Decyzja o tym, jak zintegrować AI z przepływem pracy zespołu, jest jednoznacznie decyzją dotyczącą ludzkiego przywództwa i kultury — narzędzie może dowieść swojej wartości, ale decyzji o wdrożeniu nie można zautomatyzować.

Dlaczego zespoły inżynieryjne muszą przemyśleć swoją architekturę

Wczesne komputery zaczynały od jednego komputera głównego współdzielonego przez wszystkich, a następnie przeszły do szaf serwerowych z wyspecjalizowanymi usługami. Agenci podążają tą samą ścieżką.

Dotychczasowe założenie polegało na budowaniu kilku agentów ogólnego przeznaczenia i centralizowaniu wokół nich wykorzystania, podobnie jak centralizuje się moc obliczeniową. Firmy zdają sobie jednak sprawę, że ich rzeczywistość nie opiera się na kilku współdzielonych narzędziach — jest bliższa ekosystemowi wyspecjalizowanych agentów tworzonych do konkretnych celów. Zmusza to do ponownego przemyślenia tego, co w ogóle oznacza „architektura” w przypadku bazy kodu: mniej monolitu z wtyczkami, bardziej świata mikrousług, z tą różnicą, że usługami są agenci, a nie punkty końcowe.

W większości organizacji naturalnym odruchem jest traktowanie agenta jak każdego innego elementu oprogramowania — napisanie specyfikacji, wdrożenie go i oczekiwanie spójnych wyników. Porzuciłem to podejście i zastąpiłem je sposobem myślenia opartym na modelu pracowników. Zmienia to postrzeganie kwestii projektowania organizacji — kto co zatwierdza, kto odpowiada za budżet, kto ponosi odpowiedzialność, gdy coś przestaje działać — z kwestii zarządzania wdrożeniem na kwestie zarządzania. To inny sposób strukturyzowania relacji zespołu z wykorzystywanymi narzędziami.

Dlaczego ład musi zostać ustanowiony, zanim wdrażanie AI nabierze tempa

W moich wcześniejszych rolach żałowałem, że nie zbudowaliśmy warstwy ładu, zanim wdrażanie nabrało tempa, zamiast robić to później.

Kiedy pracowałem w Meta, inżynierowie zaczęli tworzyć i publikować własnych agentów na wewnętrznej platformie; liczba agentów szybko rosła, a zespół infrastruktury nagle musiał gorączkowo nadążać za popytem — dosłownie próbując znaleźć dziesiątki tysięcy wolnych serwerów.

Z perspektywy czasu można było tego uniknąć. Jeśli założysz, że wdrażanie może błyskawicznie rozprzestrzenić się wewnątrz firmy, od pierwszego dnia budujesz kontrolę kosztów i granice dostępu jako część platformy, a nie jako rozwiązanie awaryjne.

Dyrektorzy ds. technologii muszą na nowo zaprojektować granicę między „gdzie znajduje się AI” a „czego AI może dotknąć” — przenosząc ją z edytora do infrastruktury, ponieważ to właśnie na tym poziomie powstaje ryzyko i musi znajdować się ład.

James dzieli się

Dyrektorzy ds. technologii muszą na nowo zaprojektować granicę między “gdzie znajduje się AI” a “wczego AI może dotknąć” — przenosząc ją z edytora do infrastruktury, ponieważ to właśnie na tym poziomie powstaje ryzyko i musi znajdować się ład.

Dlaczego organizacje muszą mieć scentralizowane miejsce, w którym można rozwidlać agentów

Jako inżynier byłem lepszym złodziejem niż programistą. Znajdowałem coś, co częściowo spełniało moje potrzeby, dostosowywałem to do konkretnego celu i po drodze zdobywałem wiedzę.

Pierwszym krokiem przepływu pracy nie jest „wydanie polecenia modelowi”, lecz przejrzenie scentralizowanego miejsca, aby sprawdzić, jacy agenci już istnieją do danego zadania, i rozwidlenie jednego z nich zamiast rozpoczynania od zera. Organizacje muszą stworzyć procesy umożliwiające łatwe „kradzenie” agentów.

Trzy porady dla dyrektorów ds. technologii integrujących AI z organizacjami technicznymi

Oto moje porady:

1. Nie narzucaj tego — zapracuj na to. Narzucone korzystanie ze sztucznej inteligencji w celu zwiększenia produktywności frustruje mnie, ponieważ prowadzi do powierzchownej adopcji — najlepsze narzędzia dla programistów zyskują użytkowników dzięki swoim zaletom, a programiści są wystarczająco inteligentni, by sprzeciwiać się nakazom dotyczącym tego, które narzędzia mają polubić. Dyrektorzy ds. technologii powinni przedstawiać organizacji wyzwania biznesowe o ogromnej skali — problemy tak duże, że sztuczna inteligencja jest jedynym realistycznym rozwiązaniem. Następnie należy pozwolić inżynierom, którzy je rozwiązują, stać się naturalnymi ambasadorami. 
2. Przestań traktować sztuczną inteligencję jako narzędzie do tworzenia treści i zacznij traktować ją jako infrastrukturę. Rok 2025 był rokiem, w którym narzędzia do programowania, takie jak Cursor i Copilot, weszły do głównego nurtu; teraz modele rozumujące i agenci wykonujący wieloetapowe zadania przestają być wtyczkami do edytorów, a zamiast tego stają się częścią infrastruktury firm — przesyłają kod, uruchamiają testy, wdrażają nowych inżynierów i zarządzają działaniem systemów produkcyjnych. Jeśli Twoja strategia dotycząca sztucznej inteligencji nadal sprowadza się do pytania „którą wtyczkę do środowiska IDE powinniśmy kupić?”, rozwiązujesz nieaktualny problem.
3. Zarządzaj agentami tak, jak zarządzałbyś zespołem pracowników, a nie oprogramowaniem. Agenci zasilani przez modele rozumujące są niedeterministyczni — przekaż temu samemu agentowi dwa razy te same dane wejściowe, a możesz otrzymać różne wyniki. Nie jest to błąd do naprawienia; to fundamentalna cecha tej technologii. Dyrektorzy ds. technologii już na co dzień zarządzają niedeterministycznymi systemami w postaci pracowników. Musisz zastosować wobec agentów niektóre z tych samych zabezpieczeń, które stosujesz wobec swoich pracowników. Nie przyznawaj agentowi od pierwszego dnia nieograniczonego dostępu do środowiska produkcyjnego, uprawnień administratora ani nielimitowanego budżetu chmurowego, podobnie jak nie przyznałbyś ich nowo zatrudnionej osobie.

Śledź dalsze informacje

Możesz śledzić działalność Jamesa Everinghama na platformach X i LinkedIn.

Na The CTO Club pojawi się więcej wywiadów z ekspertami!