Czy Qwen Code nadaje się do zwykłych zmian w aplikacji?

Qwen Code na lokalnym Qwen3.8-27B poprawnie wykonał eksport CSV i naprawę paginacji przy średnim poziomie rozumowania. W imporcie użytkowników przeszedł 12 testów widocznych dla agenta, ale zaliczył 4 z 5 ukrytych: nie odrzucił pustej nazwy i roli. Taki błąd mógłby utworzyć wadliwe konta mimo zielonego wyniku testów.

Testowaliśmy cztery zwykłe prace w czystych kopiach małych projektów. Wszystkie polecenia były naturalne, narzędzia normalnie dostępne, a czas nie miał sztucznego sufitu.

Właśnie dlatego wynik publicznego testu zapisujemy obok ukrytej kontroli, różnicy w kodzie, czasu, energii i komentarza recenzenta, który zna oczekiwany kontrakt i potrafi nazwać brakujące zachowanie.

Wyniki Qwen Code przy średnim poziomie rozumowania

Te liczby są obserwacjami z pojedynczych przebiegów. Nie oznaczają 80% niezawodności importu ani gwarantowanego czasu odpowiedzi. Pozwalają wskazać profil do dalszych testów i konkretne zabezpieczenie, którego nie wolno pominąć.

Polecenia, które dostał agent

Nie pisaliśmy poleceń pod gotową implementację. Oto ich sens bez skracania wymagań:

Eksport: Klienci z kilkoma tagami pojawiają się więcej niż raz w eksporcie CSV. Napraw to pod src, zachowaj istniejące kolumny i dodaj test regresji.

Paginacja: Filtrowanie działa na pierwszej stronie, ale po „load more” pojawiają się wpisy innych właścicieli i znikają pasujące. Znajdź błąd w src/activity-store.js i napraw go z testami.

Import: Dodaj import CSV z kolumnami name, email, role. Puste linie są dozwolone, ale błędny rekord lub duplikat emaila ma odrzucić cały plik bez częściowego zapisu. Dodaj testy i zaktualizuj README.

Kolejne polecenie zmieniało kontrakt: istniejący email ma aktualizować nazwę i rolę, także dla duplikatu wcześniej w tym samym pliku; operacja ma pozostać atomowa i zwrócić liczby created oraz updated.

To są polecenia podobne do zgłoszeń. Szczegóły separatora CSV i kontraktu kursora agent musiał odnaleźć w repozytorium. Walidację pustego imienia i roli powinien wyprowadzić z pojęcia „bad rows” oraz modelu danych, ale tego nie zrobił. Właśnie w tym miejscu ukryty test dostarczył wartość.

Wysiłek medium zmienił wynik eksportu CSV

Zadanie dotyczyło małego błędu eksportu. Publiczne testy nie obejmowały separatora określonego w README. Qwen Code low przeszedł 3/3 testów publicznych, ale tylko 1/3 ukrytych. Qwen Code medium przeczytał kontrakt i zaliczył wszystkie kontrole w 38,24 s.

Wniosek nie brzmi „medium jest zawsze lepsze”. Niski wysiłek może wystarczyć przy łatwo weryfikowalnej, mechanicznej zmianie. Jeśli jednak dokumentacja jest częścią kontraktu, skrócenie rozumowania oszczędziło 3,47 s i pozostawiło błędny wynik.

Poprawna paginacja wymaga zgodności

W zadaniu paginacji Qwen Code medium, Codex medium i OpenCode medium przeszły wszystkie testy. Różnił je zakres.

• Qwen Code medium przygotował najmniejszą poprawkę zgodną z istniejącym kontraktem.
• Qwen Code low zmienił kontrakt kursora, mimo że testy przeszły.
• Codex wykonał szerszą, niezgodną wstecznie przebudowę.
• OpenCode naprawił problem minimalnie, a potem kontynuował zbędne oglądanie .git.

Ukryty test nie zastąpił przeglądu różnicy. System może być logicznie poprawny i nadal zbyt szeroki do bezpiecznego przyjęcia.

Zielone testy importu ukryły brak walidacji

Qwen Code zbudował działający import, opisał zmianę i przeszedł komplet istniejących testów. Piąta kontrola ukryta wysłała rekord z pustą nazwą lub rolą. Implementacja go przyjęła.

W tym samym zadaniu Codex uzyskał 5/5 ukrytych kontroli w 212 s. OpenCode także uzyskał 5/5, w 89,04 s. To przykład, w którym Qwen Code nie był zwycięzcą jakościowym. Uczciwy wybór agenta nie może polegać na jednym logo ani średniej z niepodobnych zadań.

Kontynuacja Qwen Code dodała poprawne tworzenie lub aktualizację rekordu w tej samej sesji, ale nie wróciła do pominiętej walidacji. Agent zachował kontekst rozwiązania i jednocześnie zachował dług. To zachowanie przypomina pracę zespołu: kolejne zgłoszenie rzadko naprawia problem, którego kryterium akceptacji nie nazwało.

Jak czytać odpowiedź agenta

Zespół powinien rozdzielić pięć pytań:

1. Czy kod się buduje i testy publiczne przechodzą?
2. Czy zmiana spełnia kontrakt z dokumentacji?
3. Czy trudne wejścia są walidowane?
4. Czy zakres jest najmniejszy, który rozwiązuje problem?
5. Czy raport końcowy dokładnie opisuje to, co sprawdzono?

Agent może odpowiedzieć poprawnie na cztery z nich i nadal nie dostarczyć zmiany gotowej do scalenia. Dlatego w produkcji potrzebuje testów deterministycznych oraz przeglądu proporcjonalnego do ryzyka.

Gdzie leży wartość biznesowa

Celem agenta kodowego nie jest produkcja większej liczby linii. Ma skrócić czas od zgłoszenia do zaakceptowanej zmiany, bez zwiększania długu i liczby incydentów. Mierzymy więc:

koszt zaakceptowanej zmiany = czas agenta
  + koszt infrastruktury
  + czas przeglądu człowieka
  + oczekiwany koszt poprawek

Firma może uzyskać dodatni wynik nawet przy wolnym modelu, jeśli agent wykonuje dobrze ograniczone prace nocą. Może też stracić na szybkim modelu, jeśli senior poprawia każdy kontrakt ręcznie.

Jak Syntalith wdraża taki profil

Zaczynamy od kilkunastu rzeczywistych zgłoszeń, budujemy ukryte kryteria i porównujemy profile na odłączonych kopiach repozytorium. Dopiero później ustalamy dostęp do narzędzi, bramki akceptacji i zasady eskalacji. Zespół dostaje wyniki także wtedy, gdy lokalny model przegrywa z używanym API.

Jeśli chcesz nauczyć programistów tworzenia własnych ewaluacji i bezpiecznej pracy z agentami, Kurs AI-Native odbywa się na repozytorium uczestnika. Dla decyzji o wdrożeniu zacznij od bezpłatnego skanu procesu.

Opis całej metody jest w artykule jak testować lokalnego agenta programistycznego.