Ulepszenia wydajności sztucznej inteligencji będą w dalszym ciągu poprawiać podstawowe wyniki pracy zespołu

W cyklu najnowszej wersji tempo dostaw nagle stało się bardzo napięte. Nie chodzi o to, że popyt gwałtownie wzrósł, ani że liczba pracowników spadła, ale o to, że dwie rzeczy nałożyły się na siebie: generowanie kodu i generowanie dokumentów stało się szybsze, ale przeglądanie i wspólne debugowanie nie stały się szybsze w tym samym czasie. W rezultacie podstawowe zadania są kompresowane w pierwszej połowie, złożone problemy koncentrują się w drugiej połowie, a okno wydania staje się bardziej prawdopodobne, że wymknie się spod kontroli.

Tę zmianę najłatwiej jest błędnie ocenić jako „normalny ból po poprawie wydajności”. Prawdziwy problem jest bardziej szczegółowy: domyślna podstawowa pojemność zespołu została przepisana, ale podział zadań, progi jakości i przydział odpowiedzialności są nadal w starej wersji.

Po przyspieszeniu podstawowych zadań punkt kolejkowy zostanie przesunięty do procesu decyzyjnego.

Po zaangażowaniu sztucznej inteligencji można szybko wygenerować przykładowy kod, hermetyzację interfejsu, wersje testowe i pierwsze wersje cotygodniowych raportów. Liczba kart „w toku” na planszy szybko opadła i przez pierwsze kilka dni panowało poczucie ulgi. Jednak na etapie wspólnego debugowania wąskie gardła będą skupiać się na trzech rodzajach ocen:

• Czy granica popytu jest nadal spójna po wielu rundach zmian?
• Czy ukryte założenia wygenerowanego kodu są sprzeczne z ograniczeniami istniejącej sieci
• Kiedy wiele modułów jest modyfikowanych w tym samym czasie, kto jest odpowiedzialny za ostateczne zachowanie?

Tych trzech typów problemów nie da się rozwiązać poprzez dalsze przyspieszanie. Wymagają konsensusu między rolami, wymagają ciągłości kontekstowej i wymagają jednolitego zrozumienia kosztów niepowodzenia. Z tego powodu czas zaoszczędzony w pierwszej połowie jest często pochłaniany przez wycofanie lub dwie rundy przeróbek w drugiej połowie.

Po zwiększeniu ciśnienia tłoczenia pierwszą rzeczą, która zawodzi, jest stara definicja ukończenia.

W przeszłości definicja wykonania brzmiała zazwyczaj: „funkcja dostępna + zaliczone testy + ukończona dokumentacja”. W miarę przyspieszania sztucznej inteligencji definicja ta stanie się zbyt luźna. Zatwierdzenie, które wygląda na kompletne, może po prostu „uruchomić” bez odpowiedzi na kluczowe pytania:

• Czy można zaobserwować ścieżkę awarii
• Czy można wycofać wyjątki w skali szarości
• Czy automatycznie wygenerowana część może zostać zachowana podczas następnej zmiany

Jeśli definicja wykonania nie zostanie poprawiona, zespół będzie miał złudzenie tempa: wyższy pozorny wskaźnik ukończenia i niższy rzeczywisty wskaźnik możliwego do wykonania. Najbardziej typowym zjawiskiem na tym etapie jest to, że dane ze stand-upu są bardzo dobre, ale podczas nocy premiery pojawia się wiele problemów.

Mechanizm przeglądu należy rozszerzyć z przeglądu kodu na przegląd hipotez

Na tym etapie przegląd czystego kodu nie wystarczy. Wygenerowany kod jest często poprawny gramatycznie i kompletny strukturalnie, a problemy często kryją się w założeniach. Na przykład domyślna strategia ponawiania prób, domyślny limit czasu i domyślna ścieżka zmiany wersji wydają się rozsądne, ale po wprowadzeniu do bieżącego systemu mogą po prostu trafić w słaby punkt.

Skuteczny przegląd musi jasno określić, „od jakich warunków wstępnych zależy ta zmiana”. Im jaśniejsze założenie, tym stabilniejsze będzie późniejsze wspólne debugowanie. W rzeczywistej implementacji rejestrowanie trzech rodzajów informacji może znacznie ograniczyć liczbę przeróbek:

1. Kluczowe założenia (od jakich warunków zewnętrznych to zależy)
2. Sygnał niepowodzenia (jakie zjawisko świadczy o tym, że hipoteza została złamana)
3. Akcja wycofania (kto będzie obsługiwał sygnał i po jakim czasie od jego wystąpienia)

Nie ma to na celu zwiększenia obciążenia procesu, ale przekształcenie ukrytych ocen pierwotnie ukrytych w zapisach czatu w wyraźne ograniczenia, nad którymi można wcześniej współpracować.

Poprawa wydajności AI nie spowoduje automatycznego zmniejszenia ciśnienia, zmieni rozkład ciśnienia

Sądząc po wynikach inżynierii, ciśnienie nie zniknęło, ale przeniosło się z „prędkości wyjściowej” do „jakości konwergencji”. Kto szybciej odkryje błędne założenia, zbiegnie różnice między modułami i ustabilizuje ścieżki awarii, będzie w stanie utrzymać stabilne dostarczanie w nowym rytmie.

Zatem tym, co zespół naprawdę musi ulepszyć, nie jest technika słowa wskazówki, ale sam system dostarczania: nowa definicja wykonania, lista możliwych do sprawdzenia założeń i dyscyplina wydawnicza ze wspólnym rozumieniem kosztów wycofywania zmian. Im bardziej zautomatyzowane jest podstawowe wyjście, tym wyższa wartość tych trzech rzeczy.