Przegląd kodu AI w Synthesia ujawnia koszt szybszego generowania
Przegląd kodu AI w Synthesia ujawnia wyraźny konflikt, mimo 120-procentowego wzrostu liczby pull requestów: szybsze generowanie kodu nie eliminuje pracy inżynierskiej. Przesuwa ją na późniejszy etap.
Synthesia twierdzi, że 95 procent jej pull requestów zawiera obecnie kod wygenerowany przez AI. Mimo to mniej niż 5 procent zmian omija weryfikację przez człowieka. Te liczby dobrze obrazują problem, z którym mierzą się organizacje inżynierskie wdrażające agentów programistycznych na dużą skalę.
Nowym wąskim gardłem nie jest już pisanie kodu. Jest nim ustalenie, czy wygenerowany kod odzwierciedla zamierzony projekt, pasuje do istniejącego systemu, obsługuje nietypowe warunki i pozostaje bezpieczny po wdrożeniu.
Ta zmiana wywiera presję na liderów inżynierii, by przeprojektowali cały proces przeglądu. Amazon, AWS, Bonterra, IBM, Making Sense i Temporal testują warianty tej samej idei. Automatyzacja powinna obsługiwać rutynową kontrolę, podczas gdy ludzie zachowują decyzyjność w sprawach o istotnych konsekwencjach.
Taki podział brzmi efektywnie. Rodzi jednak trudne pytanie. Jeśli jeden system AI pisze kod, a drugi go recenzuje, jakie dowody pozwalają odpowiedzialnemu inżynierowi zaufać któremukolwiek z nich?
Przegląd kodu AI w Synthesia ujawnia nowe wąskie gardło
Kod generowany przez AI zwiększył zdolność produkcyjną szybciej, niż firmy zwiększyły zdolność do jego weryfikowania.
118 inżynierów Synthesia wdrożyło narzędzia AI do programowania w całym swoim procesie pracy w listopadzie 2025 roku. Do sierpnia 2026 roku liczba pull requestów wzrosła o 120 procent rok do roku, według CTO Petera Hilla.
Pull request to proponowana zmiana, którą inny inżynier lub zautomatyzowany system sprawdza, zanim trafi do głównej bazy kodu. Więcej pull requestów może oznaczać wyższą wydajność, ale każdy z nich generuje również pracę związaną z testowaniem, przeglądem, koordynacją i utrzymaniem.
Zmiany w Synthesia nie były jedynie drobnymi sugestiami uzupełnianymi przez narzędzie autouzupełniania. Hill powiedział w oryginalnej relacji, że 95 procent pull requestów firmy zawierało kod wygenerowany przez AI.
Ta skala ujawniła powtarzające się słabości. Agent programistyczny może utworzyć funkcję, nie rozpoznając, że ta sama możliwość już istnieje w innym miejscu repozytorium. Ograniczony kontekst zamienia wtedy jedną implementację w kilka konkurencyjnych wersji.
Synthesia miała podobno znaleźć nawet 10 wersji tej samej funkcji. Inżynierowie muszą zlokalizować duplikaty, zdecydować, która implementacja powinna znaleźć się w produkcie, usunąć pozostałe i nauczyć agenta, by nie powtarzał błędu.
Każda wygenerowana funkcja może wyglądać rozsądnie, gdy rozpatruje się ją osobno. Defekt staje się widoczny dopiero wtedy, gdy ktoś rozumie szerszy system. To rozróżnienie wyjaśnia, dlaczego kod, który przechodzi powierzchowną kontrolę, wciąż może zwiększać dług techniczny.
Dług techniczny to przyszła praca inżynierska wynikająca ze skrótów, niepotrzebnej złożoności lub słabych decyzji projektowych w obecnym oprogramowaniu. AI nie musi generować błędnej składni, by go tworzyć. Wystarczy, że model stworzy lokalnie wiarygodny kod, który koliduje z szerszą architekturą.
Hill opisał uzyskanie zamierzonego rezultatu w skali firmy jako ogrom pracy. Zastanawiał się również, czy zespoły kiedykolwiek całkowicie zaufają kodowi generowanemu przez agentów.
Ten sceptycyzm nie powstrzymał Synthesia przed korzystaniem z agentów programistycznych. Firma kieruje natomiast uwagę ludzi zgodnie z poziomem ryzyka. Zmiana komunikatu o błędzie podlega mniejszej kontroli niż zmiana dotycząca danych klientów lub kluczowych reguł biznesowych.
Nawet przy takim triage'u ponad 95 procent zmian nadal przechodzi przegląd przez człowieka. Firma zwiększa zdolność generowania kodu, zachowując zarazem ludzkie bramki kontrolne wokół większości wdrożeń.
To samo napięcie widać w całej branży. Sonar przeprowadził ankietę wśród ponad 1 100 profesjonalnych programistów i stwierdził, że respondenci przypisali AI 42 procent zatwierdzonego kodu.
Jednak 96 procent nie ufało w pełni, że kod wygenerowany przez AI będzie działał poprawnie. Tylko 48 procent stwierdziło, że zawsze weryfikuje kod wspomagany przez AI przed jego zatwierdzeniem, zgodnie z ankietą wśród programistów.
Różnica między brakiem zaufania a konsekwentną weryfikacją ma większe znaczenie niż sama liczba wdrożeń. Sugeruje, że niektóre organizacje produkują wygenerowany kod szybciej, niż ich mechanizmy kontrolne potrafią go ocenić.
Trzydzieści osiem procent respondentów stwierdziło, że kod wygenerowany przez AI wymagał więcej wysiłku przy przeglądzie niż kod napisany przez współpracowników. Sześćdziesiąt jeden procent powiedziało, że wygenerowany kod często wyglądał na poprawny, pozostając jednocześnie niewiarygodnym.
Te ustalenia nie dowodzą, że każda zmiana wygenerowana przez AI jest gorsza. Sonar sprzedaje produkty do weryfikacji kodu, a jego ankieta odzwierciedla zgłaszane doświadczenia, a nie kontrolowane pomiary produkcyjne.
Mimo to liczby są zgodne z relacjami operacyjnymi Synthesia i innych firm. Generowanie kodu przyspieszyło, ale zaufanie nie rosło w tym samym tempie.
Szybsze programowanie przesuwa pracę na późniejszy etap
Obietnica produktywności słabnie, gdy organizacje mierzą ilość wygenerowanego kodu zamiast niezawodnego oprogramowania trafiającego do użytkowników.
Agent programistyczny może stworzyć tysiące linii kodu w kilka minut. Liczba linii niewiele jednak mówi o tym, czy zmiana powinna istnieć, integruje się poprawnie lub rozwiązuje zgłoszony problem.
Amazon zetknął się z tym rozróżnieniem podczas modernizacji 17 lat kodu stojącego za jego aplikacją mobilną do zakupów. Starszy główny inżynier McLaren Stanley pracuje z 70-osobowym zespołem wspierającym ponad 1 000 programistów.
Stanley opisał sytuację, w której agent wygenerował 25 000 linii kodu w niewłaściwej wersji Swift, języka programowania Apple. Konwersja wyniku stworzyła 600 błędów, których agent nie potrafił rozwiązać jednocześnie.
Zespół odrzucił wygenerowany kod zamiast naprawiać go linia po linii. Stanley zaktualizował specyfikację, czyli szczegółowy plan określający, co agent powinien zbudować i jak powinien się zachowywać.
Po tej korekcie agent miał podobno poprawnie wygenerować kod ponownie w ciągu 15 minut. Ten epizod pokazuje obie strony argumentu o produktywności.
Agent zdołał odzyskać tempo szybciej, niż człowiek mógłby przepisać 25 000 linii. Najpierw jednak stworzył dużą, bezużyteczną zmianę, ponieważ brakowało jednego ważnego ograniczenia.
Szybkość generowania wzmocniła jakość planu. Niepełna specyfikacja doprowadziła do porażki na nietypową skalę. Poprawiona specyfikacja szybko przyniosła użyteczny rezultat.
Ta zależność zmienia sposób, w jaki starsi inżynierowie spędzają czas. Muszą określić architekturę, ograniczenia, interfejsy, kryteria akceptacji i zakazane zachowania, zanim agent rozpocznie implementację.
Praca przesuwa się od wyrażania każdej instrukcji w składni programowania w stronę tworzenia i obrony wykonalnego planu. To wciąż inżynieria oprogramowania, nawet jeśli w edytorze pojawia się mniej naciśnięć klawiszy.
Niezależne dowody dotyczące ogólnej produktywności pozostają niejednoznaczne. Randomizowane badanie METR z 2025 roku objęło 16 doświadczonych programistów open source realizujących 246 zadań w dobrze znanych im repozytoriach.
Programiści potrzebowali o 19 procent więcej czasu, gdy dostępne były narzędzia AI z początku 2025 roku, zgodnie z badaniem produktywności. Przed udziałem oczekiwali, że AI przyspieszy ich pracę o 24 procent.
Po zakończeniu badania nadal wierzyli, że AI przyspieszyła ich pracę o około 20 procent. Zmierzony wynik wskazywał na coś przeciwnego.
Badanie było niewielkie i skupiało się na doświadczonych programistach pracujących w znanych, dojrzałych repozytoriach. METR wyraźnie ostrzegł przed stosowaniem jego wyniku do każdego programisty, narzędzia lub środowiska programistycznego.
Programiści pracujący w nieznanych systemach mogą czerpać większą wartość z wyjaśnień AI i nawigacji po repozytoriach. Nowsze modele i lepsze procesy pracy z agentami również mogą zmienić rezultat.
METR przyznał, że późniejsze narzędzia prawdopodobnie oferują większe korzyści. Badanie pozostaje wartościowe, ponieważ oddziela odczuwaną szybkość od zmierzonego czasu realizacji.
Programista może czuć się szybszy, obserwując agenta tworzącego widoczny wynik. Formułowanie promptów i przeglądanie kodu może też mniej męczyć niż ręczne wdrażanie tej samej zmiany.
Żadne z tych odczuć nie gwarantuje, że poprawna zmiana szybciej trafi na produkcję. Czas poświęcony na oczekiwanie, korygowanie nieporozumień, czytanie wygenerowanego wyniku i porządkowanie niepotrzebnego kodu nadal się liczy.
Nowsze badanie terenowe w przedsiębiorstwie przedstawia bardziej optymistyczny rezultat z istotnym zastrzeżeniem. Badacze przeanalizowali 802 programistów i 196 212 pull requestów od stycznia 2024 roku do kwietnia 2026 roku.
Przepustowość na programistę osiągnęła ostatecznie 2,09 razy poziom bazowy sprzed wdrożenia w badanej firmie. Badacze zastrzegli, że wdrożenie nie zostało przydzielone losowo, więc nie mogli przypisać całego wzrostu bezpośrednio AI.
Co ważniejsze, system przeglądu organizacji zmienił się wraz ze skalą produkcji. Obciążenie przypadające na recenzenta mniej więcej się podwoiło, a zautomatyzowany przegląd wyprzedził przegląd wykonywany przez ludzi. Wskaźniki scalania i wycofywania zmian pozostały stabilne.
Te dane wspierają węższy wniosek niż „AI podwaja produktywność inżynierii”. Sugerują, że wysoka wydajność staje się trwała, gdy organizacja przeprojektowuje przegląd i gromadzi doświadczenie z narzędziami.
Centralną jednostką wartości nie jest wygenerowany kod. Jest nią zmiana, która przechodzi przegląd, trafia do użytkowników, nie powoduje incydentów i pozostaje łatwa w utrzymaniu.
Plany i agenci recenzujący stają się warstwą kontroli
Najsilniejsza odpowiedź na tandetny kod AI zaczyna się przed generowaniem i trwa poprzez wielowarstwowy, oparty na ryzyku przegląd.
Firmy budują warstwę kontroli wokół agentów programistycznych. Łączy ona specyfikacje, zautomatyzowane testy, kontrole bezpieczeństwa, egzekwowanie zasad, sygnały zaufania i eskalację do ludzi.
Planowanie jest pierwszym krokiem, ponieważ sam przegląd nie jest w stanie skutecznie uratować źle zdefiniowanego zadania. Precyzyjna specyfikacja zawęża możliwości agenta, zanim wygeneruje on dużą zmianę.
Specyfikacja powinna wskazywać zamierzone zachowanie, istotne komponenty, ograniczenia architektoniczne, ograniczenia dotyczące danych oraz testy akceptacyjne. Powinna też opisywać warunki awarii i nietypowe dane wejściowe.
Takie podejście robi więcej niż poprawia prompty. Tworzy punkt odniesienia, z którego zarówno zautomatyzowani recenzenci, jak i ludzie mogą korzystać przy ocenie rezultatu.
Bez zatwierdzonego planu recenzent musi wywnioskować intencję autora podczas czytania implementacji. Zadanie staje się trudniejsze, gdy nominalnym autorem jest agent, który poza bieżącym kontekstem nie ma stabilnego rozumienia.
Dzięki planowi pytanie w przeglądzie staje się bardziej konkretne. Czy implementacja odpowiada uzgodnionemu projektowi, czy agent wymyślił inne rozwiązanie?
AWS wykorzystuje wyspecjalizowanych agentów do przeprowadzania wczesnych kontroli, według starszego głównego inżyniera Davida Yanacka. Agenci testują, czy kod działa, porównują go z pierwotnym planem i szukają problemów bezpieczeństwa przed przeglądem przez człowieka.
Ten wielowarstwowy proces traktuje przegląd AI jako filtrację, a nie ostateczny autorytet. Maszyny zajmują się powtarzalnym czytaniem i uporządkowanymi porównaniami. Ludzie oceniają niejednoznaczne kompromisy i przyjmują odpowiedzialność.
Bonterra przyjęła podobny model po gwałtownym wzroście obciążenia związanego z przeglądami. Dostawca oprogramowania dla organizacji non-profit zatrudnia około 290 inżynierów.
W ciągu trzech miesięcy od wdrożenia AI liczba proponowanych zmian potroiła się, według CTO Tanuji Korlepra. Ilość kodu trafiającego do przeglądu wzrosła dziesięciokrotnie, a czas przeglądów potroił się.
Liczby te pokazują, dlaczego tradycyjny przegląd kodu linia po linii nie może po prostu wchłonąć nieograniczonej ilości wygenerowanego kodu. Dodanie jednego agenta programistycznego może zwiększyć produkcję szybciej, niż firma jest w stanie zatrudniać doświadczonych recenzentów.
Agenci przeglądający Bonterry porównują proponowany kod z zatwierdzonym projektem, wymaganiami bezpieczeństwa, standardami programowania i zasadami dostępności. Tworzą także ocenę poziomu pewności.
Niski wynik pewności lub oznaczony problem kieruje zmianę do człowieka. Kod wpływający na płatności, dane osobowe lub inne wrażliwe systemy zawsze podlega przeglądowi przez człowieka.
To podejście wykorzystuje ryzyko jako mechanizm przydzielania ograniczonej uwagi. Nie twierdzi, że automatyczny przegląd sprawia, iż każda zmiana niskiego ryzyka jest poprawna.
Triaging oparty na ryzyku pyta natomiast, gdzie awaria spowodowałaby największe szkody. Zespoły mogą wtedy kierować ograniczoną ludzką uwagę tam, gdzie kontekst i odpowiedzialność mają największe znaczenie.
Badania nad pull requestami tworzonymi przez agentów sugerują, że pomocne mogą być sygnały strukturalne. Jedno badanie nakładu pracy przy przeglądach z 2026 roku przeanalizowało 33 707 pull requestów wygenerowanych przez agentów w 2 807 repozytoriach.
Badacze odkryli, że 28,3 procent z nich scalono w mniej niż minutę, co odzwierciedlało wąskie zmiany wymagające niewielkiej interakcji. Inne zgłoszenia trafiały do dłuższych cykli przeglądu, w których agenci czasami zatrzymywali się lub przestawali odpowiadać na uwagi.
Badacze stworzyli model identyfikujący 20 procent pull requestów wymagających największego nakładu pracy już w momencie ich utworzenia. Wykorzystując sygnały strukturalne, objął on 69 procent całkowitego wysiłku przeglądowego w ramach tego budżetu przeglądów.
Model osiągnął wynik pola pod krzywą na poziomie 0,957 w podziale ewaluacyjnym opartym na czasie. Wynik ten mierzy, jak dobrze klasyfikator rozróżnia zmiany wymagające większego i mniejszego nakładu pracy.
Opisy tekstowe wnosiły niewielką dodatkową wartość predykcyjną. Ważniejsze od sposobu, w jaki agenci opisywali swoją pracę, było to, czego dotyczyły ich zmiany.
To ustalenie wzmacnia argument za wczesnym analizowaniem struktury zmiany. Liczba plików, objętość kodu, zmiany konfiguracji, zasięg zależności i rozproszenie architektoniczne mogą ujawniać ryzyko, zanim ktokolwiek zacznie dyskutować o stylu kodu.
Skuteczna warstwa kontroli wymaga jednak niezależności między generowaniem a oceną. Proszenie tego samego modelu o zatwierdzenie założeń, które sam wprowadził, może odtworzyć pierwotną martwą plamkę.
Zespoły potrzebują deterministycznych testów, analizy statycznej, skanerów bezpieczeństwa, polityk repozytorium i ludzkiej wiedzy domenowej obok przeglądów opartych na modelach. Każdy mechanizm kontroli wychwytuje inne tryby awarii.
Dokumentacja również staje się infrastrukturą operacyjną. Agent programistyczny nie może stosować się do decyzji architektonicznych, zasad własności ani wniosków z wcześniejszych incydentów, jeśli pozostają one rozproszone po spotkaniach i w pamięci poszczególnych osób.
Inżynierska baza wiedzy może pomóc zespołom zachować ten kontekst. Powinna wspierać proces przeglądu, nie zastępując autorytatywnych testów ani kontroli repozytorium.
Ludzka Akceptacja Nie Może Stać Się Teatrem
Przegląd zawodzi, gdy inżynier zatwierdza działające zachowanie, nie rozumiejąc wygenerowanego projektu, który leży u jego podstaw.
JD Raimondi, główny architekt AI w firmie konsultingowej Making Sense, nazywa taki rezultat „zatwierdzeniem teatralnym”. Recenzent potwierdza, że funkcja pozornie działa, pobieżnie przegląda implementację i zatwierdza ją bez zrozumienia stojących za nią wyborów.
Problem ten istniał przed generatywną AI. Duże pull requesty, presja terminów, niejasna odpowiedzialność i powierzchowne testowanie zawsze osłabiały przegląd.
Agenci programistyczni podnoszą stawkę, ponieważ mogą tworzyć przekonujące implementacje z nietypową szybkością. Czyste formatowanie i pewne wyjaśnienia mogą utrudniać zauważenie słabych założeń.
Agent może spełniać widoczne testy, a jednocześnie nieprawidłowo obsługiwać rzadkie dane wejściowe. Może wprowadzić zależność sprzeczną z polityką firmy albo powielić logikę ukrytą gdzie indziej w dużym repozytorium.
Może też osłabić bezpieczeństwo, nie powodując oczywistej awarii funkcjonalnej. Granice autoryzacji, zasady przechowywania danych, warunki wyścigu i niebezpieczne ustawienia domyślne wymagają czegoś więcej niż szybkiej demonstracji.
Temporal reaguje, wymagając od inżyniera zgłaszającego zmianę obrony pracy wygenerowanej przez agenta. Zgodnie z polityką „Send Back” inżynierowie muszą wyjaśniać własnymi słowami decyzje projektowe.
Muszą także opisać, jak kod radzi sobie z nietypowymi warunkami. Jeśli nie potrafią tego zrobić, recenzent odrzuca zgłoszenie.
CEO Samar Abbas bezpośrednio podsumował tę politykę: „Odmawiamy dopuszczenia, by przegląd kodu stał się wysypiskiem niesprawdzonych wyników modeli”.
Zasada zmienia bodźce stojące przed osobą korzystającą z agenta. Wygenerowanie większej poprawki nie przenosi już wszystkich kosztów zrozumienia na kogoś innego.
Zgłaszający musi zbudować wystarczające zrozumienie, by odpowiadać na pytania i wziąć odpowiedzialność za rezultat. Wymóg ten zniechęca do spekulacyjnego zwiększania objętości kodu i nagradza mniejsze, możliwe do obrony zmiany.
Chroni także odpowiedzialność. Agent AI nie może dołączyć do rozmowy dotyczącej incydentu, wyjaśnić naruszenia regulacyjnego ani zdecydować, czy ryzykowne wdrożenie powinno być kontynuowane.
Ludzka odpowiedzialność pozostaje niezbędna, nawet gdy maszyny wykonują większość czytania. Pytanie brzmi, czy organizacje zapewniają recenzentom wystarczająco dużo czasu, kontekstu i uprawnień, by mogli tę odpowiedzialność realizować.
Badania Google dotyczące wdrażania oprogramowania wykazały, że wdrażanie AI wiązało się zarówno z wyższą przepustowością tworzenia oprogramowania, jak i większą niestabilnością dostarczania. Raport opisał AI jako wzmacniacz otaczającego ją systemu.
Silne testowanie, jasne platformy, szybka informacja zwrotna i dobra dokumentacja mogą przekształcić zwiększone generowanie w użyteczny rezultat. Słabe mechanizmy kontroli mogą sprawić, że ta sama większa objętość zwielokrotni defekty i zamieszanie.
Takie ujęcie pozwala uniknąć dwóch częstych przesad. Kod wygenerowany przez AI nie jest automatycznie niebezpieczny, a automatyczny przegląd nie jest automatycznie wystarczający.
Wynik zależy od procesu otaczającego oba systemy. Zespół mierzący zaakceptowane sugestie lub wygenerowane linie kodu może pominąć późniejsze poprawki.
Silniejszy system pomiaru śledzi zmiany również po scaleniu. Przydatne wskaźniki obejmują defekty wykryte po wdrożeniu, nieudane wdrożenia, ustalenia dotyczące bezpieczeństwa, częstotliwość wycofywania zmian, czas przeglądu i nakład utrzymaniowy.
Zespoły powinny także odróżniać automatyzację niskiego ryzyka od istotnej logiki produktu. Aktualizacja generowanej dokumentacji nie wiąże się z takim samym ryzykiem jak zmiana autoryzacji płatności.
Klasyfikacja ryzyka również może zawieść. Mała zmiana we współdzielonym pomocniku uwierzytelniania może mieć szersze konsekwencje niż duża aktualizacja izolowanego narzędzia.
Dlatego sama liczba linii nie może określać poziomu kontroli. Systemy przeglądu potrzebują map własności, informacji o zależnościach, danych o historycznych incydentach i rozumienia wrażliwych granic.
Automatyczni recenzenci wprowadzają własny szum. Jeśli agenci zasypują programistów ostrzeżeniami o niskiej wartości, ludzie mogą przywyknąć do ignorowania alertów.
Zmęczenie alertami przekształca wówczas kontrolę techniczną w kolejną formę teatru. System przeglądu wygląda na dokładny, podczas gdy ważne ustalenia giną w rutynowych komentarzach.
Firmy muszą zatem mierzyć precyzję i użyteczność automatycznych ustaleń. Agent przeglądający powinien zmniejszać koszt ludzkiego poszukiwania, a nie tworzyć kolejną kolejkę, której nikt nie jest w stanie odpowiedzialnie obsłużyć.
Sceptyczny wniosek jest prosty. Przegląd wspomagany przez AI może pomóc zarządzać objętością kodu generowanego przez AI, ale dowody nie uzasadniają usuwania ludzkiej odpowiedzialności ze zmian wysokiego ryzyka.
Ścieżka Rozwoju Młodszych Inżynierów Stoi Przed Innym Ryzykiem
Jeśli agenci przejmą pracę, która szkoliła młodszych inżynierów, firmy muszą celowo odbudować drogę od początkującego do zaufanego recenzenta.
Programiści na poziomie juniorskim tradycyjnie zdobywają osąd poprzez implementację. Śledzą istniejący kod, wprowadzają ograniczone zmiany, otrzymują szczegółowe informacje zwrotne, debugują awarie i stopniowo zajmują się większymi systemami.
Wiele z tych zadań dobrze nadaje się dla agentów programistycznych. Są ograniczone zakresem, powtarzalne i łatwe do opisania przez starszych inżynierów.
Ich automatyzacja może poprawić krótkoterminową produktywność. Może też usunąć praktykę uczącą początkujących, jak zawodzą abstrakcje, dlaczego istnieją konwencje i gdzie systemy produkcyjne ukrywają złożoność.
Młodszy inżynier nie może stać się wiarygodnym recenzentem, zatwierdzając kod, którego jeszcze nie rozumie. Czytanie wygenerowanych wyników pomaga, ale bierna inspekcja nie zastępuje w pełni tworzenia, psucia i naprawiania oprogramowania.
Making Sense podobno odnotowało niektóre z największych wzrostów produktywności AI wśród młodszych inżynierów. Firma konsultingowa obawia się również tego, czego ci pracownicy przestają się uczyć, gdy agenci zajmują się implementacją.
Jej odpowiedzią jest pozostawienie juniorów zaangażowanych w ustalanie, dlaczego klient potrzebuje danej funkcji i jak powinna ona działać. Uczestniczą w definiowaniu problemu, zamiast otrzymywać wyłącznie wygenerowany przez AI rezultat do sprawdzenia.
IBM próbuje innego podejścia. Według Neela Sundaresana, dyrektora generalnego firmy ds. automatyzacji i AI, nowi inżynierowie otrzymują wcześniej bardziej wymagające zadania.
AI pomaga przy implementacji i testowaniu. Gdy system zawodzi, młodsi inżynierowie muszą zdiagnozować problem i go poprawić przed zatwierdzeniem przez seniora.
Sundaresan szacuje, że AI może pomóc młodszym inżynierom wykonać 70 do 80 procent niektórych zadań wcześniej kojarzonych ze starszymi programistami. Jest to szacunek kadry zarządzającej, a nie niezależny pomiar produktywności.
Istotną częścią jest towarzysząca temu odpowiedzialność. Juniorzy nadal badają awarie, zamiast traktować agenta jako niekwestionowane źródło.
Synthesia zatrudnia głównie inżynierów na poziomie mid i senior. Jej mniej doświadczeni pracownicy współpracują zarówno ze starszym kolegą, jak i agentem AI, jednocześnie odpowiadając za określone części projektów.
Bonterra również zmieniła rozwój juniorów. Agenci wykonują obecnie wiele dobrze zdefiniowanych zadań, które dawniej służyły jako zadania szkoleniowe.
Firma zamiast tego prosi młodszych inżynierów o odpowiedzialność za rezultaty wraz z doświadczonymi kolegami. Uczą się kierować agentami, kwestionować wyniki i pozostawać odpowiedzialnymi za dostarczone zachowanie.
Korlepra jasno ujął długoterminową obawę: „Jeśli branża przestanie zatrudniać juniorów, branża przestanie tworzyć seniorów”.
Ten problem z pipeline’em nie pojawi się natychmiast na pulpitach wskaźników dostarczania. Firma może ograniczyć zatrudnianie na poziomie entry-level, a mimo to zwiększać produkcję przez kilka kwartałów.
Koszt pojawi się później, gdy będzie potrzebować inżynierów rozumiejących systemy legacy, incydenty produkcyjne, ograniczenia klientów i historię architektury. Te kompetencje rozwijają się poprzez skumulowane doświadczenie.
Organizacje potrzebują zatem sygnałów szkoleniowych obok wskaźników przepustowości. Powinny śledzić, czy młodsi inżynierowie potrafią wyjaśniać zmiany, diagnozować awarie, pisać testy i podejmować coraz bardziej niejednoznaczne zadania.
Udział w przeglądach również wymaga struktury. Powierzenie młodszemu inżynierowi ogromnej poprawki wygenerowanej przez agenta bez kontekstu uczy wytrwałości, a nie osądu.
Mniejsze zmiany tworzą lepsze pętle uczenia się. Jasna specyfikacja, ograniczony zakres, obserwowalne testy i bezpośrednia informacja zwrotna od seniora pozwalają początkującym połączyć intencję z implementacją.
Przeglądy incydentów oferują kolejną ważną przestrzeń do nauki. Inżynierowie dowiadują się, dlaczego pozornie nieszkodliwe decyzje spowodowały awarie operacyjne i jak powinny zmienić się zabezpieczenia.
Firmy mogą przekazywać te wnioski zarówno do szkoleń, jak i kontekstu agentów. Cel uczenia się ludzi powinien jednak pozostać wyraźny, zamiast stawać się skutkiem ubocznym wdrażania narzędzi.
Przyszły starszy inżynier prawdopodobnie będzie spędzać więcej czasu na kierowaniu agentami i ich ocenie. To sprawia, że wiedza podstawowa jest ważniejsza, a nie mniej ważna.
Osąd wymaga mentalnego modelu systemu. Bez doświadczenia w budowaniu takiego modelu recenzent może oceniać jedynie, czy wygenerowany kod wygląda znajomo.
Ścieżka rozwoju juniorów jest więc częścią problemu przeglądu kodu AI. Firmy muszą tworzyć zarówno niezawodne oprogramowanie, jak i ludzi zdolnych rozpoznać, kiedy automatyzacja się myli.
Trzy Sygnały Pokażą, Czy Nowy Proces Działa
O kolejnej fazie zdecydują stabilność produkcyjna, ekonomika przeglądów oraz rozwój ludzkiej wiedzy eksperckiej.
Pierwszym sygnałem będzie to, czy większy wolumen pull requestów poprawia tempo dostarczania bez zwiększania liczby awarii. Firmy powinny publikować lub przynajmniej wewnętrznie śledzić częstotliwość wdrożeń obok wycofań zmian, defektów ujawnionych po wdrożeniu, incydentów i ustaleń dotyczących bezpieczeństwa.
Stabilny wskaźnik wycofań zmian jest zachęcający, ale nie obejmuje wszystkich kosztów utrzymania. Zduplikowana logika i dryf architektoniczny mogą pozostawać na produkcji długo, zanim doprowadzą do widocznego incydentu.
Jeśli przepustowość rośnie, a niezawodność i nakłady na utrzymanie pozostają stabilne, przeprojektowany workflow zyskuje wiarygodność. Jeśli kolejki do przeglądu i zakres poprawek nadal się wydłużają, generowanie jedynie przesunęło ograniczenie w inne miejsce.
Drugim sygnałem będzie to, czy przegląd oparty na ryzyku zmniejsza nakład pracy ludzi bez osłabiania odpowiedzialności. Bonterra i Synthesia kierują zmiany według ich wrażliwości, podczas gdy AWS wykorzystuje agentów do wstępnych kontroli.
Przydatne dane pokazałyby, które automatyczne ustalenia inżynierowie akceptują, jakie defekty przedostają się dalej oraz jak często zmiany uznane za niskiego ryzyka wymagają późniejszej naprawy.
Opóźnienia w przeglądach powinny się zmniejszać dlatego, że automatyzacja usuwa rutynową pracę, a nie dlatego, że ludzie zatwierdzają więcej kodu bez jego zrozumienia. Wymóg przedstawiania wyjaśnień stosowany przez Temporal stanowi jeden ze sposobów sprawdzenia rzeczywistego zrozumienia.
Jeżeli inżynierowie potrafią uzasadnić wygenerowane projekty, poświęcając jednocześnie mniej czasu na mechaniczne kontrole, przegląd kodu AI wykonuje użyteczną pracę. Jeśli zatwierdzanie staje się rytuałem, workflow zawodzi.
Trzecim sygnałem będzie to, czy młodsi inżynierowie nadal rozwijają się w kierunku samodzielnej odpowiedzialności technicznej. Firmy powinny obserwować gotowość do awansu, wyniki w debugowaniu, udział w obsłudze incydentów oraz złożoność zadań, które juniorzy mogą odpowiedzialnie realizować.
Krótkoterminowy wzrost produktywności nie zrekompensuje kurczącej się puli doświadczonych recenzentów. Każde zautomatyzowane zadanie szkoleniowe wymaga zastępczej pętli nauki, zapewniającej rzeczywiste konsekwencje i informacje zwrotne.
Przegląd kodu AI w Synthesia pokazuje, że sam agent programistyczny jest tylko jednym z elementów. Specyfikacje, kontekst repozytorium, automatyczne kontrole, zasady eskalacji, ludzkie wyjaśnienia i rozwój kariery decydują o końcowym rezultacie.
Liderzy inżynierii powinni teraz zadawać trudniejsze pytanie niż to, ile kodu wygenerowała AI. Ile zweryfikowanego, łatwego w utrzymaniu oprogramowania trafiło do użytkowników i czy zespół wzmocnił zdolność oceny kolejnej zmiany?
Organizacje, które potrafią odpowiedzieć na obie części tego pytania, będą miały dowody produktywności. Te, które nie potrafią, będą nadal szybciej tworzyć kod, jednocześnie kumulując niepewność na dalszych etapach.
