Cum am construit un joc-quiz Spotify din scaunul pasagerului: Așa arată dezvoltarea cu AI în realitate

Există un joc muzical viral numit Hitster. Scanezi un QR code. Spotify pornește o melodie. Prietenii ghicesc anul lansării. Toți aranjează cărți pe o linie temporală. Simplu. Captivant. Costă vreo 25 de euro pachetul de cărți.

Un dezvoltator s-a gândit: de ce să-l cumpăr când pot să-mi fac unul propriu? Provocarea? Era pasager pe o autostradă din Austria spre Germania. Cu telefonul în mână, un server acasă și Claude AI ca partener de codat.

Rezultatul? Un exemplu perfect despre ce poate face dezvoltarea asistată de AI azi – și unde se blochează încă.

Limitările au fost esența proiectului

Nu a fost un test artificial. A fost o încercare reală, cu constrângeri adevărate. Fără laptop. Fără tastatură. Fără căutări Google pe ecranul mic. Doar mesaje vocale către Claude pe Telegram, serverul de acasă rula codul, iar feedback-ul venea pe telefon.

Stack-ul ales a fost ultra-minimal: HTML, CSS și JavaScript pur. Fluxul PKCE de la Spotify, care nu cere backend. QRCode.js pentru generat coduri. Html5-QRCode pentru scanat. Nimic în plus. Nimic complicat.

Asta arată puterea designului impus de limitări. Fără acces ușor la biblioteci sau docuri, alegi tool-uri testate, bine documentate. Evită dependențe ciudate. Păstrezi totul previzibil.

Trei ore până la prima victorie

Când mașina s-a oprit la un drive-thru, nucleul funcționa deja. Dezvoltatorul scana QR-ul pe telefon și auzea muzica din playlist-ul Spotify.

Gândește-te la ritm: de la idee la prototip funcțional în trei ore. Totul prin comenzi vocale și execuție remote. Autentificarea Spotify – care implică de obicei console de developeri, OAuth și debug de token-uri – a mers din prima testare serioasă.

Cheia? Comunicare clară. Dezvoltatorul a descris exact ce vrea. Claude a pus întrebări, a ales tool-urile potrivite și a implementat. Când a apărut blocajul (trebuia să se adauge ca test user la Spotify), a cerut ajutor uman. AI-ul nu a bănuit.

Unde a excelat fluxul de lucru

Raportarea erorilor remote a revoluționat debugging-ul. Testat pe Chrome Android, fără DevTools. Normal: ghicești eroarea, modifici codul, reîmprospătezi, repeți. În schimb, Claude a adăugat log-uri client-side care trimiteau erorile JS pe server. Dezvoltatorul descria doar ce vedea ("butonul nu răspunde"), iar Claude citea log-urile reale. Debugging-ul a devenit rapid ca și cum DevTools era deschis – fără să citească niciun stack trace.

Autentificarea a mers flawless. PKCE de la Spotify nu cere server backend, deci zero complicații infra. Client ID luat din Spotify Developer Console, dat lui Claude, și login-ul era gata. Câteva iterații pentru test user, și ok. Exemplu ideal de tech care susține workflow remote.

Tailscale Serve a făcut testarea instant. Fără port forwarding sau firewall. Claude a rulat tailscale serve --bg --https=8443 http://127.0.0.1:8080, și app-ul era accesibil pe telefon prin tailnet. Fără docuri. A funcționat direct. Tool-uri ca astea fac dezvoltarea cu AI posibilă.

UI-ul a ieșit curat, fără designer. Claude știe design systems și pattern-uri UI. Interfața a trecut rapid de la rough la polished. Fără Figma sau dezbateri despre culori.

Apoi a venit realitatea

API-ul Spotify s-a rupt în tăcere. Endpoint-ul de playlist returna 403 Forbidden, deși autentificarea era ok. Claude a analizat log-urile din browser și a găsit schimbarea din februarie 2026: /v1/playlists/{id}/tracks înlocuit cu /v1/playlists/{id}/items. Două linii de cod fix. Dar a durat iterații să diagnosticheze – eroarea nu era evidentă. Lecție: AI-ul debug-uiește sistematic cu log-uri, dar nu e magie. Raționează pas cu pas.

A urmat zidul legal. Cu jocul aproape gata, dezvoltatorul întreabă Claude: "De ce nu există clone Hitster publice?" Răspuns rapid: Politica Spotify interzice jocuri cu API-ul lor. Secțiunea III: "Nu crea jocuri, inclusiv quiz-uri trivia."

Nu e o portiță. Nu o ocolești. E interzis clar. Hitster probabil are acord special cu Spotify. Lipsa clonelor publice nu e din cauză tehnică – e contractuală.

Lecție cheie: AI-ul face ușor să construiești chestii care încalcă ToS. Bariera tehnică a dispărut; acum bottleneck-ul e legal și business.

Fluxul care a făcut totul posibil

Mesaje vocale către Claude pe Telegram. Tailscale pentru acces rețea instant. Flag-ul --dangerously-skip-permissions ca Claude să scrie fișiere și să ruleze comenzi fără aprobări constante din mașină. Încrederea s-a adaptat.

Voce în, cod out, reload pe telefon. Trei tool-uri au creat un loop de feedback suficient de strâns pentru un drum cu mașina.

Ce lipsește (și contează)

Raportarea erorilor client-side e ok, dar nu perfectă. DevTools Protocol ar da lui Claude acces direct la console, network și DOM – ca un mediu real de dev.

Proiectul e limitat la ce rulează pe server acasă cu IP public și Tailscale. Vrei cloud infra? Revii la CLI, env vars și deploy-uri complexe.

Și ToS-ul ține jocul privat – proof of concept pentru prieteni, nu produs.

Concluzia adevărată

Nu e despre AI care înlocuiește dev-ii. E despre cum iterația devine fulgerătoare când bottleneck-ul trece de la "găsesc librăria potrivită" la "comunic ce vreau clar".

Dezvoltatorul trebuia să înțeleagă proiectul. Să vadă problema legală când Claude a semnalat. Să știe tool-urile potrivite (Tailscale, PKCE, vanilla JS) sub constrângeri.

Ce s-a schimbat? Timpul de la "am o idee" la "prototip funcțional". De la zile la ore. De la ore la un drum cu mașina.

Nu magie. Doar tool-uri mai bune + comunicare clară + constrângeri rezonabile.

Vrei să construiești proiecte mai rapid? NameOcean oferă Vibe Hosting și tool-uri AI pentru iterații turbo. De la prototip la infra scalabilă, ai rețea, domain-uri și totul gata să accelerezi.