Narzędzia programistyczne AI rywalizują o wejście do przepływów pracy na poziomie komputerów stacjonarnych

W zeszłym tygodniu, po zmianie procesu regresji skali szarości strony środkowej z „przeglądarki skupionej na człowieku” na „ciągłe wykonywanie agenta”, pierwszym ujawnionym problemem nie było to, że model odpowiedział niepoprawnie, ale to, że łącze wykonania zostało zerwane na granicy pulpitu: stan logowania znajdował się w przeglądarce, polecenie budowania znajdowało się w terminalu, a zrzuty ekranu i adnotacje znajdowały się w innym narzędziu. Jeśli sesja zostałaby przeskoczona w jakimkolwiek kroku, kontekst musiałby zostać ponownie złożony.

Przed tą transformacją proces wydawał się bardzo zautomatyzowany: produkt CI uruchamiał środowisko podglądu, skrypt uruchamiał przypadek użycia ścieżki głównej, a następnie strona wyjątku była wysyłana do ręcznego przeglądu. To, co naprawdę utrudnia efektywność, to faza wykańczania. W przypadku problemów, takich jak przemieszczenie strony, wahania stylu i nieprawidłowy stan komponentów, „bieżący model DOM, żądania sieciowe, błędy konsoli i kroki interaktywne” muszą zostać umieszczone na tej samej osi czasu, aby możliwe było zbieżne rozwiązywanie problemów. Linia ta jest często przecinana podczas przełączania między wieloma narzędziami.

Po zmianie na pojedynczą sesję agenta łańcuch wykonania składał się z trzech etapów: najpierw użyj lokalnych poleceń, aby pobrać podgląd i próbne dane, następnie steruj przeglądarką, aby odtworzyła ścieżkę w tej samej sesji, a na koniec bezpośrednio zapisz łatkę naprawczą i wywołaj minimalną regresję. Sam model nie stał się nagle mądrzejszy, ale znacznie poprawiła się szybkość lokalizacji problemu, a powód jest prosty: kontekst nie opuszcza powierzchni wykonawczej.

Konkretne korzyści znajdują odzwierciedlenie w trzech miejscach.

Po pierwsze, ciągłość stanu. W przeszłości, gdy odtwarzałem defekt frontonu, nazwa pliku zrzutu ekranu, dziennik terminala i różnica kodu były rozproszone w różnych oknach, a znaczniki czasu musiały być wielokrotnie dopasowywane podczas rozwiązywania problemów. Teraz rozmowa w naturalny sposób niesie ze sobą polecenia, operacje na stronach i sekwencję modyfikacji kodu, a nieprawidłowość zmieniła się z „problemu ze zbieraniem informacji” na „problem z oceną”.

Po drugie, niepowodzenie można powtórzyć. Najbardziej kłopotliwą rzeczą w tradycyjnej automatyce jest to, że „czasami pojawia się raz i znika”. Wykonanie pojedynczej sesji zachowuje pełną sekwencję działań, a te same dane wejściowe można uruchomić ponownie lokalnie, minimalizując koszty powtarzania. W przypadku typowych błędów front-endu, takich jak konkurencja w animacjach, drgania nawodnienia pierwszego ekranu i nieprawidłowe ustawienie czasu, funkcja ta jest cenniejsza niż dodatkowy wynik testu porównawczego.

Trzecim jest redukcja kosztów utrzymania. W przeszłości za każdym razem, gdy dodano narzędzie, trzeba było zachować warstwę kodu klejącego: uwierzytelnianie, mapowanie parametrów, format dziennika i ponowne próby niepowodzenia. Wykonanie w trakcie sesji usuwa część tego kleju, a zespół skupia się z „okablowania przewodów” z powrotem na „definiowaniu kryteriów kontroli”. Jest to również powód, dla którego wiele produktów do programowania AI rywalizuje ostatnio o wejście na komputery stacjonarne: po uzyskaniu dostępu kolejne możliwości mogą w naturalny sposób przepełnić łańcuch wykonawczy.

Ta ścieżka nie oznacza, że ​​zespół front-endowy może porzucić istniejący system inżynieryjny. Obydwa typy scenariuszy nadal nie nadają się do pozostawienia wyłącznie Agentowi. Pierwszą kategorią są strony, na których ocena marki i projektu w dużym stopniu opiera się na ręcznej ocenie. Automatyczne wykonanie może przeprowadzić wstępną selekcję, ale nie może zastąpić ostatecznej recenzji. Druga kategoria to środowisko korporacyjne ze złożonymi granicami uprawnień. Jeśli agent stacjonarny nie może uzyskać minimalnego modelu autoryzacji, wzrost wydajności zostanie zrównoważony kosztem audytów bezpieczeństwa.

Nieporozumieniem godnym naprawdę uwagi jest postrzeganie tej fali zmian jako przedłużenia „wojny modelowej”. Bardziej krytycznym aspektem rywalizacji w przepływie pracy front-endu stało się: kto może stabilnie przejąć lokalne wykonanie, kontrolę przeglądarki, pamięć kontekstową i łącza do odtwarzania. Luka w parametrach zostanie szybko zamknięta, a po utworzeniu łącza wykonawczego koszt migracji będzie coraz wyższy.

Taki jest również wniosek płynący z tej rundy praktyk: wejście na poziom komputera stacjonarnego nie jest wisienką na torcie, lecz staje się głównym polem bitwy narzędzi programowania AI. Gdy problemy front-endowe wymagają ciągłej konwergencji między wierszami poleceń, przeglądarkami i repozytoriami kodu, ktokolwiek opanuje to łącze, opanuje prawdziwą wydajność.