Jak wykorzystać modele językowe AI do automatyzacji pracy programisty i zespołów DevOps

Po co programiście i DevOpsom modele językowe – perspektywa z klawiatury, nie z keynote’u

AI nie zastąpi programisty – ale szybko zastąpi programistę bez AI

Marketing lubi hasła w stylu „AI zastąpi developerów”. W praktyce projekty pokazują coś zupełnie innego: zespół, który umie sensownie korzystać z modeli językowych, po prostu dowozi szybciej, z mniejszą ilością nudnej, ręcznej pracy. Różnica nie polega na tym, że bot „pisze aplikację za ludzi”, tylko na tym, że odcina im 20–40% czasu na powtarzalne, mało kreatywne czynności.

Dla programisty oznacza to mniej przepisywania tego samego kodu-boilerplate, mniej walki z dokumentacją bibliotek i obcych API, a więcej czasu na decyzje architektoniczne, projektowanie kontraktów, rozmowy z biznesem. Dla zespołów DevOps to szybsze budowanie pipeline’ów, mniej kopiuj-wklej z czyichś gistów i lepsze opisy procesów, które do tej pory siedziały tylko w głowie jednej osoby w zespole.

Modele językowe stają się czymś w rodzaju turbo-doładowanej „gumowej kaczki”: można im opowiedzieć problem, rozbić go na etapy, poprosić o warianty, a one odpowiadają tekstem i kodem, który można szybko przetestować. Różnica względem klasycznego „rubber duck debugging” jest taka, że kaczka z AI próbuje aktywnie podsunąć rozwiązanie, zamiast tylko słuchać.

Scenka nr 1: pojedynczy developer w małej firmie

Wyobraźmy sobie full-stacka w małej firmie. Musi ogarnąć front, backend, bazę, CI/CD, trochę AWS-a, trochę monitoringu. Nie ma wewnętrznego architekta ani dedykowanego DevOpsa, za to ma deadliny i Jira rosnącą szybciej niż trawa po deszczu. Dla takiej osoby modele językowe są:

• mentorem do „szybkich pytań” – jak poprawnie skonfigurować CORS w określonym frameworku, jak użyć konkretnej funkcji w bibliotece, jak wygląda idiomatyczny kod w danym języku,
• generatorami szkieletów – CRUD dla nowego modelu, prosty handler HTTP, konfiguracja lintera, minimalny Dockerfile,
• pomocą w debugowaniu – analizują stacktrace, proponują hipotezy i kolejne eksperymenty diagnostyczne.

Taki developer używa LLM jak dynamicznej dokumentacji i drugiej pary oczu, która nie śpi o 2 w nocy. Nie potrzebuje rozbudowanych integracji – przeglądarka, IDE z wtyczką, ewentualnie prosty skrypt do odpytywania API modelu.

Scenka nr 2: zespół DevOps w korporacji

Drugi biegun to zespół DevOps w dużej organizacji, który obsługuje kilkadziesiąt repozytoriów, kilka chmur, złożone przepływy CI/CD i compliance. Tutaj modele językowe pełnią trochę inną rolę:

• automatyzują tworzenie i korektę plików YAML, Terraform, Ansible, Helm,
• generują opisy pipeline’ów z gąszczu konfiguracji, tak by menedżer czy security engineer rozumieli, co się dzieje,
• pomagają w reagowaniu na incydenty: skracają logi, wyciągają kluczowe patterny, proponują eksperymenty diagnostyczne.

Tutaj AI jest bardziej elementem platformy niż „tylko” czatem. Działa w pipeline’ach, komentuje PR-y, podpowiada w IDE. Zespół nie szuka magii; szuka narzędzia, które obniży koszt kontekstu – zrozumienia, co się dzieje w rozbudowanym ekosystemie.

Granice: co oddać LLM-owi, a czego pilnować samemu

Najzdrowsze podejście można streścić tak: AI pisze „pierwszy draft”, człowiek pisze „ostateczną wersję”. Modelem językowym warto się posługiwać w zadaniach typu:

• generowanie szkieletów kodu i infrastruktury,
• tworzenie propozycji testów, scenariuszy i checklist,
• pisanie wstępnych wersji dokumentacji, opisów PR, runbooków,
• wyszukiwanie i agregowanie informacji z wielu źródeł w zwięzłej formie.

Natomiast w głowie inżyniera muszą zostać:

• decyzje architektoniczne – co gdzie trafi, jak podzielić odpowiedzialności, jak dobrać technologie,
• model domenowy i logika biznesowa – AI może pomóc zapisać te reguły w kodzie, ale nie „wymyśli” za zespół zasad gry,
• bezpieczeństwo, odpowiedzialność prawna, zgodność z regulacjami – tutaj model może coś podpowiedzieć, lecz nie przejmuje odpowiedzialności,
• weryfikacja – czy to, co wygenerował model, jest sensowne, bezpieczne i zrozumiałe.

Jak działają modele językowe, żeby z nimi nie walczyć – minimum technicznego zaplecza

Predykcja tokenów zamiast „zrozumienia świata”

Model językowy nie „rozumie” kodu ani twojego problemu tak jak doświadczony senior. Jego podstawowy mechanizm to przewidywanie kolejnych tokenów (kawałków tekstu) na podstawie sekwencji, którą już dostał. To trochę jak bardzo zaawansowane autouzupełnianie: widzi fragmenty kodu, docstringi, komentarze, i na tej bazie zgaduje, co najczęściej pojawiało się „dalej” w podobnych kontekstach.

Z tego wynikają dwie ważne konsekwencje:

• model znakomicie radzi sobie z powtarzalnymi strukturami – typowym kodem, typowymi konfiguracjami, schematami YAML,
• gorzej z rzadkimi, niestandardowymi przypadkami i sytuacjami, w których potrzeba elementu „zdrowego rozsądku” o świecie lub firmowej domenie.

