TL;DR
- AI zmienia DevOps, ale nie zastąpi ludzi – cały czas potrzebny jest ludzki input i nadzór
- Model Context Protocol (MCP) to nowy standard, który pozwala modelom AI korzystać z zewnętrznych narzędzi
- DevOps zbliża się do MLOps – firmy chcą hostować własne modele AI, co tworzy nowe wyzwania
- „Rework time” to nowy problem – AI oszczędza czas jednostki, ale zespół może tracić czas na poprawki
- Większe zmiany = więcej błędów – AI zachęca do robienia większych commitów, co prowadzi do problemów z integracją
- Halucynacje i context limit to główne bariery dla pełnej automatyzacji
- 2025 będzie rokiem integracji – AI stanie się naturalną częścią pipeline’ów
Gdzie jesteśmy dziś z GenAI w świecie IT
Marzec 2025 przyniósł kolejne przełomy w sztucznej inteligencji. DeepSeek R1 pokazał, że da się robić zaawansowane modele taniej – chiński model na rynku trochę zamieszał. Grok 3 od X.com dołączył do walki gigantów. Natomiast EXO v2 umożliwił uruchamianie dużych modeli na klastrach zwykłych komputerów.
Te zmiany redefiniują cały krajobraz AI. Modele przestają być zabawką dla wielkich korporacji. Stają się dostępne dla każdej firmy, która chce eksperymentować.
Grzegorz Ochmański z AWS – ponad 17 lat w IT, ostatnie 4 lata i 3 miesiące w Amazon Web Services, gdzie zajmuje się głównie AWS4Games i pipeline’ami dla gier – nakreślił realistyczny obraz tego, gdzie obecnie znajduje się DevOps w kontekście GenAI.
Co AI może już robić w DevOps
AI w poszczególnych etapach DevOps:
✅ Gdzie AI już pomaga:
- Kodowanie – Gemini 2.5 Pro, Claude 3.7 Sonnet generują dobry kod i boilerplate
- Planowanie – tworzenie tasków na podstawie wymagań, „walking skeleton” aplikacji
- Testowanie – unit testy i testy integracyjne dla wygenerowanego kodu
- Budowa – Terraform, Helm charts, skrypty automatyzacji
- Monitorowanie – analiza logów, metryk i wyciąganie wniosków
⚠️ Gdzie jeszcze potrzebny człowiek:
- Release – decyzje o wypuszczeniu na produkcję
- Deploy – faktyczne wdrożenia wymagają nadzoru
- Operate – zarządzanie produkcją to za duża odpowiedzialność dla AI
Jednak przy specjalistycznych obszarach jak gry, AI kuleje. Training set jest za mały – nikt nie udostępni kodu Wiedźmina 3, żeby trenować modele. Mimo to przy bibliotekach open source jak FreeJS wyniki są imponujące.
Model Context Protocol – przełom w integracji AI
Model Context Protocol to jedna z najważniejszych innowacji ostatnich miesięcy. Antropic wypuścił go w listopadzie jako open source. Dlatego w ciągu trzech miesięcy największe firmy technologiczne zaczęły budować swoje integracje.
Problem był taki: modele AI działają w zamkniętej przestrzeni. Mają dane do konkretnej daty i nie wiedzą, co dzieje się na świecie. Jednak jak zapytasz o obecną datę, czysty model nie będzie wiedział.
MCP rozwiązuje to przez standardyzację protokołu narzędzi. Działa jak klient-serwer – model AI jest klientem, który przez JSON odpytuje serwer o dodatkowe funkcje.
Magnus AI to doskonały przykład tej technologii w praktyce. Firma nie stworzyła własnego modelu – używa modeli Antropica. Zamiast tego zbudowała MCP serwer, który daje modelowi dostęp do maszyny wirtualnej z Ubuntu. Model ma kontrolę nad systemem, może pisać kod, testować go, uruchamiać. Ma nawet dostęp do internetu, więc potrafi sobie napisać narzędzie do parsowania Google’a czy integracji z pyszne.pl.
AWS wypuścił wczoraj swój MCP serwer. Możesz teraz w naturalnym języku odpytywać swoje konto o koszty. Model przygotuje ci nawet grafiki, bo ma dostęp do generowania obrazków.
Dostępne integracje MCP:
- Kubernetes – zarządzanie klastrami bez znajomości kubectl
- Docker – tworzenie i zarządzanie kontenerami
- Systemy plików – operacje na plikach i katalogach
- Bazy danych – zapytania i zarządzanie danymi
- Slack/Teams – automatyzacja komunikacji
- AWS/Azure/GCP – zarządzanie zasobami chmurowymi
Kto będzie pisał te integracje? Software development nie schodzi na ten poziom. Dlatego to naturalnie spada na DevOpsów.
DevOps zbliża się do MLOps
Ochmański podkreślił różnicę między Platform Engineering a DevOps: Platform Engineering daje deweloperom platformę, na której mogą robić cuda, a DevOps to całościowy proces i podejście do tworzenia oprogramowania. Gdy połączymy DevOps, DevSecOps i MLOps, powstaje nam platforma do zarządzania modelami AI.
Dlaczego firmy chcą hostować własne modele AI:
- Legal issues – regulacje branżowe uniemożliwiają dzielenie się danymi
- Regulated business – banki, zakłady bukmacherskie, firmy finansowe
- Bezpieczeństwo danych – kontrola nad wrażliwymi informacjami
- Niezależność – brak uzależnienia od zewnętrznych dostawców
Hostowanie modeli AI to nowy paradygmat dla DevOps. Te modele są ogromne – DeepSeek R1 ma 495 GB. Muszą być w pamięci kart graficznych, żeby działały szybko.
Rozwiązaniem jest sharding na wielu nodach. Zamiast jednego wielkiego serwera, używasz klastra zwykłych maszyn z kartami graficznymi. NVIDIA wprowadziła timesharing GPU – możesz przydzielić część karty graficznej konkretnej aplikacji.
Naturalną platformą dla tego jest Kubernetes. MLOpsowie skupiali się na trenowaniu modeli. Teraz jednak potrzebują DevOpsów do hostowania inferencji.
Stack technologiczny dla AI w DevOps:
- KServe – serving modeli ML na Kubernetesie
- Seldon Core – MLOps platforma do deploymentu modeli
- Ray Cluster – distributed computing dla AI workloads
- VLLM – optymalizacja inferencji dla dużych modeli językowych
- Kubeflow – end-to-end ML workflows
- NVIDIA GPU Operator – zarządzanie kartami graficznymi w K8s
Rzeczywistość kontra oczekiwania
Raporty DORA z 2024 roku pokazują interesujący paradoks. AI oszczędza czas pojedynczego developera, ale niekoniecznie całego zespołu.
Pojawił się nowy problem – „rework time”. Developer napisze moduł z AI, ale senior musi siedzieć i troubleshootować. Sprawdzać, dlaczego kod działa tak, a nie inaczej. Albo dlaczego w ogóle nie działa.
Drugi problem to „delivery disconnect”. AI zachęca do robienia większych zmian. Zamiast małych commitów, robisz cały moduł na raz. Ochmański nazwał to „over bravery” – nadmierną odwagą programistów, którzy myślą: „co ja tu będę zmieniał 10 linii, zrobię od razu całe 10-20 funkcji”. Potem integration testy wszystkie leżą, a senior developer musi odkręcać to, co AI narobił.
Suma sumarium – czas dla zespołu pozostaje ten sam. Wydaje się, że oszczędzasz, ale w praktyce przesuwasz pracę na innych.
Jest też presja psychologiczna. Inna firma już to ma, więc my też musimy. W firmach technologicznych żyjemy w świecie GPU timesharing i mikroservisów. Jednak w public service Excel ciągle jest wyzwaniem. Ten disconnect od rzeczywistości prowadzi do nierealistycznych oczekiwań.
Dlaczego AI jeszcze nas nie zastąpi
AI to „genialny ośmiolatek, który potrafi wszystko, ale sam nic z siebie nie zrobi”. Ta metafora dobrze oddaje obecny stan technologii.
Modele działają na zasadzie transformer – potrzebują input, tłumaczą go na tokeny, przeszukują bazę wiedzy, przewidują kolejne słowo. Nie potrafią myśleć samodzielnie.
Halucynacje wyjaśnione technicznie:
Ochmański wyjaśnił mechanizm halucynacji na pytanie z sali. Transformer pocina tekst na tokeny, które są przetwarzane na wektory z wagami. Problem w tym, że przy treningu używamy 32-bitowych wag, ale przy deploymencie robimy kwantyzację do 8-bit czy 4-bit, żeby zmniejszyć rozmiar modelu.
Mniej precyzyjne wagi oznaczają słabsze korelacje między tokenami. Wystarczy, że raz ta korelacja będzie źle zinterpretowana, a model zaczyna „brnąć”. Z racji kontekstu zapamiętuje to, co pytałeś, więc halucynacja się rozprzestrzenia jak efekt motyla.
Gdybyśmy zachowali 32-bitowe wagi, halucynacje byłyby rzadsze, ale hardware’u by nam zabrakło, a koszty hostowania byłyby astronomiczne.
Inne bariery techniczne:
- Context limit – powyżej 10k linii kodu model się gubi i może wpaść w pętlę błędów
- Koszty iteracji – nieskończone poprawki mogą być bardzo drogie
- Brak determinizmu – modele działają probabilistycznie, nie na logice boolowskiej
Amazon Q CLI w projekcie 26 razy proponował zastąpienie 730 linii kodu pięcioma. W kolejnej iteracji zapomniałby o tym, co zrobił.
Modele już obecnie są trenowane na półsyntetycznych danych – to daje świetne rezultaty, ale niesie ryzyko. Były eksperymenty, gdzie w 50. iteracji model zaczął generować losowe rzeczy, zrozumiałe dla niego, ale nie dla ludzi. To zjawisko nazywa się „rozkładem modelu”.
Skala treningu jest ogromna – nie mówimy o skali internetu, tylko o wielokrotnie większych rzędach wielkości. Najnowsze modele jak Sonnet 3.7 czy DeepSeek to właśnie efekt trenowania na takich gigantycznych, częściowo syntetycznych datasetach.
Model może zepsuć więcej, niż naprawić. Dlatego efekt motyla w kodzie to poważne ryzyko.
Przyszłość DevOps w erze AI
Predykcje na 2025 wskazują na „wplecenie” AI w pipeline. Nie będzie to osobne narzędzie, do którego idziesz z błędem. AI stanie się naturalną częścią całego procesu.
Jenkins już ma kroki z automatyczną analizą błędów. Dostaje message na Slack z pełną analizą problemu. To oszczędza czas na debugowaniu.
DevOps nie umrze, ale się zmieni. Podobnie jak blockchain czy NFT, niektóre technologie znikają z nagłówków. Jednak AI ma realne zastosowania i zostanie.
Zmiana polega na automatyzacji rutynowych zadań. Shell skrypty, boilerplate kod, podstawowa infrastruktura. AI to zrobi szybciej. Human robi review, testy, deployment.
Co z dodatkowym czasem? Nowe kompetencje w MLOps. Integracje MCP. Hostowanie modeli AI. Zarządzanie klastrami GPU.
Rynek pracy się nie zawali. State of DevOps 2024 nie pokazuje masowych zwolnień.
Czy AI nas zastąpi? Jeszcze nie
Ochmański użył ciekawej analogii z filmu „Idiocracy”: „Oglądaliście film Idiocracy? Tam był moment, kiedy wszystko podlewali Gatorade’em. Gościu zasugerował podlewanie wodą, a komputer wywalił połowę miasta z roboty. Jeszcze nie jesteśmy na tym etapie.”
Na pytanie z sali o autonomiczne poprawki w pipeline, odpowiedział wprost: to jeszcze lata. Koszty, halucynacje, ograniczenia techniczne.
AI potrzebuje ludzkiej pomysłowości i nadzoru. Zawsze musi być input. Nawet najbardziej genialny output wymaga człowieka, który go zweryfikuje.
To nie znaczy, że technologia stoi w miejscu. Gemini 2.5 Pro i Claude 3.7 Sonnet robią rzeczy, które jeszcze rok temu były nieosiągalne. Postęp jest zdumiewający.
Jednak pełna autonomia to odległa przyszłość. Na razie AI to potężne narzędzie, które wymaga mądrego operatora.
Kluczowy insight
Paradoks małych commitów
Standardowo myślimy: Skoro AI generuje więcej kodu szybciej, to robimy większe zmiany i commity – oszczędzamy czas na ciągłym commitowaniu.
W praktyce okazuje się, że: AI sprawia, że programiści wpadają w „over bravery” i robią zbyt duże zmiany naraz, co prowadzi do więcej błędów integracji i „rework time” dla seniorów.
Dlaczego to jest istotne: Zespoły myślą, że zyskują produktywność, ale w rzeczywistości przesuwają pracę z juniora na seniora. Efekt netto może być zerowy lub negatywny.
Test na jutro: Następnym razem gdy używasz AI do kodowania, zamiast generować cały moduł naraz, spróbuj robić małe commity po każdej funkcji i sprawdź ile czasu senior poświęca na review vs standardowe podejście.
Ten wpis jest częścią mojej kolekcji notatek z ciekawych podcastów, webinarów i innych treści, które uważam za wartościowe i do których sam chcę wracać. Jeśli chcesz sprawdzić oryginalne źródło, znajdziesz je tutaj: https://www.youtube.com/watch?v=iIFNvUIkz1c
Dodaj komentarz
Musisz się zalogować, aby móc dodać komentarz.