Klaudia Ciesielska, Brandsit: Jakie umiejętności staną się najważniejsze dla inżynierów oprogramowania w ciągu najbliższych kilku lat?

McLaren Stanley, Amazon: Już teraz widzimy, że ponieważ coraz częściej wykorzystujemy agentów do pracy, którą wcześniej wykonywali inżynierowie bezpośrednio przy klawiaturze, zmienia się charakter tej roli. Inżynierowie oprogramowania nie piszą już kodu ręcznie tak często jak wcześniej. Coraz częściej proszą agentów, aby robili to za nich.

To uwalnia ich czas, ale też wymusza więcej myślenia systemowego i projektowego. Coraz ważniejsze stają się decyzje architektoniczne wyższego poziomu: co budować, jak to budować i jak zaprojektować cały system.

W środowisku enterprise przez lata coraz więcej zadań niezwiązanych bezpośrednio z tworzeniem oprogramowania przeszkadzało inżynierom w pracy. Mam na myśli rozwiązywanie konfliktów przy scalaniu kodu, zarządzanie pipeline’ami czy inne ręczne zadania deweloperskie, które były trochę oderwane od samego projektowania i budowania oprogramowania. A przecież wiele osób weszło do tej branży właśnie po to, żeby tworzyć.

Rozwój agentowy pozwala inżynierom wrócić do myślenia wyższego poziomu. Daje im możliwość szybszego testowania pomysłów, szybszego sprawdzania koncepcji i szybszego wprowadzania innowacji.

Myślę, że sama dyscyplina inżynierii oprogramowania będzie przesuwać się właśnie w tym kierunku. Zmienią się także role. Być może product managerowie i projektanci będą bardziej bezpośrednio zaangażowani w codzienną pracę z agentami. Z kolei dawny podział na frontend i backend może stać się mniej formalny, ponieważ inżynierowie będą mogli pracować szerzej, na większej liczbie systemów.

„Rozwój agentowy pozwala inżynierom wrócić do myślenia wyższego poziomu. Daje im możliwość szybszego testowania pomysłów, szybszego sprawdzania koncepcji i szybszego wprowadzania innowacji.”

Wcześniej wymagało to głębokiej specjalizacji. Teraz część tej specjalizacji jest wbudowana w modele i w sposób sterowania procesem rozwoju. To może uwolnić inżynierów od bardziej powtarzalnych zadań i pozwolić im skupić się na kreatywnej innowacji, dla której wielu z nas w ogóle wybrało tę branżę.

Najbardziej ekscytuje mnie właśnie to. Jednocześnie ta dziedzina zmienia się tak szybko, że trudno przewidzieć, jak dokładnie będzie wyglądać za kilka lat. Mam poczucie, że dopiero zaczynamy rozumieć, jak duża może być ta zmiana.

Klaudia: Jaki procent kodu jest dziś generowany przez AI, a jaki procent nadal jest pisany ręcznie w Twoim zespole?

McLaren Stanley: Mój zespół został od podstaw stworzony jako zespół AI native development. To nie dotyczy całej struktury Amazona, ale w przypadku mojego zespołu nie piszemy ręcznie żadnego kodu. Ani jednej linijki. Korzystamy w całości z rozwoju agentowego.

Co ważne, nie dałem zespołowi formalnego zakazu ręcznego pisania kodu. Nie powiedziałem: „manualne kodowanie jest niedozwolone”. Stało się to naturalną konsekwencją procesu.

Na początku, kiedy zaczynaliśmy nowe projekty, zdarzało się, że ktoś wprowadzał ręczną zmianę w kodzie, ale nie aktualizował agenta o kontekst tej zmiany. Wtedy agent często nadpisywał tę zmianę albo ponownie stosował wzorzec, który człowiek próbował poprawić.

„Mój zespół został od podstaw stworzony jako zespół AI native development. To nie dotyczy całej struktury Amazona, ale w przypadku mojego zespołu nie piszemy ręcznie żadnego kodu. Ani jednej linijki.”

To naturalnie prowadzi do innego sposobu pracy. Zamiast próbować samodzielnie napisać konkretną implementację albo naprawić konkretny błąd, starasz się stworzyć system agentowy, który może naprawiać błędy automatycznie.

Jeśli agent zrobi coś, czego programista się nie spodziewa, nie poprawia tego ręcznie w kodzie. Albo instruuje agenta, aby dokonał poprawki i włączył ją do swojego kontekstu, albo wraca do etapu specyfikacji i projektowania, aby uzupełnić go o nową informację.

Zazwyczaj aktualizujemy wtedy specyfikacje projektowe i proces sterowania agentem, tak aby podobny wzorzec został wychwycony w przyszłości albo aby zmienić sposób działania architektury. To przesuwa interakcję z kodem z poziomu ręcznego pisania na poziom pracy z agentem i systemem.