Świadomość, że to „tylko” predykcja, pomaga ustawić oczekiwania. Jeśli poprosisz model o „wymyślenie nowej architektury jakiegoś superinnowacyjnego systemu”, dostaniesz raczej kompilację znanych patternów niż rewolucję.

Halucynacje, pozorna pewność i pamięć na gumkę

Skoro model przewiduje tekst na podstawie statystyki, zdarzają się tzw. halucynacje: odpowiedzi brzmiące bardzo pewnie, ale po prostu nieprawdziwe. W świecie developerów przyjmuje to formę:

• nieistniejących metod lub klas, które „pasują” nazwą do konwencji biblioteki, ale nie występują w dokumentacji,
• przykładów konfiguracji, które mieszają wersje API (np. kawałek sprzed kilku lat z nowym parametrem),
• zmyślonych linków do dokumentacji, issue czy artykułów.

Drugi problem to ograniczona pamięć kontekstowa. Model mieści w jednym „oknie” określoną liczbę tokenów (np. kilka, kilkanaście tysięcy), czyli:

• jeśli rozmowa jest długa, starsze fragmenty są stopniowo „wypychane” z kontekstu,
• jeśli wklejasz bardzo duży plik lub wiele plików, przeanalizuje tylko tę część, która zmieści się w limicie.

Z tego powodu przyda się przemyślana strategia dzielenia zadań na mniejsze porcje oraz skracania kontekstu: podsumowania, wypunktowania, selekcja kluczowych fragmentów kodu.

Ogólny model vs wyspecjalizowany asystent w IDE lub pipeline’ach

ChatGPT czy podobne interfejsy to przykład ogólnego modelu. Jest wytrenowany na szerokim zestawie danych i potrafi przechodzić od rozmowy o gotowaniu do debugowania Kubernetes. Z kolei asystent w IDE (np. GitHub Copilot, inne wtyczki) to często:

• ten sam lub podobny model, ale karmiony głównie kodem z twojego repo i otwartych plików,
• ściślej zintegrowany z edytorem: widzi, co jest wokół kursora, i uzupełnia kod w locie,
• czasem z dodatkowymi filtrami bezpieczeństwa oraz możliwością „wołania narzędzi” (np. uruchamiania testów czy komend lintera).

W pipeline’ach CI/CD modele działają zazwyczaj jako usługi: skrypt w kroku pipeline’u wysyła do API diff, logi czy konfigurację i dostaje odpowiedź, którą zamienia w komentarz do PR, alert na Slacku czy podsumowanie buildu.

Praktyczne pojęcia: kontekst, temperatura, system prompt, tool calling

Kilka pojęć pomaga lepiej rozumieć, co się dzieje „pod maską”:

• Kontekst – wszystko, co model „widzi” w aktualnym zapytaniu: twój prompt, historię rozmowy, wklejony kod. Im precyzyjniejszy kontekst, tym większa szansa na przydatną odpowiedź.
• Temperatura – parametr sterujący „kreatywnością” modelu. Niska temperatura sprzyja przewidywalnym, powtarzalnym odpowiedziom (dobra do generowania kodu), wysoka – bardziej wariantowym i twórczym (lepsza do burzy mózgów).
• System prompt – ukryta lub jawna wiadomość, która definiuje „rolę” modelu: czy ma być surowym reviewerem, czy przyjaznym nauczycielem, czy generatorem minimalnych przykładów.
• Tool calling – mechanizm, w którym model zamiast odpowiadać tekstem, woła zdefiniowane narzędzia (np. wywołuje API, uruchamia testy, sprawdza coś w bazie wiedzy), a dopiero potem łączy wyniki w odpowiedź.

Dobrze dobrany system prompt plus odpowiednia temperatura potrafią diametralnie zmienić użyteczność asystenta. To jak różnica między „kolega z biurka obok” a „prowadzący code review według firmowych zasad”.

Jak ta wiedza przekłada się na sposób zadawania pytań

Dla programisty i DevOpsa kluczową umiejętnością staje się prompt engineering w praktycznej, a nie „akademickiej” wersji. Czyli:

• podawanie konkretnego kontekstu: język, framework, wersja, fragmenty kodu, oczekiwany styl,
• definiowanie roli: „zachowuj się jak doświadczony Go developer skupiony na performance i czytelności”,
• stawianie ograniczeń: „odpowiedz wyłącznie kodem z krótkimi komentarzami, bez dodatkowych opisów”,
• proszenie o plan przed szczegółami: „najpierw zaproponuj strategię, potem przejdziemy do implementacji krok po kroku”.

Dzięki temu model staje się bardziej przewidywalny. Zamiast walczyć z „magicznością” odpowiedzi, można traktować go jak bardzo szybki, ale nieco roztrzepany silnik generujący propozycje, które trzeba przejrzeć i oswoić.

Codzienna robota programisty z AI – od pierwszego commita do bugfixu

Szkicowanie architektury i kontraktów API

Zanim powstanie linijka kodu, dobrze jest ułożyć architekturę i kontrakty. Modele językowe potrafią tu być zaskakująco pomocne, jeśli dostaną jasny opis domeny i ograniczeń. Przykładowy prompt:

„Projektujemy REST API dla systemu rezerwacji wizyt lekarskich. Technologie: backend w NestJS, baza Postgres, komunikacja asynchroniczna przez RabbitMQ. Opisz proponowaną strukturę modułów, podział odpowiedzialności i główne endpointy. Zwróć uwagę na wersjonowanie API i autoryzację.”

Odpowiedź modelu stanie się bazą do dyskusji w zespole. Nie chodzi o ślepe przyjęcie propozycji, tylko o szybkie otrzymanie pierwszego szkicu: listy modułów, przykładowych struktur DTO, możliwych błędów i statusów HTTP. To oszczędza czas na „gapienie się w pusty ekran” i daje wspólny punkt odniesienia.

Generowanie szkieletów kodu i boilerplate’u

Najbardziej oczywisty obszar automatyzacji pracy programisty to generowanie powtarzalnych fragmentów kodu. Im bardziej schematyczne zadanie, tym lepiej:

