Jak powstał Claude Code i dlaczego oznacza nową erę agentów programistycznych

Dlaczego nowa generacja agentów programistycznych staje się kluczowa dla firm technologicznych

W ciągu zaledwie kilku lat duże modele językowe przeszły drogę od ciekawostki do jednego z kluczowych czynników zmieniających sposób pracy zespołów technologicznych. Początkowo traktowano je jako ulepszone autouzupełnianie kodu: narzędzia, które pozwalają szybciej pisać pojedyncze linie czy funkcje. Dziś coraz więcej organizacji oczekuje od AI czegoś znacznie więcej – partnera wytwarzającego oprogramowanie, który rozumie kontekst biznesowy, zna repozytorium i potrafi samodzielnie zaplanować oraz przeprowadzić złożone zmiany.

Presja na zespoły inżynierskie stale rośnie. Firmy oczekują jednocześnie szybszego dostarczania funkcjonalności, wyższej jakości kodu i mniejszej liczby błędów w produkcji. Rynek pracy staje się coraz bardziej konkurencyjny, a koszt opóźnień w realizacji roadmapy produktowej potrafi być liczony w milionach. W tym kontekście proste „chatboty do kodu” przestają wystarczać. Usprawniają pojedyncze zadania, ale nie zmieniają fundamentalnie procesu wytwarzania oprogramowania.

To właśnie w tej luce pojawia się nowa generacja agentów programistycznych, której symbolem stał się Claude Code rozwijany w Anthropic. Jego twórca, inżynier i praktyk Boris Cherny, w licznych rozmowach branżowych podkreśla, że celem nie było stworzenie kolejnego generatora fragmentów kodu, lecz asystenta działającego jak świadomy kontekstu współpracownik. W jego wizji agent nie tylko rozumie polecenia w języku naturalnym, ale potrafi poruszać się po całym cyklu pracy deweloperskiej: od analizy wymagań po przygotowanie gotowego pull requestu.

Niniejszy tekst podsumowuje najważniejsze wątki z wypowiedzi Borisa Cherny’ego i doświadczeń zespołów korzystających z Claude Code, rozwijając je o praktyczną perspektywę CTO, liderów technologicznych, product ownerów i samych deweloperów. W przeciwieństwie do wielu technicznych opracowań, artykuł jest adresowany także do osób nietechnicznych – wyjaśnia pojęcia, opisuje kontekst biznesowy i pokazuje konkretne scenariusze zastosowań bez zakładania specjalistycznej wiedzy. Kluczowe jest zrozumienie, że mówimy nie o „magicznej” technologii, lecz o przemyślanej kombinacji modelu LLM, inżynierii systemowej oraz iteracyjnej współpracy z zespołami developerskimi.

Od marzenia o „programiście‑agencie” do produktu: historia powstania Claude Code

Punktem wyjścia dla Claude Code była obserwacja ograniczeń wcześniejszych narzędzi AI do kodu. Klasyczne code completion działało lokalnie w edytorze, podpowiadając kolejne fragmenty funkcji, ale bez szerszego kontekstu aplikacji. Proste chatboty z modelem LLM potrafiły wygenerować przykładowe rozwiązanie na podstawie promptu, jednak wymagały od programisty ręcznego wyszukiwania plików, kopiowania fragmentów kodu i samodzielnej oceny, czy wynik rzeczywiście pasuje do reszty systemu.

W praktyce oznaczało to, że deweloper musiał nieustannie „pilotować” AI: wskazywać konkretne pliki, tłumaczyć zależności, ręcznie składać zmiany i pisać testy. Narzędzia przyspieszały pracę, ale nie zdejmowały z barków inżyniera odpowiedzialności za całościowe zrozumienie systemu i zarządzanie złożonością.

Boris Cherny, opowiadając o genezie Claude Code, zwraca uwagę na inne podejście: asystent powinien zachowywać się jak doświadczony członek zespołu, który zna historię repozytorium, rozumie styl kodu i ma świadomość wymagań biznesowych. W wywiadach podkreśla, że celem było zbudowanie „programisty‑agenta”, który potrafi nie tylko pisać kod, lecz przede wszystkim planować, dzielić zadania na kroki i korzystać z całego środowiska narzędziowego – od testów automatycznych po issue trackery.

