Przejdź do treści
Wróć do bloga
qwen3.8Artykuł

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

Sprawdziliśmy eksport CSV, paginację i import użytkowników. Qwen wykonał dwie zmiany poprawnie, a w trzeciej pominął walidację wykrytą przez ukryty test.

Autor

Syntalith

Opublikowano Zaktualizowano 4 min czytania

Lokalny Qwen3.8-27B z Qwen Code dobrze poradził sobie z eksportem CSV i poprawką paginacji przy ustawieniu medium. W zadaniu importu użytkowników przeszedł 12 testów dostępnych w repozytorium, lecz tylko 4 z 5 testów ukrytych. Przyjął rekord z pustą nazwą lub rolą. W praktyce taki brak walidacji może przepuścić wadliwe konto, choć widoczne testy zakończą się sukcesem.

Sprawdziliśmy cztery zwykłe zmiany w czystych kopiach małych projektów. Polecenia opisaliśmy językiem zgłoszeń, udostępniliśmy standardowe narzędzia i nie ustawiliśmy sztucznego limitu czasu.

W tabeli „test” oznacza jeden sprawdzany warunek. Test publiczny był dostępny agentowi w repozytorium, a ukryty sprawdzał dodatkowy warunek poza jego widokiem. Zapisujemy też czas przebiegu i zakres zmiany, ponieważ same zielone testy nie opisują kosztu ani bezpieczeństwa poprawki. W zapisanych zadaniach z punktacją OpenAI Codex oceniał zmianę według kryteriów Syntalith: poprawności, testów regresji, zgodności, dyscypliny zakresu, weryfikacji i dokumentacji.

Wyniki Qwen Code przy ustawieniu medium

ZadanieTesty ukryteTesty publiczneCzas przebieguCo oznacza wynik
Eksport CSV3/33/338,24 snajlepszy wynik zadania
Paginacja3/33/3264,53 snajmniejsza zgodna poprawka
Import CSV4/512/1293,14 sbrak walidacji pustych pól
Kontynuacja importu3/312/12146,88 spoprawne tworzenie lub aktualizacja rekordu, wcześniejszy problem z walidacją pozostał

Zapis 3/3 oznacza, że przebieg spełnił wszystkie trzy sprawdzane warunki. 4/5 oznacza jeden niespełniony warunek i nie jest miarą „80% niezawodności”. Każdy wiersz opisuje pojedynczy przebieg, więc czasy nie są obietnicą odpowiedzi, a tabela nie wyznacza prawdopodobieństwa sukcesu.

Polecenia przekazane agentowi

Polecenia nie zawierały instrukcji implementacji. Ich pełny sens był następujący:

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.

W kolejnym poleceniu zmieniliśmy kontrakt. Istniejący adres e-mail miał aktualizować nazwę i rolę, również wtedy, gdy duplikat pojawił się wcześniej w tym samym pliku. Operacja nadal miała być atomowa i zwracać liczniki created oraz updated.

Były to polecenia podobne do prawdziwych zgłoszeń. Agent musiał sam znaleźć w repozytorium separator CSV i kontrakt kursora. Z modelu danych oraz wymogu odrzucania błędnych wierszy powinien był wywnioskować, że puste imię i rola są błędnym rekordem. Ukryty test sprawdził właśnie ten brak.

Eksport CSV przy ustawieniu medium

Pierwsze zadanie dotyczyło małego błędu w eksporcie. Publiczne testy nie sprawdzały separatora opisanego w README. Qwen Code przy low przeszedł 3/3 testów publicznych, ale tylko 1/3 ukrytych. Przy medium odczytał zapisany kontrakt i przeszedł wszystkie testy w 38,24 s.

Nie wynika z tego, że medium zawsze wygrywa. Low może wystarczyć przy mechanicznej zmianie z tanią weryfikacją. W tym przebiegu krótsze rozumowanie oszczędziło 3,47 s, ale pozostawiło zachowanie niezgodne z dokumentacją.

Zgodność paginacji jest częścią poprawności

