Qwen zbudował interfejs w 26 minut. Odbiór zajął 48

Ten test zaczął się od pustego katalogu, jednego zdania i lokalnego Qwen3.8-27B sterowanego przez Qwen Code na domowym RTX 3090. Po 26 minutach i 3 sekundach powstał rozbudowany panel rekrutacyjny z wyszukiwaniem, sortowaniem, etapami procesu, napływającymi zgłoszeniami, szczegółami kandydata i widokiem mobilnym.

Pierwsza wersja nie nadawała się jeszcze do odbioru. Przebieg zakończył detektor pętli, zanim agent wykonał pełny test w przeglądarce. Późniejszy pomiar wykazał 251 327 elementów DOM i dokument wysoki na 485 065 px. Dwie sesje naprawcze doprowadziły stronę do poprawnego stanu. Łączny zarejestrowany czas pracy modelu wyniósł 48 minut i 25 sekund.

Poniżej jest cały wynik, razem z poleceniem, tym co Qwen zbudował, tym co zepsuł i czasem potrzebnym na poprawki. Dane kandydatów są sztuczne. To domowy eksperyment. Nie był realizacją klienta ani testem infrastruktury produkcyjnej.

Dokładne polecenie dla agenta

Model działał przez Qwen Code w trybie low, z deklarowanym oknem 150k. 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. Polecenie celowo sprawdzało, ile model potrafi wymyślić i zbudować samodzielnie. Jako brief produkcyjny byłoby zbyt luźne: nie definiowało budżetu DOM, dostępności ani zachowania na dużym zbiorze.

Co powstało po 26 minutach

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

Kod generował 10 000 sztucznych kandydatów. Panel filtrował ich według etapu, obsługiwał wyszukiwanie i sortowanie, symulował nowe aplikacje, pokazywał szczegóły kandydata oraz aktualizował stan lejka. Były też skróty klawiaturowe i tryb ograniczonego ruchu.

To był dobry pierwszy artefakt z bardzo słabego briefu. Jego wartość oceniamy przez wynik i czas do odbioru, bez przeliczania go na produktywność człowieka.

Pełna oś czasu

Tabela nie obejmuje czasu człowieka na przygotowanie polecenia, przegląd i niezależne testy. Pomijamy też nieudany start kontynuacji trwający 0,93 s, który nie wysłał tokenów do modelu.

Poprzednia wersja tego tekstu zawierała błędne zdanie, że naprawa trwała dłużej niż generacja. Zachowane podsumowania pokazują 22:22 napraw wobec 26:03 generacji. Liczba przydatna przy planowaniu to 48:25 pracy modelu do przyjętego wyniku.

Dlaczego wirtualizacja wyrenderowała wszystko

Qwen zaprojektował wirtualną listę, która miała utrzymywać w DOM tylko widoczne rekordy. Sama idea była właściwa. Dwa szczegóły unieważniły ją 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 miał 485 065 px wysokości. Zwykły pełny zrzut strony 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 już konkretne: zachować projekt i interakcje, naprawić tysiące elementów, sprawdzić desktop, mobile oraz konsolę. Qwen Code medium potrzebował 14:24. Oprócz dwóch usterek wirtualizacji znalazł problemy, których nie było w zgłoszeniu:

Po tej sesji niezależny Chromium zmierzył 722 węzły i 15 wierszy na desktopie oraz 577 węzłów i 10 wierszy przy szerokości 390 px. Strona mieściła się w wysokości viewportu i nie miała poziomego przepełnienia.

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

Automatyczna kontrola mierzyła nakładanie całych wierszy. Nie sprawdzała relacji nazwy kandydata i firmy wewnątrz komórki. Na mobile znacznik etapu potrzebował 72–84 px, a jego kolumna miała 51 px.

Trzecie polecenie nazwało oba problemy. Qwen zmienił dwie reguły CSS, ale przez wznowienie dużej sesji potrzebował 7:58 i 20 wywołań. Wynik był poprawny, lecz nieefektywny. Niezależna drobna zmiana powinna trafić do świeżej sesji.

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.

Pokazuje też ograniczenie. Wynik po 26 minutach nadawał się do pokazania pomysłu, ale nie do przekazania użytkownikom. Dopiero test na 10 000 rekordów, pomiary DOM, kliknięcie interakcji, kontrola konsoli i obejrzenie zrzutów doprowadziły go do stanu odbiorowego.

W praktyce taki agent ma wartość, gdy szybko zamienia pomysł w coś, co zespół może ocenić, albo bierze dobrze opisany błąd w odizolowanej kopii. Nadal potrzebuje kryteriów i osoby, która potrafi odrzucić atrakcyjny, lecz wadliwy wynik.

Masz już prototyp wygenerowany przez agenta?

Syntalith może sprawdzić go tak jak ten panel: zachować oryginał, wybrać jeden przepływ użytkownika, uruchomić go na realistycznym wolumenie, zmierzyć wydajność i interakcje, a następnie oddać mapę usterek oraz stały zakres doprowadzenia do produkcji.

Bezpłatny skan procesu służy do wyboru przepływu i ryzyka wartego sprawdzenia. Audyt procesu AI od 4990 zł netto zawiera kryteria odbiorowe, architekturę, plan i stałą wycenę. Aplikacje AI zaczynają się od 25 000 zł netto.

Zanonimizowane liczby 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.