Ta wizja wpisuje się w szerszy trend agentowego AI. Zamiast pojedynczego modelu odpowiadającego na pytania, mamy system zdolny do samodzielnego wykonywania sekwencji działań, analizowania wyników i korygowania własnych błędów. W przypadku Claude Code oznacza to, że agent umie na przykład:

• przeczytać opis zadania w języku naturalnym,
• przeszukać repozytorium w poszukiwaniu relewantnych plików,
• zaproponować plan modyfikacji,
• wprowadzić zmiany w kodzie,
• uruchomić testy,
• i na koniec przygotować pull request do review.

Co istotne, nie jest to efekt pojedynczego „genialnego” modelu, lecz kombinacji kompetentnego LLM, narzędzi do pracy na repozytorium, systemu zarządzania kontekstem oraz wielu iteracji z realnymi zespołami developerskimi. Cherny wielokrotnie podkreśla, że wczesne wersje Claude Code popełniały błędy i wpadały w „spirale” powtarzających się prób. Dopiero wprowadzenie mechanizmów planowania, weryfikacji i sprzężenia zwrotnego pozwoliło uzyskać jakość umożliwiającą produkcyjne wdrożenia.

Jak działa agent programistyczny Claude Code: architektura, kontekst i przepływ pracy

Różnica między prostym modelem językowym a agentem programistycznym polega przede wszystkim na tym, że agent nie zatrzymuje się na wygenerowaniu odpowiedzi. Potrafi zaplanować zadanie, wykonać kolejne kroki, sprawdzić ich wynik i na tej podstawie podjąć dalsze decyzje.

W przypadku Claude Code można wyróżnić kilka kluczowych elementów koncepcyjnej architektury:

• LLM jako „mózg” – duży model językowy, który rozumie język naturalny i kod źródłowy, analizuje kontekst i podejmuje decyzje o kolejnych krokach.
• Dostęp do kontekstu projektu – agent ma możliwość czytania plików z repozytorium, dokumentacji, testów czy opisów zadań. Zamiast „wczytywać” całe repozytorium na raz, system indeksuje kod i wykorzystuje inteligentne wyszukiwanie.
• Planowanie kroków – zamiast od razu zmieniać kod, Claude Code najpierw proponuje plan: które pliki należy zmodyfikować, jakie testy dodać, co potencjalnie może się zepsuć.
• Pętla sprzężenia zwrotnego – po wprowadzeniu zmian agent uruchamia testy, analizuje błędy i samodzielnie je poprawia, przechodząc przez kilka iteracji, zanim zaproponuje gotowy PR.

W tle kluczową rolę odgrywa kontekstowe wyszukiwanie (często określane skrótem RAG – Retrieval-Augmented Generation), które można wyjaśnić w prosty sposób: zamiast próbować „przeczytać” cały kod za jednym razem, agent najpierw wyszukuje w repozytorium te fragmenty, które są najbardziej istotne dla danego problemu, a dopiero potem je analizuje i modyfikuje. To tak, jakby doświadczony programista najpierw zadał kilka celnych pytań wyszukiwarce w IDE, a dopiero później zaczął pracę nad konkretnymi plikami.

Z perspektywy użytkownika sesja pracy z Claude Code może wyglądać następująco:

• Deweloper opisuje w języku naturalnym zadanie – na przykład: „Dodaj możliwość logowania dwuskładnikowego z użyciem SMS dla użytkowników biznesowych”.
• Agent przeszukuje repozytorium, identyfikuje moduły odpowiedzialne za logowanie, zarządzanie użytkownikami i wysyłkę powiadomień.
• Claude Code proponuje plan – wskazuje, jakie pliki zostaną zmienione, jakie nowe komponenty powstaną i jakie testy należy dodać.
• Po akceptacji planu przez dewelopera agent dokonuje zmian w kilku plikach, generuje testy i uruchamia je.
• W razie niepowodzenia testów samodzielnie analizuje błędy, poprawia kod i ponownie odpala testy.
• Na końcu przygotowuje pull request z opisem zmian i linkami do relewantnych fragmentów kodu.

Tego typu przepływ pracy dobrze wpisuje się w szerszy krajobraz agentowego AI, opisywany również na przykładach spoza świata inżynierii oprogramowania. Dobrym punktem odniesienia jest analiza wykorzystania agentów w branży telekomunikacyjnej w artykule o agentowym AI w telekomunikacji, gdzie podobne podejście planowania zadań i korzystania z narzędzi jest wykorzystywane do obsługi klienta i operacji sieciowych.

