Poprawki i dalsze prace przy kodzie tworzonym z pomocą AI

Nie myl poprawek kodu ze wskaźnikiem deployment rework w DORA

W aktualnych miarach dostarczania oprogramowania DORA deployment rework rate oznacza stosunek nieplanowanych wdrożeń wynikających z incydentu produkcyjnego do wszystkich wdrożeń. To konkretna miara po wdrożeniu. Poprawka po review, nieudanym teście lub zmianie projektu przed wydaniem nie staje się automatycznie przypadkiem tej miary. Zachowaj definicję i zakres DORA przy raportowaniu; szeroka liczba zmian kodu nie jest jej zamiennikiem.

Przykład ilustracyjny: bezpieczne ponawianie webhooka

Przykład ilustracyjny — nie są to dane klienta, telemetryka produktu ani wyniki badań. Agent proponuje logikę ponawiania wysyłki webhooka. Test pokazuje, że po przekroczeniu limitu czasu odbiorca mógł już przetworzyć zdarzenie, więc ponowienie może dostarczyć je drugi raz. Programista dodaje klucz idempotencji, aktualizuje test i ponawia odpowiednie kontrole.

Dostępne zapisy mogą pokazać, że implementację zmieniono po ujawnieniu przypadku podwójnego dostarczenia i że poprawiona wersja przeszła ten test. Nie dowodzą, że AI spowodowała słabość, że zmiana była możliwa do uniknięcia, że nakład pracy był mniejszy lub większy ani że produkcja zachowa się zawsze poprawnie. Zmianę wymuszoną nowym wymaganiem należy odróżnić od korekty względem pierwotnego wymagania.

Co zapisać, zanim zinterpretujesz sygnał poprawek

Określ analizowaną jednostkę, na przykład zmianę lub wdrożenie, stan pracy w chwili kolejnej czynności, dostępny wyzwalacz (review, test, zmiana wymagań lub incydent) oraz późniejszą decyzję, jeśli jest znana. Nieznany wyzwalacz pozostaw jako nieznany. Porównuj zapisy o tej samej definicji i zakresie: poprawka po code review i wdrożenie po incydencie to różne zdarzenia. Pytaj, co wywołało zmianę i jakie dowody pojawiły się później, nie traktując iteracji jako straty, werdyktu jakości ani miary produktywności.