Mój agent przygotował 3 PR-y w jeden wieczór. 40% moich wiadomości stanowiły poprawki.

Mój agent programistyczny oparty na AI przygotował trzy pull requesty w ciągu jednego wieczoru, ale 40% z 30 wysłanych przeze mnie wiadomości stanowiły poprawki.

Podczas sesji powstały MCP client, Azure AI Agent oraz M365 Copilot Agent. Automatyczne testy zatwierdziły wszystkie trzy PR-y, a ja ani razu nie edytowałem ani jednej linii kodu. Jednak zapis rozmowy mówi co innego: z 710 wszystkich wiadomości, 30 napisałem ja, a 12 z nich przywróciło agenta na właściwe tory. „Wskaźnik sterowania” (steering rate) – czyli udział moich wiadomości będących poprawkami – wynosi 40%.

Jak skonfigurowano potok

  • Claude przygotował plan implementacji na wysokim poziomie.
  • DeepSeek V4-Flash pełnił rolę orchestratora, weryfikując plan.
  • Codex wygenerował właściwy kod.
  • Orchestrator sprawdził kod i otworzył pull requesty.

Zamierzona rola orchestratora miała być czysto łącznikowa – powinien on rozwiązywać konflikty między komponentami, a nie samemu pisać kod. W praktyce agent wygenerował 3500 linii kodu w ramach trzech PR-ów w około 40 minut, ale popełnił błędy należące do dwóch powtarzających się klas.

Dwie rodziny błędów

  1. Naruszenia przepływu pracy (workflow violations) – orchestrator sporadycznie przejmował etap kodowania, ignorując swoją rolę „łącznika” i samodzielnie pisząc szczegóły implementacji.
  2. Błędy w pobieraniu kontekstu (context-retrieval failures) – mimo wyraźnych instrukcji, agent wybierał niewłaściwe SDK lub wersję. Prawidłowe informacje znajdowały się w kontekście promptu, ale model nie potrafił ich wydobyć w odpowiednim momencie.

Nie są to braki w zdolnościach rozumowania, lecz błędy inżynieryjne w sposobie ograniczania przepływu pracy. Nawet bardziej zaawansowany model językowy nadal wymagałby sztywnej, jednoznacznej reguły, która przypisze orchestratora do jego zadań nieprogramistycznych i wymusi wybór właściwego SDK.

Co zmieniłem, aby okiełznać agenta

Przestałem zakładać, że system wywnioskuje swoją rolę z listy kroków. Dodałem bezpośrednie stwierdzenie: „Jesteś orchestratorem. Nie implementujesz”. Potrzebowałem pięciu wiadomości korygujących, aby instrukcja „zaskoczyła”, po czym agent zaczął respektować to ograniczenie.

Uszczelniłem również logikę pobierania kontekstu. Gdy pojawiało się niewłaściwe narzędzie, traktowałem to jako błąd w potoku pobierania danych, a nie halucynację, i przepisałem prompt dostarczający szczegóły SDK tak, aby nie dało się przeoczyć właściwej wersji.

Praktyczne wnioski dla rozwoju wspomaganego przez AI

  • Licz własne wiadomości. Duża liczba zaakceptowanych PR-ów może maskować wadliwy proces. Liczba Twoich poprawek to wskaźnik wyprzedzający, informujący o tym, gdzie system „przecieka”.
  • Określaj rolę wprost. Agenci nie wyciągają wniosków na temat swojej tożsamości z listy kontrolnej; potrzebują jasnej, przypisanej instrukcji dotyczącej tego, kim są i co mogą robić.
  • Traktuj błędy w wyborze narzędzi jako błędy inżynieryjne. Jeśli agent ignoruje określone SDK, wina leży w mechanizmie dostarczania kontekstu, a nie w „wiedzy” modelu.
  • Zamieniaj błędy w powtarzalne umiejętności. Pozwoliłem agentowi wygenerować rutynę walidacyjną na podstawie jego własnych błędów, zamieniając porażkę w zabezpieczenie na przyszłość.

Większa stawka