• CRUD-y dla encji w typowych frameworkach (Django, Spring, Laravel, Nest, Rails),
• komponenty w React/Vue/Angular, które różnią się głównie nazwami pól i prostą walidacją,
• szablony testów jednostkowych i integracyjnych dla istniejących funkcji,
• adaptery do popularnych usług zewnętrznych (płatności, e-mail, storage).

Dobrze działa podejście: „opisz encję, format danych i minimalne wymagania, a poproś model o wygenerowanie kontrolera, serwisu i testów w zadanej konwencji”. Następnie iteracyjnie doprecyzowuj oczekiwania: styl nazewnictwa, sposób obsługi błędów, podział miejsc na logikę biznesową.

Pułapka polega na tym, że wygenerowanie kodu jest bardzo tanie, a sprzątanie bałaganu – już nie. Jeśli model produkuje sporo powtórzeń, zbyt rozbudowanych warunków, zbędnych warstw abstrakcji, warto go „wychowywać” odpowiednimi promptami: prosić o minimalizm, pokazywać własne przykłady preferowanego stylu, a nawet wklejać fragmenty „dobrego” kodu jako wzorzec.

Debugowanie krok po kroku z pomocą LLM

Najprostsze, ale bardzo skuteczne podejście do debugowania z AI polega na potraktowaniu modelu jak parę świeżych oczu, które można prowadzić po śladach. Zamiast wklejać cały projekt i pytać „czemu nie działa?”, lepiej ułożyć historię problemu.

Przykładowy schemat rozmowy:

1. Opisujesz objaw: co konkretnie nie działa, jaki jest błąd, w jakich warunkach.
2. Wklejasz minimalny fragment kodu (funkcja, handler endpointu, kawałek konfiguracji), który najprawdopodobniej ma z tym związek.
3. Dodajesz logi, stack trace, wynik kilku prostych eksperymentów.
4. Prosisz o hipotezy i propozycję kolejnych kroków diagnostycznych.

Zamiast „napraw to”, można napisać:

„Oto endpoint w NestJS, który zwraca 500. Pod spodem widać stack trace. Zaproponuj 3 najbardziej prawdopodobne przyczyny błędu i konkretne kroki, jak je zweryfikować (komendy, logowanie, zmiany w kodzie).”

Taka forma zmusza model, by najpierw zbudował mapę problemu, a dopiero potem dotknął kodu. Efekt? Zamiast przypadkowej „magicznej poprawki” częściej powstaje rozsądny plan debugowania, który można ręcznie przejść i zweryfikować.

Dobrą praktyką jest też iteracja w stylu pair programming:

Jeśli chcesz pójść krok dalej, pomocny może być też wpis: Wybór licencji a SaaS: na co uważać, gdy udostępniasz open source jako usługę.

• Ty uruchamiasz test, kopiujesz wynik.
• Model interpretuje logi, proponuje zmianę.
• Ty wprowadzasz poprawkę, odpalasz testy i wracasz z efektami.

To spowalnia automatyzm „kopiuj–wklej” i zmniejsza ryzyko, że w kodzie zostaną poprawki, których sam nie rozumiesz.

Refaktoryzacja i upraszczanie złożonego kodu

Kiedy zespół odziedziczy „historyczny” moduł z tysiącem linii w jednej klasie, mało kto się pali, żeby go dotykać. LLM nadaje się tu idealnie do pracy w trybie „najpierw zrozum, potem ruszaj”.

Dobry wzorzec:

1. Najpierw prosisz o wyjaśnienie istniejącego kodu w ludzkim języku: opis ścieżek, gałęzi warunków, skutków ubocznych.
2. Później o identyfikację potencjalnych odpowiedzialności: „wymień główne grupy zachowań, które można wydzielić do osobnych metod/klas”.
3. Dopiero na końcu o konkretną propozycję refaktoryzacji.

Przykład promptu:

„Tu jest plik z 800 linijkami kodu w Java Spring. Nie zmieniaj go jeszcze. Najpierw:

1. Wypisz w punktach główne odpowiedzialności tej klasy.
2. Wskaż miejsca, które są najbardziej złożone poznawczo (duże if-y, zagnieżdżone pętle).
3. Zaproponuj podział na mniejsze klasy/serwisy, ale bez kodu – tylko opisowo.”

Na bazie takiej analizy można ustalić w zespole kierunek zmian, dopiero potem poprosić model o konkretne wycinki refaktoryzacji: wydzielenie jednej metody, zamianę „god objectu” na kilka prostszych serwisów, wprowadzenie wzorca strategii.

Jeśli kod obejmuje logikę biznesową newralgiczną dla firmy (np. naliczanie opłat), warto za każdym razem:

• otoczyć go testami regresyjnymi przed refaktoryzacją,
• prosić model o generowanie testów na podstawie opisanej logiki,
• po zmianach uruchamiać całą paczkę testów i porównywać zachowanie przed/po.

Model potrafi też upraszczać konstrukcje typu „if w ifie w switchu”. Dobrze działa polecenie: „Przepisz ten fragment tak, by zachować to samo zachowanie, ale zmniejszyć liczbę zagnieżdżeń i poprawić czytelność. Dodaj krótkie komentarze przy miejscach, gdzie logicznie coś się zmieniło.”

Docstringi, komentarze i dokumentacja na bazie kodu

Większość developerów nie ma czasu ani cierpliwości, by pisać rozbudowane docstringi. LLM potrafi tu odciążyć zespół, o ile podejdzie się do tego świadomie.

Schemat może być prosty:

• Programista pisze kod funkcji/metody.
• Zaznacza ją w IDE i prosi asystenta o wygenerowanie docstringa w ustalonym formacie (np. Google style, JSDoc, PHPDoc).
• Sprawdza opis, dopisuje niuanse domenowe, które model pominął.

Podobnie można genenerować:

