---
title: "Kod pisany przez agentów i tak przechodzi przegląd"
url: "https://hurukan.com/pl/blog/kod-pisany-przez-agentow-i-tak-przechodzi-przeglad"
description: "Autonomiczna fabryka oprogramowania to realna przewaga i najłatwiejsza rzecz w tej dziedzinie do przesadzenia. Oto dokładnie, gdzie automatyzacja się kończy."
---

# Kod pisany przez agentów i tak przechodzi przegląd

24 lipca 2026·2 min czytania·hurukan

hurukan jest w dużej mierze budowany przez agentów. Piszą kod, generują testy, uruchamiają zestaw, integrują i otwierają zmianę do wydania. Skraca to dystans między zauważeniem problemu a jego poprawką w działającym wdrożeniu z tygodni do godzin i jest to prawdziwa przewaga.

Jest to zarazem twierdzenie w tej dziedzinie najbardziej narażone na napompowanie — warto więc spisać, gdzie automatyzacja się kończy i dlaczego te zatrzymania nie są tymczasowe.

## Co jest naprawdę zautomatyzowane

**Implementacja ze specyfikacji.** Mając jasny opis zmiany i istniejącą bazę kodu, agent pisze wiarygodną implementację szybciej niż człowiek i nie nudzi się przy żmudnych częściach.

**Generowanie testów.** Łącznie z przypadkami, które zmęczony człowiek pomija: pusta lista, duplikat, strefa czasowa, równoległy zapis.

**Integracja i potok.** Budowanie, uruchamianie testów, sprawdzanie typów, rozwiązywanie rutynowych konfliktów — i robienie tego w sposób ciągły, a nie paczkami.

**Nudne utrzymanie.** Aktualizacje zależności, migracje z wycofywanych rozwiązań, spójność między podobnymi ścieżkami kodu. Prawdziwa praca, historycznie odkładana i taka, która po cichu psuje system.

## Co nie jest

**Decyzja, co budować.** Specyfikacja jest oceną dotyczącą firmy, a nie zadaniem programistycznym. Agenci nie wiedzą, która z pięciu usterek ma znaczenie dla firmy działającej na tym w najbliższy wtorek.

**Architektura o długich konsekwencjach.** Wybory, z którymi żyje się latami: gdzie leży granica, co twierdzi model danych, co świadomie uczyniono niemożliwym. Tanie do szybkiego zepsucia i drogie, gdy okaże się zepsute.

**Przegląd.** Każda wygenerowana zmiana przechodzi przegląd i te same bramki co każda inna. Przewaga prędkości bierze się z szybszych bramek, a nie z mniejszej ich liczby — a kto oferuje to drugie, opisuje system, który wypuści coś, czego nie powinien.

**Decyzja o wydaniu.** Człowiek decyduje, co trafia do firmy działającej na tym oprogramowaniu. To nie zostanie zautomatyzowane — nie dlatego, że się nie da, tylko dlatego, że odpowiedzialność za złe wydanie musi być do kogoś przypięta.

## Tryb awarii wart nazwania

Ilość. Agent szybko wyprodukuje dużą, wiarygodnie wyglądającą zmianę, a jej porządny przegląd zajmuje tyle samo co przegląd czegokolwiek innego. Zespoły mierzące szybkość generowania, a nie szybkość przeglądu, gromadzą niedoprzeglądany kod w tempie, którego żaden ludzki proces nie wchłonie — a dług przychodzi naraz.

Obroną jest to, że generowane zmiany muszą być małe, testy naprawdę niezależne od implementacji, a zdolność przeglądu musi być ograniczeniem, pod które wymiaruje się całość. Jeśli przegląd jest wąskim gardłem, system działa poprawnie.

## Po co mówić to tak wprost

Bo autonomiczna fabryka oprogramowania brzmi jak twierdzenie o niepotrzebności inżynierów, a nim nie jest. Jest twierdzeniem o odstępie między usterką a jej poprawką — czyli o rzeczy, którą klient może zmierzyć.

To jest wersja, do której chcielibyśmy być przykładani, i jest mniejszym twierdzeniem, niż sugerują te słowa. Dla firmy proszonej o oparcie swoich operacji na tym oprogramowaniu mniejsze twierdzenie, które wytrzymuje sprawdzenie, jest warte więcej niż większe, które nie wytrzymuje.

-   inżynieria AI
-   CI/CD
-   przegląd kodu
-   fabryka oprogramowania

## Czytaj dalej

-   [System zapisu nie umie działać](https://hurukan.com/pl/blog/system-zapisu-nie-umie-dzialac)
-   [Podatek od integracji](https://hurukan.com/pl/blog/podatek-od-integracji)