Osobiście przez cały ostatni rok nie napisałem ręcznie żadnego kodu. Mój zespół również generuje dziś 100 proc. kodu za pośrednictwem agentów. Inne zespoły w Amazonie są na różnych etapach adopcji, ale ponieważ byliśmy zespołem pionierskim, który miał sprawdzić, co można zrobić z tymi narzędziami, u nas tak właśnie naturalnie się to rozwinęło.

Klaudia: Jak zapewniacie jakość i bezpieczeństwo kodu generowanego przez AI?

McLaren Stanley: Używamy do tego całego zestawu narzędzi i stale iterujemy ten proces. Na samym początku było w nim dużo ludzkiego przeglądu. Przygotowywaliśmy specyfikację projektową, a następnie sprawdzaliśmy ją osobno dla Androida i iOS, ponieważ na jej podstawie generowaliśmy kod dla obu platform.

Potem sprawdzaliśmy cały kod tak, jakby napisał go człowiek. Przeglądaliśmy każdą linijkę na obu platformach. Bardzo szybko ludzie stali się jednak ogromskim wąskim gardłem. Do tego dochodziły ręczne testy, które miały potwierdzić, czy aplikacja działa i czy konkretna zmiana spełnia swoje zadanie.

Proces naturalnie popchnął nas więc w stronę znacznie bardziej agentowej ewaluacji i bardziej zautomatyzowanego środowiska testowego. Dużo czasu poświęcamy na wzmacnianie testów end-to-end i testów automatycznych, aby mieć pewność, że podstawowa funkcjonalność aplikacji nie zostanie naruszona, gdy agenci będą pisać nowe funkcje.

Są to testy jednostkowe, testy end-to-end prowadzone agentowo, ale też przypadki testowe zapisane w języku angielskim zrozumiałym dla człowieka, które następnie wykonuje agent.

Korzystamy również z narzędzi wspierających różne etapy cyklu życia oprogramowania. W nowym projekcie wybraliśmy język, który oferuje więcej bezpieczeństwa na etapie kompilacji, między innymi bezpieczeństwo wątków, pamięci i typów. Używamy Swifta zamiast Objective-C. Dzięki temu agent otrzymuje znacznie lepszą informację zwrotną od kompilatora o tym, czy pisze bezpieczny kod. To pozwala mu szybciej dochodzić do właściwego rozwiązania.

Wdrożyliśmy też dużo statycznego lintingu, czyli zautomatyzowanych narzędzi przeglądu kodu, które prowadzą agenta w trakcie pracy.

Jedną z ciekawszych technik jest wykorzystanie LLM jako testera. Jeden agent pisze kod i działa trochę jak architekt kodu. Inne agenty piszą kod dla Androida i iOS. Mamy też osobnego agenta w pipeline’ie, który wykonuje przegląd kodu. Ma inny kontekst niż agent generujący kod, ale zna specyfikację projektową, testy i wymagania.

Taki agent sprawdza, czy kod wygenerowany przez pierwszego agenta rzeczywiście spełnia wymagania specyfikacji. Działa więc podobnie jak tester kodu, ale w wersji agentowej. Celowo dajemy mu inną perspektywę, inną personę i inny zestaw kontekstu, żeby mógł wychwycić błędy lub odstępstwa od wzorców.

Jednocześnie utrzymujemy ten sam próg jakości, który mieliśmy dla kodu pisanego przez ludzi. Nadal wykonujemy ludzkie przeglądy, zwłaszcza na etapie projektowania, kiedy decydujemy, co właściwie budować. Amazon bardzo mocno podchodzi do bezpieczeństwa, stabilności i jakości, więc nie jesteśmy gotowi iść na kompromis tylko dlatego, że kod został wygenerowany przez agenta.

Zmieniło się raczej to, że nauczyliśmy się tworzyć bezpieczniejsze środowisko dla agenta. Dajemy mu informację zwrotną wcześniej w cyklu pracy, tak aby mógł szybciej sprawdzić, czy jego odpowiedzi są bezpieczne, poprawne i zgodne z wymaganiami. Dzięki temu ludzie nie muszą analizować każdej linijki kodu implementacyjnego. Mogą skupić się na pytaniach wyższego poziomu: czy budujemy właściwą rzecz, czy odpowiadamy na potrzeby klientów i czy kierunek jest dobry.

„Utrzymujemy ten sam próg jakości, który mieliśmy dla kodu pisanego przez ludzi.”

Klaudia: Jakie jest największe błędne przekonanie ludzi na temat tworzenia oprogramowania generowanego przez AI?