• krótkie komentarze do skomplikowanych bloków,
• opisy endpointów do OpenAPI/Swagger,
• sekcje „How it works” w README dla poszczególnych modułów.

Dobrym zwyczajem jest doprecyzowanie w promptach:

• języka (polski/angielski),
• poziomu szczegółowości („dla mid developera”, „dla początkującego w tej technologii”),
• docelowego formatu (Markdown, AsciiDoc, komentarz w kodzie).

Przykład:

„Na podstawie tego kodu w TypeScript wygeneruj docstring w formacie TSDoc. Użyj krótkich, konkretnych zdań. Nie opisuj rzeczy oczywistych typu ‘iteruje po tablicy’, skup się na efektach ubocznych i wyjątkach.”

W większych projektach przydaje się też generowanie „opisu modułu” – prosisz model, żeby na bazie kilku plików streścił, co ten kawałek systemu robi, z kim się integruje i jakie ma zależności. Taki skrót jest złotem dla nowych osób w zespole.

Przyspieszanie code review z AI jako „pierwszą linią”

Code review to jedno z miejsc, gdzie LLM może zabrać naprawdę sporo żmudnej roboty. Nie chodzi o zastąpienie ludzkiego reviewera, ale o przygotowanie „brudnego szkicu” uwag.

Typowy scenariusz:

1. Pipeline CI/CD pobiera diff z PR (np. w formacie unified diff).
2. Wysyła go do modelu z kontekstem: konwencje projektu, zasady bezpieczeństwa, preferencje stylu.
3. Model generuje listę komentarzy: potencjalne bugi, niespójności, miejsca do uproszczenia.
4. Te komentarze są dodawane do PR jako „botowe” sugestie, które reviewer może przejrzeć, zaakceptować, odrzucić lub rozwinąć.

Jak ułożyć prompt dla takiego bota? Dobrze jest zawrzeć:

• język komunikatu („pisz po polsku, zwięźle, w tonie koleżeńskiego review”),
• priorytety: bezpieczeństwo, performance, czytelność, zgodność z konwencjami,
• ograniczenia: „nie oceniaj formatowania, tym zajmuje się linter”,
• preferowaną formę wynikową: lista komentarzy z referencją do linii + ocena wagi (np. „bug”, „suggestion”, „question”).

Model świetnie wyłapuje:

• powtarzające się fragmenty, które można uogólnić,
• brak obsługi edge case’ów (np. pustych list, nulli),
• nierówne nazewnictwo,
• miejsca, gdzie brakuje testów dla szczególnie wrażliwej logiki.

Ciekawym zabiegiem jest też proszenie modelu o „mini podsumowanie PR-a” w jednym–dwóch akapitach: co zmieniono, które moduły dotknięto, jakie są potencjalne ryzyka. Reviewer dostaje wtedy coś w rodzaju skróconej notatki od autora, nawet jeśli autor takiej notatki nie napisał.

Analiza i naprawa testów z użyciem LLM

Gdy w projekcie rośnie liczba testów, rośnie też ilość czasu przepalanego na ich utrzymanie. Szczególnie, gdy test jest długi, wieloetapowy i nikt już nie pamięta, o co w nim chodziło. Model może tu pomóc na kilka sposobów.

Pierwszy scenariusz to diagnoza flakiness:

• wklejasz test oraz przykładowe logi z kilku nieudanych i udanych odpaleń,
• opisujesz środowisko (lokalnie, CI, docker, równoległe joby),
• prosisz o hipotezy przyczyn niestabilności i propozycje, jak test uprościć lub „odflakować”.

Drugi – automatyczne generowanie dodatkowych przypadków testowych. Na podstawie jednej dobrze opisanej ścieżki model potrafi:

• zaproponować warianty wejścia (np. różne kombinacje parametrów),
• wygenerować testy graniczne (max/min, wartości skrajne),
• narysować krótką tabelę „wejście → oczekiwany wynik” dla biznesu.

Przykład promptu:

„Na podstawie tego testu integracyjnego w Go wygeneruj 5 dodatkowych przypadków, które mogłyby ujawnić edge case’y. Zwróć je jako tabelę z kolumnami: opis przypadku, wejście, oczekiwany status HTTP, najważniejsza asercja.”

Trzeci scenariusz to pomoc w „zrozumieniu” skomplikowanego zestawu testów. Model może ułożyć mapę:

• które testy pokrywają daną funkcję/endpoint,
• jakie ścieżki są w ogóle nieprzetestowane,
• gdzie testy dublują się logicznie.

Na tej podstawie łatwiej podjąć decyzję, które testy konsolidować, a które napisać od nowa.

Innymi słowy: AI świetnie liczy gwoździe i podaje narzędzia, ale to człowiek decyduje, gdzie postawić ścianę. Podobnie jak przy dyskusji o sieciach 5G czy IoT na blogach takich jak Złota Kielnia, sednem nie jest „magia technologii”, tylko sprytne użycie jej w konkretnym kontekście.

Automatyzacja pracy DevOps i SRE z wykorzystaniem LLM

Generowanie i utrzymywanie konfiguracji IaC

Terraform, Ansible, Helm, Pulumi – konfiguracje rosną, powielają się i szybko stają się „kopiuj–wklej–&–modify”. Model językowy świetnie nadaje się do wyciągania wzorców i porządkowania tego chaosu.

Praktyczny sposób pracy wygląda tak:

• Wklejasz kilka istniejących plików konfiguracyjnych, które uważasz za wzorcowe.
• Prosisz model o zidentyfikowanie wspólnych elementów i miejsc, gdzie można wprowadzić zmienne lub moduły.
• Dopiero potem generujesz module / role / chart na bazie tego wzorca.

Zamiast: „napisz mi Terraform dla nowego serwisu w AWS”, lepiej użyć:

„Tu są trzy istniejące moduły Terraform dla naszych serwisów backendowych w AWS. Zidentyfikuj pola, które różnią się między nimi, i wygeneruj czwarty moduł dla serwisu X, trzymając się tych samych konwencji nazewniczych, tagów i polityk bezpieczeństwa. Skup się na powtarzalności, a nie optymalizacji kosztów.”