W zadaniu paginacji Qwen Code medium, Codex medium i OpenCode medium przeszły wszystkie dostępne testy. Różniły się zakresem zmian.

  • Qwen Code medium przygotował najmniejszą poprawkę zachowującą istniejący kontrakt.
  • Qwen Code low zmienił kontrakt kursora, mimo przejścia testów.
  • Codex wykonał szerszą przebudowę, która nie zachowała zgodności wstecznej.
  • OpenCode naprawił problem minimalnie, a potem oglądał niepotrzebne pliki .git.

Zaliczenie ukrytych testów nie zastępuje przeglądu zmian w kodzie. Kod może działać poprawnie, a mimo to obejmować zbyt szeroki zakres, by bezpiecznie go przyjąć.

Import z brakującą walidacją

Qwen Code zbudował działający import, opisał zmianę i przeszedł cały widoczny zestaw. Piąty ukryty test podał rekord z pustą nazwą lub rolą. Implementacja go zaakceptowała.

W tym samym zadaniu Codex przeszedł 5/5 ukrytych testów w 212 s, a OpenCode przeszedł 5/5 w 89,04 s. Qwen Code nie dał tu najlepszego wyniku jakościowego. Porównanie ma sens dopiero po rozdzieleniu zadań, warunków i zakresu zmian, zamiast sprowadzania decyzji do nazwy narzędzia albo jednej średniej.

Druga próba Qwen Code dodała poprawne tworzenie lub aktualizację rekordu w tej samej sesji, lecz nie naprawiła wcześniejszego błędu walidacji. W zespole działa to podobnie: kolejne zgłoszenie rzadko naprawia warunek, którego nikt nie wpisał do wymagań.

Jak czytać odpowiedź agenta

Recenzent powinien odpowiedzieć na pięć osobnych 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 spełnić cztery warunki, a mimo tego dostarczyć zmianę niegotową do scalenia. W produkcji potrzebne są więc powtarzalne testy i przegląd dopasowany do skutków błędu.

Wartość biznesowa to zmiana przyjęta przez zespół

Celem agenta kodowego jest skrócenie drogi od zgłoszenia do zmiany przyjętej przez zespół, przy zachowaniu długu i liczby incydentów pod kontrolą. Przydatny koszt można zapisać tak:

koszt zmiany przyjętej przez zespół = czas agenta
  + koszt infrastruktury
  + czas przeglądu człowieka
  + oczekiwany koszt poprawek

„Czas agenta” to czas przebiegu, „koszt infrastruktury” obejmuje sprzęt i energię, „czas przeglądu” oznacza pracę człowieka, a „koszt poprawek” uwzględnia przewidywane naprawy po wdrożeniu. Wolny model może się opłacać przy dobrze ograniczonych zadaniach wykonywanych nocą. Szybki model może zwiększać koszt, jeśli senior musi ręcznie odtwarzać każdy pominięty warunek.

Jak Syntalith wdraża taki profil

Zaczynamy od kilkunastu rzeczywistych zgłoszeń, zapisujemy dodatkowe testy i uruchamiamy każdy wariant na odłączonej kopii repozytorium. Później ustalamy dostęp do narzędzi, reguły określające działania wymagające zgody człowieka oraz zasady eskalacji. Pokazujemy zespołowi także wynik lokalnego modelu, gdy wypada słabiej od używanego API.

Jeśli chcesz nauczyć programistów tworzenia własnych testów agentów i bezpiecznej pracy z nimi, 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.

Bezpłatny skan procesów

Zacznij od bezpłatnego skanu procesów.

  • 30 minut z inżynierem, który może prowadzić Twoje wdrożenie.
  • Przegląd procesów, które kosztują Cię najwięcej czasu i pieniędzy.
  • Pisemne podsumowanie: co zautomatyzować, w jakiej kolejności, z widełkami kosztów.

W 30 minut wybieramy proces do oceny, a w ciągu 2 dni roboczych dostajesz rekomendację, także gdy lepsza będzie prostsza droga.

0 zł

30 minut · pisemne podsumowanie w 2 dni robocze