Dlaczego architekt oprogramowania potrzebuje czegoś więcej niż AI asystenta do kodowania
Większość dyskusji o sztucznej inteligencji w programowaniu koncentruje się na jednym obszarze: automatyzacji pisania kodu. Narzędzia oparte na dużych modelach językowych potrafią dziś generować całe funkcje, podpowiadać testy jednostkowe czy komentować pull requesty. To realna wartość, ale z perspektywy architektów oprogramowania i tech leadów pozostaje pytanie: co z projektowaniem systemów jako całości?
W praktyce największe ryzyka i koszty nie wynikają z pojedynczych linijek kodu, lecz z decyzji architektonicznych: sposobu podziału odpowiedzialności między modułami, wyboru stylu integracji, modeli danych, polityk bezpieczeństwa czy strategii skalowania. To tu zapadają decyzje, które trudno później odwrócić, a ich konsekwencje liczy się w latach, nie sprintach.
Koncepcja „AI coding assistant” jest więc zbyt wąska. Coraz ważniejsza staje się rola „AI pair architect” – modelu, który pełni funkcję strukturalnego, opiniotwórczego partnera w rozmowie o architekturze, zamiast być wyłącznie generatorem fragmentów kodu. Taki model nie zastępuje projektanta, lecz pomaga mu myśleć szerzej, systematyczniej i bardziej wielowymiarowo.
Jednocześnie warto zachować trzeźwość. Zmęczenie wokół szumu związanego z AI jest uzasadnione, o czym dobrze świadczą analizy w stylu krytycznego spojrzenia na rozczarowanie wokół ChatGPT-5 i potencjalnej bańki inwestycyjnej. Wiele obietnic okazuje się przesadzonych, a część zastosowań – powierzchowna lub wręcz szkodliwa, jeśli modele traktuje się jak nieomylne źródło prawdy.
Dlatego użycie LLM-ów jako „pair architect” powinno opierać się na konkretnych, powtarzalnych schematach pracy. Zamiast magicznych rozwiązań chodzi o zestaw praktycznych workflowów: jak prowadzić z modelem rozmowę o threat modelingu, jak użyć go do scenariuszy capacity planningu, jak strukturyzować spór monolit kontra mikroserwisy, jak dobrać model danych i zaprojektować kontrakty API, oraz jak dokumentować decyzje w sposób audytowalny.
Adresatami takiego podejścia są przede wszystkim tech leadzi, inżynierowie na poziomie staff/principal oraz doświadczeni programiści, którzy na co dzień projektują systemy i nie chcą oddawać decyzji maszynie, lecz zwiększyć zasięg własnego osądu. Model ma być partnerem do dyskusji, nie pilotem automatycznym.
Rola „pair architecta” w nowoczesnym projektowaniu systemów
Rola współczesnego architekta oprogramowania lub tech leada rzadko sprowadza się do wyboru „stosów technologicznych”. To przede wszystkim praca nad klarownym zrozumieniem wymagań biznesowych, identyfikacją ryzyk, doborem wzorców architektonicznych, wspieraniem zespołów w podejmowaniu kompromisów oraz dokumentowaniem kluczowych decyzji, np. w formie Architecture Decision Records (ADR).
W pracy tej ważne są elementy trudne do automatyzacji: rozpoznanie interesariuszy, uwzględnianie celów biznesu, ograniczeń finansowych, regulacyjnych i organizacyjnych. Jednocześnie wiele zadań ma charakter analityczny i powtarzalny: analiza scenariuszy, wyliczanie konsekwencji technicznych, generowanie wariantów rozwiązań, tworzenie list ryzyk czy edge case’ów.
„Pair architect” można rozumieć przez analogię do pair programmingu. Człowiek pozostaje odpowiedzialny za decyzje i rozumienie kontekstu, a model pełni funkcję wymagającego partnera: dopytuje o założenia, wskazuje luki w rozumowaniu, proponuje alternatywne rozwiązania, porządkuje argumenty za i przeciw, pomaga spisać wnioski.
Modele językowe wnoszą do tej roli kilka istotnych możliwości. Potrafią szybko porównać wiele podejść, przypomnieć szeroki katalog wzorców architektonicznych oraz typowych błędów, wygenerować uporządkowane listy zagrożeń, scenariuszy użycia lub wymagań niefunkcjonalnych, a także wesprzeć w dokumentowaniu uzasadnienia decyzji. W jednym miejscu można połączyć dyskusję, analizę alternatyw i zapis konkluzji.
Równocześnie ich ograniczenia są realne i dobrze udokumentowane. Modele halucynują – potrafią z dużą pewnością opisywać technologie czy limity, które nie istnieją. Dysponują wiedzą historyczną, często nie obejmującą najnowszych zmian w usługach chmurowych czy bibliotekach. Nie znają specyfiki danej organizacji: struktury zespołów, realnych kompetencji, nieformalnych procesów, historii projektów. Mają też skłonność do prezentowania uogólnionych odpowiedzi tam, gdzie potrzebne są precyzyjne, lokalne niuanse.
Dlatego warto przyjąć jasny podział odpowiedzialności. Po stronie człowieka musi pozostać: dopasowanie architektury do celów biznesowych, akceptowalny poziom ryzyka, ostateczny wybór kompromisów między kosztami, szybkością dostarczania a jakością, a także ocena ograniczeń organizacyjnych – np. realnej zdolności zespołu do utrzymania danego rozwiązania.
Obszary, które mogą być współdzielone z modelem, to m.in.: burza mózgów wokół ryzyk i edge case’ów, porównanie kilku wzorców architektonicznych dla jasno opisanych wymagań, generowanie checklist do przeglądów technicznych, wstępne szkice ADR-ów czy scenariusze migracji. Model może też wspierać w przygotowaniu materiałów do komunikacji z innymi działami, np. uproszczonych wyjaśnień dla biznesu, dlaczego wybrano daną opcję.
Threat modeling z użyciem LLM – jak prowadzić ustrukturyzowane rozmowy o bezpieczeństwie
Threat modeling to uporządkowane podejście do pytania: „co może pójść nie tak w tym systemie, kto może to wykorzystać i jak możemy się przed tym zabezpieczyć?”. W praktyce sprowadza się do identyfikacji zasobów (np. bazy danych z wrażliwymi danymi), aktorów (użytkownicy, integracje partnerskie, potencjalni atakujący), granic zaufania (np. między siecią publiczną a prywatną) oraz potencjalnych wektorów ataku. Ramy takie jak STRIDE czy attack trees pomagają w usystematyzowaniu analizy, ale wymagają czasu i dyscypliny.
Model językowy może tu pełnić rolę facylitatora. Zamiast oczekiwać „magicznych” odpowiedzi z zakresu bezpieczeństwa, warto użyć go jako narzędzie prowadzące rozmowę i wymuszające pełniejszą listę hipotez. Dobrze przygotowany prompt pozwala szybko przejść od ogólnego opisu systemu do zmapowanych zasobów i granic zaufania, a następnie do listy zagrożeń i potencjalnych mitygacji.
Przykładowy szablon promptu do zainicjowania threat modelingu może wyglądać następująco (w wolnym tłumaczeniu): opisz krótko architekturę systemu, typy danych i użytkowników, a następnie poproś model o zidentyfikowanie aktywów, aktorów i granic zaufania. W kolejnym kroku można poprosić o enumerację zagrożeń dla konkretnych komponentów lub przepływów danych, wraz z sugestiami mitygacji oraz wskazaniem, które wymagają zmian architektury, a które można obsłużyć konfiguracją lub politykami bezpieczeństwa.
Dobrą praktyką jest iteracyjne doprecyzowywanie odpowiedzi. Po wklejeniu uproszczonego opisu diagramu architektury (np. „frontend web, backend API, baza danych transakcji, bramka płatności, zewnętrzny system CRM”) warto poprosić model o wskazanie zagrożeń dla każdej granicy: między użytkownikiem a frontendem, między frontendem a API, między API a bazą i usługami zewnętrznymi. Następnie można zakwestionować odpowiedzi („załóż, że działamy w UE i podlegamy RODO; jakie dodatkowe zagrożenia się pojawiają?”) i doprecyzować kontekst regulacyjny czy branżowy.
Ilustracją może być prosty system płatności online. Dobrze przygotowany model wskaże nie tylko oczywiste kwestie, jak ochrona danych kart płatniczych czy zabezpieczenie komunikacji TLS, lecz także mniej oczywiste zagrożenia: ryzyko eskalacji uprawnień w panelu administracyjnym, ataki na proces resetowania hasła, możliwość wykorzystania webhooków do wstrzyknięcia złośliwych ładunków, czy skutki braku izolacji środowisk testowych od produkcyjnych. Zbyt ogólna odpowiedź natomiast ograniczy się do uniwersalnych porad w rodzaju „stosuj szyfrowanie”, „waliduj dane wejściowe” bez powiązania z konkretną architekturą.
Ostateczna odpowiedzialność musi jednak pozostać po stronie architekta lub eksperta ds. bezpieczeństwa. Warto stosować prostą checklistę przeglądu: czy zidentyfikowane zagrożenia odpowiadają rzeczywistości systemu, czy brakuje zagrożeń specyficznych dla domeny (np. fraud w płatnościach, nadużycia promocji, ataki na łańcuch dostaw), czy proponowane mitygacje są technicznie i organizacyjnie wykonalne oraz czy są zgodne z polityką ryzyka organizacji.
Model nie może być traktowany jak wyrocznia bezpieczeństwa. Jego rola to rozszerzenie spektrum rozważanych scenariuszy i pomoc w ich dokumentowaniu. Dobrze sprawdza się w generowaniu materiału do przeglądu, ale każda rekomendacja wymaga krytycznego spojrzenia i często weryfikacji z zespołem bezpieczeństwa.
Planowanie pojemności (capacity planning) i skalowanie systemów z użyciem LLM
Planowanie pojemności i skalowanie systemów to próba przełożenia języka biznesu na parametry techniczne. Liczba użytkowników aktywnych dziennie, wskaźniki wzrostu, oczekiwane czasy odpowiedzi czy wymagania dostępności muszą zostać przetłumaczone na szacunkową liczbę żądań na sekundę, przepustowość odczytów i zapisów, przyrost danych, koszt infrastruktury i strategie skalowania.
Modele językowe mogą tu pomóc jako narzędzie do tworzenia przybliżonych modeli obciążenia i scenariuszy „co jeśli”. Po podaniu podstawowych założeń biznesowych model jest w stanie zaproponować orientacyjne przeliczenia: ile żądań wygeneruje określona liczba użytkowników w godzinach szczytu, które komponenty architektury będą prawdopodobnie wąskimi gardłami, jak różne wzorce ruchu (np. kampanie marketingowe, sezonowość) zmienią charakter obciążenia.
Przykładowy szablon promptu może polegać na zebraniu w jednym miejscu kluczowych liczb: użytkownicy miesięcznie, udział użytkowników dziennie aktywnych, średnia liczba operacji na użytkownika, szczytowy współczynnik jednoczesności. Następnie można poprosić model o wyprowadzenie krok po kroku prognozowanego RPS (requests per second) dla głównych endpointów, przybliżonego przyrostu danych oraz wymagań co do opóźnień.
W kolejnym kroku warto poprosić o zidentyfikowanie potencjalnych wąskich gardeł w opisanej architekturze: które komponenty mogą wymagać skalowania poziomego, gdzie pojawi się ryzyko konkurencyjnego dostępu do zasobów, jakie elementy infrastruktury chmurowej (np. limity IOPS, przepustowość sieci, limity API) mogą być ograniczające. Dobrą praktyką jest proszenie modelu o przedstawienie rozumowania krok po kroku oraz uporządkowane podsumowanie w postaci zwięzłego zestawienia, choć liczby powinny zawsze zostać zweryfikowane niezależnie.
Modele dobrze nadają się też do budowania scenariuszy typu „a co, jeśli?”. Można zapytać o skutki nagłego wzrostu ruchu dziesięciokrotnie, o konsekwencje problemów typu „noisy neighbor” w środowiskach współdzielonych, czy o zachowanie systemu przy awarii całego regionu chmurowego. Taka praca przypomina odkrywanie ukrytej złożoności w pozornie prostych abstrakcjach – podobnie jak w analizie nieoczywistych aspektów frameworków front-endowych, o których mowa w tekście o ciemnych stronach pozornie prostych hooków w React.
Kluczowe jest jednak, by wnioski z modelu traktować jako wstępne hipotezy. Dobrze skonstruowana checklista przeglądu dla człowieka powinna obejmować: porównanie wyliczeń z rzeczywistymi danymi telemetrycznymi z produkcji lub środowisk testowych, korektę założeń pod kątem konkretnych parametrów sprzętu i usług chmurowych, uwzględnienie limitów dostawcy oraz ograniczeń kosztowych, a także stres test założeń przy użyciu danych historycznych.
LLM wspiera tu myślenie scenariuszowe i pozwala szybciej dojść do pytań, które warto zadać. Ostateczne decyzje dotyczące wymiarowania zasobów, budżetów czy planów awaryjnych muszą jednak opierać się na twardych danych z monitoringu i testów obciążeniowych, a nie na szacunkach z modelu.
Monolit czy mikroserwisy? Jak użyć AI do podejmowania decyzji architektonicznych
Spór między architekturą monolityczną a mikroserwisową trwa od lat i często przyjmuje formę ideologicznej debaty. W praktyce wybór ten jest przede wszystkim decyzją organizacyjno-operacyjną, a dopiero w drugiej kolejności – technologiczną. Liczy się wielkość i dojrzałość zespołu, poziom automatyzacji wdrożeń, kultura on-call, dojrzałość monitoringu, a także dynamika zmian w poszczególnych częściach domeny biznesowej.
Monolit upraszcza wiele aspektów: pojedynczy proces wdrożeniowy, spójny model danych, brak skomplikowanych protokołów komunikacji między usługami. Z drugiej strony może stać się trudny w utrzymaniu, jeśli rośnie bez kontroli. Mikroserwisy zwiększają autonomię zespołów i pozwalają skalować niezależnie krytyczne fragmenty systemu, ale wprowadzają znaczną złożoność operacyjną: zarządzanie siecią, obserwowalność, odporność na awarie częściowe, wersjonowanie kontraktów.
Model językowy może pomóc ustrukturyzować tę decyzję, unikając odpowiedzi w rodzaju „to zależy” bez dalszego uzasadnienia. Po podaniu szczegółów dotyczących wielkości zespołu, rozkładu kompetencji, obecnego stopnia automatyzacji CI/CD, poziomu dojrzałości monitoringu oraz wymagań biznesowych, można poprosić model o przedstawienie argumentów przemawiających za monolitem lub mikroserwisami, wraz z jawnym wyszczególnieniem zalet i kosztów każdego podejścia.
Dobrym zastosowaniem jest wygenerowanie wstępnego szkicu ADR porównującego dwie lub trzy opcje architektoniczne. Taki dokument może zawierać kontekst, problem do rozwiązania, rozważane warianty, kryteria oceny, analizę plusów i minusów, decyzję oraz konsekwencje. Model przyspiesza przygotowanie struktury i wypełnienie jej treścią, ale wybór oraz niuanse językowe muszą zostać dopasowane przez osobę odpowiedzialną za architekturę do kultury organizacyjnej.
Cennym wzorcem jest także poproszenie modelu o zaproponowanie ewolucyjnej ścieżki: od dobrze zorganizowanego, modułowego monolitu do stopniowej ekstrakcji usług w momentach, gdy uzasadniają to dane i organizacja. Taki plan może obejmować kamienie milowe, np. wprowadzenie modułowych granic w kodzie, wydzielenie krytycznych funkcji do osobnych komponentów, wzmocnienie infrastruktury obserwowalności, a dopiero później pełną separację na poziomie deploymentu.
Jednym z największych ryzyk przy korzystaniu z modeli jest ich tendencja do faworyzowania modnych rozwiązań. Jeśli prompt nie zawiera informacji o dojrzałości organizacji, poziomie utrzymania czy dopuszczalnej złożoności operacyjnej, model może nadmiernie promować mikroserwisy czy rozbudowane architektury event-driven. Warto więc świadomie przekazywać kontekst: liczba osób w zespole, dostępność SRE/DevOps, poziom dyżurów on-call, dotychczasowy stan automatyzacji.
Przed podjęciem decyzji przydaje się krótka checklista: czy wybór jest powiązany z celami biznesowymi, czy odpowiada realnym zdolnościom operacyjnym zespołu, czy dodatkowa złożoność jest proporcjonalna do korzyści, oraz czy granice danych są dobrze zdefiniowane. Model można także poprosić o „kontrargumenty” dla podjętej decyzji – o wskazanie ryzyk, antywzorców i potencjalnych problemów migracyjnych.
W kontekście tej dyskusji warto mieć wyraźnie proste, praktyczne stanowisko: dopóki organizacja nie osiągnie określonej skali i dojrzałości, prostsze architektury – dobrze zaprojektowany monolit lub modułowy monolit – są zwykle bezpieczniejszym wyborem. Model może pomóc tę tezę uargumentować i zakomunikować interesariuszom, ale nie powinien jej narzucać wbrew zdrowemu rozsądkowi.
Wybór bazy danych i projektowanie kontraktów API z pomocą LLM
Dobór bazy danych i projektowanie modeli danych są jednymi z najbardziej strategicznych decyzji w projekcie. Wybór między bazą relacyjną, dokumentową, klucz-wartość czy time-series wpływa na sposób modelowania domeny, możliwości zapytań, skalowanie oraz odporność na awarie. Istotne są też wymagania dotyczące spójności, dostępności i opóźnień, a także wzorce dostępu do danych: czy dominuje odczyt, zapis, czy złożone zapytania analityczne.
Model językowy może pomóc w mapowaniu wymagań domenowych i typowych zapytań na kandydackie rozwiązania technologiczne. Po zebraniu informacji o głównych encjach, relacjach między nimi, typowych operacjach odczytu i zapisu oraz ograniczeniach niefunkcjonalnych, można poprosić model o zaproponowanie dwóch wariantów: relacyjnego i nierelacyjnego, wraz z omówieniem kompromisów. Warto też poprosić o szkic schematu lub struktury dokumentów oraz o wskazanie potencjalnych problemów przy skalowaniu.
Przydatne są również scenariusze migracyjne. Można zapytać model o ryzyka związane z przejściem z bazy relacyjnej na dokumentową (lub odwrotnie): wpływ na transakcje, spójność danych, zmianę schematów, migrację danych historycznych, wpływ na raportowanie. Otrzymana lista nie powinna zastępować szczegółowej analizy, ale może stanowić punkt wyjścia do planu migracji.
Dobrym zastosowaniem jest także porównanie, jak określona funkcjonalność wygląda w różnych bazach. Na przykład: jak zrealizować system koszyka zakupowego i historii zamówień w bazie relacyjnej, dokumentowej oraz klucz-wartość, jakie są plusy i minusy każdego podejścia, gdzie pojawiają się konflikty między spójnością a prostotą. Tego typu porównania pomagają zespołowi świadomie wybrać technologię, zamiast kierować się wyłącznie przyzwyczajeniem lub modą.
Naturalnym rozszerzeniem tematu danych jest projektowanie kontraktów API. Dobrze zaprojektowane API to stabilny, czytelny kontrakt dla innych zespołów i partnerów zewnętrznych. Wymaga jasnego nazewnictwa zasobów, przemyślanych endpointów, spójnych schematów żądań i odpowiedzi, przewidywalnego modelu błędów oraz polityki wersjonowania.
Model może tu przyspieszyć proces, gdy punktem wyjścia są scenariusze użytkownika lub wymagania integracyjne. Po opisaniu kluczowych person, ich celów i przepływów można poprosić o propozycję REST lub GraphQL API: listę zasobów, przykładowe endpointy, formaty JSON-owych odpowiedzi, standardowy model błędów, strategię paginacji i podstawowe mechanizmy bezpieczeństwa, takie jak autoryzacja czy limitowanie zapytań.
Warto prosić o jednoczesne wygenerowanie mapy zasobów i przykładów payloadów, co przyspiesza przeglądy z zespołami klienckimi. Dobrze przygotowany prompt obejmuje też prośbę o uwzględnienie wersjonowania, komunikatów błędów z przyjaznymi komunikatami dla użytkownika oraz wskazanie miejsc, w których API powinno być bardziej konserwatywne wobec zmian, by nie łamać integracji.
Przed akceptacją projektu API wskazana jest checklista: spójność nazewnictwa, strategia wersjonowania, podejście do kompatybilności wstecznej, jasne reguły obsługi błędów, rozwiązania w zakresie paginacji i filtrowania, a także aspekty bezpieczeństwa – od uwierzytelniania i autoryzacji po kontrolę limitów. Trzeba też dopasować wzorce do możliwości wybranego stosu technologicznego, który często ma swoje niuanse i „ukryte funkcje”. Przypomina to odkrywanie mniej oczywistych możliwości frameworków, opisane np. w tekście o ukrytych możliwościach Angulara, które potrafią istotnie wpłynąć na projekt przepływu danych i strukturę API.
Wygenerowane przez model projekty baz danych i API należy traktować jako punkty startowe: przyspieszają dyskusję, pozwalają szybciej zobaczyć konsekwencje decyzji, ułatwiają dokumentowanie, ale nie są gotową specyfikacją produkcyjną. Konieczne są przeglądy techniczne, testy, pilotaże i iteracje.
Checklista, guardrails i kiedy osąd architekta musi przeważyć nad rekomendacją AI
Skuteczne korzystanie z LLM-ów jako „pair architect” wymaga spójnych praktyk, które chronią przed typowymi błędami i zapewniają ślad decyzyjny. Pomaga w tym prosta, przekrojowa checklista dla każdej sesji architektonicznej z udziałem modelu. Na początku trzeba jasno zdefiniować problem oraz ograniczenia: cele biznesowe, zakres, budżet, wymagania niefunkcjonalne. Następnie przekazać modelowi jak najwięcej konkretnego kontekstu: przewidywany ruch, charakter danych, dojrzałość organizacji, używany stos technologiczny.
Warto konsekwentnie prosić o strukturalne odpowiedzi: listy ryzyk, warianty rozwiązań z uzasadnieniem, szkice ADR-ów, scenariusze „co jeśli”, a w razie potrzeby – podsumowania w formie krótko opisanych kroków. Każdą odpowiedź należy traktować jako hipotezę, którą trzeba zakwestionować: poprosić model o wskazanie założeń, o argumenty przeciwne, o krytykę wcześniejszych rekomendacji. Na koniec należy udokumentować, co zostało przyjęte, co odrzucone i z jakiego powodu.
Świadomość typowych porażek modeli jest kluczowa. Halucynacje technologiczne (np. nieistniejące funkcje usług chmurowych), nadmiernie pewne stwierdzenia dotyczące bezpieczeństwa czy zignorowanie wymagań niefunkcjonalnych pojawiają się częściej, niż można by oczekiwać. Modele mają też tendencję do pomijania ograniczeń organizacyjnych, takich jak limity kompetencji czy obciążenie zespołu.
Istnieją obszary, w których szczególną ostrożność należy uznać za obowiązek. Wszelkie przepływy płatności, przetwarzanie danych zdrowotnych, systemy o krytycznym znaczeniu dla bezpieczeństwa fizycznego czy infrastruktury powinny zawsze przechodzić przez pogłębiony przegląd ekspercki, niezależnie od tego, jak przekonująca jest odpowiedź modelu. W takich przypadkach AI może co najwyżej wspierać proces analizy, ale nigdy nie powinna być jedynym źródłem rekomendacji.
Istotnym elementem odpowiedzialnego korzystania z LLM-ów jest śledzenie decyzji. Prompty, odpowiedzi i podjęte na ich podstawie działania warto dołączać do dokumentacji architektonicznej. Pozwala to po czasie odtworzyć przebieg rozważań, zrozumieć, dlaczego wybrano daną opcję oraz ocenić, gdzie model pomógł, a gdzie zawiódł.
Praktycznym wzorcem pracy jest włączenie modelu w cykl przeglądów architektury. Można z wyprzedzeniem przygotować prompty i wstępne analizy, następnie podczas spotkania wykorzystać model do eksploracji alternatyw w czasie rzeczywistym, a po spotkaniu przeprowadzić walidację wniosków w mniejszym gronie, z uwzględnieniem dodatkowych danych i opinii ekspertów domenowych.
Ostatecznie jednak to człowiek – tech lead, architekt, inżynier na poziomie staff/principal – musi pozostać arbitrem. Do niego należy powiązanie rozwiązań technicznych z kierunkiem biznesowym, ocena ryzyka i długoterminowych konsekwencji oraz podejmowanie decyzji nieodwracalnych lub o wysokim koszcie zmiany. Rola ta coraz częściej polega na orkiestracji różnych źródeł informacji: wiedzy zespołu, danych z monitoringu, doświadczeń z innych projektów i wkładu modeli językowych.
To przesunięcie roli – z samotnego decydenta w kierunku koordynatora dyskusji człowiek–AI – może stać się jednym z najbardziej konstruktywnych skutków rozwoju narzędzi AI w inżynierii oprogramowania. Wymaga jednak systematycznego eksperymentowania, a nie ad hoc wykorzystywania modeli w chwilach presji czasu. Warto łączyć opisane tutaj workflowy z istniejącymi praktykami przeglądów technicznych oraz z krytycznymi perspektywami na temat hype’u wokół AI, takimi jak wspomniana analiza potencjalnej bańki na rynku sztucznej inteligencji.
Modele językowe mogą stać się wartościowymi „pair architectami” – pod warunkiem, że pozostaną narzędziami w rękach doświadczonych inżynierów, a nie odwrotnie.