Gdy MacLaren Stanley, Senior Principal Engineer w Amazon Stores, mówi, że jego zespół nie pisze ręcznie „ani jednej linijki” kodu, łatwo potraktować to jako efektowną deklarację o automatyzacji pracy programistów. W rzeczywistości jest to jednak punkt wyjścia do ważniejszej rozmowy: nie o tym, czy sztuczna inteligencja potrafi wygenerować implementację, ale o tym, jak zmienia cały proces tworzenia oprogramowania.
Stanley opowiadał o tym podczas spotkania z dziennikarzami z Europy Środkowo-Wschodniej. Nie występował w roli rzecznika AWS, lecz jako praktyk pracujący w zespole Amazon, związany między innymi z technologiami stojącymi za aplikacją Amazon Shopping. Jego doświadczenie jest ciekawe nie dlatego, że pokazuje najbardziej radykalną wersję użycia AI w programowaniu, ale dlatego, że dobrze odsłania kierunek, w którym może przesuwać się cała branża.
Przez ostatnie lata rozmowa o AI w software development najczęściej koncentrowała się na narzędziach wspierających pojedynczego programistę. AI miała podpowiadać fragmenty kodu, uzupełniać funkcje, pomagać w testach, dokumentacji albo szybszym wyszukiwaniu błędów. Była dodatkiem do istniejącego procesu. W takim modelu organizacja pracy pozostawała zasadniczo taka sama, tylko część zadań wykonywało się szybciej.
Model, o którym mówi Stanley, idzie dalej. W jego zespole AI nie jest tylko asystentem programisty. Jest elementem procesu, wokół którego organizuje się sposób pracy. To właśnie oznacza AI native development: nie doklejenie narzędzia do starego modelu, lecz przebudowanie pracy inżynierskiej tak, aby agenci AI mogli realnie uczestniczyć w tworzeniu oprogramowania.
Najciekawsze w deklaracji o braku ręcznego pisania kodu nie jest więc samo „100 proc.” generowane przez agentów. Ważniejsze jest to, co musiało zmienić się wokół kodu. Stanley podkreśla, że nie zakazał zespołowi ręcznego programowania. Taki sposób pracy pojawił się naturalnie. Gdy inżynier wprowadzał ręczną zmianę, ale nie aktualizował kontekstu agenta, system mógł później tę zmianę nadpisać. To wymusiło nowe podejście: zamiast poprawiać pojedynczy fragment implementacji, trzeba poprawiać specyfikację, instrukcje i sposób działania całego systemu agentowego.
To przesuwa centrum ciężkości software development. W tradycyjnym modelu programista pracował bezpośrednio na kodzie. W modelu AI native coraz więcej wartości powstaje wcześniej: w definiowaniu wymagań, projektowaniu architektury, zarządzaniu kontekstem, przygotowaniu testów i tworzeniu warunków, w których agent może wygenerować poprawne rozwiązanie.
Stanley ujął to w rozmowie bardzo konkretnie: zamiast próbować naprawić konkretny błąd, inżynier próbuje stworzyć system agentowy, który będzie mógł naprawiać błędy automatycznie. To zdanie dobrze pokazuje skalę zmiany. AI w programowaniu nie jest wtedy po prostu szybszą klawiaturą. Staje się częścią środowiska, które trzeba zaprojektować, nadzorować i stale udoskonalać.
Nie oznacza to, że rola inżyniera znika. Zmienia się raczej miejsce, w którym powstaje jego wartość. Jeśli agent może napisać implementację, człowiek musi lepiej określić, co ma zostać zbudowane, dlaczego, w jakiej architekturze, według jakich wzorców i pod jakimi warunkami jakościowymi. Programista coraz częściej staje się projektantem systemu pracy: definiuje problem, opisuje wymagania, ustawia proces, ocenia wynik i decyduje, czy rozwiązanie rzeczywiście odpowiada na potrzeby użytkownika.
To ważna zmiana kompetencyjna. Znajomość składni i umiejętność ręcznego pisania kodu nadal mają znaczenie, ale przestają być jedynym symbolem profesjonalizmu. Coraz większą wagę zyskują myślenie systemowe, architektura, precyzyjne formułowanie wymagań, rozumienie zależności, walidacja wyników, projektowanie testów i zarządzanie kontekstem. W dużych organizacjach, gdzie systemy mają wiele warstw, długą historię i liczne zależności, to właśnie te kompetencje decydują o jakości zmian.
Największa wartość AI może zresztą nie leżeć w samym generowaniu kodu, ale w skracaniu fazy rozumienia systemu. Stanley opowiadał o bibliotece sieciowej, którą sam napisał kilka lat wcześniej. Nie przygotował wtedy pełnej dokumentacji, bo znał projekt z własnej pracy. Gdy po latach wrócił do tego kodu, agent przeanalizował bibliotekę i wygenerował dokumentację deweloperską: sposób użycia, strukturę zależności, parametry i wymagania. Na tej podstawie można było przygotować nową implementację w czasie liczonym nie w tygodniach, lecz w godzinach.
Ten przykład jest ważny, bo pokazuje realny problem enterprise development. W dużych firmach wyzwaniem rzadko jest samo wpisanie kodu. Znacznie trudniejsze bywa zrozumienie, jak działa stary system, dlaczego podjęto konkretne decyzje, jakie zależności są ukryte w architekturze i co trzeba zachować podczas modernizacji. Jeśli AI potrafi odtworzyć tę wiedzę, uporządkować ją i przełożyć na specyfikację, zmienia się ekonomia pracy nad dużymi systemami.
Widać to szczególnie przy długu technologicznym. Modernizacja aplikacji, refaktoryzacja, migracja do nowszych języków czy porządkowanie architektury często przegrywają z bieżącym rozwojem funkcji dla klientów. Są potrzebne, ale trudne do uzasadnienia, bo wymagają czasu doświadczonych inżynierów, koordynacji między zespołami i nie zawsze dają natychmiastowy efekt biznesowy. Stanley mówił, że AI „ogromnie zmieniła równanie ROI”. Dzięki agentom niewielki zespół ekspertów mógł pracować nad modernizacją aplikacji Amazon Shopping bez blokowania zespołów rozwijających bieżące funkcje produktowe.
To jeden z najważniejszych wniosków dla zarządów, CIO i CTO. AI w software development nie powinna być oceniana wyłącznie przez pryzmat liczby wygenerowanych linijek kodu. Znacznie ciekawsze pytanie brzmi, czy zmienia opłacalność projektów, które wcześniej były odkładane: modernizacji, migracji, dokumentowania starych systemów, automatyzacji testów czy redukcji długu technologicznego.
Ale przyspieszenie nie usuwa ryzyka. Przeciwnie, jeśli kod powstaje szybciej, szybciej mogą powstawać także błędy. Dlatego AI native development wymaga mocniejszej warstwy kontroli jakości, a nie mniejszej. Stanley podkreśla, że jego zespół utrzymuje ten sam próg jakości, który obowiązywał przy kodzie pisanym przez ludzi. Zmienia się natomiast sposób jego egzekwowania.
Na początku ludzie przeglądali kod generowany przez agentów niemal tak, jakby napisał go człowiek. Sprawdzali każdą linijkę, testowali zmiany i oceniali implementację. Szybko okazało się jednak, że człowiek staje się wąskim gardłem. W odpowiedzi większe znaczenie zyskały testy automatyczne, testy end-to-end, statyczna analiza kodu, informacje zwrotne z kompilatora i techniki, w których jeden model ocenia pracę drugiego.
To podejście, określane jako „LLM jako sędzia”, pokazuje nowy model kontroli. Jeden agent generuje kod, a inny, z odmiennym kontekstem, sprawdza, czy wynik spełnia wymagania specyfikacji. Człowiek nadal jest obecny w procesie, ale jego rola przesuwa się z ręcznego analizowania każdej linijki na ocenę tego, czy system buduje właściwe rozwiązanie, czy testy są sensowne, czy wymagania są kompletne i czy wynik odpowiada potrzebom klienta.
To także bardziej praktyczne spojrzenie na problem halucynacji AI. W publicznej debacie często mówi się o nich tak, jakby były główną barierą dla wykorzystania modeli generatywnych. Stanley proponuje inne ujęcie: agenta warto traktować nie jak quasi-ludzką inteligencję, ale jak skuteczne, choć nadal naiwne narzędzie rozpoznawania wzorców. Jeśli dostaje nieprecyzyjne instrukcje, zwraca nieprecyzyjne odpowiedzi.
Wniosek dla firm jest prosty, choć trudny do wdrożenia. Jakość pracy AI zależy nie tylko od wyboru modelu. Zależy także od jakości dokumentacji, specyfikacji, repozytoriów, standardów architektonicznych, testów i wiedzy organizacyjnej, którą firma potrafi przekazać agentom. AI nie przykrywa niedojrzałości procesu. Bardzo często ją ujawnia.
Dlatego największą barierą w adopcji AI w programowaniu może nie być sama technologia, lecz organizacja. Łatwo kupić dostęp do narzędzia i zachęcić programistów, by z niego korzystali. Znacznie trudniej odpowiedzieć na pytania: kto odpowiada za jakość kodu generowanego przez AI, jak dokumentowany jest kontekst przekazywany agentom, jakie testy są wymagane przed wdrożeniem, jak mierzyć efektywność i czy architektura systemu jest gotowa na taki model pracy.
To ma znaczenie również dla rynku usług IT w Europie Środkowo-Wschodniej. Region przez lata budował silną pozycję na kompetencjach inżynieryjnych, outsourcingu, software house’ach i centrach usług technologicznych. Jeśli jednak koszt samej implementacji zacznie spadać, przewaga oparta wyłącznie na dostarczaniu kodu będzie coraz trudniejsza do obrony.
Nie oznacza to końca firm usługowych. Oznacza raczej konieczność przesunięcia wartości wyżej. Klienci będą potrzebować partnerów, którzy potrafią projektować architekturę pod pracę z AI, przygotowywać dobre specyfikacje, wdrażać systemową kontrolę jakości, integrować agentów z procesami enterprise oraz brać odpowiedzialność za bezpieczeństwo i przewidywalność rezultatów. Model „dostarczamy kod” będzie musiał ewoluować w stronę „projektujemy proces tworzenia oprogramowania z udziałem AI”.
Największym błędem byłoby więc czytanie deklaracji o braku ręcznego kodowania jako zapowiedzi prostego końca pracy programistów. Bardziej trafna interpretacja jest inna: kończy się epoka, w której ręczne pisanie kodu było najważniejszym symbolem wartości inżyniera.
Kod nadal pozostaje kluczowy. Bez niego nie ma produktu, aplikacji ani usługi. Ale coraz więcej wartości powstaje przed nim i wokół niego: w zrozumieniu problemu, opisie wymagań, jakości architektury, systemie testów, kontroli agentów i decyzji, czy tworzone rozwiązanie ma sens biznesowy.
AI nie sprawia, że software development staje się prosty. Sprawia, że inaczej rozkładają się kompetencje, ryzyka i odpowiedzialność. Programista przyszłości może rzadziej pisać każdą linijkę kodu ręcznie, ale będzie musiał lepiej rozumieć system, który pozwala ten kod bezpiecznie tworzyć.