Model, karmiony istniejącymi przykładami, staje się „uczniem” twojego stylu. Ty nadal decydujesz, które abstrahowanie ma sens, a które tylko komplikuje życie.

Diagnozowanie awarii na podstawie logów i metryk

Gdy coś wybucha w produkcji, pierwszy odruch to skakanie między kibaną, Grafaną, Sentry i Slackiem. LLM może pełnić rolę „szybkiego czytacza logów”, który zamiast człowieka łączy kropki między kilkoma kanałami.

Szczególnie użyteczny jest scenariusz:

• zbierasz reprezentatywny wycinek logów z kilku komponentów (np. gateway, serwis A, serwis B) z tego samego czasu,
• dodajesz wykres metryk (SERIES z Grafany jako JSON lub opis),
• opisujesz objaw biznesowy: „użytkownicy nie mogą dokończyć płatności kartą, widzą błąd X”.

Prompt może wyglądać tak:

„Na podstawie tych logów i metryk spróbuj odtworzyć sekwencję zdarzeń prowadzącą do błędu. Wypisz 3–5 najbardziej prawdopodobnych hipotez przyczyny razem z konkretnymi miejscami w logach/metrykach, które je wspierają. Zaproponuj konkretne dodatkowe logi lub dashboardy, które warto dodać, aby szybciej diagnozować podobny problem w przyszłości.”

Model nie zastąpi doświadczenia SRE, ale bardzo przyspieszy wstępną analizę, szczególnie u mniej doświadczonych osób. Z czasem można go też „nauczyć” specyfiki danego systemu, regularnie karmiąc opisami prawdziwych incydentów i ich przyczyn.

Tworzenie i weryfikacja runbooków oraz procedur operacyjnych

Runbooki często żyją w Confluence jako długie, nieczytane dokumenty. AI może pomóc zamienić je w coś bardziej dynamicznego – zarówno przy tworzeniu, jak i późniejszym utrzymaniu.

Przykładowe zastosowania:

• Na podstawie opisu kilku realnych incydentów model generuje draft runbooka „co zrobić, gdy X”.
• Pomaga ujednolicić styl: te same sekcje, sposób numerowania kroków, format komand.
• Weryfikuje spójność – sprawdza, czy opisany krok nie jest sprzeczny z aktualną konfiguracją.

Można też połączyć runbooki z „tool callingiem”. Model, widząc sygnał z systemu alertingu, może:

• sprawdzić w bazie wiedzy, czy istnieje pasujący runbook,

Interaktywne asystenty operacyjne w Slacku i CLI

Gdy zespół rośnie, „sre’owy know-how” zaczyna się rozmywać po Slacku, w komentarzach do ticketów i w głowach kilku starszych inżynierów. Model językowy może zagrać rolę takiego „dyżurnego kumpla z większą pamięcią”, podłączonego do narzędzi, których i tak używacie na co dzień.

Najprostszy wariant to bot w Slacku lub MS Teams, który:

• potrafi wyszukiwać i streszczać istniejące runbooki,
• odpowiada na pytania typu: „jak bezpiecznie zrestartować serwis X w regionie Y?”,
• generuje wersję „TL;DR” dla długiego opisu incydentu lub taska z Jiry.

Krok dalej to integracja z CLI. Zamiast przeklinać przy kolejnej inkantacji kubectl, inżynier pisze:

„Pokaż mi wszystkie Pody serwisu payments-api w stagingu, posortowane po restarcie, i wyświetl logi tego, który restartuje się najczęściej.”

Warstwa pośrednia zamienia to na konkretne komendy (kubectl, aws cli, az, gcloud) i dopiero wtedy wykonuje. Model staje się tłumaczem z „naturalnego SRE” na język skryptów. Z czasem można dołożyć bezpieczeństwo:

• białe listy komend,
• tryb „dry-run” z pokazaniem, co dokładnie zostanie wykonane,
• wymóg potwierdzenia przy komendach destrukcyjnych (np. kasowanie zasobów, migracje).

Takie podejście szczególnie pomaga osobom spoza „rdzenia DevOps”, które czasem muszą coś „podejrzeć” w klastrze, ale nie żyją w kubectl na co dzień.

Automatyczne aktualizacje i refaktoryzacja konfiguracji

Konfiguracje infrastruktury starzeją się szybciej niż aplikacje. Nowe wersje providerów Terraform, zmiany API chmury, deprecacje – to wszystko potrafi zamienić przyjemny kod IaC w skansen. Model językowy może asystować w masowych aktualizacjach.

Dobrym wzorcem jest praca w dwóch krokach. Najpierw prosisz model:

• o przejrzenie repo z IaC (lub jego wycinka),
• o zbudowanie listy miejsc, gdzie używane są przestarzałe pola, wersje providerów lub „hacki” obejściowe,
• o zaproponowanie mapy migracji: co, w jakiej kolejności i jak zmienić.

Dopiero na tej podstawie generujesz konkretne zmiany. Przykładowy prompt:

„Tu są trzy moduły Terraform używające starej wersji providera AWS. Zidentyfikuj pola i zasoby, które są deprecated w aktualnej wersji, i zaproponuj zmiany tak, aby zachować ten sam efekt końcowy. Zwróć uwagę na polityki bezpieczeństwa i tagowanie, nie upraszczaj ich.”

Model często potrafi też odchudzić chaos w helm chartach: wskazać powtarzające się wartości dla różnych środowisk, zaproponować sensowne values.yaml i podzielić je na values-dev, values-staging, values-prod. Zamiast ręcznie przeszukiwać kilkanaście plików, dostajesz plan „co z czym skleić”.

Projektowanie polityk bezpieczeństwa i zgodności z pomocą AI