McLaren Stanley: Jest ich wiele, bo ta dziedzina rozwija się i zmienia bardzo szybko. Jeszcze rok temu nie rozmawialibyśmy o rozwoju opartym na specyfikacjach, orkiestratorach agentów czy AI native development. Półtora roku temu dużym tematem był raczej vibe coding.

Dobrym przykładem błędnego przekonania są halucynacje. Wiele osób mówi: „martwię się, że agenci będą produkować błędne odpowiedzi”. I to prawda, może się tak zdarzyć. Ja jednak myślę o tym mniej jak o agencie, który generuje złą odpowiedź, a bardziej jak o bardzo naiwnym asystencie.

Jeśli dajesz nieprecyzyjne instrukcje, dostajesz nieprecyzyjne odpowiedzi. Oczywiście to także zmienia się z czasem, bo modele są coraz lepsze, większe i mają więcej kontekstu. Ale zasadniczo ważne jest, aby inaczej myśleć o tym narzędziu.

Nie chodzi o science fiction, czyli AI zbliżającą się do ludzkiej inteligencji. Bardziej chodzi o narzędzie, które bardzo dobrze rozpoznaje wzorce. Im solidniejsze i bardziej precyzyjne instrukcje mu dajesz, tym lepsze odpowiedzi otrzymujesz.

Dlatego nie myślę o tym głównie w kategorii halucynacji ani przybliżania się do ludzkiej inteligencji. Myślę o tym w kategoriach narzędzia, które pozwala lepiej wykorzystać i zwielokrotnić ludzką ekspertyzę oraz intencję, z jaką siadamy do budowania czegoś dla klientów.

Dla mnie metafora halucynacji jest więc nie do końca trafna. Ważniejsze pytanie brzmi: jak używać tego narzędzia i jak sprawiać, aby z czasem było mniej naiwne? Takie podejście pomogło nam myśleć o tym problemie bardziej systemowo.

Klaudia: Jeff Bezos powiedział niedawno podczas VivaTech w Paryżu, że AI nie doprowadzi do masowego bezrobocia i może ostatecznie stworzyć niedobór pracowników. Czy zgadzasz się z tym poglądem?

McLaren Stanley: Generalnie się zgadzam. Można spojrzeć na historię, na rewolucję przemysłową albo pojawienie się komputera. Takie zmiany tworzą nowe sposoby innowacji. Pozwalają ludziom wnosić wyobraźnię i kreatywność, a także uwalniają ich do myślenia na wyższym poziomie.

Myślę, że to samo dotyczy rewolucji AI. Gdy ludzie nauczą się dobrze używać tych narzędzi, pojawi się więcej możliwości, aby robić nowe rzeczy i wnosić ludzką kreatywność do pracy. Patrząc na historię i na to, co dziś widzę w tych narzędziach, uważam, że ten wzorzec się utrzyma.

Lubię porównanie do rewolucji przemysłowej. Pierwsza fala innowacji to samo narzędzie. W późnej fazie rewolucji przemysłowej nastąpiło przejście od silnika parowego do silnika elektrycznego. Ale prawdziwa innowacja nie polegała tylko na samym silniku elektrycznym. Polegała na tym, że można było uczynić go małym, a potem przeorganizować całą fabrykę. Dzięki temu można było budować rzeczy, których wcześniej nie dało się budować.

Dla mnie jesteśmy dziś w podobnej fazie. Mamy nowe narzędzie, które pozwala budować i robić rzeczy w sposób wcześniej niemożliwy. Kolejna warstwa innowacji pojawi się wtedy, gdy ludzie zaczną wykorzystywać te narzędzia do budowania nowych rozwiązań, rozwiązywania nowych problemów, a być może nawet tworzenia nowych branż.

Jesteśmy dopiero na początku tej zmiany. Ledwie drapnęliśmy powierzchnię tego, jak może wyglądać ta innowacja. To oczywiście moja osobista opinia.

Klaudia: Wiele firm w Europie Środkowo-Wschodniej rosło dzięki outsourcingowi i usługom tworzenia oprogramowania. Czy uważasz, że inżynieria AI native zmieni ten model biznesowy?

McLaren Stanley: Trudno mi to przewidzieć. Myślę, że na pewno będzie to miało wpływ. W miarę jak firmy będą się rozwijać, innowować i korzystać z niesamowitych kompetencji, jakie oferują pracownicy w Europie Środkowo-Wschodniej, one również będą przyjmować nowe narzędzia i wnosić nowe innowacje do tej przestrzeni.

To zmieni sposób, w jaki o tym myślimy. Spodziewam się, że stworzy to także nowe możliwości, choć trudno mi spekulować, jak dokładnie będzie to wyglądać.

Uważam jednak, że także tutaj istnieje przestrzeń dla dużej fali innowacji.