Nowy inżynier 10x nie pisze 10-krotnie więcej kodu. Buduje system, który go pisze.

Inżynier 10x był mitem Doliny Krzemowej przez dziesięciolecia. Samotny geniusz, słuchawki na uszach, produkujący elegancki kod z nadludzką szybkością. Debattowaliśmy, czy istnieją, spieraliśmy się, jak ich zatrudnić, i cicho zazdrościliśmy tym, którzy twierdzili, że nimi są.

Ale coś ciekawego wydarzyło się w drodze do przyszłości opartej na AI: inżynier 10x stał się rzeczywistym. Tylko wyglądają inaczej niż to sobie wyobrażaliśmy.

OpenAI niedawno opublikował, jak trzyosobowy zespół użył Codex, aby wydać 1500 żądań ściągnięcia i około miliona linii kodu, bez ręcznego napisania jednej linii. Trzej inżynierowie, a zero kodu napisanego ręcznie. Produkt wydany dla setek wewnętrznych użytkowników.

To nie jest 10x; to bliżej 100x. A umiejętność, która to umożliwiła, nie była szybszym pisaniem ani znajomością więcej algorytmów. Było to budowanie systemu, który sprawia, że agenci AI są produktywni: przepływy pracy, barierki, pętle weryfikacyjne, interfejsy, do których agenci się podłączają, a ludzie przeglądają przez nie.

Uważam, że jest to pojawienie się nowej funkcji kluczowej w organizacjach inżynierskich. Nazywałbym to Inżynierią Orkiestracji AI.

Trzy dyscypliny wchodzą na spotkanie

Jeśli spojrzymy na to, co tak naprawdę robi Inżynier Orkiestracji AI, rozpoznamy trzy znajome dyscypliny połączone w jedną.

Najbardziej oczywistym składnikiem jest DevOps. DevOps scentralizował pipeline wdrożeniowy. Jeden zespół skonfigurował przepływy pracy CI/CD, których każdy inżynier używał podczas wydawania kodu. Inżynieria Orkiestracji AI robi to samo, ale dla przepływów pracy agentów. Definiuje, jak zadania są przypisywane do agentów, jak wyjścia są weryfikowane, jak działają ponowne próby i awarie. Jest to wspólna infrastruktura, na której agenci działają.

Potem jest architektura, która nakłada się na DevOps bardziej, niż by się wydawało. Architekci decydują, które interfejsy są zablokowane, które wzorce są egzekwowane, które granice nie mogą być przekroczone. W świecie agentów ma to jeszcze większe znaczenie. Agenci potrzebują czystych, dobrze udokumentowanych baz kodu z wyraźnymi umowami. Inżynier Orkiestracji AI definiuje te ograniczenia, nie tylko dla ludzkiej czytelności, ale dla zrozumiałości agenta. Zanieczyszczona baza repozytorium nie jest już tylko długiem technicznym. Jest to limit produktywności dla każdego agenta, który ją dotyka.

Najmniej zrozumianym elementem jest warstwa specyficzna dla AI. Inżynieria promptów, zarządzanie kontekstem, wybór modelu, konfiguracja agenta. Dziś większość inżynierów robi to w sposób rozproszony, zadanie po zadaniu. Każda osoba sama ustala swój styl promptowania, swój zestaw agentów, swoje obejścia. Inżynier Orkiestracji AI scentralizuje to. Buduje wspólne podręczniki, ponownie używalne konfiguracje, wiedzę organizacyjną na temat tego, co działa, a co nie, w różnych modelach i przypadkach użycia.

Oddzielnie, te trzy funkcje istnieją w większości organizacji inżynierskich dzisiaj. Argumentem jest, że połączenie ich w jedną, scentralizowaną rolę tworzy coś jakościowo innego.

Metafora showrunnera

Reżyser filmu nie obsługuje kamery, nie gra w scenach, nie edytuje materiału. Ale każdy kadr odzwierciedla jego decyzje.

Wybiera kompozycję ujęcia, tempo, ton. Decyduje, kiedy przybliżyć, a kiedy oddalić. Ustawia środowisko (oświetlenie, projektowanie planu, blokowanie), tak aby każda osoba na planie mogła wykonać swoją najlepszą pracę w ramach spójnej wizji. Załoga jest indywidualnie utalentowana, ale bez tej koordynacji, otrzymujesz bałagan, który nigdy nie zostanie wydany.

Inżynieria Orkiestracji AI działa w ten sam sposób. Agenci są zdolni. Modele są potężne. Ale bez kogoś, kto projektuje system, który koordynuje ich, definiuje ograniczenia, buduje pętle sprzężenia zwrotnego, strukturyzuje przepływy pracy, otrzymujesz to, co wszyscy doświadczyliśmy: niespójne wyjścia, zmarnowany komput, agenci pracujący na przekór sobie, a inżynierowie spędzający więcej czasu na naprawie kodu wygenerowanego przez AI, niż gdyby sami go napisali.

Reżyser robi film większy niż suma jego części. Inżynier Orkiestracji AI robi to samo dla flot agentów.

Dlaczego większość organizacji inwestuje za mało

To, co widzę w całej branży: firmy inwestują dużo w narzędzia AI i za mało w systemy wokół nich.

Inżynierowie mają dostęp do Copilot, Claude, Codex. Eksperymentują indywidualnie. Niektórzy stają się użytkownikami o wysokim poziomie. Większość osiąga plateau na etapie “fancy autocomplete”. 20% zysków produktywności, o których mówią badania? To objaw adopcji na poziomie narzędzi bez myślenia systemowego.