Polityki bezpieczeństwa (IAM, NetworkPolicies, Security Groups, OPA, Kyverno) lubią być albo zbyt restrykcyjne, albo zbyt luźne. Uderzenie w równowagę wymaga cierpliwego przeglądu uprawnień. Model językowy może pełnić rolę „kontrolera rozsądku”.

Praktyczny schemat:

• podajesz aktualne definicje ról/uprawnień (np. IAM policy JSON, manifesty Kubernetes),
• opisujesz docelowy poziom zaufania (np. „serwis X ma mieć dostęp tylko do odczytu z bucketów oznaczonych tagiem team=fin”),
• prosisz model o wykrycie nadmiarowych uprawnień i wygenerowanie bardziej precyzyjnych zasad.

Dobrym trikiem jest też proszenie o „negatywną walidację”:

„Załóż się ze mną, że ta polityka IAM jest zbyt szeroka. Wymyśl 3 scenariusze, w których skompromitowana aplikacja mogłaby jej użyć do wykonania niepożądanego działania. Na tej podstawie zaproponuj modyfikację polityki.”

Taka gra w „adwokata diabła” ujawnia luki, które w codziennej rutynie łatwo przeoczyć. Szczególnie gdy zespół żyje w trybie „byle PR przeszedł, potem się zaostrzy”.

Model jako „architekt pipeline’u CI/CD”

Pliki YAML dla GitHub Actions, GitLaba, CircleCI czy ArgoCD szybko puchną. Wprowadzanie kolejnych jobów przez kopiuj–wklej kończy się labiryntem warunków i zależności. LLM może posłużyć jako zewnętrzne spojrzenie na cały pipeline.

Dobrym ćwiczeniem jest wklejenie kilku głównych plików konfiguracyjnych (lub ich istotnych fragmentów) i zadanie pytania:

„Opisz przepływ od push’a do deploya na produkcję własnymi słowami. Wypisz miejsca, gdzie robimy to samo kilka razy, i zaproponuj uproszczenia (np. reusable workflows, anchors, templates).”

Na tej podstawie możesz poprosić o konkretną refaktoryzację:

• wydzielenie wspólnych kroków budowania i testowania,
• opisanie warunków (branches, tags) w bardziej czytelny sposób,
• usunięcie martwych ścieżek, które już nie są używane.

Model dobrze sprawdza się też przy tworzeniu „polityk CI” w formie żywego dokumentu. Przykładowo:

• na podstawie obecnych pipeline’ów przygotowuje listę standardowych etapów: lint, testy jednostkowe, testy integracyjne, security scan, deploy,
• dla każdego z nich opisuje minimalne wymagania (np. „żaden PR nie może ominąć security scan’u dla paczek npm”),
• z tego powstaje dokument, którym możecie się posługiwać przy review nowych pipeline’ów.

Automatyczne generowanie środowisk testowych z opisów scenariuszy

Dużo zespołów DevOps i SRE męczy się z utrzymywaniem „tymczasowych” środowisk: branch-owych, PR-owych, event-owych. Samo stawianie i zwijanie takiego środowiska bywa trywialne, ale spięcie go z wymaganiami biznesowymi już nie. Tu model językowy pozwala operować językiem scenariuszy, a nie suchych YAML-i.

Przykładowy przepływ:

• product owner opisuje scenariusz: „Chcę przetestować migrację płatności kartą z integracji A do integracji B, z mockowanym bankiem i realnym systemem faktur.”,
• LLM na tej podstawie dobiera definicje usług, feature flagi, dane testowe i konfigurację stubów,
• pipeline na bazie wygenerowanej konfiguracji stawia środowisko typu „ephemeral env”.

Oczywiście ktoś musi najpierw zbudować „klocki”: moduły Terraform, helm charty, definicje danych testowych. Ale później rolą modelu jest ich odpowiednie poskładanie z opisu sytuacji. To trochę jak z zestawem LEGO – podstawowe elementy się nie zmieniają, zmienia się kombinacja.

Dobrym pomysłem jest też przechowywanie „przepisów na środowiska” w repo i korzystanie z modelu wyłącznie jako tłumacza:

• z języka naturalnego na selekcję istniejących przepisów,
• z suchych manifestów na zrozumiały opis, co to środowisko właściwie robi i do czego jest.

Usprawnianie post-mortemów i analizy incydentów

Retrospektywa po incydencie bywa bolesna, ale też daje najwięcej merytoryki. Problem w tym, że samo zebranie informacji i zapisanie sensownego post-mortemu zjada godziny. Model językowy pomaga odciążyć ten proces.

Dobrym uzupełnieniem będzie też materiał: 5G a IoT: gdzie naprawdę widać różnicę w opóźnieniach i zasięgu — warto go przejrzeć w kontekście powyższych wskazówek.

Zazwyczaj masz:

• zrzut konwersacji z kanału #incident-xyz,
• kilka zrzutów ekranów z Grafany, Kibany lub narzędzi APM,
• surowe logi oraz komentarze z ticketów.

Możesz poprosić model o:

• ułożenie osi czasu zdarzeń z zaznaczeniem „momentów kluczowych”,
• oddzielenie faktów od hipotez (co wiemy na pewno, a co tylko podejrzewaliśmy),
• wyciągnięcie wniosków organizacyjnych (np. brak runbooka, braki w monitoringach) bez przerzucania winy na konkretne osoby.

Przykładowy prompt:

„Na podstawie tej konwersacji Slack i timeline’u z alertingu przygotuj szkic post-mortemu w formacie: streszczenie, oś czasu, przyczyna pierwotna, czynniki pogarszające, co zadziałało dobrze, działania zapobiegawcze. Unikaj wskazywania winnych, skup się na procesach i narzędziach.”

Taki szkic można potem szybko zweryfikować, uzupełnić technicznymi detalami i wrzucić do Confluence. Efekt uboczny: baza wiedzy o incydentach rośnie dużo szybciej, a nowi członkowie zespołu mają z czego się uczyć.

Wspomaganie planowania capacity i kosztów chmury

