Przez miesiąc pozwalałem agentowi napędzanemu przez AI zarządzać moim potokiem CI/CD. Pod koniec okresu próbnego agent naprawiał nieudane buildy, otwierał pull requesty i ponownie uruchamiał zadania, pozostawiając jedynie jeden krok wymagający ludzkiego zatwierdzenia. Eksperyment pokazuje, że „agentowy” DevOps może przenieść rutynowy triage z back-office'u do zautomatyzowanego „mózgu”, ale jednocześnie obnaża znaczenie mechanizmów kontrolnych (guardrails), które chronią autonomiczny system przed staniem się nowym źródłem ryzyka.

Dlaczego ten eksperyment miał znaczenie

Większość zespołów programistycznych wciąż traktuje AI jako zaawansowane autouzupełnianie — narzędzie, które sugeruje linię kodu lub wyjaśnia komunikat o błędzie. W 2025 roku branża przesuwa się od „AI, które pomaga ci pisać” w stronę „AI, które działa”. Agent zdolny do działania może czytać logi, decydować o poprawce, stosować ją i uczyć się na podstawie wyników — a wszystko to bez wpisywania ani jednej komendy przez programistę.

Podstawowa idea: potok agentowy

Potok agentowy nie jest pojedynczym, monolitycznym modelem z nieograniczonym dostępem do produkcji. To wyspecjalizowany orkiestrator, który koordynuje konkretne narzędzia, zachowuje kontekst i operuje w ramach ścisłych mechanizmów kontrolnych. Główna pętla odzwierciedla ludzki proces rozwiązywania problemów:

  1. Postrzegaj – pobieraj logi, wyniki testów i metryki.
  2. Rozumuj – analizuj awarię, planuj najbezpieczniejszą metodę naprawy.
  3. Działaj – wywołuj narzędzie o określonym zakresie, aby zastosować poprawkę, zaktualizować zależność lub ponownie uruchomić zadanie.
  4. Ucz się – zapisuj wynik, aby kolejna decyzja była lepiej uzasadniona.

Architektura, która zapewniła bezpieczeństwo eksperymentu, wyglądała następująco:

  • Platforma CI/CD – planuje i uruchamia zadania.
  • Orkiestrator – „mózg”, który odbiera dane, uruchamia pętlę kontrolną i decyduje, co należy zrobić.
  • Narzędzia – „ręce”, które wykonują konkretne czynności (np. otwieranie PR, podnoszenie wersji).
  • Magazyn kontekstu – lekka pamięć ostatnich awarii i poprawek.
  • Mechanizmy kontrolne (guardrails) – sztywne limity, które zapobiegają bezpośredniemu dotykaniu produkcji przez agenta lub wprowadzaniu zmian bez wyraźnego zatwierdzenia przez człowieka.

Poprzez odizolowanie dużego modelu językowego (LLM) od bezpośredniego zapisu w środowisku produkcyjnym, system zmniejszył powierzchnię ataku, pozwalając jednocześnie modelowi na analizowanie problemu.

Miesiąc z życia agenta

Tydzień 1 – obserwacja w trybie tylko do odczytu

Agent działał w trybie „tylko wyjaśniania”. Każdy nieudany build generował wiadomość na Slacku, która podsumowywała błąd i sugerowała możliwe przyczyny. Kod nie ulegał zmianie. Ta faza udowodniła, że etapy percepcji i rozumowania działają na rzeczywistych logach, oraz dała zespołowi pewność, że agent rozumie bazę kodu.

Tydzień 2 – proponowanie poprawek

Przez kolejne siedem dni orkiestrator otwierał pull requesty dla problemów o niskim ryzyku, takich jak błędy lintingu czy nieaktualne zależności. Inżynierowie przeglądali PR-y przed ich scaleniem.

Tydzień 3 – kontrolowane działanie

Po wprowadzeniu przepływu pracy opartego na zatwierdzeniach, agent otrzymał pozwolenie na ponowne uruchamianie zadań w środowisku nieprodukcyjnym. Gdy build kończył się niepowodzeniem, orkiestrator automatycznie przypisywał (pinning) właściwą wersję uszkodzonej zależności, otwierał PR, a po jego scaleniu ponownie uruchamiał potok.