Jakie realne problemy rozwiązuje Claude Code w codziennej pracy developerów

Z punktu widzenia zespołów technicznych kluczowe pytanie nie brzmi „czy agent jest imponujący technologicznie?”, lecz „jakie konkretne pain pointy usuwa z naszego dnia pracy”. Claude Code adresuje kilka powtarzalnych obszarów, w których tradycyjne narzędzia AI okazywały się niewystarczające.

Onboarding nowych programistów

Bez agenta wprowadzenie nowej osoby do dużego kodbase wymaga wielu tygodni: czytania dokumentacji (często nieaktualnej), pytań do bardziej doświadczonych kolegów, samodzielnego śledzenia zależności między modułami. Nawet proste pytanie „gdzie jest logika walidacji płatności?” może oznaczać godzinę przeszukiwania repozytorium.

Z Claude Code nowy deweloper może zadać takie pytanie bezpośrednio agentowi. Ten wyszukuje odpowiednie fragmenty kodu, wyjaśnia ich rolę i wskazuje pliki, w których znajdują się kluczowe elementy logiki. W efekcie nowa osoba szybciej zaczyna wykonywać realne zadania, a seniorzy mniej czasu poświęcają na odpowiadanie na powtarzalne pytania.

Praca z legacy code

W wielu organizacjach znacząca część systemów to wieloletnie aplikacje, które powstawały w różnych technologiach i stylach. Bez agenta zrozumienie starego modułu czy zaplanowanie refaktoryzacji wymaga od dewelopera żmudnego śledzenia zależności i ręcznej analizy wielu plików.

Claude Code potrafi w krótkim czasie zbudować „mapę” danego obszaru kodu, wskazać powiązania między modułami i zaproponować bezpieczne ścieżki refaktoryzacji. Deweloper skupia się na ocenie propozycji i podejmowaniu decyzji architektonicznych, zamiast tracić czas na żmudne przeglądanie plików.

Przyspieszenie implementacji nowych funkcjonalności

W tradycyjnym podejściu implementacja nowego feature’a wymaga najpierw zlokalizowania miejsc w kodzie, które trzeba zmodyfikować, a następnie zaprojektowania i wdrożenia zmian. Nawet jeśli AI generuje fragmenty kodu, to programista nadal ręcznie szuka plików, łączy zmiany i tworzy testy.

Z Claude Code proces może wyglądać inaczej: deweloper opisuje wymaganie, agent wskazuje miejsca w kodzie wymagające modyfikacji, proponuje implementację oraz zestaw testów jednostkowych. Programista ocenia propozycje, wprowadza ewentualne korekty i akceptuje finalne zmiany. Boris Cherny w swoich wypowiedziach zwraca uwagę, że prawdziwy przełom następuje wtedy, gdy agent najpierw przygotowuje dobry plan, a dopiero potem generuje kod – jeśli plan jest poprawny, jakość kodu istotnie rośnie.

Eliminacja „nudnych” zadań

Boilerplate, migracje schematów bazy danych, powtarzalne testy integracyjne – to obszary, które rzadko rozwijają kompetencje zespołu, a pochłaniają znaczącą ilość czasu. Do tej pory deweloperzy wykonywali je ręcznie lub z pomocą prostych generatorów.

Agent programistyczny przejmuje dużą część tych zadań. Claude Code jest w stanie zaproponować migracje, wygenerować odpowiedni kod i testy, a następnie uruchomić je, aby upewnić się, że nic nie zostało pominięte. Programista pełni rolę weryfikatora, a nie „maszyny do pisania kodu”.

Diagnostyka błędów

Typowy scenariusz bez agenta to długie analizowanie stack trace’ów, ręczne wyszukiwanie w repozytorium oraz próby odtworzenia sytuacji, w której wystąpił błąd. Przy złożonych systemach rozproszonych bywa to wyjątkowo frustrujące.

Claude Code potrafi zestawić stack trace z odpowiadającymi mu fragmentami kodu, przeanalizować możliwe przyczyny błędu i zaproponować poprawki. Często jest także w stanie samodzielnie przygotować test reprodukujący problem, a następnie go naprawić. Cherny podkreśla, że dzięki takim mechanizmom deweloperzy mogą skupić się na najtrudniejszych przypadkach, zamiast „gasić pożary” w prostszych sytuacjach.