Planowanie pojemności i kosztów zwykle opiera się na zrzutach z paneli billingowych i kilku arkuszach kalkulacyjnych. Spięcie tego w spójną historię wymaga czasu. LLM dobrze radzi sobie z „przeżuwaniem” takich danych.

Możesz:

• wyeksportować raporty kosztów z AWS/GCP/Azure (np. CSV, JSON),
• dodać do tego opis zmian w systemie (nowe funkcje, kampanie marketingowe, migracje),
• zapytać o korelacje i hipotezy, co napędza wzrost kosztów.

Model nie zastąpi dedykowanych narzędzi FinOps, ale potrafi szybko:

• wyłapać „dziwne” wzrosty w konkretnych usługach lub regionach,
• przekształcić surowe dane w kilka sensownych scenariuszy („jeśli przeniesiemy ruch z X do Y, to spodziewany efekt to…”),
• przygotować wersję prezentacyjną dla biznesu w języku nie wymagającym rozumienia EC2 vs. Fargate.

Dobry nawyk to spinanie takich analiz z backlogiem. Można poprosić model o:

„Na podstawie tych danych kosztowych i listy zgłoszeń w Jirze zaproponuj 5 tasków optymalizacyjnych, które mają największy potencjał oszczędności przy małym ryzyku. Dla każdego podaj szacowany wpływ (jako rząd wielkości, nie jako dokładną kwotę).”

Budowanie wspólnego „języka” między Dev, DevOps i biznesem

Naturalną konsekwencją wykorzystania LLM w zespołach technicznych jest to, że coraz więcej rzeczy da się tłumaczyć między światami: kodu, infrastruktury i celów biznesowych. Dobrym przykładem są „dwujęzyczne” opisy zmian.

Załóżmy, że w PRze do repo IaC wprowadzane są zmiany w konfiguracji autoskalera. Dla inżyniera to kilka linijek w YAML. Dla biznesu – potencjalna zmiana kosztów i dostępności. Model może generować:

• krótkie, techniczne podsumowanie dla DevOps,
• oraz wersję biznesową, w której zmiana jest opisana w kategoriach ryzyka, kosztu i wpływu na użytkowników.

Analogicznie przy planowaniu nowych feature’ów:

• product opisuje wymagania w języku user stories,
• LLM na tej podstawie generuje zarys wymagań niefunkcjonalnych (SLO, limity, oczekiwany wolumen ruchu),
• zespół DevOps ma od razu punkt startowy do zaplanowania monitoringu, limitów i capacity.

Najczęściej zadawane pytania (FAQ)

Czy AI naprawdę może zastąpić programistę albo zespół DevOps?

Modele językowe nie zastępują programisty ani DevOpsów, tylko zmieniają sposób ich pracy. Zamiast pisać wszystko od zera, inżynier część czasu spędza na formułowaniu dobrych pytań, weryfikacji wygenerowanego kodu i podejmowaniu decyzji technicznych. AI jest tu raczej turbo-doładowaną „gumową kaczką”, która podsuwa propozycje rozwiązań.

W praktyce zespół, który umie korzystać z LLM-ów, szybciej dowozi zadania i ma mniej nużącej roboty: mniej przepisywania boilerplate’u, mniej przekopywania się przez dokumentację i logi. Klucz pozostaje ten sam: człowiek musi rozumieć architekturę, domenę biznesową i być w stanie ocenić, czy wynik AI ma sens.

Do czego konkretnie programista może użyć modeli językowych w codziennej pracy?

Najczęstsze zastosowanie to odciążenie w powtarzalnych, technicznych zadaniach. Programista może poprosić model o wygenerowanie szkieletu CRUD-a, handlera HTTP, konfiguracji lintera, prostego Dockerfile czy przykładowych testów. LLM dobrze radzi sobie tam, gdzie istnieją „typowe wzorce” w kodzie.

Druga kategoria to wsparcie w uczeniu się i debugowaniu. Zamiast wertować kilka stron dokumentacji, można zapytać: „Jak w frameworku X poprawnie ustawić CORS dla takiego i takiego przypadku?”. Przy błędach – wkleić stacktrace, opisać kontekst i poprosić o hipotezy oraz kolejne kroki diagnostyczne. To trochę jak mieć pod ręką doświadczonego kolegę, który nie śpi o 2 w nocy.

Jak zespoły DevOps mogą wykorzystać AI w CI/CD i infrastrukturze?

W świecie DevOps LLM-y świetnie sprawdzają się przy pracy z konfiguracją i „klejeniem” narzędzi. Mogą generować i poprawiać pliki YAML, Terraform, Ansible czy szablony Helm, na przykład tworząc pierwszy draft pipeline’u na podstawie krótkiego opisu procesu. To przyspiesza start, a człowiek dopieszcza szczegóły i bezpieczeństwo.

Dobry efekt daje też użycie AI do opisywania złożonych pipeline’ów i logów. Model potrafi streścić rozbudowaną konfigurację tak, by menedżer czy security engineer zrozumieli, co się dzieje, oraz wyciągnąć z długich logów najważniejsze wzorce błędów. W wielu firmach LLM jest wpięty w CI: dostaje diff albo logi i od razu generuje komentarz do PR czy podsumowanie buildu.

Jakie zadania warto oddać modelom językowym, a co musi zostać po stronie człowieka?

LLM dobrze nadają się do „pierwszego draftu”: generowania szkieletów kodu i infrastruktury, propozycji scenariuszy testowych, checklist czy wstępnych wersji dokumentacji (opisy PR, runbooki, notatki z procesu). Sprawdzają się też w szybkim zbieraniu i kondensowaniu informacji z wielu źródeł w jedną, zwięzłą odpowiedź.

Po stronie człowieka zostają decyzje, które wymagają zrozumienia kontekstu biznesowego i odpowiedzialności: architektura systemu, model domenowy, logika biznesowa oraz kwestie bezpieczeństwa i zgodności z regulacjami. Inżynier musi też świadomie weryfikować wynik: czy wygenerowany kod jest sensowny, bezpieczny, pasuje do reszty systemu i standardów zespołu.

