Netflix, Meta i IBM: AI zrobi z każdego programistę 10x, ale z dziesięciokrotnie większym bałaganem

Wizja programisty, który dzięki sztucznej inteligencji staje się dziesięciokrotnie bardziej wydajny, jest kusząca, ale rzeczywistość konferencyjnych kuluarów maluje znacznie bardziej złożony obraz. Podczas wydarzenia All Things AI w Durham, eksperci z takich gigantów jak Netflix, Meta oraz IBM postawili sprawę jasno: AI rzeczywiście może uczynić z każdego „programistę 10x”, jednak ceną za ten skok produktywności jest konieczność wykonania dziesięciokrotnie większej pracy przy czyszczeniu i weryfikacji kodu. Zamiast obiecanego odpoczynku, inżynierowie stają przed wyzwaniem zarządzania chaosem, który generują ich cyfrowi asystenci.

Zjawisko to idealnie wpisuje się w tzw. Paradoks Jevonsa, który wielokrotnie przywoływano podczas prelekcji. Teoria ta sugeruje, że im bardziej wydajny staje się dany zasób, tym częściej jest on wykorzystywany, co paradoksalnie nie prowadzi do oszczędności, lecz do wzrostu całkowitego zapotrzebowania. W kontekście technologicznym oznacza to, że AI nie zlikwiduje miejsc pracy, ale radykalnie zmieni ich charakter — programiści zamiast pisać każdą linię kodu, stają się kontrolerami jakości i architektami procesów, którzy muszą poświęcać coraz więcej czasu na przygotowanie kontekstu i sprawdzanie wyników.

Adwersaryjny przegląd kodu i armia agentów

Ben Ilegbodu, architekt UI w firmie Netflix, przedstawił fascynującą, choć nieco wyczerpującą wizję codziennej pracy z automatyzacją. Według niego, stworzenie jednego agenta do wykonania zadania to dopiero początek. Aby proces był rzetelny, konieczne jest zatrudnienie drugiego agenta, którego jedynym celem jest ocena pracy tego pierwszego. Ilegbodu idzie nawet o krok dalej, stosując metodę, którą nazywa „adversarial code review” (adwersaryjny przegląd kodu), gdzie zadanie jest dzielone między wielu wyspecjalizowanych agentów recenzujących różne fragmenty oprogramowania.

W tym ekosystemie niezbędny staje się trzeci agent, pełniący rolę orkiestratora, który zarządza komunikacją i działaniami między dwiema stronami. Taka struktura pozwala Ilegbodu na „równoległe zwielokrotnienie samego siebie”, co umożliwia mu pracę w językach, których wcześniej nie znał, takich jak Python, Bash czy Groovy. Jednak ta ciągła zmiana kontekstu i rola dyrygenta cyfrowej orkiestry ma swoją cenę — jak sam przyznaje, pod koniec dnia czuje się wyczerpany faktem, że przez osiem godzin „rozmawiał z czymś”, zamiast po prostu tworzyć.

Pułapka nienasyconego stażysty i gnicie kontekstu

Justin Jeffress, Developer Advocate w Meta, porównuje dzisiejsze modele AI do niezwykle entuzjastycznych, ale naiwnych młodszych programistów. Główna różnica polega na tym, że AI nigdy nie czuje się przytłoczone nadmiarem danych — będzie przyjmować każdą ilość informacji, dopóki wystarczy nam tokenów. To jednak prowadzi do zjawiska, które Jeffress określa jako context rot (gnicie kontekstu). Im więcej nieuporządkowanych danych trafia do agenta, tym bardziej rozproszona staje się jego uwaga, co drastycznie zwiększa ryzyko błędnych odpowiedzi.

