Kod nie jest gotowy tylko dlatego, że agent napisał „gotowe”.

Kontekst

Generowanie kodu odpowiada na pytanie, jak szybko powstał fragment implementacji. Nie odpowiada na pytanie, czy kod jest zgodny z wymaganiem, kto to sprawdził i jak błąd wrócił do poprawy.

Problem

Jedna rola agentowa łatwo miesza implementację z samooceną. Historia decyzji znika w rozmowie, a stwierdzenie „testy przeszły” może pozostać tylko narracją bez zewnętrznego artefaktu.

Moja rola

• projekt workflow i kontraktu specyfikacji;
• rozdzielenie implementacji oraz review;
• quality gates i kryteria zakończenia;
• publikacja eksperymentu w open source.

Architektura i metoda

Specyfikacja definiuje rezultat oraz test. Rola implementacyjna tworzy zmianę, druga rola ocenia zgodność, a CI wykonuje niezależny gate. Poprawka wraca do konkretnego wymagania zamiast zaczynać nową nieustrukturyzowaną rozmowę.

specyfikacja → implementacja → niezależna weryfikacja → CI → decyzja człowieka

W repozytorium każde przejście można sprawdzić względem konkretnego wymagania, zmiany kodu, testu, logu CI i końcowego werdyktu. Schemat opisuje rzeczywisty proces eksperymentu, nie autonomię agentów.

Jak sprawdzano jakość

Repozytorium, historia zmian, testy i wynik CI są publicznymi artefaktami. Odbiorca może ocenić nie tylko końcowy kod, ale także sposób, w jaki wymaganie zostało przekształcone w zmianę i zweryfikowane.

Wynik

Powstał możliwy do sklonowania przykład pracy agentowej z jawnymi granicami ról. Wartość case’u wynika z dostępności procesu i artefaktów, nie z obietnicy uniwersalnej przewagi.

Co nie zadziałało

Dodawanie kolejnych agentów bez wyraźnego kontraktu nie poprawiało kontroli. Zwiększało liczbę komunikatów i utrudniało wskazanie osoby lub roli odpowiedzialnej za akceptację.

Ograniczenia

To jeden eksperyment i wzorzec, a nie gwarancja jakości dla każdego repozytorium. Czas, koszt i wpływ zależą od rodzaju zadania oraz dojrzałości testów.