Co to są „halucynacje” w AI i jak programista może się przed nimi bronić?

Halucynacje to sytuacje, w których model z pełną pewnością podaje rzeczy nieprawdziwe: nieistniejące metody, klasy czy pola konfiguracji, zmyślone przykłady i linki. Wynika to z natury LLM-ów – one przewidują kolejne tokeny na podstawie statystyki, a nie „wiedzy” o świecie lub twoim projekcie.

Praktyczna obrona jest prosta, choć wymaga dyscypliny. Po pierwsze: każdy fragment kodu z AI należy traktować jak wkład juniora – trzeba go przeczytać, przetestować i skonfrontować z dokumentacją czy specyfikacją biblioteki. Po drugie: przy nietypowych, domenowych tematach lepiej karmić model precyzyjnym kontekstem (fragmenty dokumentów, istniejący kod, opisy wymagań), zamiast liczyć, że „samo zgadnie”.

Jak pisać skuteczne prompty dla modeli językowych w pracy developerskiej?

Dobry prompt jest konkretny i osadzony w kontekście. Zamiast pytania „Jak napisać logowanie?”, lepiej opisać sytuację: „Mam backend w NestJS, auth w oparciu o JWT, chcę dodać logowanie prób logowania do Postgresa – pokaż przykładowy serwis + migrację”. Model wtedy pracuje na zbliżonym do twojego scenariuszu, a nie na abstrakcji.

Pomaga też rozbijanie problemu na kroki. Najpierw poprosić o plan („jakie kroki proponujesz, żeby…”), potem o kod do pierwszego kroku, na końcu o testy lub refaktor. W bardziej złożonych przypadkach sensowne jest proszenie o krótkie podsumowanie: „Streść w 5 punktach, co właśnie zmieniliśmy i dlaczego”, co potem można wkleić do opisu PR.

Czym różni się ogólny chat AI (typu ChatGPT) od asystenta w IDE czy AI w pipeline’ach?

Ogólny chat to uniwersalny model: umie rozmawiać „o wszystkim”, ale z twoim kodem styka się dopiero wtedy, gdy mu go wkleisz. Asystent w IDE (jak Copilot czy podobne wtyczki) widzi aktualny plik, projekt i często całe repo – dzięki temu potrafi podrzucać podpowiedzi dopasowane do twoich nazw klas, wzorców i stylu kodu.

W pipeline’ach CI/CD AI działa zwykle jako usługa. Skrypt w jednym z kroków wysyła do modelu diff, logi czy konfigurację i odbiera odpowiedź, która ląduje jako komentarz do PR, raport w systemie CI albo wiadomość na Slacku. Dla zespołu DevOps to nie „jeszcze jeden chat”, ale element platformy, który obniża koszt zrozumienia, co się dzieje w złożonym ekosystemie.

Co warto zapamiętać

• Modele językowe nie zastępują programistów ani DevOpsów, tylko odcinają 20–40% żmudnej, powtarzalnej pracy – mniej „klepania” boilerplate’u i walki z dokumentacją, więcej czasu na architekturę, projektowanie i rozmowę z biznesem.
• Dla pojedynczego full‑stacka LLM to mentor od szybkich pytań, generator szkieletów (CRUD, Dockerfile, konfiguracje) i pomocnik w debugowaniu; wystarcza przeglądarka, wtyczka do IDE i ewentualnie prosty skrypt do API, bez całej korporacyjnej otoczki.
• W dużym zespole DevOps modele językowe stają się elementem platformy: automatyzują YAML/Terraform/Helm, tłumaczą złożone pipeline’y na ludzki język dla managerów i security, pomagają przy incydentach streszczając logi i podpowiadając kolejne kroki.
• Najzdrowszy model pracy to „AI robi pierwszy draft, człowiek wersję finalną”: LLM generuje szkielety kodu i infrastruktury, propozycje testów, checklisty oraz wstępną dokumentację, a inżynier decyduje, co zostaje, co trzeba poprawić, a co wyrzucić.
• Kluczowe decyzje muszą zostać w głowie zespołu: architektura, model domenowy, logika biznesowa, bezpieczeństwo i zgodność z regulacjami oraz ostateczna weryfikacja jakości – AI może podsunąć wzorzec, ale nie przejmie za to odpowiedzialności.
• LLM to zaawansowane autouzupełnianie, które przewiduje kolejne tokeny; świetnie radzi sobie z typowymi wzorcami konfiguracji i kodu, ale w niestandardowych przypadkach zamiast „genialnego pomysłu” często sklei znane schematy w nowym opakowaniu.

Bibliografia

• Attention Is All You Need. NeurIPS (2017) – Architektura Transformer, podstawa współczesnych LLM
• Language Models are Few-Shot Learners. NeurIPS (2020) – Opis GPT‑3, predykcja tokenów, możliwości i ograniczenia
• A Survey of Large Language Models. ACM Computing Surveys (2023) – Przegląd LLM, halucynacje, kontekst, zastosowania w programowaniu
• On the Dangers of Stochastic Parrots: Can Language Models Be Too Big?. ACM FAccT (2021) – Ryzyka LLM, halucynacje, brak „zrozumienia świata”
• GitHub Copilot: AI Pair Programmer Productivity Study. GitHub (2022) – Badanie wpływu asystentów AI na produktywność developerów
• The Impact of AI on Developer Productivity: Evidence from GitHub Copilot. Microsoft Research (2023) – Analiza skrócenia czasu zadań programistycznych z AI
• State of DevOps Report. Puppet (2021) – Metryki efektywności DevOps, automatyzacja i praktyki CI/CD
• Accelerate: The Science of Lean Software and DevOps. IT Revolution Press (2018) – Badania nad praktykami DevOps, automatyzacją i produktywnością zespołów
• Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation. Addison-Wesley (2010) – Fundamenty CI/CD, automatyzacja i rola pipeline’ów