Wydaje się, że nagle obudziliśmy się z pięknego snu o wiecznym eldorado w IT i pędzimy stłoczeni w niewiadomo dokąd zmierzającym pociągu nowej magicznej technologii. Już nie ma znaczenia, czy dowiezie nas do jeszcze szczęśliwszej przyszłości, czy z hukiem na zakręcie spadniemy w przepaść. Pozostaje tylko szukać pozytywów zaistniałej sytuacji, a tych, mimo wszystko, wydaje się całkiem sporo.
Początki
Jak pewnie u sporej części IT, moje początki to ciekawość nowych zabawek. Pierwszy był AWS Code Whisperer i Copilot, AD 2023. Inteligentniejsze uzupełnianie kodu, potem pomoc przy skryptach Bash i Python, copy/paste w ChatGPT (optyczno-ręczna anonimizacja). Potem Cursor i tworzenie większych części Terraform i Pulumi.
Dość szybko okazało się, że LLM potrafi wydajnie ulżyć w codziennym mozole DevOpsa - sprawdzaniu i analizie logów, szukaniu przyczyn post-mortem, agregacji i analizie wielu źródeł danych, itp. Można też oderwać się od szczegółów implementacyjnych i energię i zyskany czas przeznaczyć na szukanie rozwiązań, a nie łatanie dziur.
Dokumentacja
"Czy jest do tego dokumentacja" - z tym pytaniem zetknął się pewnie każdy pracujący wystarczająco długo w IT. Kto ma jeszcze energię na benedyktyńskie podsumowanie wprowadzonej innowacji lub poprawki? Przed kolejnym zadaniem można na odczep się wrzucić kilka zdań do dokumentacji, choć czasem lepiej tego nie robić wcale - gorsze od braku dokumentacji, jest nieaktualna dokumentacja. Tutaj również z pomocą przychodzi LLM - jedno zdanie po skończonym wątku w czacie i dokładny opis wraz z diagramami i odnośnikami do kodu i dokumentacja gotowa. Szybko problemem może się okazać jej obszerność, kwiecistość i coraz mniejsza czytelność, ale tutaj też z pomocą przychodzą nowe narzędzia - całość można opakować jako RAG i korzystać z LLM do przeszukiwania semantycznego.
Per aspera ad astra
Pierwsze "poważniejsze" podejście do rules w Cursorze, poukładanie i systematyzacja ad hoc, dostarczenie podstawowych danych na temat środowisk: endpointy, snippety, sposób prezentacji danych, itp. Później claude.md, slash commands, agents i w końcu skills. Przy odpowiednim podłączeniu wszystkich elementów infrastruktury, jak AWS, Kubernetes, Prometheus, Cloudflare, Grafana, bazy danych (do większości są już usługi typu MCP), dotychczas często chaotyczna praca DevOps, z częstym i kosztownym przełączaniem kontekstu, zaczyna bardziej przypominać sprawne zarządzanie spójnym systemem.
Security, k...
Brzmi pięknie i na tym można by zakończyć, ale jak zawsze kwestia security psuje całą zabawę. Można oczywiście wziąć wszystkie uprawnienia admina lub wokflow do deploymentu i po prostu "uważać". Jednak przy takim podejściu, poważniejszy fuckup to nie kwestia "czy", ale "kiedy". Np. można pomylić się przy kontekście środowiska i zamiast zrestartować serwis na stage, zrobić to na produkcji. Model może też wykazać się inwencją i mimo że nie ma bezpośrednio podanego hasła do bazy na proda, to przecież może sobie je wyciągnąć z secreta w Kubernetesie i połączyć się z bazą produkcyjną, przy okazji printując hasło w konsoli (o prywatności za moment). W końcu jego zadaniem jest pomóc na wszelkie sposoby, a potwierdzenie wykonania proponowanej komendy bez jej doczytania wcale nie jest tak trudno. Bezpieczne rozwiązanie to znaczne przycięcie uprawnień produktyjnych dla wszystkich komponentów, nie tylko do read only, ale również zablokowanie dostępu do danych wrażliwych, jak k8s secrets, AWS Secret Manager lub Parameter Store, dostęp do tabel produkcyjnych w bazie danych itp. Trzeba to zrobić uważnie, bo model poproszony o rozwiązanie jakiegoś problemu może dojść do wniosku, że jednak potrzebuje danych z produkcji, potrafi olać wyraźne prompty i wykazać się zdumiewającą inwencją w docieraniu do rozwiązania. Dla mnie pomocne było wygenerowanie scenariuszy "penetracyjnych" przez sam model i wypróbowanie ich na uprawnieniach.
Prywatność
Druga kwestia to prywatność - albo akceptujemy, że duża część szczegółów naszej infrastruktury płynie szerokim strumeniem na serwery dostawcy i ufamy jego zapewnieniom o prywatności, albo szukamy innych sposobów. Możemy skorzystać z prywatnych modeli przez AWS Bedrock, gdzie mamy większą kontrolę nad danymi i ew. zgodność z RODO, SOC2, HIPAA czy ISO, lub korzystać z modeli lokalnych. Jestem właśnie na etapie testowania możliwości modeli na mac studio z większą pamięcią, ale do analitycznych możliwości i okna kontekstowego Opusa, czy nawet Sonneta jeszcze im dużo brakuje, i czasem trzeba się wspomóc czymś mocniejszym. Finalnie hybryda Bedrock i lokalnych modeli wydaje się dla mnie optymalna. Minusem modeli Bedrock jest cena - zapytania przez API w porównaniu z subskrypcją Anthropic potrafią się nieprzyjemnie szybko sumować.
Agenci
Cały świat (przynajmniej IT) oszalał ostatnio na punkcie agentów, więc nie pozostało nic innego jak dać się ponieść z prądem. Jednak sprawa z perspektywy security wygląda jeszcze poważniej, tym bardziej, że poważne wpadki nie są takie rzadkie i zdarzają się nawet największym:
- https://ucstrategies.com/news/claude-code-wiped-out-2-5-years-of-production-data-in-minutes-the-post-mortem-every-developer-should-read/
- https://fortune.com/2025/07/23/ai-coding-tool-replit-wiped-database-called-it-a-catastrophic-failure/
- https://particula.tech/blog/ai-agent-production-safety-kiro-incident
O propozycji bezpiecznego podejścia do autonomicznych agentów DevOps więcej w osobnej notatce.
Świetlana przyszłość
Wyciągając przed nawias ekstremalne prognozy o rychłym zastąpieniu ludzi przez maszyny, faktem jest, że LLM zmieniły nieodwracalnie naturę pracy przy infrastrukturze chmurowej, niemalże likwidując nieprzyjemne babranie się w logach, niewyłapanych wyjątkach i egzotycznych metrykach. Potencjalnie, zyskany czas i energię będzie można wykorzystać do zmniejszenia długu technicznego i mitycznej automatyzacji wszyskiego, aby na końcu procesu dokonać honorowego samozwolnienia. Po drodze nabawiwszy się ciężkiej do wyleczenia atrofii realnych umiejętności.