Liderzy opinii
Ludzie walczą o życie, gdy AI przyspiesza dostarczanie oprogramowania

Przez większość historii tworzenia oprogramowania ludzie byli kontrolą. Programista wprowadza zmianę, inna osoba ją przegląda, ktoś ją zatwierdza i w końcu zostaje wdrożona.
AI przyspiesza cały ten system, podczas gdy wciąż staramy się utrzymać ludzi w jego centrum. Programiści mogą teraz tworzyć kod i zmiany w ciągu kilku sekund. Agenci mogą pracować w repozytoriach, narzędziach, infrastrukturze i innych systemach przy mniejszym udziale człowieka.
Naszym odruchem jest przywrócenie ludzi do procesu. Przeglądamy pull request, zatwierdzamy wywołanie narzędzia, sprawdzamy zmianę i potwierdzamy wdrożenie, ponieważ chcemy mieć pewność, że AI nie zrobiło czegoś, czego nie powinna. Trzymamy się kurczowo.
Ten odruch ma sens. Przegląd ludzki dał nam sposób na utrzymanie kontroli, gdy oprogramowanie zmierza w stronę produkcji. Jednak AI zaczyna działać z taką prędkością i wolumenem, że ludzie nie mogą już pełnić roli jednostki skalującej zarządzanie.
AI już porusza się szybciej niż przegląd ludzki
Pierwsza fala generatywnej AI w tworzeniu oprogramowania skupiała się głównie na pomocy programistom w szybszym pisaniu kodu. To samo w sobie zmienia dostarczanie oprogramowania. Więcej kodu oznacza więcej zmian w aplikacjach, infrastrukturze i bazach danych, które przechodzą przez testy, bezpieczeństwo, przegląd, wdrożenie i produkcję.
Problem nie polega koniecznie na tym, że AI tworzy gorsze zmiany. Tworzy więcej zmian, szybciej. Jeśli kontrolą całego tego nowego outputu ma być kolejna osoba przeglądająca każdą zmianę, w końcu matematyka przestaje działać.
Już widzimy oznaki tego. Anthropic niedawno poinformował, że użytkownicy Claude Code zatwierdzają około 93 % żądań uprawnień. Firma odkryła, że powtarzające się żądania mogą wywoływać zmęczenie zatwierdzaniem, gdy ludzie zwracają na nie mniej uwagi w miarę wzrostu liczby zatwierdzeń. Anthropic używa teraz automatycznego klasyfikatora, aby ocenić działania i zatrzymać potencjalnie niebezpieczne, zamiast prosić osobę o zatwierdzenie wszystkiego.
Zastanów się, co to mówi o nadzorze ludzkim. Jeśli ktoś zatwierdza 93 % przypadków, dodanie kolejnego zatwierdzenia niekoniecznie daje większą kontrolę. W pewnym momencie człowiek staje się kolejnym krokiem w przepływie pracy.
Możemy używać AI do tworzenia większej ilości oprogramowania. Nie możemy odpowiedzieć, tworząc równie dużą operację przeglądu ludzkiego za nią.
AI przechodzi od tworzenia kodu do podejmowania działań
Asystenci kodowania wprowadzili AI do rozwoju. Agenci dają AI możliwość uczestniczenia w znacznie większej części cyklu życia oprogramowania (SDLC). Agent może otrzymać cel, zdecydować, jak go osiągnąć, używać narzędzi, obserwować wyniki i dostosowywać kolejne działania.
W inżynierii oprogramowania może to oznaczać modyfikację plików, uruchamianie poleceń, interakcję z repozytoriami, wywoływanie API, testowanie kodu lub pracę z infrastrukturą. Ludzie coraz bardziej przyzwyczajają się do pozwalania agentom na samodzielną pracę. W badaniu obejmującym miliony interakcji człowiek‑agent Anthropic odkryło, że doświadczeni użytkownicy Claude Code stosowali pełną automatyczną akceptację w ponad 40 % sesji, czyli mniej więcej dwukrotnie częściej niż nowi użytkownicy.
To nie znaczy, że autonomiczne agenty już dziś działają w środowiskach produkcyjnych wszędzie. Nie działają. Jednak rozwój oprogramowania daje nam wczesny wgląd w to, dokąd zmierza ta technologia.
Obecnie AI generuje więcej zmian, a przegląd ludzki zaczyna się wyczerpywać. Następnie AI będzie uczestniczyć w kolejnych etapach SDLC. W końcu agenci będą tworzyć, weryfikować, wdrażać, obserwować i naprawiać zmiany przy znacznie mniejszym udziale człowieka.
Na każdym etapie usuwamy kolejne miejsce, w którym człowiek zapewniał kontrolę. Pytanie zmienia się z tego, czy AI może wykonać pracę, na to, co AI powinno móc robić samodzielnie.
Uprawnienie nie jest władzą
Agenci potrzebują dostępu, aby wykonywać użyteczną pracę. Agent pomagający wdrażać oprogramowanie może potrzebować dostępu do repozytorium, systemu CI/CD, środowiska chmurowego lub bazy danych. Odebranie tego dostępu oznacza jednocześnie odebranie dużej części przydatności agenta.
Jednak dostęp i władza to nie to samo. Przyznanie agentowi uprawnienia do dotarcia do systemu nie oznacza, że powinien mieć władzę do podejmowania każdej dostępnej w nim akcji.
Tradycyjna kontrola dostępu może określić, czy agent ma uprawnienie do dotarcia do czegoś. Potrzebujemy także sposobu, aby określić, czy konkretna akcja, którą chce podjąć, powinna się odbyć. Staje się to ważniejsze, gdy system podejmujący decyzję może interpretować zadanie inaczej niż osoba, która je zleciła, napotka przeszkodę i wybierze inną ścieżkę lub użyje legalnego narzędzia w nieprzewidziany sposób.
OWASP opisuje wersję tego problemu jako Excessive Agency. Wskazuje na nadmierną funkcjonalność, uprawnienia i autonomię jako przyczyny szkodliwych działań oraz zaleca niezależne zatwierdzanie działań o wysokim wpływie.
NVIDIA podchodzi do tego samego problemu na poziomie architektury. Jej Open Agent Safety Platform umieszcza egzekwowanie polityk poza agentem i stawia prosty punkt: nie można oczekiwać, że agent w pełni samodzielnie zarządza swoim zachowaniem.
To powinno kształtować sposób, w jaki budujemy AI SDLC. Agent może potrzebować uprawnienia do dostępu do bazy danych, środowiska infrastruktury lub systemu wdrażania. To nie oznacza, że agent powinien samodzielnie decydować, że każda zmiana, którą chce wprowadzić, jest bezpieczna.
AI podejmuje decyzje na podstawie prawdopodobieństw. Nie powinniśmy pozwalać, aby każda z tych decyzji automatycznie stawała się akcją wobec krytycznego systemu.
Człowiek w pętli nie może być jedyną odpowiedzią
Oczywistą reakcją jest utrzymanie osoby przed konsekwentnymi działaniami AI. W niektórych decyzjach jest to właśnie to, co powinniśmy zrobić. Błędem jest zamienianie „człowieka w pętli” w odpowiedź na każdą decyzję.
Jeśli każda akcja podejmowana przez agenta wymaga, aby ktoś ją przejrzał i kliknął „zatwierdź”, odtworzyliśmy wąskie gardło, które AI miało usunąć. Co gorsza, wystarczająca liczba zatwierdzeń może przekształcić nadzór w nawyk. Osoba klikająca „zatwierdź” przez cały dzień niekoniecznie wykorzystuje swoją ocenę.
Musimy być bardziej rozważni, gdzie podejmowane są decyzje. AI może podejmować decyzje w ramach przydzielonego mu zadania. Polityka może obsługiwać decyzje, w których zasady są już znane. Ludzie mogą zajmować się wyjątkami i decyzjami, które naprawdę wymagają oceny.
Zmiana o niskim ryzyku, spełniająca ustaloną politykę, nie powinna wymagać, aby ktoś na nią patrzył. Zmiana naruszająca politykę powinna zostać automatycznie zatrzymana. Wyjątek o istotnych konsekwencjach biznesowych, bezpieczeństwa lub operacyjnych może wymagać podjęcia decyzji przez człowieka.
To bardzo inny model niż po prostu umieszczanie człowieka w każdej pętli. Celem nie jest usunięcie ludzi. Chodzi o to, aby nie uczynić uwagi człowieka czynnikiem, od którego zależy każda akcja, i uczynić ścieżkę regulowaną najłatwiejszą.
Umieść kontrolę tam, gdzie zachodzi akcja
Przedsiębiorstwa nie będą standaryzować jednego modelu AI ani jednego agenta. Programiści będą korzystać z różnych copilotów. Zespoły będą eksperymentować z różnymi modelami. AI pojawi się w narzędziach deweloperskich, produktach bezpieczeństwa, platformach danych i aplikacjach wewnętrznych.
Próba budowania odrębnego procesu zarządzania wokół każdego narzędzia AI nie będzie skalowalna. Kontrola musi znajdować się bliżej akcji, którą AI chce podjąć.
Jeśli zmiana wygenerowana przez AI trafia do potoku wdrożeniowego, powinna podlegać tym samym politykom co zmiana wygenerowana przez człowieka. Jeśli agent chce zmodyfikować infrastrukturę, dane lub bazę produkcyjną, kontrole wokół tego systemu nie powinny znikać z powodu zmiany podmiotu.
Źródło zmiany nie określa ryzyka. Ryzyko zależy od samej zmiany. Programista, asystent kodowania, zautomatyzowany proces lub autonomiczny agent mogą podążać inną ścieżką do tej samej akcji, ale ta akcja nadal może podlegać tej samej polityce, zanim stanie się istotna.
To także pozwala, aby technologia zmieniała się bez zmuszania firm do przebudowywania zarządzania przy każdej zmianie. Modele będą się zmieniać. Agenci będą stawać się bardziej zdolni. Kontrole wokół krytycznych systemów mogą pozostać spójne.
NIST przyjmuje podobne podejście oparte na ryzyku w swoim AI Risk Management Framework, które traktuje zarządzanie jako coś, co musi działać w całym cyklu życia AI, a nie jako jednorazowe zatwierdzenie na końcu. W kontekście dostarczania oprogramowania oznacza to wprowadzanie kontroli w ścieżkę, którą AI już podąża, zamiast dokładać kolejny ręczny proces.
Gdy człowiek odchodzi, dowody nie mogą odejść razem z nim
Istnieje kolejny problem ukryty w modelu przeglądu ludzkiego. Gdy usuwasz osobę z procesu, nie tracisz tylko przeglądu. Możesz także stracić osobę, która pomogła udowodnić, że przegląd miał miejsce.
Staje się to poważnym problemem dla firm z wymaganiami w zakresie bezpieczeństwa, zgodności i audytu. Nadal muszą wiedzieć, co się zmieniło, kto lub co to zainicjowało, jaka polityka została zastosowana, czy przeszła, kto zatwierdził wyjątek, gdzie zmiana została uruchomiona i co stało się później.
Nie możesz zautomatyzować zmiany i pozostawić dowodów w formie ręcznej. W procesie sterowanym przez ludzi zespoły mogą później odtworzyć dowody z ticketów, zatwierdzeń, logów potoku, zrzutów ekranu i rozmów. To podejście staje się trudniejsze w miarę wzrostu liczby zmian i staje się nierealistyczne, gdy maszyny tworzą i wykonują zmiany nieustannie.
Dowody muszą stać się częścią procesu dostarczania. Decyzje polityki, zatwierdzenia, wyjątki, wdrożenia i wyniki powinny generować zapisy w trakcie wykonywania pracy. Dowody audytowe stają się produktem ubocznym dostarczania oprogramowania, a nie czymś, co zespoły tworzą po fakcie.
To pozostawia dwa różne zadania dla zarządzania w AI‑napędzanym SDLC. Przed akcją należy określić, czy powinna się odbyć. Po akcji należy udowodnić, co się stało.
Ludzie nie znikną. Nasza rola się zmienia.
Istnieje zrozumiałe odruchowe dążenie do mierzenia kontroli liczbą interwencji człowieka. Więcej przeglądów wydaje się bezpieczniejszych. Więcej zatwierdzeń wydaje się bezpieczniejszych. Utrzymywanie człowieka w każdej pętli wydaje się bezpieczniejsze.
AI zweryfikuje to założenie. Jeśli AI będzie nadal zwiększać ilość oprogramowania, które możemy tworzyć, ludzie nie będą w stanie przejrzeć każdej zmiany, zatwierdzić każdej akcji, obserwować każdego wdrożenia i odtworzyć każdej decyzji później. Próba zrobienia tego albo spowolni AI, albo przekształci nadzór ludzki w jedynie formalny pieczątek.
Cykl życia oprogramowania oparty na AI (AI SDLC) wymaga innego podziału pracy. AI może wykonywać większą część zadań, podczas gdy polityka reguluje powtarzalne decyzje, a ludzie wkraczają, gdy coś naprawdę wymaga oceny. Dowody powinny być tworzone automatycznie w trakcie.
Damy AI większy dostęp, ponieważ tak staje się ona użyteczna. Dajemy agentom większą autonomię, ponieważ w ten sposób uzyskujemy od nich większe możliwości. Wyzwanie polega na zapewnieniu, aby większy dostęp i autonomia nie przekształciły się cicho w nieograniczoną władzę.
Ludzie nie muszą trzymać się mocniej. Celem nie jest mniejsza kontrola. To model kontroli, który nie zależy od tego, że sami trzymamy każdą decyzję w ręku. Musimy zbudować mechanizmy, które pozwolą nam poluzować uchwyt, nie tracąc kontroli.