Organizacje, które przełamują bariery, te, które zgłaszają dwukrotnie większą wydajność, mają coś wspólnego. Scentralizowały pracę orkiestracji. Ktoś (lub jakiś zespół) posiada przepływy pracy agentów, przygotowanie repozytorium, infrastrukturę weryfikacji, wspólny kontekst, do którego każdy agent ma dostęp.

Czym tak naprawdę jest ta rola

Dzień powszedni Inżyniera Orkiestracji AI może obejmować:

• Projektowanie przepływów pracy agentów: definiowanie, jak żądanie funkcjonalne staje się specyfikacją, staje się planem, staje się zadaniami agentów, staje się przeglądanym i scalonym kodem.
• Budowanie infrastruktury weryfikacji: automatyczne testy, reguły lintowania, skany bezpieczeństwa i ramy oceny, które agenci muszą przejść, zanim ich praca zostanie scalona.
• Utrzymywanie zdrowia repozytorium dla konsumpcji agenta: dokumentacja, wyraźne interfejsy, zarządzanie zależnościami i uproszczenie kodu, wszystko zoptymalizowane dla zrozumiałości agenta, a nie tylko dla czytelności ludzkiej.
• Scentralizowanie strategii promptów i kontekstu: wspólne systemowe prompty, potoki pobierania, decyzje dotyczące trasowania modeli i szablony konfiguracji, których używa cały zespół.
• Monitorowanie i poprawianie wydajności agenta: śledzenie wskaźników powodzenia, trybów awarii, kosztów na zadanie i czasu do scalenia w całej flotylli agentów, a następnie dostosowywanie systemu na podstawie danych.

Osoba ta siedzi na skrzyżowaniu inżynierii platformy, architektury oprogramowania i ekspertyzy AI. Nie pisze funkcji. Buduje system, który sprawia, że dostarczanie funkcji jest szybkie, niezawodne i skalowalne.

Historyczny wzorzec

We wczesnych dniach obliczeń w chmurze wdrożenie było pobocznym zadaniem każdego inżyniera. Każdy zespół miał własne skrypty, własne konfiguracje serwerów, własny sposób dostarczania kodu do produkcji. DevOps pojawił się, aby scentralizować tę pracę, a inżynieria platformy ewoluowała, aby zbudować ją w ramach wspólnej, samousługowej infrastruktury.

AI podąża tym samym torem. Obecnie użycie agenta jest pobocznym zadaniem każdego inżyniera. Każda osoba ma swój własny styl promptowania, własne preferencje narzędzi, własny model mentalny dotyczący tego, kiedy AI pomaga, a kiedy nie. Organizacje, które scentralizują tę pracę, które traktują ją jako infrastrukturę, a nie indywidualne eksperymenty, wyrównają się w tym samym stopniu, w jakim organizacje z dojrzałymi praktykami DevOps wyprzedziły te, które ich nie mają.

Różnica polega na szybkości. Przejście na DevOps zajęło dekadę. To może potrwać kwartały. Chociaż przyznam, że ta prognoza zakłada, że organizacje rozpoznają wzorzec szybciej, niż zwykle robią.

Ścieżka do przodu

Jeśli jesteś liderem inżynierskim, oto co bym sugerował, choć Twoje doświadczenie może się różnić w zależności od tego, jak daleko Twoja drużyna jest już zaawansowana.

1. Zidentyfikuj, kto już wykonuje tę pracę nieoficjalnie. Każda organizacja ma kogoś, kto rozwiązał przepływy pracy agentów, do kogo inni inżynierowie chodzą po radę dotyczącą promptowania lub konfiguracji narzędzi. Ta osoba to Twój proto-Inżynier Orkiestracji AI.
2. Uczynij to jawne. Nadaj funkcji nazwę, mandat i zasoby. Nie pozwól, by pozostała stroną projektu przywiązana do “prawdziwej” pracy.
3. Rozpocznij od przygotowania repozytorium. Przed inwestowaniem w zaawansowane przepływy pracy agentów upewnij się, że Twoja baza kodu jest czymś, co agenci mogą naprawdę nawigować. Czyste interfejsy, dobra dokumentacja, kompleksowe testy, uproszczona architektura.
4. Scentralizuj to, co działa. Kiedy ktoś odkryje strategię promptowania lub wzorzec przepływu pracy, który dramatycznie poprawia wyjście agenta, zapisz to. Uczynij to domyślnym dla całego zespołu, a nie wiedzą plemienną zamkniętą w jednej osobie.
5. Mierź na poziomie systemu. Nie śledź tylko indywidualnego użycia narzędzi. Śledź, ile zadań agenci wykonują od końca do końca, jaki wygląda wskaźnik przeglądu i przeróbek, gdzie są wąskie gardła.

Nowy 10x

Mityczny inżynier 10x był zawsze o indywidualnych bohaterstwach. Jedna osoba, przerastająca wszystkich dzięki czystemu talentowi i kofeinie.

Rzeczywistość inżyniera 10x w erze AI dotyczy myślenia systemowego. Osoba, która sprawia, że każdy inny inżynier (i każdy agent) jest bardziej produktywny, budując odpowiednią infrastrukturę, odpowiednie przepływy pracy, odpowiednie ograniczenia.

Oni nie piszą 10-krotnie więcej kodu. Budują system, który go pisze.

Nie jestem pewien, czy ta rola skrystalizuje się dokładnie tak, jak ją opisałem. Ale jestem dość pewien, że organizacje, które rozwiążą warstwę orkiestracji (niezależnie od tego, jak ją nazwą), będą tymi, które rzeczywiście zrealizują zyski produktywności, o których wszyscy inni tylko mówią.