Cognition stawia na to, że testy Devin GPT-6 Astra mogą zastąpić przegląd kodu dowodami
Cognition rozszerzyło testowanie Devin GPT-6 Astra na trzy produkty, czyniąc weryfikację najnowszym polem rywalizacji w autonomicznej inżynierii oprogramowania. Model obsługuje teraz testowanie w Devin Cloud, Devin Desktop i Devin CLI. Może obsługiwać aplikacje, analizować wyniki oraz zwracać dowody wizualne wraz z pisemnymi raportami.
Istotna zmiana nie polega na tym, że Devin może generować więcej kodu. Agenci programistyczni już tworzą poprawki, otwierają pull requesty i uruchamiają zestawy testów. Cognition chce teraz, aby Devin przedstawiał dowody, że jego zmiany działają, ograniczając zakres kodu wygenerowanego przez AI, który inżynierowie muszą ręcznie sprawdzać.
Ta obietnica wywiera presję na tradycyjny rozwój oprogramowania oparty przede wszystkim na przeglądzie kodu. Rodzi też trudne pytanie dla Cognition, OpenAI i każdego konkurencyjnego agenta programistycznego. Czy agent może wiarygodnie oceniać pracę wytworzoną przez ten sam zautomatyzowany system, czy też ludzka uwaga jedynie przenosi się z przeglądu kodu na przegląd dowodów?
Testowanie Devin GPT-6 Astra tworzy teraz dowody możliwe do oceny
Cognition pozycjonuje dowody testowe, a nie wyłącznie generowanie kodu, jako rezultat, który powinni oceniać inżynierowie.
OpenAI opublikowało swój przypadek testowania Devin 11 września 2026 r. Firma twierdzi, że Cognition stosuje GPT-6 Astra w swoim agencie chmurowym, interfejsie wiersza poleceń i aplikacji desktopowej.
Cognition dodało już Astra do Devin 3 września. Jego wdrożenie modelu informuje, że Astra jest dostępna bezpośrednio w Devin Desktop i Devin CLI. Model stanowi również część mieszanki modeli wykorzystywanej przez Devin Cloud.
Integracja rozdziela dwa zadania, które produkty do programowania często przedstawiają jako jeden ciągły proces. Jeden model może wdrażać zmianę, podczas gdy Astra może wspierać etap testowania. To rozróżnienie ma znaczenie, ponieważ edytowanie kodu i walidowanie aplikacji wymagają różnych umiejętności.
Model programistyczny koncentruje się przede wszystkim na repozytoriach, specyfikacjach i zmianach w kodzie źródłowym. Tester aplikacji musi także interpretować ekrany, śledzić stan interfejsu, obsługiwać oprogramowanie i rozpoznawać, czy obserwowane zachowanie odpowiada zamierzonemu rezultatowi.
Cognition twierdzi, że Astra szczególnie dobrze radzi sobie z tą drugą grupą zadań. Firma raportuje wyniki na poziomie state of the art w wewnętrznym benchmarku testowania. Nie opublikowała jednak wystarczających szczegółów, aby osoby z zewnątrz mogły odtworzyć lub niezależnie zweryfikować ten konkretny wynik.
Publiczne przykłady wyjaśniają, co Cognition rozumie przez autonomiczną weryfikację. W jednej demonstracji Devin testuje Otter Run, grę na iPhone’a, w symulatorze. Zwraca nagranie działającej gry oraz raport opisujący, które kontrole zakończyły się powodzeniem.
Raport wskazuje również obszary, których Devin nie testował. To zastrzeżenie jest ważne, ponieważ dopracowany materiał wideo mógłby inaczej sugerować szerszy zakres pokrycia, niż faktycznie osiągnięto podczas uruchomienia.
Nagranie pokazuje obserwowalne zachowanie, a raport określa deklarowany zakres. Razem dają recenzentowi coś bliższego artefaktowi testowemu niż typowemu podsumowaniu agenta.
Inny proces zaczyna się od dostarczonego przez klienta zrzutu ekranu z błędem. Cognition twierdzi, że zespół może wysłać ten obraz do Devin, który diagnozuje problem, zmienia kod i zwraca kolejny zrzut ekranu pokazujący rezultat.
Ta sekwencja łączy widoczną usterkę z widocznym wynikiem. Może skrócić pętlę informacji zwrotnej dla problemów z interfejsem, które trudno wyjaśnić wyłącznie za pomocą logów lub komentarzy w pull requestach.
Zrzut ekranu dowodzi jednak tylko tego, co pojawiło się w jednym momencie. Nie potwierdza, że powiązane ścieżki nadal działają, że podstawowa implementacja jest łatwa w utrzymaniu ani że usterka pozostanie naprawiona w innych warunkach.
Dlatego bardziej użyteczną funkcją jest pakiet dowodowy. Inżynierowie mogą porównać wymagane zachowanie, zadeklarowany plan testów, zarejestrowane działania oraz wszelkie nieprzetestowane obszary przed podjęciem decyzji o scaleniu.
Zmienia to jednostkę przeglądu. Zamiast otrzymywać tylko diff i zapewnienie napisane przez agenta, inżynier otrzymuje twierdzenie poparte śladem wykonania.
Ta zmiana tworzy centralny zakład Cognition. Jeśli recenzenci zaufają śladowi, mogą poświęcać mniej czasu na odtwarzanie tego, co się wydarzyło, na podstawie wygenerowanego kodu. Jeśli nie, dodatkowe artefakty staną się kolejną warstwą wymagającą kontroli.
Dlaczego weryfikacja stała się wąskim gardłem agentów programistycznych
Czynnikiem ograniczającym w agentowym tworzeniu oprogramowania przesuwa się z produkcji kodu do zdolności wiarygodnej weryfikacji.
Agenci programistyczni mogą tworzyć zmiany szybciej, niż większość zespołów jest w stanie je ocenić. Gdy kilka agentów działa równolegle, każda udana sesja może wygenerować kolejną gałąź, pull request, raport testowy lub decyzję następczą.
Cognition twierdzi, że jego inżynierowie uruchamiali równolegle od 10 do 20 sesji Devin. Każda sesja może obsługiwać osobny serwer deweloperski w chmurze. Taki poziom współbieżności byłby niewygodny na laptopie jednego inżyniera.
Większa współbieżność nie tworzy automatycznie większej wartości produkcyjnej. Może zamiast tego generować kolejkę wiarygodnie wyglądających zmian oczekujących na ludzką weryfikację.
Ta kolejka jest szczególnie trudna, ponieważ wygenerowany kod może wyglądać rozsądnie, zanim zawiedzie podczas wykonania. Recenzent może potrzebować odtworzyć środowisko, uruchomić aplikację, powtórzyć zgłoszony przepływ i sprawdzić zachowanie w sąsiednich obszarach.
Cognition opisywało to wyzwanie jako część szerszego przejścia w stronę asynchronicznego rozwoju oprogramowania. Więcej sesji Devin jest obecnie uruchamianych przez harmonogramy, automatyzacje, zdarzenia i inne instancje Devin niż przez bezpośrednie interaktywne zapytania.
Asynchroniczny agent programistyczny pracuje, gdy jego ludzki właściciel zajmuje się czymś innym. Taki układ oszczędza uwagę tylko wtedy, gdy zwrócony wynik jest zrozumiały i wystarczająco wiarygodny.
Bez weryfikacji inżynierowie wracają do stosu niewyjaśnionych diffów. Muszą odtworzyć kontekst każdego zadania, zanim zdecydują, czy wykonana praca jest przydatna.
Wcześniejszy opis weryfikacji agentów autorstwa Cognition mówi, że liczba zatwierdzonych codziennych uruchomień testów wzrosła ponad dwukrotnie w ciągu kilku miesięcy. Jest to raportowana przez firmę aktywność produktu, a nie niezależna miara niezawodności lub wartości dla klientów.
Mimo to kierunek ma sens. W miarę jak agenci generują więcej zmian, zespoły potrzebują zwięzłych dowodów wskazujących, które wyniki zasługują na uwagę.
Celem nie jest natychmiastowe wyeliminowanie ludzkiego osądu. Chodzi o obniżenie jego kosztu poprzez przybliżenie istotnych obserwacji do ukończonego zadania.
Użyteczny pakiet dowodowy może odpowiedzieć na kilka pytań, zanim inżynier przeczyta implementację. Czy aplikacja uruchomiła się poprawnie? Czy zmieniona funkcja się pojawiła? Którą ścieżkę użytkownika agent przetestował? Co pozostało poza testem?
Te pytania są często bardziej wartościowe niż deklaracja agenta, że wszystkie testy zakończyły się powodzeniem. Konwencjonalny zestaw testów ocenia wyłącznie asercje, które ktoś wcześniej przewidział i zakodował.
Nagrania interfejsu mogą ujawnić zmiany stanu, które nigdy nie zostały uwzględnione w testach jednostkowych. Pisemne notatki dotyczące zakresu mogą również ujawnić braki w pokryciu zamiast ukrywać je w długim dzienniku wykonania.
Presja wykracza poza Cognition. Codex od OpenAI, wspierane przez Anthropic systemy programistyczne, agenci deweloperscy Google, Cursor oraz frameworki open source konkurują o obciążenia inżynieryjne.
Każdy produkt może poprawiać swój wynik w generowaniu kodu. Jednak wdrożenie w przedsiębiorstwach zależy od tego, co dzieje się po wygenerowaniu, gdy osoba ponosząca odpowiedzialność musi zatwierdzić istotną zmianę.
Dlatego głównym przeciwnikiem nie jest jeden rywalizujący model. Jest nim proces oparty przede wszystkim na przeglądzie kodu, zbudowany wokół czytania każdej istotnej linii przed zaufaniem wynikowi.
Ten proces istnieje z ważnych powodów. Kod komunikuje architekturę, przyszłe koszty utrzymania, założenia bezpieczeństwa i zachowanie w przypadku awarii, których krótka demonstracja może nigdy nie ujawnić.
Cognition nie twierdzi, że te kwestie znikają. Jego deklarowanym celem jest sprawienie, by inżynierowie z czasem analizowali mniej kodu, jednocześnie dostarczając więcej ukończonej pracy.
To sformułowanie pozostawia miejsce na selektywny przegląd. Zespoły mogą dokładnie analizować moduły wysokiego ryzyka, jednocześnie akceptując przegląd oparty na dowodach w przypadku wąskich poprawek interfejsu, rutynowych migracji lub dobrze ograniczonych narzędzi wewnętrznych.
Praktyczny efekt będzie zależał od tego, jak dobrze zespoły zachowają kontekst zadania. Baza wiedzy dla zespołów inżynierskich może pomóc recenzentom połączyć dowody agenta z wymaganiami, decyzjami projektowymi i wcześniejszymi awariami.
Weryfikacja staje się bardziej wartościowa, gdy odzwierciedla te źródła. Czyste nagranie znaczy mniej, jeśli agent błędnie zrozumiał wymaganie definiujące sukces.
Astra przekształca testowanie w odrębną umiejętność agenta
Wkład Astry wynika z połączenia obsługi komputera, oceny wizualnej, rozumowania o bazie kodu i zwięzłego raportowania w jednej pętli testowej.
Model do obsługi komputera interpretuje wizualny interfejs i wykonuje działania takie jak klikanie, wpisywanie, przewijanie oraz przechodzenie między ekranami. Testowanie wprowadza dodatkowy wymóg: działania te muszą wspierać jednoznaczne asercje dotyczące oczekiwanego zachowania.
Pętla testowa Cognition zaczyna się od planu opartego na repozytorium. Agent analizuje odpowiedni kod, zanim zadeklaruje, co będzie testował. Ogranicza to ryzyko, że wymyśli ścieżki interfejsu lub założenia niepoparte przez aplikację.
Plan tworzy również punkt odniesienia dla końcowego raportu. Recenzenci mogą sprawdzić, czy uruchomienie objęło zamierzone zachowanie, zamiast oceniać nagranie bez określonych kryteriów.
Podczas wykonania Devin może opatrywać oś czasu notatkami przygotowawczymi i nazwanymi etapami testu. Może oznaczać asercje jako zaliczone, nieudane lub nieprzetestowane.
Cognition twierdzi, że wymaganie od agenta określenia oczekiwania przed działaniem ogranicza racjonalizowanie wyników. Agent ma mniej swobody, by po zobaczeniu rezultatu reinterpretować nieoczekiwany ekran jako sukces.
Przypomina to rozwój sterowany testami, w którym oczekiwane zachowanie definiuje się przed implementacją. Tutaj zobowiązanie powstaje podczas weryfikacji zachowania, a nie przed każdą zmianą w kodzie.
Agent może następnie obsługiwać przeglądarkę, symulator lub aplikację desktopową. Rejestruje przebieg i zwraca artefakty, które człowiek może sprawdzić asynchronicznie.
Astra wydaje się dobrze dopasowana do tego etapu, ponieważ model został wytrenowany do obsługi komputera oraz długich, wieloetapowych zadań profesjonalnych. OpenAI twierdzi, że może instalować oprogramowanie, rozwiązywać widoczne problemy i przeprowadzać kontrole jakości frontendów.
W opublikowanych przez OpenAI wynikach obsługi komputera Astra uzyskała 72,6 procent w OSWorld 2.0. GPT-5.6 Sol uzyskał 65,7 procent w przedstawionym porównaniu.
OpenAI twierdzi również, że Astra realizowała te symulowane zadania średnio w około 40 minut. Wcześniejszy model potrzebował około 75 minut. Liczby te pochodzą z konfiguracji ewaluacyjnej OpenAI i nie powinny być traktowane jako uniwersalne miary środowiska produkcyjnego.
To samo wydanie podaje wynik Astry na poziomie 57,9 procent w Terminal-Bench 4.0. GPT-5.6 Sol uzyskał 37,3 procent, podczas gdy Claude Fable 5.1 otrzymał 55,8 procent.
W FrontierCode 1.1 Extended Astra uzyskała 64,5 procent. Claude Fable 5 uzyskał 64,9 procent, co pozostawiło Astrę nieznacznie za tym modelem w benchmarku Cognition.
Cognition opisuje FrontierCode jako własną ewaluację rzeczywistych zadań inżynieryjnych. Punktacja uwzględnia jakość i możliwość scalenia, a rozwiązania niespełniające kryteriów blokujących nie otrzymują punktów.
Te porównania sugerują, że atrakcyjność Astry nie wynika wyłącznie z wyższej surowej wydajności programistycznej. Publiczne stanowisko Cognition podkreśla czytelniejsze raporty, bardziej kompleksowe testy oraz łatwiejsze do śledzenia nagrania wideo.
Te cechy bezpośrednio wpływają na czas przeglądu. Technicznie udane uruchomienie nadal może marnować ludzką uwagę, jeśli przedstawione dowody są mylące, rozwlekłe lub oderwane od żądanej zmiany.
Zwięzły raport powinien wskazywać testowane zachowanie, środowisko, zaobserwowany wynik i pozostałą niepewność. Przydatne nagranie powinno ułatwiać znalezienie istotnych przejść, zamiast zmuszać recenzenta do oglądania nieedytowanej sesji.
Cognition stworzyło również deterministyczne skrypty do powtarzalnych zadań konfiguracyjnych. Skrypt deterministyczny wykonuje określoną sekwencję, zamiast prosić model o improwizowanie każdej czynności.
Jednym z przykładów jest uwierzytelnianie. Przechodzenie przez proces logowania na podstawie zrzutów ekranu może pochłaniać czas i wprowadzać błędy niezwiązane z testowaną funkcją.
Zapisany skrypt może szybko utworzyć uwierzytelnioną sesję przeglądarki. Agent może wtedy skupić rozumowanie na zachowaniu, które ma znaczenie.
Ta hybrydowa architektura ujawnia ważną lekcję inżynierską. Lepsze autonomiczne testowanie nie oznacza powierzania każdej operacji modelowi językowemu.
Niezawodne systemy rezerwują przewidywalne kroki dla konwencjonalnej automatyzacji. Wykorzystują model tam, gdzie wartość dodają interpretacja, odzyskiwanie sprawności lub elastyczna nawigacja.
Cognition pozwala również Devin proponować wielokrotnego użytku umiejętności testowe po rozwiązaniu trudnego problemu konfiguracyjnego. Użytkownik może przejrzeć tę automatyzację przed dodaniem jej do repozytorium.
Z czasem może to przekształcić powtarzające się odkrycia w stabilną infrastrukturę. Improwizowana ścieżka modelu staje się sprawdzonym skryptem dla przyszłych uruchomień.
To połączenie ogranicza również zmienność. Jeśli każdy test rozpoczyna się od innego zachowania konfiguracji, porównywanie wyników staje się trudne, a diagnozowanie błędów kosztowne.
Astra zapewnia elastyczne postrzeganie i rozumowanie. Deterministyczne skrypty ograniczają powtarzalne działania. Plan testów definiuje sukces, a raport dowodowy pokazuje, co objęło uruchomienie.
Mechanizm ten ma większe znaczenie niż kolejna przewaga w benchmarku. Pokazuje, jak agenci programistyczni mogą przejść od tworzenia wiarygodnie wyglądających poprawek do uczestnictwa w kontrolowanych przepływach pracy inżynierskiej.
Agent Nadal Nie Może Samodzielnie Ocenić Własnej Pracy Domowej
Dowody mogą ograniczyć wysiłek potrzebny do przeglądu, ale nie mogą uczynić samoweryfikacji niezależną, kompletną ani automatycznie godną zaufania.
Najbardziej oczywistym ryzykiem jest skorelowana porażka. Jeśli agent błędnie zrozumie zadanie podczas implementacji, ten sam system może przenieść to niezrozumienie do swojego planu testów.
Kod i test mogą wtedy być ze sobą zgodne, choć oba będą sprzeczne z rzeczywistym wymaganiem użytkownika. Czysty raport dokumentowałby spójność, a nie poprawność.
Niezależne testy ograniczają ten problem, gdy wynikają ze specyfikacji, pracy innego inżyniera lub oddzielnego systemu ewaluacyjnego. Istniejące pakiety testów regresyjnych również zapewniają ograniczenia, których agent implementujący nie wymyślił w trakcie sesji.
Podejście Cognition pomaga, opierając plany na kodzie źródłowym i określając oczekiwania przed każdym działaniem. Te środki mogą ograniczyć odchylenia, lecz nie tworzą prawdziwej niezależności.
Firma otwarcie opisywała wcześniejsze niepowodzenia. Devin czasami testował niepowiązane obszary, grzązł w konfiguracji środowiska lub pomijał zachowanie, które pull request miał zmienić.
Problemy te wyjaśniają, dlaczego system potrzebuje planów, adnotacji i deterministycznych narzędzi konfiguracyjnych. Pokazują również, że dopracowane dowody zależą od orkiestracji wykraczającej poza bazowy model.
Dowody wizualne mają dodatkowe ograniczenia. Wideo może pokazać, że jeden przepływ zadziałał w jednym środowisku i przy jednym stanie danych. Nie może potwierdzić szerokiej poprawności w różnych przeglądarkach, uprawnieniach, warunkach obciążenia ani wobec złośliwych danych wejściowych.
Raport może trafnie oznaczać te luki jako nieprzetestowane. Recenzenci nadal muszą zdecydować, czy pominięte ścieżki są na tyle istotne, by zablokować wdrożenie.
Pokrycie testowe staje się szczególnie ważne przy zmianach backendu, infrastruktury i bezpieczeństwa. Wiele poważnych błędów nie daje oczywistego wizualnego objawu podczas krótkiego uruchomienia.
Migracja bazy danych może pozornie zakończyć się sukcesem, zanim uszkodzi przypadek brzegowy. Zmiana uprawnień może działać dla zaprezentowanego konta, jednocześnie ujawniając dane innego najemcy.
Kod wrażliwy na bezpieczeństwo wymaga myślenia adversarialnego, a nie jedynie potwierdzenia wystąpienia oczekiwanego zachowania. Zespoły potrzebują testów zaprojektowanych tak, by podważały założenia, zamiast odtwarzać szczęśliwą ścieżkę.
OpenAI samo stosuje ograniczenia wobec zaawansowanych możliwości Astry w zakresie cyberbezpieczeństwa. Model może pomagać w bezpiecznym przeglądzie i tworzeniu poprawek, podczas gdy niektóre procesy związane z exploitami pozostają ograniczone lub monitorowane.
Niezależne relacje o premierze Astry zwracały również uwagę na nierozwiązane kwestie bezpieczeństwa związane ze złożoną pracą autonomiczną. Niezawodność w rzeczywistych warunkach pozostaje mniej pewna, niż sugerują kontrolowane demonstracje.
Jakość oprogramowania stanowi wyzwanie długoterminowe. Przejście dzisiejszych testów nie pokazuje, czy powtarzające się zmiany wprowadzane przez agentów pozostawiają kod zrozumiały i łatwy do adaptacji.
Krytyczna analiza ograniczeń benchmarków programistycznych wskazuje, że obecne testy często pomijają erozję strukturalną. Kod może pozostać funkcjonalny, jednocześnie stając się trudniejszy do bezpiecznej modyfikacji.
Ta obawa bezpośrednio ogranicza propozycję „przeglądania mniejszej ilości kodu”. Inżynierowie czytają kod nie tylko dla natychmiastowej poprawności. Analizują abstrakcje, granice odpowiedzialności, powieloną logikę, obserwowalność i przyszły koszt utrzymania.
Wideo z wykonania nie może ujawnić wszystkich tych cech. Nie zrobi tego również raport skupiony na widocznym zachowaniu.
Właściwa polityka przeglądu będzie prawdopodobnie zależała od ryzyka. Wizualna korekta w wewnętrznym panelu wymaga innego poziomu kontroli niż logika uwierzytelniania, przetwarzanie płatności czy infrastruktura krytyczna dla bezpieczeństwa.
Zespoły mogą definiować bramki scalania, które łączą rodzaje dowodów. Zmiana niskiego ryzyka może wymagać zaliczonego pakietu testów, nagranego przepływu użytkownika i kompletnego raportu zakresu.
Zmiana wyższego ryzyka może dodatkowo wymagać przeglądu projektu przez człowieka, niezależnych testów bezpieczeństwa oraz ręcznej inspekcji wrażliwych plików. Dowody agenta mogą wspierać te kontrole, nie zastępując ich.
Kolejną kwestią jest integralność dowodów. Recenzenci potrzebują pewności, że nagrania odpowiadają zgłoszonemu commitowi, środowisku, konfiguracji i danym testowym.
Jeśli artefakty mogą zostać odłączone od dokładnego kodu podlegającego przeglądowi, mogą opisywać wcześniejszy lub inaczej skonfigurowany build. Silne pochodzenie powinno łączyć każde twierdzenie z jego stanem wykonania.
Cognition nie opisało publicznie szczegółowo wszystkich mechanizmów pochodzenia stojących za wyróżnionym przepływem pracy. Jego wewnętrzny benchmark pozostaje również zastrzeżony, co ogranicza porównania między niezależnymi laboratoriami.
Twierdzenie dotyczące benchmarku należy więc odczytywać jako sygnał produktowy, a nie rozstrzygającą miarę jakości autonomicznego testowania.
Nawet publiczne wyniki OpenAI mierzą zadania o ograniczonym zakresie. Repozytoria produkcyjne zawierają nieudokumentowane założenia, niestabilne zależności, prywatne usługi i reguły wydawania specyficzne dla organizacji.
Astra może poprawić zdolność agenta do poruszania się w tej złożoności. Nie eliminuje potrzeby inżynierskiego osądu dotyczącego tego, jakie dowody są wystarczające.
Kluczowe rozróżnienie dotyczy dowodu i przesłanek. W zwykłej praktyce tworzenia oprogramowania testowanie dostarcza przesłanek, że wybrane zachowania działały w określonych warunkach.
Rzadko dowodzi całkowitej poprawności. Publiczny język Cognition czasami używa słowa „udowodnić” w znaczeniu potocznym, lecz zespoły powinny zachować węższą interpretację inżynierską.
Ta ostrożność nie czyni funkcji mniej ważną. Definiuje, gdzie może ona tworzyć wartość, nie zachęcając do niebezpiecznego zaufania.
Trzy Sygnały Pokażą, Czy Inżynierowie Mogą Przeglądać Mniej Kodu
Kolejnym testem będzie to, czy Cognition potrafi przełożyć silniejsze demonstracje na mierzalne, uwzględniające ryzyko wdrożenie w zespołach produkcyjnych.
Pierwszym sygnałem jest niezależna odtwarzalność. Cognition powinno opublikować wystarczająco dużo szczegółów o swoim benchmarku testowym, aby osoby z zewnątrz mogły zrozumieć wybór zadań, punktację, kierowanie modeli i obsługę błędów.
Odtwarzalne wyniki wzmocniłyby twierdzenie, że Astra poprawia testowanie, zamiast jedynie tworzyć lepiej wyglądające artefakty. Pokazałyby również, jak często system uczciwie zgłasza błąd lub niepełne pokrycie.
Jakość dowodów musi być oceniana niezależnie od ukończenia zadania. Agent testujący może osiągnąć właściwy wynik, jednocześnie dostarczając bezużyteczny raport, albo stworzyć przekonującą dokumentację dla niekompletnego testu.
Przydatne miary mogłyby obejmować dokładność twierdzeń, pominięte defekty, fałszywe zaliczenia, kalibrację pokrycia i czas recenzenta. Powinny także śledzić, czy recenzenci podejmują właściwą decyzję o scaleniu.
Jeśli niezależne ewaluacje potwierdzą poprawę w tych wymiarach, przepływ pracy Cognition z ograniczonym przeglądem zyska wiarygodność. Jeśli wyniki będą wyraźnie różnić się między repozytoriami, zespoły będą potrzebowały węższych zasad wdrożenia.
Drugim sygnałem jest zachowanie w środowisku produkcyjnym. Cognition twierdzi, że liczba codziennych zatwierdzonych uruchomień testów wzrosła, ale sama liczba zatwierdzeń nie dowodzi lepszego oprogramowania ani niższego kosztu przeglądu.
Silniejszymi wskaźnikami są scalone zmiany, wskaźniki defektów, które przedostały się do produkcji, częstotliwość wycofań oraz czas poświęcony na przegląd każdej zaakceptowanej kontrybucji. Zespoły powinny porównywać te wyniki z podobnymi zmianami obsługiwanymi w ramach konwencjonalnego przeglądu.
Cognition badało już „produktywne godziny inżynierskie” jako metrykę biznesową. Jego ewaluacja objęła 233 odłożone sesje i wykazała, że około połowa mieściła się w granicach dwukrotności ludzkich szacunków.
Firma przyznała również, że indywidualne szacunki pozostają obarczone szumem. Według opublikowanej analizy błędy dwu- lub trzykrotne w obu kierunkach są powszechne.
Ta szczerość ma znaczenie, ponieważ twierdzenia o produktywności mogą oderwać się od wyników oprogramowania. Szacunek zaoszczędzonych godzin nie uwzględnia kosztu defektu odkrytego po wdrożeniu.
Najbardziej przekonujące dowody połączyłyby skrócony czas przeglądu ze stabilną lub poprawiającą się jakością. Jeśli zespoły analizują mniej kodu, lecz doświadczają większej liczby regresji, przepływ pracy jedynie przenosi koszt na późniejszy etap.
Jeśli czas przeglądu spada bez pogorszenia liczby defektów, wycofań lub utrzymania, centralna teza Cognition staje się znacznie mocniejsza.
Trzecim sygnałem jest to, jak konkurenci przeprojektują weryfikację. Dostawcy modeli i firmy tworzące agentów programistycznych mogą odpowiedzieć niezależnymi agentami recenzującymi, silniejszymi śladami wykonania lub standaryzowanymi formatami dowodów.
Istotna reakcja konkurencyjna potwierdziłaby, że weryfikacja stała się główną warstwą produktu. Dałaby również kupującym alternatywy pozwalające uniknąć sytuacji, w której jeden agent ocenia własne wyniki.
Oddzielne modele implementacyjne i recenzujące mogą wprowadzić użyteczną różnorodność. Różni dostawcy, prompty lub systemy generowania testów rzadziej odtworzą dokładnie to samo nieporozumienie.
Sama różnorodność modeli nie gwarantuje jednak niezależności. Dwa agenty mogą nadal opierać się na tej samej niekompletnej specyfikacji lub istniejącym pakiecie testów.
Najlepsze systemy połączą niezależne projektowanie testów, deterministyczne kontrole, pochodzenie artefaktów i jawne polityki ryzyka. Przegląd przez człowieka będzie mógł wtedy koncentrować się na decyzjach, których automatyzacja nie może bezpiecznie skompresować.
Liderzy inżynierii powinni zacząć od wyboru ograniczonych zadań, w których obserwowalne zachowanie mocno odzwierciedla sukces. Sensownymi kandydatami są poprawki błędów interfejsu, rutynowe wewnętrzne przepływy pracy i dobrze określone regresje.
Powinni wymagać od Devin wskazania, czego nie przetestował. Powinni również porównywać jego dowody ze zgłoszonym commitem i zachowywać normalne kontrole dla wrażliwych zmian.
Programiści mogą wykorzystywać nowy przepływ pracy jako filtr uwagi, a nie źródło autorytetu. Raport wskazuje, gdzie patrzeć, nagranie pokazuje, co się wydarzyło, a kod pozostaje dostępny, gdy ryzyko wymaga inspekcji.
Rezultat, do którego dąży Cognition, jest możliwy, ale nie nastąpi automatycznie. Lepsze testowanie może zmniejszyć nakład pracy związany z przeglądem kodu tylko wtedy, gdy dowody pozostają oparte na faktach, mają jasno określony zakres i są powiązane z efektami na produkcji.
Najważniejsze pytanie dla zespołów ma więc charakter praktyczny: które zmiany można zatwierdzić na podstawie dowodów z wykonania, a które nadal wymagają przeczytania każdej istotnej linijki? Celowo sprawdźcie tę granicę, zanim uczynicie testowanie Devin GPT-6 Astra częścią domyślnego procesu scalania zmian.
