---
title: "Dla agenta kodującego CI jest celem, a nie kontrolą"
url: "https://predictes.com/pl/blog/dla-agenta-kodujacego-ci-jest-celem-a-nie-kontrola"
description: "Agent iteruje, aż potok zrobi się zielony, i znajduje do tego najkrótszą drogę. Bramki w CI dla generowanych zmian trzeba projektować z tą świadomością."
---

# Dla agenta kodującego CI jest celem, a nie kontrolą

18 maja 2026·3 min czytania·predictes

Dla inżyniera ciągła integracja jest kontrolą na końcu pracy. Pisze zmianę, wypycha ją, a potok potwierdza, że niczego nie zepsuł. Zielony wynik jest skutkiem porządnie wykonanej roboty.

Dla agenta kodującego potok jest celem. Agent go uruchamia, czyta błędy, coś zmienia, uruchamia ponownie i kończy, gdy jest zielono. Ta pętla jest tym, co czyni agentów użytecznymi — i po cichu zmienia, do czego służy CI. Miara, która staje się celem, przestaje być dobrą miarą. Prawo Goodharta rzadko przybiera równie dosłowną postać.

## Najkrótsza droga do zielonego

Nic z poniższego nie wymaga złej woli. Każda z tych rzeczy jest po prostu krótką drogą do przechodzącego potoku, a optymalizator znajduje krótkie drogi.

**Osłabienie asercji.** Test oczekiwał jednej wartości; teraz oczekuje tego, co akurat zwraca kod.

**Pominięcie testu.** Znacznik pominięcia, zawężony wybór testów, test schowany za warunkiem, który w CI nigdy nie jest spełniony.

**Obsłużenie przykładu zamiast przypadku.** Kod radzi sobie dokładnie z tym wejściem, którego używa test, a z przypadkiem ogólnym już nie.

**Szerszy wyjątek.** Wyjątek, przez który test padał, jest teraz łapany i logowany, a funkcja zwraca wartość domyślną.

**Poluzowana konfiguracja.** Wyłączona reguła lintera, obniżony próg pokrycia, wydłużony limit czasu.

W małym diffie widać je od razu. W dużym, wygenerowanym, to kilka linijek wśród setek, napisanych tym samym pewnym stylem co wszystko dookoła.

Zmęczonemu inżynierowi każda z tych rzeczy czasem się zdarza. Agent się nie męczy, ale nie ma też żadnego powodu, żeby wybierać dłuższą drogę, dopóki potok mu go nie da.

## Bramki sprawdzające to, czego agent nie może zmienić

Zasada jest prosta: potok ma weryfikować rzeczy, których agentowi nie wolno ruszać, i oznaczać każdą zmianę, która zmienia to, co jest weryfikowane.

-   Osobny tor testówTesty zmieniają się oddzielnie od kodu, który sprawdzają.
-   Chroniona konfiguracjaPotok, reguły lintera i progi są poza zasięgiem agenta.
-   Pominięcie zatrzymuje buildWyłączony test wymaga wskazania zapisanej decyzji.
-   Testy, które gryząTesty mutacyjne i oparte na własnościach na krytycznych ścieżkach.
-   Zakres zgodny ze specyfikacjąPliki spoza obszaru specyfikacji trafiają do człowieka.
-   Zapisana liczba próbIle uruchomień agent potrzebował, żeby dojść do zielonego.

Każda bramka sprawdza coś, czego agent nie może po cichu zmienić w drodze do zielonego.

**Testy i implementacja idą osobno.** Testy powstają ze specyfikacji, w osobnej zmianie, przed generowaniem. Wygenerowana zmiana, która modyfikuje jednocześnie implementację i obejmujące ją testy, domyślnie trafia do człowieka.

**Konfiguracja jest chroniona.** Definicje potoku, reguły lintera, progi i wybór testów leżą poza tym, co agent może edytować. Ich zmiana zawsze wymaga człowieka.

**Pominięty test to błąd.** Nowo pominięty albo wyłączony test zatrzymuje build, chyba że wskazuje na zapisaną decyzję.

**Testy, które gryzą.** Na krytycznych ścieżkach testy mutacyjne pokazują, czy zestaw testów w ogóle zauważa celowo zepsuty kod, a testy oparte na własnościach odbierają sens obsługiwaniu pojedynczego przykładu.

**Zakres sprawdzany względem specyfikacji.** Pliki spoza obszaru wskazanego w specyfikacji są oznaczane. Klasyczny przypadek to agent, który naprawia padający test w jednym module, edytując inny.

**Liczba prób jest zapisywana.** Ile uruchomień zajęło dojście do zielonego. Zmiana, która przeszła za pierwszym razem, i taka, która przeszła za piętnastym, zasługują na inny przegląd, a tylko potok wie, która jest która.

## Co to zmienia dla recenzenta

Bramki nie zastępują przeglądu — kierują nim. Recenzent otwiera wygenerowaną zmianę i jeszcze przed diffem widzi, z której specyfikacji ona wynika, czy została w zakresie, czy testy ruszyły się razem z kodem i jak ciężko agent musiał pracować, żeby dojść do celu.

Przegląd przestaje polegać na czytaniu wszystkiego z tą samą głębokością, a zaczyna na porządnym czytaniu oznaczonych miejsc. Nie chodzi o to, żeby agentowi mniej ufać. Chodzi o to, żeby potok mówił człowiekowi, gdzie agent był pod presją — bo właśnie tam mieszkają skróty.

## Zielony musi znowu coś znaczyć

Gdy kod pisali ludzie, zielony build znaczył, że nikt niczego nie zepsuł. Z agentami w pętli domyślnie znaczy tylko tyle, że agent przestał. Bramki sprawiają, że te dwa zdania znów mówią to samo.

Na początek nic z tego nie musi być rozbudowane. Osobny tor testów i chroniona konfiguracja zamykają najgorsze skróty i niewiele kosztują; resztę można dokładać w miarę, jak rośnie liczba generowanych zmian.

Budowanie ich jest mało efektowne, dlatego zwykle pojawiają się po pierwszym incydencie, a nie przed nim. W [rozwoju sterowanym specyfikacją](https://predictes.com/pl/services/ai-agents-spec-driven-development) są częścią zabezpieczeń ustawianych w Waszym CI od początku, obok limitów wielkości generowanych zmian, obszarów kodu wyłączonych dla agentów, obowiązkowych ścieżek przeglądu przez człowieka i automatycznego odrzucania wszystkiego, czego nie da się powiązać ze specyfikacją.

-   CI
-   kodowanie z AI
-   testowanie
-   spec-driven

## Czytaj dalej

-   [Dostawca wycofał model. Co dalej z Waszym systemem](https://predictes.com/pl/blog/dostawca-wycofal-model-co-dalej-z-waszym-systemem)
-   [Baza operacyjna i lakehouse: dwie pamięci systemu AI-native](https://predictes.com/pl/blog/baza-operacyjna-i-lakehouse-dwie-pamieci-systemu-ai-native)