Nowy standard. Twoje centrum tworzenia inteligentnego, szybkiego i zrównoważonego oprogramowania AI
Table of Contents
Rozwój AI agentowego to model dostarczania oprogramowania, w którym agenci AI wykonują wieloetapowe zadania inżynierskie przy ograniczonym udziale człowieka. AI odczytuje zgłoszenie, pisze kod, uruchamia testy, poprawia to, co nie przeszło, i otwiera pull request do zatwierdzenia przez człowieka.
Czy to jest wystarczająco bezpieczne dla twojej bazy kodu objętej regulacjami? To zależy od tego, czego agenci mogą dotykać, i od tego, co musi się wydarzyć, zanim ich praca zostanie scalona.
Jeśli do ręcznego procesu review dodasz agentów, zyskasz szybsze pisanie kosztem dłuższej kolejki do przeglądu. Ale jeśli najpierw przełożysz zasady inżynierskie na wykonywalne reguły, możesz prowadzić więcej prac równolegle niż w tradycyjnym sprincie, a przy tym mieć lepszy ślad audytowy niż ten, który ten sprint zapewniał.
Podsumowanie dla kadry zarządzającej
Inżynieria agentowa przenosi wąskie gardło dostarczania z pisania kodu na jego walidację. Przedsiębiorstwa mogą na to odpowiedzieć, zamieniając praktyki review w zautomatyzowane bramki kontrolne (z odizolowanymi środowiskami dla agentów, deterministycznymi kontrolami przed scaleniem, policy-as-code i standardami czytelnymi maszynowo).
Dzięki temu przedsiębiorstwo może zyskać ściślejszą kontrolę architektoniczną i bogatszą dokumentację każdej zmiany niż w przypadku klasycznego sprintu, ponieważ pipeline stale wytwarza dowody (zamiast składać je dopiero przed audytem).
Przedsiębiorstwa, które pominą tę pracę, otrzymają wynik opisany w badaniu DORA 2025: większą przepustowość i mniejszą stabilność. Mechanizmy kontrolne są inwestycją, która sprawia, że ta przepustowość staje się realna, co najpewniej wyjaśnia prognozę Gartnera, że do końca 2027 roku anulowanych zostanie ponad 40% projektów związanych z AI agentowym.
Jakie są zastrzeżenia wobec agentowego tworzenia oprogramowania?
Obawy podnoszone podczas spotkań zakupowych dotyczące jakości kodu i ekspozycji danych znajdują potwierdzenie w badaniach. Raport DORA 2025, oparty na danych od blisko 5 000 specjalistów technologicznych, pokazał, że 90% badanych korzysta dziś z AI w pracy, a ponad 80% deklaruje wzrost produktywności, podczas gdy 30% nadal deklaruje niewielkie lub zerowe zaufanie do generowanego przez nią kodu.
W tym samym zbiorze danych adopcja AI dodatnio koreluje z przepustowością dostarczania i ujemnie ze stabilnością dostarczania. Podsumowanie DORA jest proste:
AI nie naprawia zespołu — wzmacnia to, co już w nim jest.
Dlatego liderzy doradztwa w Google Cloud przestrzegają przed budowaniem na pękniętym fundamencie. Chodzi o wdrażanie agentów w środowisku z nierozwiązanym długiem technicznym, gdzie tylko przyspieszają istniejący chaos.
To nie jedyny prosty błąd, jaki można popełnić. Innym jest rozprzestrzenianie się odizolowanych i dublujących się agentów, co zwiększa dług techniczny, a jednocześnie poszerza obszar ataku agentów autonomicznych.
Badanie liderów Google umieszcza prywatność i bezpieczeństwo danych (37%), integrację z systemami legacy (28%) oraz kontrolę kosztów (27%) na czele listy obaw — mniej więcej w takiej kolejności, w jakiej te pytania pojawiają się przy ocenie dostawcy.
Adopcja wyprzedza też dziś ład organizacyjny. MIT Sloan Management Review i BCG, w badaniu 2 102 członków kadry zarządzającej ze 116 krajów, odnotowały 35% poziom adopcji AI agentowego w ciągu dwóch lat, a kolejne 44% organizacji planuje wdrożenie. W dużej mierze wynika to z tego, że dostawcy dodają funkcje agentowe do narzędzi, na które firmy już mają licencje.
Jednocześnie ostrzegają, że tempo adopcji nie jest miarą postępu.
Jak agentowe dostarczanie tworzy wartość?
Wartość pojawia się wtedy, gdy walidację zamieniasz z bramki w pętlę. W swoich czterech poziomach agentowego tworzenia oprogramowania, Kaspar von Grünberg opisuje poziom pierwszy jako stan, w którym znajduje się większość zespołów w przedsiębiorstwach. To moment, w którym agenci jedynie sugerują, ludzie zatwierdzają wszystko, a wynik pozostaje ograniczony przepustowością review jednej osoby.
Na poziomie drugim agenci pracują równolegle w tle i kilka pull requestów posuwa się naprzód jednocześnie, co od razu wyklucza review linia po linii. Odpowiedzią platformową jest uruchamianie zautomatyzowanych kontroli (testów, skanów bezpieczeństwa, oceny polityk), kierowanie każdego niepowodzenia z powrotem do agenta, by spróbował ponownie, oraz powierzanie ludziom weryfikacji zachowania całości zamiast czytania każdego diffu.
Każdy mechanizm kontrolny, który da się wykonać automatycznie, zwiększa liczbę zmian, jakie system może bezpiecznie przyjąć bez czytania każdej linii przez człowieka. To zwiększa przepustowość zwalidowanych zmian, a nie surowy wolumen commitów.
Zasoby przestają być stałą liczbą tygodni pracy deweloperów zadeklarowanych podczas planowania sprintu i stają się funkcją tego, ile twoje bramki mogą bezpiecznie przyjąć. Wyższa przepustowość zwalidowanych zmian skraca speed-to-market — wskaźnik, który Deloitte zestawia z first-pass yield (zadaniami ukończonymi bez poprawek lub z minimalnymi poprawkami) oraz niezawodnością agentów (przepływami pracy ukończonymi przez agenta bez eskalacji) w swoim scorecardzie return-on-autonomy.
Przepustowość okupiona poprawkami nie jest przepustowością.
Ta pętla działa dzięki zawężeniu tego, o czym agenci mogą decydować. Daniela Petruzalek z Google nazywa to ograniczaniem sprawczości agenta.
Jeśli twój proces zawsze obejmuje budowanie, testowanie, lintowanie i wdrożenie, wpisanie tych kroków do promptu sprawia, że wraz z rozwojem sesji model może któryś pominąć, więc pakujesz tę sekwencję w narzędzie i eliminujesz możliwość pominięcia.
Do czego agent AI powinien mieć dostęp?
Każda sesja agenta powinna działać we własnym odizolowanym środowisku, pod własną tożsamością, z limitami zasobów i bez dostępu do danych produkcyjnych ani sekretów.
To element pracy nad platformą, a nie kwestia preferencji dotyczących narzędzi. Bez sandboxów dla poszczególnych sesji, tożsamości agentów, limitów zasobów i świadomie przygotowanego kontekstu agenci wchodzą ze sobą w konflikt, niepotrzebnie zużywają moc obliczeniową i wytwarzają wyniki, których system nie potrafi ocenić.
Tożsamość sprawia, że reszta mechanizmów nadzoru może działać. Gdy każde działanie agenta da się przypisać do odrębnego podmiotu z jasno określonym zakresem uprawnień, można stosować zasadę najmniejszych uprawnień, odbierać dostęp i dokładnie wiedzieć, kto co zmienił.
Kontekst też może być ograniczeniem. Agent, który dostaje wyłącznie zanonimizowaną bazę danych testowych, nie może ujawnić danych klientów w prompcie, logach dostawcy modelu ani artefakcie testowym. Na przykład GitHub ogranicza dostęp agentów do narzędzi przez prywatny rejestr MCP zatwierdzonych serwerów zamiast pozwalać każdemu programiście podłączać cokolwiek zechce.
Kto powinien mieć prawo mergować w środowisku opartym na agentach?
Agenci zgłaszają propozycje, a pipeline i wskazany z imienia człowiek podejmują ostateczną decyzję. Taka kontrola odpowiada na większość pytań o odpowiedzialność za jakość kodu, a główne platformy wdrażają ją dziś domyślnie, zamiast traktować jako ustawienie, o którym trzeba pamiętać.
W dokumentacji GitHub Enterprise wprost zapisano, że chmurowy agent Copilot nie może samodzielnie mergować pull requestów, a dodatkowe zabezpieczenia dla gałęzi docelowych wynikają z zestawów reguł repozytorium.
Wokół tego działają kontrole uruchamiane jeszcze przed interwencją człowieka. Udokumentowany przepływ w GitHub obejmuje /security-review przegląd lokalnych zmian przed otwarciem pull requestu, push protection blokujące pojawianie się sekretów w odpowiedziach generowanych przez AI, automatyczny code review wychwytujący błędy przed recenzją człowieka oraz code scanning z funkcją Autofix, w którym programista zatwierdza sposób naprawy.
To mechanizmy kontroli, których dojrzałe organizacje inżynierskie już wcześniej chciały, ale teraz rzeczywiście ich potrzebują ze względu na skalę.
Bramka może potwierdzić, że kod się kompiluje, trzyma się przewodnika stylu i obsługuje oczywistą ścieżkę błędu, dzięki czemu człowiek może ocenić, czy zmiana jest właściwa. To przesunięcie uwagi wyjaśnia, dlaczego role inżynierskie są redefiniowane wokół kontekstu i osądu.
Skąd bierze się ścieżka audytu w agentowym tworzeniu oprogramowania?
Ścieżka audytu jest efektem ubocznym tej pętli, a nie osobnym zadaniem dokumentacyjnym. Każda zmiana przechodząca przez nadzorowany pipeline agentowy trafia dalej wraz z powiązanym zestawem artefaktów: zgłoszeniem lub promptem określającym intencję, diffem, przebiegiem testów, skanem bezpieczeństwa, oceną zgodności z politykami oraz wskazanym z imienia człowiekiem, który zatwierdził merge.
Ręczne składanie takiego łańcucha na potrzeby wydania w środowisku regulowanym to koszmar zespołów compliance engineering. Tutaj pipeline generuje go sam, bo i tak potrzebuje tych dowodów.
Blueprint Deloitte dla organizacji opartej na agentach pokazuje, jak to wdrożyć. Policy-as-code, czyli zapisane w formie czytelnej dla maszyn polityki ryzyka, zgodności z przepisami i nadzoru osadzone w systemie dostarczania, które zapewniają automatyczne egzekwowanie, zabezpieczenia działające w czasie rzeczywistym i kompleksowe ścieżki audytu.
Ten sam raport opisuje agentów strażniczych, którzy monitorują i weryfikują innych agentów, aby autonomiczne decyzje pozostawały audytowalne na dużą skalę, i wymienia rolę Autonomy Auditor wśród stanowisk, które z tego wynikają.
W tradycyjnym sprincie te same dowody były rozproszone: część w systemie zgłoszeń, część w wątku na czacie, część na dashboardzie CI i część w czyjejś pamięci o tym, dlaczego przyznano wyjątek. Deloitte twierdzi, że audytowalność może stać się przewagą konkurencyjną, a nie centrum kosztów.
Czy zgodność z przepisami można egzekwować przed review, a nie po nim?
Tak — jeśli potraktujesz reguły regulacyjne i architektoniczne jako kontekst, który agent otrzymuje, oraz bramki, które musi przejść, zamiast jako dokument, który recenzent ma po prostu pamiętać.
Architecture decision records zapisują warunki i ograniczenia stojące za decyzją, ale mają tę samą wadę co każda strona w wiki: opierają się na tym, że ludzie o nich wiedzą i się do nich stosują.
Jednym z rozwiązań jest przekazywanie standardów, procedur kontrolnych i decyzji rady agentom za pośrednictwem serwera MCP, z którego korzystają zarówno agenci programistów wspierający pisanie kodu, jak i zautomatyzowani agenci w CI/CD. Dzięki temu reguły pozostają aktualne z założenia.
W regulowanych branżach to oddziela realne ograniczenie od pobożnego życzenia. Oprogramowanie do wyrobów medycznych objęte IEC 62304 jest klasyfikowane do trzech klas bezpieczeństwa według ciężkości możliwego urazu i wymaga identyfikowalności od zagrożenia przez wymaganie i projekt aż po test, z udokumentowanymi zapisami na każdym etapie.
Identyfikowalność to łańcuch artefaktów, który nadzorowany pipeline już wytwarza, a najczęściej zawodzi wtedy, gdy tkwi w odłączonych od siebie arkuszach kalkulacyjnych. Ta sama logika obejmuje dowody zarządzania zmianą w usługach finansowych oraz obowiązki wynikające z HIPAA i FDA kształtujące pracę nad produktami ochrony zdrowia.
Dopilnuj aktualnego kalendarza regulacyjnego, bo tego lata się zmienił. Unijny pakiet Digital Omnibus dotyczący AI, przyjęty przez Parlament 16 czerwca 2026 roku i przez Radę 29 czerwca 2026 roku, odroczył obowiązki dla systemów wysokiego ryzyka pierwotnie przewidziane na 2 sierpnia 2026 roku. Samodzielne systemy z załącznika III podlegają teraz tym wymogom od 2 grudnia 2027 roku, a AI osadzona w regulowanych produktach, takich jak wyroby medyczne, od 2 sierpnia 2028 roku.
Obowiązki przejrzystości z artykułu 50 nie zostały odroczone i obowiązują od 2 sierpnia 2026 roku, z okresem przejściowym do 2 grudnia 2026 roku na oznaczanie treści pochodzących z systemów już obecnych na rynku. Wiele szeroko udostępnianych harmonogramów AI Act nadal pokazuje stare daty, więc przed zbudowaniem mapy drogowej sprawdź je w aktualnym źródle.
Dostarczanie w sprincie a nadzorowane dostarczanie agentowe
Wymiar | Konwencjonalne dostarczanie w sprintach | Zarządzane dostarczanie agentowe |
|---|---|---|
Jednostka potencjału | Liczba tygodni pracy deweloperów zadeklarowana na sprint | Zweryfikowane zmiany, które pipeline jest w stanie przyjąć w ciągu tygodnia |
Gdzie odbywa się walidacja | Przegląd człowieka jako bramka przed mergem | Zautomatyzowana pętla, z niepowodzeniami kierowanymi z powrotem do agenta |
Kto może mergować | Każdy uprawniony człowiek, o ile pozwalają na to przyjęte zasady | Pipeline i wskazana z imienia osoba zatwierdzająca; agenci domyślnie zablokowani |
Kiedy sprawdzana jest zgodność z przepisami | Retrospektywnie, podczas przeglądu i przygotowań do audytu | W trakcie wykonania, jako policy-as-code i ograniczenia kontekstowe |
Materiał dowodowy na potrzeby audytu | Odtwarzany na podstawie ticketów, czatów i logów CI | Generowany dla każdej zmiany: intencja, diff, testy, skany, osoba zatwierdzająca |
Główny czynnik kosztowy | Liczba etatów i licencje stanowiskowe | Tokeny, moc obliczeniowa CI i uwaga reviewerów |
Dominujący tryb awarii | Dostarczanie zbyt wolne dla biznesu | Kolejki review i pipeline’y się zapychają; zaufanie do wyników spada |
Granica skalowania | Tempo rekrutacji i onboardingu | Pokrycie testami, dojrzałość polityk i kontrola kosztów |
Jakie jest absolutne minimum, żeby zacząć z agentowym tworzeniem oprogramowania?
Kluczowe są testy automatyczne oraz szybki, deterministyczny pipeline.
Dla zespołów, które na dużą skalę uruchamiają agentów bez takiego przygotowania, istnieje wyraźny tryb awarii. Pipeline’y CI się zapychają, kolejki review rosną lawinowo, a zespoły przestają ufać wynikom.
Potwierdza to ustalenie DORA, że 90% organizacji wdrożyło co najmniej jedną platformę wewnętrzną, a jakość tej platformy koreluje z czerpaniem wartości z AI.
Kontrola kosztów staje się kwestią inżynierską, gdy agenci działają w trybie ciągłym.
Wydatki na tokeny i moc obliczeniową CI zastępują licencje stanowiskowe jako zmienną rosnącą wraz z przepustowością. Ekonomia tokenów (tokenomics) staje się realnym ograniczeniem, gdy platforma zaczyna sama generować sobie pracę. Trzeba uwzględnić w budżecie ponowienia, bo mechanizmem jest właśnie pętla ponowień, oraz ustalić limit dla każdego workflow.
Potencjał ludzki to realne, ale często niedoszacowane ograniczenie. Każde zadanie wykonywane w tle zużywa mentalną przepustowość reviewera, nawet jeśli samą pracę wykonuje agent. Wypalenie związane z AI jest już raportowane. Uwaga reviewerów powinna być przeznaczana na wyjątki i ocenę projektową.
Warto też uczciwie ocenić, na którym szczeblu jesteś. Według drabiny autonomii Deloitte w 2025 roku udział organizacji z wieloetapową orkiestracją klasy produkcyjnej wynosił od 8% do 10%, z optymalizacją na poziomie domeny od 2% do 3%, a z samoewoluującymi sieciami agentów — poniżej 1%. Dane MIT SMR to potwierdzają. Wśród najbardziej zaawansowanych wdrażających 79% inwestuje w AI, które generuje wnioski dla człowieka podejmującego decyzje, a 54% — w AI, które decyduje i wdraża.
Czego potrzebujesz, żeby agentowe tworzenie oprogramowania przynosiło dodatni ROI?
O tym, co wyróżnia agentową inżynierię, decyduje system dostarczania, w którym działa model, ponieważ do końca tygodnia każdy konkurent może licencjonować ten sam model.
To, co różni organizacje, to środowiska, jakie dostają agenci, to, co mogą odczytywać, jakie bramki muszą przejść, jakie materiały dowodowe generuje pipeline oraz kto odpowiada za wyjątki.
MIT SMR i BCG ujmują to w kategoriach nadzoru, wskazując, że 58% liderów wdrożeń spodziewa się zmian w strukturach nadzoru w ciągu trzech lat, a oczekiwania wobec zakresu decyzyjności AI wzrosną o 250%, i dochodzą do wniosku, że wyzwanie ma bardziej organizacyjny niż technologiczny charakter.
To wyzwanie ma bardziej organizacyjny niż technologiczny charakter.
Zapytaj partnera odpowiedzialnego za dostarczanie oprogramowania, które mechanizmy kontrolne uczyni wykonalnymi w twojej bazie kodu, jakie dowody twoi audytorzy będą otrzymywać przy każdej zmianie oraz jak zamierza skupić uwagę osób recenzujących na ocenie, a nie na składni.
W Monterail chętnie pokażemy, jak wygląda pierwszy kontrolowany przyrost w twoim środowisku.
AI agentowe w organizacji — FAQ
)
Michał Nowakowski
Solution Architect and AI Expert at Monterail
Michał Nowakowski is a Solution Architect and AI Expert at Monterail. His strong data and automation foundation and background in operational business units give him a real-world understanding of company challenges. Michał leads feature discovery and business process design to surface hidden value and identify new verticals. He also advocates for AI-assisted development, skillfully integrating strict conditional logic with open-weight machine learning capabilities to build systems that reduce manual effort and unlock overlooked opportunities.
)