Tydzień 4 – mierzenie wpływu

Ostatni tydzień skupił się na mierzeniu wyników i śledzeniu, ile awarii udało się rozwiązać agentowi.

Zalety: eliminacja nudnej pracy

Eksperyment pokazał, że agent AI może przejąć powtarzalne części CI/CD: czytanie logów, wykrywanie znanych wzorców, podnoszenie wersji i ponowne uruchamianie zadań. Inżynierowie musieli jedynie zatwierdzać końcowe zmiany i badać nieliczne przypadki brzegowe, których agent nie potrafił rozwiązać. W praktyce oznaczało to mniej powiadomień w środku nocy, mniej przełączania kontekstu i szybszą pętlę zwrotną dla programistów.

Pułapki i sposoby ich łagodzenia

  • Pewne siebie, lecz błędne poprawki – Agent czasami stosował poprawkę na poziomie objawu, która maskowała głębszy błąd. Mechanizmy kontrolne wymagające ludzkiego zatwierdzenia dla każdej zmiany dotykającej kodu produkcyjnego trzymały to ryzyko w ryzach.
  • Przeładowanie szumem – Niefiltrowane powiadomienia mogą zagłuszyć realne alerty.
  • Rozszerzanie zakresu (scope creep) – Przyznanie modelowi nieograniczonego dostępu szybko prowadzi do niezamierzonych skutków ubocznych. Ścisłe oddzielenie LLM (rozumowanie) od narzędzi (działanie) w architekturze zapobiegło wprowadzaniu przez agenta dowolnych zmian.

Plan wdrażania krok po kroku dla innych zespołów

Jeśli Twoja organizacja chce wypróbować potok agentowy, postępuj zgodnie z tą stopniową ścieżką:

  1. Skonfiguruj orchestrator – lekką usługę, która może wywoływać LLM, przechowywać kontekst i wywoływać API CI/CD.
  2. Zdefiniuj guardrails – stwórz białą listę zadań CI/CD, które agent może uruchamiać, wymagaj zatwierdzania PR i blokuj wszelkie bezpośrednie zapisy na produkcji.
  3. Tydzień 1: Tryb obserwacji – przesyłaj logi do orchestratora i pozwól mu publikować podsumowania diagnostyczne na kanale czatu.
  4. Tydzień 2: Tryb sugestii – pozwól agentowi otwierać PR-y dla poprawek niekrytycznych; zachowaj obowiązek weryfikacji przez człowieka.
  5. Tydzień 3: Kontrolowane działanie – przyznaj uprawnienia do ponownego uruchamiania zadań w środowiskach stagingowych lub testowych po scaleniu PR.
  6. Tydzień 4: Metryki i dostrajanie – śledź sklasyfikowane awarie, fałszywe alarmy oraz zaoszczędzony czas; odpowiednio dostosuj progi alertów i guardrails.
  7. Iteruj – rozszerzaj zestaw narzędzi (np. automatyczne rollbacki, skanowanie bezpieczeństwa) dopiero wtedy, gdy każda nowa funkcja przejdzie te same kontrole bezpieczeństwa.

Kontrargument

Sceptycy zauważają, że agenci mogą być „pewni siebie w błędnych odpowiedziach”. Eksperyment nie wyeliminował tej obawy; pokazał jedynie, że dzięki rygorystycznym mechanizmom guardrails można czerpać korzyści, zachowując jednocześnie zarządzalne ryzyko.

Wnioski

Agent AI obsługujący pętlę kontrolną CI/CD może przekształcić reaktywny, manualny proces triage'u w niemal samonaprawiający się pipeline, pod warunkiem izolacji modelu, wymuszenia ścisłych kroków zatwierdzania i rozpoczęcia od podejścia o niskim ryzyku, opartego najpierw na obserwacji. Prawdziwa wartość nie polega na zastępowaniu inżynierów, lecz na odciążeniu ich od żmudnych, powtarzalnych czynności, które utrzymują pipeline'y w stanie sprawności i pozwalają programistom skupić się na tworzeniu.