W wielu wypowiedziach twórca Claude Code zwraca uwagę również na wymiar ludzki: mniej frustracji, więcej czasu na projektowanie architektury i rozwiązywanie problemów produktowych, a mniej na żmudne przeklikiwanie się przez kod. To właśnie ta zmiana jakości pracy, a nie pojedynczy wskaźnik „X% wzrostu produktywności”, okazuje się najbardziej odczuwalna.

Co odróżnia Claude Code od wcześniejszych narzędzi AI do kodu i klasycznych LLM

Na rynku istnieje już wiele narzędzi wykorzystujących AI w programowaniu. Różnica między nimi a agentem takim jak Claude Code nie sprowadza się jednak wyłącznie do „lepszego modelu”. Kluczowe są trzy cechy.

• Agentowość – Claude Code nie jest tylko modelem odpowiadającym na pytania. Potrafi samodzielnie planować i wykonywać sekwencje działań w repozytorium: edytować pliki, uruchamiać testy, przygotowywać PR-y. To radykalnie zmienia sposób jego wykorzystania w zespole.
• Głęboki kontekst – agent ma dostęp do dużych fragmentów kodu i dokumentacji, a nie tylko do kilku plików wklejonych do promptu. Dzięki temu rozumie zależności w obrębie całego systemu.
• Integracja z narzędziami developerskimi – Claude Code pracuje na gałęziach, pull requestach, issue trackerach i pipeline’ach CI. Wpisuje się w istniejący proces wytwarzania oprogramowania, zamiast funkcjonować jako odizolowany chatbot.

Te różnice są możliwe dzięki równoległemu rozwojowi samych modeli oraz inżynierii systemowej wokół nich. Postępy w zakresie jakości instrukcji i technik strojenia modeli dobrze ilustrują inicjatywy opisywane w analizach typu WizardLM – Enhancing Large Language Models with AI-Evolved Instructions, gdzie pokazano, jak ewolucja sposobu formułowania zadań przekłada się na zdolność modeli do realizacji złożonych poleceń. Claude Code korzysta z podobnych wniosków, ale osadza je w bardzo konkretnym kontekście pracy z kodem.

Warto podkreślić, że kluczem nie jest wyłącznie „większy model”. O sukcesie takiego rozwiązania decyduje to, jak jest ono wbudowane w cykl pracy zespołu: w jaki sposób zarządza kontekstem, jak planuje zadania, jakie ma mechanizmy weryfikacji oraz jak integruje się z istniejącą infrastrukturą CI/CD i narzędziami zarządzania pracą.

Bezpieczeństwo, kontrola i ryzyka: co musi wiedzieć CTO i product owner przed wdrożeniem agenta AI

Z perspektywy decydentów technologicznych i biznesowych najważniejsze pytanie dotyczy nie tyle możliwości agenta, ile bezpieczeństwa jego stosowania. Wprowadzenie systemu, który ma dostęp do repozytorium, testów i potencjalnie danych produkcyjnych, wymaga świadomego podejścia do ryzyk.

Bezpieczeństwo kodu i danych

Podstawową kwestią jest zrozumienie, jakie dane trafiają do modelu i w jakim trybie jest on uruchamiany. W przypadku prywatnych repozytoriów, kluczy dostępowych czy danych osobowych konieczne jest rygorystyczne zarządzanie dostępem, maskowanie lub anonimizacja wrażliwych informacji oraz wybór odpowiedniego modelu wdrożenia (np. środowisko chmurowe z gwarancjami izolacji danych vs rozwiązanie on‑premises).

CTO i liderzy bezpieczeństwa powinni opracować jasne zasady: które repozytoria mogą być indeksowane przez agenta, jakie dane muszą być automatycznie filtrowane, jakie logi zdarzeń są przechowywane i audytowane. Istotne jest także przeszkolenie zespołów z praktyk nieumieszczania w kodzie czy dokumentacji danych, które w ogóle nie powinny pojawić się w systemach wersjonowania.

Prompt injection i manipulacja agentem

Nową kategorią ryzyk w erze agentów jest prompt injection – sytuacja, w której złośliwe fragmenty kodu, komentarzy lub dokumentacji próbują „przeprogramować” model. Jeśli agent polega na treściach znalezionych w repozytorium, może natrafić na instrukcje ukryte w komentarzach, nakazujące np. usunięcie zabezpieczeń czy zmianę logiki autoryzacji.

