Ewaluacja agentów kodujących na zmianach, które zostały już zmergowane

Uruchomienie określają trzy rzeczy: narzędzie, model, z którego korzysta, i sposób ich konfiguracji. Zapisujemy wszystkie trzy. Jeśli narzędzie to umożliwia, zmieniamy za każdym razem tylko jedną z nich.

Do tego dochodzą liczby ponowień, revertów, poprawek i uwag z review. Wyniki przedstawiamy oddzielnie dla każdego typu zadania. Dzięki temu widać, kiedy jeden kandydat najlepiej radzi sobie z naprawianiem błędów, a inny z refaktoryzacją.

Kryteria akceptacji ustalamy z tobą, zanim cokolwiek zostanie uruchomione. Zmiana się liczy, jeśli przechodzi odłożone testy, nie wychodzi poza zakres zadania i recenzent mógłby ją zmergować w obecnej postaci. Nakład pracy przy review mierzymy jako czas, który recenzent poświęca na każdą zmianę. Koszt zaakceptowanej zmiany obejmuje każde ponowienie i każde przerwane uruchomienie. Jeśli więc kandydat jest tani w jednym uruchomieniu, ale potrzebuje trzech prób, do jego kosztu wliczamy wszystkie trzy.

Samo odtworzenie nigdy nie przesądza o wyniku. Jedna grupa zadań pozostaje poza jakimkolwiek strojeniem, a każdy wynik potwierdzamy na zadaniach, nad którymi twoi inżynierowie pracują teraz, zanim ktokolwiek zacznie na nim polegać. To chroni przed dwiema sytuacjami, w których odtworzenie może wprowadzić w błąd: przyszłą pracą, która różni się od dawnych zadań, i zmianami, które przechodzą wszystkie testy, a mimo to są błędne.

Gdy pojawia się nowy model albo zmienia się twój harness, ta sama konfiguracja daje podstawy do decyzji, czy wdrożyć zmianę szerzej. Ponieważ testujemy każdą zmianę osobno i zapisujemy każde uruchomienie, twój zespół może samodzielnie powtórzyć ewaluację.

Metoda działa też wtedy, gdy zmienia się nie samo narzędzie, lecz sposób jego używania. Zmodyfikowany skill lub playbook pstack możesz uruchomić obok swojej bazowej konfiguracji, na jednym zestawie zadań o ustalonym zakresie dla obu. Tak samo jest z dwiema konfiguracjami Kilo, które różnią się dostawcą lub modelem. Sesje Devin Desktop da się porównać z pracą przekazaną do chmury tylko wtedy, gdy produkt może zacząć od przywróconego checkoutu. Testy muszą pozostać poza tym checkoutem. Jeśli produkt tego nie umożliwia, rzetelniejszy obraz da pilotaż na twojej bieżącej pracy. Dla każdego typu zadania raport pokazuje poprawność, ponowienia, obciążenie review i koszt.

Praca z pstack w Cursorze · Konfiguracja Kilo · Przekazywanie zadań Devinowi

• Ile kosztuje każda zaakceptowana zmiana, licząc zarówno wydatki, jak i czas recenzentów
• Liczba zaakceptowanych zmian w rozbiciu na narzędzia, modele i ustawienia, policzona na twojej bazie kodu
• Decyzja zapisana na piśmie razem z danymi, które ją uzasadniają