Qwen zbudował interfejs w 26 minut. Akceptacja zajęła 48

Po 26 minutach i 3 sekundach Qwen Code miał gotowy panel rekrutacyjny: wyszukiwanie, sortowanie, etapy, szczegóły kandydata i układ mobilny. Zaczęliśmy od pustego katalogu i jednego zdania. Kod wygenerował lokalny Qwen3.8-27B na domowym PC z RTX 3090.

W przeglądarce panel utworzył jednak 251 327 elementów DOM i stronę wysoką na 485 065 pikseli. Detektor pętli zatrzymał pierwszą sesję przed pełną kontrolą interfejsu. Dopiero dwie sesje naprawcze doprowadziły projekt do stanu przyjętego w teście; łączny zapisany czas modelu wyniósł 48 minut i 25 sekund.

Pokazujemy polecenie, zrzuty i naprawy. Dane kandydatów są syntetyczne, a eksperyment odbył się poza pracą dla klientów i środowiskiem produkcyjnym.

Dokładne polecenie dla agenta

Model działał przez Qwen Code z poziomem rozumowania low i deklarowanym oknem 150 000 tokenów kontekstu. Dostał dokładnie to:

Build me a polished interactive frontend page for an AI recruitment/ATS product from scratch in this empty folder. I want to see what you can do in one shot. Use the Impeccable skill in overdrive mode, but keep it genuinely usable. Surprise me. Make it runnable locally, responsive, and finish and test it without asking me questions.

Nie było makiety, listy komponentów ani gotowego systemu wizualnego. Luźne polecenie miało sprawdzić, ile model zaprojektuje i zbuduje samodzielnie. Jako zlecenie produkcyjne wymagałoby doprecyzowania: nie określało budżetu DOM, wymagań dostępności ani zachowania przy realistycznej liczbie rekordów.

Co powstało po 26 minutach

Qwen stworzył cztery główne pliki tekstowe, łącznie 2028 linii kodu i tekstu oraz 79 588 bajtów:

Kod generował 10 000 sztucznych rekordów kandydatów. Panel filtrował je według etapu, obsługiwał wyszukiwanie i sortowanie, symulował napływ nowych aplikacji, otwierał szczegóły kandydata i aktualizował liczniki lejka. Zawierał także skróty klawiaturowe oraz obsługę ograniczenia ruchu.

To użyteczna pierwsza wersja z bardzo ogólnego zlecenia. Oceniamy ją przez uzyskany rezultat i czas do akceptacji, bez przekładania tego pojedynczego przebiegu na produktywność człowieka.

Pełna oś czasu

Tabela nie obejmuje czasu człowieka na przygotowanie polecenia, obejrzenie strony i kontrole wykonane osobno od sesji modelu. Obejmuje trzy zapisane etapy pracy. „Wywołanie narzędzia” oznacza pojedynczą operację odnotowaną przez Qwen Code, na przykład odczyt pliku, komendę lub edycję.

Wcześniejsza wersja tekstu błędnie sugerowała, że naprawa trwała dłużej niż generowanie. Zachowane podsumowania pokazują 22:22 pracy naprawczej wobec 26:03 generowania. Przy planowaniu liczy się 48:25 zarejestrowanego czasu przebiegów do uzyskania zaakceptowanego rezultatu.

Dlaczego wirtualizacja wyrenderowała wszystko

Qwen zaprojektował wirtualną listę, która miała utrzymywać w DOM wyłącznie widoczne rekordy. Pomysł był właściwy, lecz dwa szczegóły implementacji zniweczyły go w przeglądarce:

1. obszar przewijania nie miał ograniczonej wysokości, więc jego clientHeight urósł do wysokości całej listy;
2. pozycja top trafiała na statyczny element listy, chociaż absolutnie pozycjonowany był wewnętrzny przycisk.

Obliczone okno widocznych rekordów objęło przez to wszystkie 8652 pasujące osoby. Dokument osiągnął wysokość 485 065 px. Zwykły pełnostronicowy zrzut nie kończył się, dopóki przeglądarka testowa tymczasowo nie ograniczyła układu.

Naprawa ujawniła cztery kolejne błędy

Drugie polecenie było konkretne: zachować projekt i interakcje, ograniczyć liczbę elementów, sprawdzić widok desktopowy i mobilny oraz przejrzeć konsolę. Qwen Code z poziomem medium potrzebował 14:24 od uruchomienia do zakończenia tego etapu. Oprócz dwóch usterek wirtualizacji znalazł cztery problemy, których nie było w zgłoszeniu:

Po tej sesji osobny przegląd w Chromium zmierzył 722 węzły DOM i 15 widocznych wierszy na desktopie oraz 577 węzłów i 10 wierszy przy szerokości 390 px. Strona mieściła się w obszarze widoku i nie miała poziomego przepełnienia.

Test geometrii przeszedł, zrzut nadal wyglądał źle

Automatyczna kontrola mierzyła nakładanie prostokątów całych wierszy. Nie porównywała położenia nazwy kandydata i firmy wewnątrz komórki. Na mobile znacznik etapu potrzebował 72-84 px szerokości, a jego kolumna miała 51 px.

Trzecie polecenie opisało oba problemy. Qwen zmienił dwie reguły CSS, lecz wznowienie dużej sesji zajęło 7:58 i 20 wywołań narzędzi. Rezultat był poprawny, choć taki zakres lepiej obsłużyłaby świeża sesja.

Co Qwen faktycznie potrafił

Ten przebieg pokazuje trzy użyteczne możliwości:

• z pustego katalogu stworzył spójny, interaktywny prototyp na podstawie jednego zdania;
• w istniejących 2028 liniach odnalazł zależność między CSS, clientHeight, wirtualizacją i pozycjonowaniem;
• podczas naprawy głównego problemu wykrył cztery niezależne błędy interakcji i danych.

Widać też wyraźną granicę. Wynik po 26 minutach nadawał się do omówienia pomysłu, lecz nie do przekazania użytkownikom. Akceptacja wymagała testu na 10 000 rekordów, pomiarów DOM, sprawdzenia interakcji, kontroli konsoli i obejrzenia zrzutów.

Taki agent jest przydatny, gdy szybko zamienia pomysł w materiał do oceny albo bierze precyzyjnie opisany błąd w odizolowanej kopii. Nadal potrzebuje kryteriów akceptacji i osoby gotowej odrzucić atrakcyjny, lecz wadliwy rezultat.

Masz już prototyp wygenerowany przez agenta?

Syntalith może sprawdzić taki prototyp w podobny sposób: zachować oryginał, wybrać jeden przepływ użytkownika, uruchomić go na realistycznej liczbie rekordów, zmierzyć wydajność i interakcje, a następnie przekazać mapę usterek oraz uzgodniony zakres prac produkcyjnych.

Jeśli chcesz używać lokalnego modelu do takich zadań, dobierzemy i wdrożymy profil z testem odbioru. Przy gotowym prototypie możemy zacząć od audytu procesu AI, a uzgodniony zakres zrealizować jako aplikację AI.

Pełne pomiary z pozostałych prób są w zestawieniu wyników. Bezpośrednie porównanie klientów opisujemy w artykule Qwen Code, Codex, Claude Code i OpenCode na tym samym Qwenie.