Aby się przed tym bronić, potrzebne są warstwowe zabezpieczenia: filtrowanie wejść, wyraźny rozdział między danymi a instrukcjami oraz kontrola uprawnień agenta w systemach, do których ma dostęp. Temat został szerzej opisany w analizie Prompt injection w erze agentów AI, gdzie pokazano praktyczne techniki minimalizowania tego typu zagrożeń.

Odpowiedzialność i audytowalność

Boris Cherny wielokrotnie podkreśla, że niezależnie od poziomu automatyzacji każda linia kodu powinna zostać zrecenzowana przez inżyniera. To nie tylko kwestia jakości, ale też odpowiedzialności prawnej i biznesowej. Organizacja musi mieć jasne zasady: kto akceptuje zmiany, jak są one dokumentowane i w jaki sposób można odtworzyć decyzje podjęte przez agenta.

W praktyce oznacza to zaprojektowanie procesu code review, w którym pull requesty tworzone przez Claude Code przechodzą taki sam – lub nawet nieco bardziej rygorystyczny – proces akceptacji, jak te pisane ręcznie. Warto także zadbać o logowanie decyzji agenta: jakie polecenia otrzymał, jakie pliki zmienił, jakie testy uruchomił i jakie były ich wyniki.

Przed wdrożeniem agenta warto przygotować listę kontrolną dla CTO i product ownera, obejmującą m.in.:

• pytania do dostawcy dotyczące przechowywania i wykorzystywania danych,
• wymagane polityki bezpieczeństwa i zarządzania dostępem,
• zasady korzystania z agenta przez zespoły (co może robić samodzielnie, co wymaga recenzji),
• procedury reagowania na incydenty związane z błędnymi lub szkodliwymi zmianami.

Claude Code i podobne narzędzia mogą być bezpieczne i niezwykle wartościowe, ale tylko wówczas, gdy wdrażane są w sposób świadomy, z uwzględnieniem ryzyk technicznych, organizacyjnych i prawnych.

Jak zmienia się rola programistów i organizacji: praktyczne rekomendacje wdrożeniowe

Pojawienie się agentów programistycznych to nie tylko zmiana narzędzia, ale transformacja sposobu pracy. Boris Cherny w swoich wypowiedziach idzie nawet dalej, sugerując, że w perspektywie kilku lat sama nazwa „software engineer” może zacząć tracić na znaczeniu, a rola inżynierów przesunie się w stronę projektowania rozwiązań, definiowania wymagań i współpracy z użytkownikami.

Dla pojedynczego dewelopera oznacza to przejście od roli „osoby piszącej kod” do roli projektanta i weryfikatora. Codzienna praca coraz częściej polega na formułowaniu zadań dla agenta, ocenie proponowanych planów, przeglądzie pull requestów i dbaniu o spójność architektury systemu. Umiejętność precyzyjnego definiowania problemów w języku naturalnym staje się równie ważna, jak znajomość konkretnego frameworka.

Dla liderów technicznych i CTO rola przesuwa się w stronę architektów procesów: trzeba zaprojektować, jak ludzie i agenci współpracują, jakie są granice autonomii agenta, jak mierzyć jego skuteczność i jak minimalizować ryzyka. Coraz istotniejsze staje się myślenie systemowe – łączenie modeli, narzędzi, polityk bezpieczeństwa i praktyk zespołowych w spójną całość.

Product ownerzy z kolei muszą nauczyć się projektować przepływy pracy, które maksymalnie wykorzystują możliwości agenta. Może to oznaczać inne rozbijanie user stories, bardziej precyzyjne opisy wymagań funkcjonalnych czy większy nacisk na kryteria akceptacji, które agent może przełożyć na testy automatyczne.

Praktyczne rekomendacje wdrożeniowe dla organizacji obejmują m.in.:

• Start od pilota – warto zacząć od jednego zespołu lub projektu, w którym łatwiej jest obserwować efekty, wyciągać wnioski i stopniowo skalować dobre praktyki.
• Jasne zasady użycia – należy zdefiniować, jakie działania agent może wykonywać autonomicznie (np. generowanie boilerplate’u, proste poprawki), a które wymagają obowiązkowej recenzji technicznej.
• Mierzenie efektów – oprócz czasu od ticketu do PR-a czy liczby błędów warto monitorować także satysfakcję deweloperów oraz jakość architektury systemu w dłuższym okresie.
• Inwestycja w edukację – szkolenia z formułowania zadań (promptów), rozumienia ograniczeń modeli, dobrych praktyk bezpieczeństwa i pracy z agentami powinny stać się stałym elementem rozwoju kompetencji zespołów.

