Când AI-ul local dă rateuri din motive banale

Există un tip specific de frustrare care vine odată cu privitul unui sistem inteligent care eșuează din motive stupide. Am trăit asta recent experimentând cu agenți de programare AI care rulează local — un trend care câștigă teren pe măsură ce modelele open-weight devin mai capabile și importanța confidențialității în dezvoltare crește.

Experimentul a fost simplu: poate un agent de codare care rulează integral pe hardware propriu să construiască un joc funcțional? Nu un demo trivial, ci ceva cu management real de stare, logică de randare, manipulare a input-ului și o interfață playabilă. Răspunsul, după multă bătaie de cap, a fost da — dar drumul până acolo a scos la iveală o categorie de probleme pe care ecosistemul de tooling AI nu le gestionează elegant.

Configurația care ar fi trebuit să funcționeze

Stackul era format din trei componente care reprezintă vârful tehnologiei în dezvoltarea AI local: un CLI de agent de codare agnostic față de provider, Ollama care servește o API compatibilă OpenAI de pe localhost, și Qwen3.8 27B rulând pe mașina locală. Pentru context, nu e o configurație subdimensionată — modelul 27B la 17GB încape confortabil în 32GB de memorie unificată și suportă tool calling cu capabilități de reasoning respectabile.

Rezultatele inițiale au fost promițătoare. În cincisprezece minute, agentul produsese o structură HTML completă și aproape 200 de linii de CSS în stil NES cu efecte de bevel și o paletă de culori corectă. Mai impresionant, agentul și-a prins singur o greșeală în timpul execuției: a scris un fișier, l-a re-citit, a observat o nepotrivire între ce intenționa și ce a ajuns pe disk, și l-a reparat fără să fie rugat. Asta e comportament agentic genuin, și sugera că modelul e capabil de sarcina respectivă.

Apoi agentul a încercat să scrie fișierul cu logica jocului, și totul s-a oprit.

Spirala morții

A urmat o secvență pe care oricine s-a luptat cu tooling AI o va recunoaște. Treisprezece încercări consecutive de a scrie fișierul cu motorul jocului, fiecare terminată la mijlocul generării. Streamul pur și simplu murea, fără eroare, fără explicație, fără output util.

Partea cea mai enervantă nu era eșecul în sine — era să privești procesul de reasoning al agentului. Pentru că fiecare încercare pornea de la zero, modelul re-deriv aceleași decizii de design de la capăt, ajungând la tabele de scorare și abordări de implementare diferite de fiecare dată. Trei încercări însemna trei răspunsuri diferite la aceeași întrebare arhitecturală. Agentul petrecea o oră gândind și nu livra nimic.

Candidatul evident părea presiunea pe memorie. Închiderea taburilor din browser a eliberat câteva gigabytes de RAM și lucrurile s-au îmbunătățit marginal, ceea ce părea să confirme diagnosticul. Dar asta era o lecție greșită de tras.

Ce dezvăluiau de fapt logurile

Revenind peste logurile serverului, povestea era alta. Nu exista o singură eroare de out-of-memory în niciunul dintre ele. Memoria liberă a sistemului stătea confortabil între 21 și 27 de gigabytes pe tot parcursul, raportat la amprenta de 17 gigabytes a modelului. Memoria nu a fost niciodată problema.

Problema reală era o nepotrivire de configurație care nu producea nicio eroare vizibilă. Configul agentului anunța un context window de 32.768 de tokeni. Dar serverul Ollama fusese restartat cu un plafon de doar 8.192 de tokeni, iar această discrepanță trecuse neobservată. Agentul planifica fericit un fișier de 800 de linii de scris dintr-o singură mișcare, pentru că, din punctul lui de vedere, avea 32k de marjă. Când generarea reală lovea peretele de 8k la mijlocul unui tool-call, conexiunea era tăiată fără mesaj de eroare pe care agentul să-l poată înțelege.

Era și o complicație secundară ascunsă în logurile de startup: Ollama pornise cu context-shifting activat, ceea ce ar fi permis ferestrei să alunece când rămânea fără spațiu, sacrificând tokeni mai vechi pentru a face loc celor noi. Dar arhitectura modelului nu suporta această funcție, așa că fusese dezactivată silențios. Ceea ce ar fi trebuit să fie o limită soft a devenit un zid hard.

Disciplina DevOps pe care o cere dezvoltarea AI

Această experiență cristalizează ceva important despre dezvoltarea AI local pe care entuziasmul din jurul modelelor open-weight tinde să estompeze. Când rulezi modele pe propriul hardware, nu doar scrii cod — operezi infrastructură. Și infrastructura cere aceeași disciplină de diagnosticare, management al configurației și atenție la parametrii operaționali pe care îi cer sistemele de producție.

Context window-urile nu sunt proprietăți abstracte ale modelului de setat și uitat. Sunt parametri operaționali care interacționează cu tool chain-ul în moduri non-evidente. Când contextul configurat al agentului nu se potrivește cu plafonul real al serverului, nu primești un warning — primești eșecuri silențioase care par incompetență a modelului când sunt de fapt misconfigurare operațională.

Concluzia practică pentru dezvoltatorii care explorează agenții de codare AI locali e straightforward: validează mediul la fel de riguros cum ai valida un deployment de producție. Verifică că configurația agentului se potrivește cu parametrii runtime. Citește logurile serverului, nu doar output-ul agentului. Înțelege ce features ale arhitecturii modelului sunt suportate efectiv versus ce încearcă tooling-ul să activeze.

Modelele devin mai bune. Tooling-ul se maturizează. Dar diferența dintre "funcționează în demo-uri" și "funcționează sigur în uzul zilnic" încă necesită judecată umană să o traverseze — și acea judecată arată mult a disciplină tradițională de DevOps aplicată unei noi clase de infrastructură.

Buildul de Tetris a reușit în final. A durat patru ore și jumătate în două zile, a produs cod curat în trei fișiere și funcționează corect. Dar lecțiile au venit nu din succes, ci din înțelegerea motivelor eșecurilor — și din recunoașterea că uneori cele mai costisitoare probleme nu au nimic de-a face cu inteligența.