2 godzin temu
Gdy MacLaren Stanley, Senior Principal Engineer w Amazon Stores, mówi, iż jego zespół nie pisze manualnie „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, ale jako praktyk pracujący w zespole Amazon, związany między innymi z technologiami stojącymi za aplikacją Amazon Shopping. Jego doświadczenie jest interesujące nie dlatego, iż pokazuje najbardziej radykalną wersję użycia AI w programowaniu, ale dlatego, iż 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, ale przebudowanie pracy inżynierskiej tak, aby agenci AI mogli realnie uczestniczyć w tworzeniu oprogramowania.
Najciekawsze w deklaracji o braku manualnego 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, iż nie zakazał zespołowi manualnego 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, iż rola inżyniera znika. Zmienia się raczej miejsce, w którym powstaje jego wartość. jeżeli 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ść manualnego pisania kodu przez cały czas 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, ale 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żeli 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ł, iż 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żeli 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, iż 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ę. gwałtownie okazało się jednak, iż 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 przez cały czas jest obecny w procesie, ale jego rola przesuwa się z manualnego analizowania każdej linijki na ocenę tego, czy system buduje adekwatne 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ć przez cały czas naiwne narzędzie rozpoznawania wzorców. jeżeli 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, ale 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żeli 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 systemu z udziałem AI”.
Największym błędem byłoby więc czytanie deklaracji o braku manualnego kodowania jako zapowiedzi prostego końca pracy programistów. Bardziej trafna interpretacja jest inna: kończy się epoka, w której manualne pisanie kodu było najważniejszym symbolem wartości inżyniera.
Kod przez cały czas 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, iż software development staje się prosty. Sprawia, iż inaczej rozkładają się kompetencje, ryzyka i odpowiedzialność. Programista przyszłości może rzadziej pisać każdą linijkę kodu manualnie, ale będzie musiał lepiej rozumieć system, który pozwala ten kod bezpiecznie tworzyć.
Przeczytaj więcej w Q&A.