Z perspektywy twórcy Claude Code największa wartość nie wynika z jednorazowego skoku efektywności, ale z długofalowej zmiany sposobu myślenia o tworzeniu oprogramowania: od „ręcznego kodowania” w kierunku projektowania systemów, w których ludzie i agenci współpracują jak zgrany zespół.

Organizacje, które chcą dobrze wykorzystać najbliższe 6–12 miesięcy, powinny już teraz:

• zidentyfikować obszary kodu i procesy, w których agent może przynieść najszybszy zwrot z inwestycji,
• przygotować minimalne polityki bezpieczeństwa i zasady pracy z agentem,
• zaplanować pilotaż i sposób mierzenia jego efektów,
• zainwestować w edukację liderów technicznych i product ownerów.

Co dalej z agentami programistycznymi: scenariusze rozwoju i strategiczne decyzje dla biznesu

Claude Code jest dziś jednym z najbardziej rozpoznawalnych przykładów agenta programistycznego, ale wiele wskazuje na to, że jesteśmy dopiero na początku drogi. W perspektywie kilku lat można spodziewać się głębszej integracji agentów z całym cyklem życia oprogramowania – od planowania roadmapy, przez development, testy, aż po monitoring produkcji, SRE i bezpieczeństwo.

Możliwe są scenariusze, w których agent nie tylko implementuje pojedyncze funkcjonalności, ale przejmuje odpowiedzialność za utrzymanie konkretnych komponentów: planuje refaktoryzacje, proponuje zmiany architektury, reaguje na alerty z monitoringu i samodzielnie przygotowuje propozycje poprawek. W takim świecie człowiek coraz częściej pełni rolę nadzorcy i projektanta systemów współpracy wielu agentów.

Kolejnym krokiem może być połączenie różnych typów agentów – programistycznych, biznesowych, operacyjnych – w „wielozespołowe” środowiska. Agent produktowy mógłby analizować zachowania użytkowników i priorytetyzować backlog, agent programistyczny – implementować zmiany, a agent operacyjny – monitorować ich wpływ na wydajność i stabilność systemu. Dla organizacji oznacza to konieczność podjęcia strategicznych decyzji już dziś.

Kluczowe dylematy obejmują m.in.:

• Budować własne agenty czy korzystać z gotowych rozwiązań? – własny system daje większą kontrolę, ale wymaga znaczących inwestycji. Gotowe narzędzia przyspieszają start, lecz stawiają pytania o vendor lock‑in i elastyczność.
• Centralizować wdrożenie czy pozostawić eksperymenty zespołom? – centralizacja ułatwia kontrolę i standaryzację, ale może spowolnić innowacje. Z kolei lokalne eksperymenty pozwalają szybciej testować nowe podejścia, kosztem spójności.
• Traktować agenta jako plugin do IDE czy pełnoprawnego członka zespołu projektowego? – to decyzja, która wpływa na sposób projektowania procesów, ról i odpowiedzialności.

Można wyróżnić co najmniej trzy modele dojścia:

• Konserwatywny – agent wykorzystywany głównie do analizy kodu, wyjaśnień i prostych sugestii, bez autonomicznych zmian w repozytorium.
• Zbalansowany – agent tworzy pull requesty, ale wszystkie przechodzą obowiązkowy, dokładny code review; to podejście będzie prawdopodobnie dominujące w najbliższych latach w sektorze enterprise.
• Progresywny – w mniej krytycznych systemach agent prowadzi całe ścieżki zmian, od planu po merge, przy audycie na poziomie metryk i okresowych przeglądów architektonicznych.

Historia powstania Claude Code i jego szybka adopcja w różnych branżach pokazuje, że wchodzimy w nową epokę: przejścia od „narzędzi do kodu” do „cyfrowych współpracowników”. Firmy, które potraktują ten trend strategicznie – inwestując nie tylko w samą technologię, ale także w procesy, bezpieczeństwo i kompetencje ludzi – zyskają trwałą przewagę konkurencyjną. Pozostałe będą musiały nadganiać, w świecie, w którym kod coraz częściej piszą agenci, a ludzie projektują systemy, w których ci agenci działają.