Jeśli kod piszą agenci, recenzowaną rzeczą staje się specyfikacja

Gdy implementacja staje się tania i szybka, wąskie gardło się przesuwa. Przestaje nim być pisanie, a zaczyna dokładna wiedza, o co się poprosiło. Rozwój sterowany specyfikacją traktuje specyfikację jako artefakt główny — wersjonowany, recenzowany, wykonywalny przez testy — a implementację pozwala wyprodukować agentom.

  • Specyfikacje na tyle precyzyjne, żeby z nich budować. Napisane tak, że kompetentny agent albo nowy inżynier wyprodukuje z nich to samo.
  • Przegląd tam, gdzie zapadają decyzje. Inżynierowie recenzujący intencję i kryteria akceptacji, a nie przeglądający pobieżnie wielkie wygenerowane diffy — bo to tam przegląd naprawdę się załamuje.
  • Testy wyprowadzone ze specyfikacji. Kryteria akceptacji wyrażone jako wykonywalne testy, żeby specyfikacja była sprawdzalna, a nie aspiracyjna.
  • Potok, który prowadzi Wasz zespół. Ustawiony w Waszych repozytoriach i CI, z zabezpieczeniami i bramkami przeglądu czyniącymi generowany kod bezpiecznym do scalenia.
Porozmawiajmy o tym

Co przekazujemy

  • Format specyfikacji

    Struktura działająca w Waszej dziedzinie: intencja, ograniczenia, kryteria akceptacji i to, co jawnie poza zakresem. Dość krótka, żeby ją przeczytać, i dość precyzyjna, żeby z niej zbudować.

  • Potok agentowy

    Generowanie, uruchamianie testów, iteracja i moment, w którym pyta się człowieka. Skonfigurowany w Waszym CI, a nie jako usługa prowadzona przez kogoś innego.

  • Zabezpieczenia

    Limity wielkości generowanych zmian, obszary kodu wyłączone, obowiązkowe ścieżki przeglądu przez człowieka i automatyczne odrzucanie wszystkiego, czego nie da się powiązać ze specyfikacją.

  • Strategia testów

    Testy akceptacyjne ze specyfikacji, testy własnościowe tam, gdzie pasują, i zestaw ewaluacyjny dla komponentów AI. Testy pisane niezależnie od implementacji, inaczej całość jest kołowa.

  • Praktyka przeglądu

    Czego recenzent naprawdę szuka w generowanym kodzie i jak utrzymać zdolność przeglądu jako wiążące ograniczenie — bo jeśli nim nie jest, gromadzi się kod niedoprzeglądany.

  • Uzdolnienie zespołu

    Wasi inżynierowie prowadzący tę metodę, z nazwanymi trybami porażki. To praktyka pracy, a nie narzędzie do zainstalowania.

Jak to przebiega

  1. 01

    Wybrać ograniczony obszar

    Dobrze rozumianą część kodu z dobrym pokryciem testami. Zaczynanie od obszaru najsłabiej rozumianego to sposób, w jaki zespoły dochodzą do wniosku, że metoda nie działa.

  2. 02

    Napisać specyfikacje porządnie

    Dwie albo trzy prawdziwe funkcje wyspecyfikowane z wymaganą precyzją. Większość zespołów odkrywa tutaj, że ich dotychczasowe zgłoszenia nie były nawet blisko specyfikacji.

  3. 03

    Uruchomić pętlę

    Generuj, testuj, recenzuj, iteruj — z otwarcie mierzonym poziomem błędów, żeby metodę oceniać na dowodach.

  4. 04

    Poszerzyć albo przerwać

    Rozszerzyć na większą część kodu, jeśli liczby na to pozwalają. Jeśli nie, to uprawniony wynik i lepiej wiedzieć go po czterech tygodniach niż po czterech kwartałach.

Dobre dopasowanie, gdy

  • Zespół już używa asystentów kodujących doraźnie, z niespójnymi wynikami.
  • Dobrze pokryty kod, w którym ograniczeniem jest specyfikacja, a nie pisanie.
  • Duże ilości podobnej pracy: integracje, adaptery, migracje, warstwa CRUD.
  • Chcecie, żeby metoda należała do Waszego zespołu, a nie do dostawcy.

To nie ta usługa, gdy

  • Małe albo żadne pokrycie testami. Generowany kod bez testów to nieweryfikowalne zobowiązanie — najpierw pokrycie.
  • Praca badawcza i eksploracyjna, gdzie specyfikacja powstaje dopiero po eksperymencie.
  • Oczekujecie, że to usunie potrzebę inżynierów. Przesuwa to, na co idzie ich czas; nie usuwa ich — a dostawca obiecujący inaczej sprzedaje co innego.

Najczęstsze pytania

Czy to naprawdę przyspiesza wytwarzanie?
Dla właściwego rodzaju pracy istotnie — implementacja przestaje być ograniczeniem. Dla pracy słabo wyspecyfikowanej albo naprawdę nowatorskiej bywa wolniej, bo napisanie precyzyjnej specyfikacji jest trudniejsze niż napisanie kodu. Wiedza, który to przypadek, jest większością wartości.
Jak zapobiegacie problemowi ilości?
Ograniczając wielkość generowanych zmian, wymagając powiązania każdej zmiany ze specyfikacją i traktując zdolność przeglądu jako ograniczenie, pod które wymiarujemy potok. Zespoły mierzące szybkość generowania i ignorujące szybkość przeglądu gromadzą dług, który przychodzi naraz.
Kto odpowiada za generowany kod?
Inżynier, który go zrecenzował i scalił, dokładnie jak przy każdej innej zmianie. To nie formalność — to powód, dla którego przeglądu nie wolno rozluźnić, niezależnie od przepustowości generowania.
Jacy agenci i jakie modele?
Takie, które sprawdzają się na Waszym kodzie, trzymane jako wymienialne. Liczy się metoda; narzędzia w tym obszarze zmieniają się co kilka miesięcy, a cokolwiek zbudowanego wokół jednego dostawcy trzeba będzie przebudować.
Czy możecie to ustawić i odejść?
Taki jest zamiar. Zwykle cztery do ośmiu tygodni na zbudowanie praktyki z Waszym zespołem, a potem jedno spotkanie po tym, jak z nią pożyją. Jeśli rok później nadal prowadzimy Wasz potok, ustawiliśmy go źle.

Czytaj dalej

Pozostałe usługi