Rozwiązaniem tego problemu ma być „inżynieria kontekstu” — nowa dyscyplina, która polega na budowaniu precyzyjnych reguł, narzędzi i umiejętności, do których agent może się odwołać w konkretnym momencie. Jeffress sugeruje, że programiści muszą opanować „prompt chaining”, czyli rozbijanie złożonych poleceń na drobne, sekwencyjne kroki. Co ciekawe, zauważył on specyficzną, fraktalną naturę pracy z AI: bot wykonuje 80% zadania, zostawiając 20% człowiekowi. Kiedy jednak człowiek próbuje dokończyć te 20%, okazuje się, że 80% z tego pozostałego fragmentu znów mogą wykonać boty — i tak w kółko, w niekończącym się procesie czyszczenia i dopracowywania detali.

Koniec z życzeniowym promptowaniem

Luis Lastras, dyrektor ds. technologii językowych i multimodalnych w IBM, uważa, że błędy AI często nie wynikają z ułomności samej technologii, lecz z braku umiejętności dekompozycji zadań u użytkowników. Krytykuje on tzw. „wishful prompting” (życzeniowe promptowanie), czyli dopisywanie do poleceń fraz w stylu: „Błagam, nie halucynuj, od tego zależy moja kariera”. Według Lastrasa jest to odpowiednik rzucania zaklęć, który nie ma nic wspólnego z inżynierią.

Zamiast prośby o „niehalucynowanie”, IBM promuje podejście modułowe. Firma udostępniła niedawno bibliotekę open source mellea.ai, która zawiera gotowe wzorce i funkcje zakodowane w języku Python. Pozwalają one na:

• Dodawanie sztywnych wymagań do wywołań LLM.
• Wykrywanie szkodliwych lub błędnych wyników.
• Strukturyzowanie odpowiedzi w konkretne schematy danych.

Lastras zdradził również, że IBM pracuje nad funkcją „przełączania mózgów” (switch brains), która pozwoli agentom na dynamiczną zmianę modelu LLM w zależności od specyfiki zadania. Badania firmy wykazują, że mniejszy, wyspecjalizowany model dziedzinowy, któremu da się więcej czasu na wnioskowanie, często przewyższa możliwościami największe, ogólne modele rynkowe.

Podatek od przygotowań i twarde ograniczenia

Justin Chau, starszy programista w Intuit, zwraca uwagę na jeszcze jeden aspekt: dług technologiczny wynikający z niejawnych założeń. To, co dla człowieka jest oczywiste, dla maszyny takie nie jest. Chau radzi, aby zamiast instruować AI, co ma robić, nakładać na nią twarde ograniczenia (constraints). Model LLM może zignorować instrukcję, jeśli uzna, że znalazł „lepszą” drogę do celu, ale znacznie trudniej jest mu złamać kategoryczny zakaz, np. dotyczący używania konkretnego języka znaczników jak HTML.

Najskuteczniejszą formą kontroli pozostaje jednak całkowite odbieranie uprawnień. Jeśli agent nie otrzyma dostępu do GitHub, mamy absolutną pewność, że nie zmodyfikuje kodu w repozytorium bez naszej wiedzy. To podejście przesuwa punkt ciężkości pracy programisty z samego pisania na zarządzanie dostępami i architekturą bezpieczeństwa.

Współczesna inżynieria oprogramowania w dobie AI zaczyna przypominać poszukiwania z „Autostopem przez Galaktykę” Douglasa Adamsa. Podobnie jak komputer Deep Thought, który po wiekach obliczeń podał wynik „42”, dzisiejsze modele dają odpowiedzi, które wymagają budowy jeszcze potężniejszych systemów tylko po to, by zrozumieć, o co właściwie zapytaliśmy. AI nie tyle zdejmuje z nas ciężar pracy, co nakłada na nas „podatek od przygotowań”, zmuszając do bycia bardziej precyzyjnymi, niż kiedykolwiek wcześniej. W tym nowym paradygmacie największą wartością nie jest już umiejętność pisania kodu, lecz zdolność do jego dekompozycji i rygorystycznej weryfikacji.