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

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.