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

Tag: Gpu Timesharing

DevOps w erze GenAI – rewolucja czy ewolucja? #EN133