Dezvoltarea de agenți AI întâlnește worktree-urile RTL de la NVIDIA
NVIDIA Research a prezentat HORIZON pe 4 iulie 2026, ca un framework hands-free pentru dezvoltarea agenților AI în design hardware, tratând munca RTL ca evoluție de cod la nivel de repository în loc de generare one-shot. Acest lucru contează deoarece schimbă designul agentului de la output de cod plauzibil la acceptare executabilă, cu commit-uri git care acționează drept checkpoint-uri solide. Conform unui rezumat MarkTechPost al lucrării, sistemul a atins 100% finalizare în suitele de benchmark RTL evaluate.
HORIZON de la NVIDIA transformă RTL-ul într-un loop de agent nativ git
Am citit HORIZON mai puțin ca o poveste despre model și mai mult ca o poveste despre workflow. Echipa de cercetare de la NVIDIA Research nu pretinde că un backbone mai mare a rezolvat brusc designul hardware. Ei spun că unitatea de lucru era greșită. În loc să ceară modelului un răspuns Verilog finit, HORIZON plasează sarcina într-un git worktree izolat, editează fișiere, rulează evaluatori și salvează progresul doar când poarta trece.
Această distincție contează pentru echipele din semiconductor și EDA deoarece RTL-ul plauzibil este ieftin, dar RTL-ul care trece este scump. Un modul poate arăta corect și totuși să eșueze la comportamentul de reset, gestionarea lățimii de biți sau cazurile de margine ale simulatorului. HORIZON face din repository, nu din prompt, suprafața de operare.
Rezultatul principal este puternic: 100% finalizare pe ChipBench, RTLLM, Verilog-Eval și CVDP în lucrarea HORIZON de pe arXiv, lucrarea menționând că o rată reziduală a fost cauzată de un defect al harnessului de benchmark, nu de o eroare a agentului. Dar afirmația mai importantă este arhitecturală: feedback-ul executabil este loop-ul.
Așa cum parafrazează rezumatul sursă, „designul hardware agentic nu este rezolvat.” Această precauție este importantă. Lucrarea raportează un milestone, nu o închidere.
Cum harnessul Markdown devine pachetul de proiect
Inputul orientat către operator este un harness Markdown structurat cu patru părți: obiectiv, îndrumare de domeniu, specificație de evaluator și predicat de acceptare. Îmi place acest design deoarece obligă o echipă să scrie ce înseamnă succesul înainte ca agentul să înceapă să editeze codul.
În termeni practici, harnessul devine un pachet de proiect care conține politica agentului, evaluatorul executabil, regula de acceptare, comportamentul de version control și skill-urile de domeniu. Pentru RTL, acel evaluator poate include compilare, simulare, aserțiuni și extragerea de acoperire. Cu alte cuvinte, HORIZON nu generează doar cod; generează cod într-un mediu care îl poate respinge.
Acesta este un pattern util pentru agenți AI personalizați dincolo de hardware. Într-o implicare cu client, cel mai mare mod de eșec nu era calitatea modelului. Era absența unei condiții de trecere executabile. Dacă singurul rubric este „arată bine,” un agent va deriva. Dacă rubricul este „trece acest harness de test,” loop-ul devine gestionabil.
Lucrarea de pe arXiv face și un punct important de implementare: același slot folosit pentru simulare în RTL ar putea găzdui teste unitare, proveri de teoreme, profilere sau instrumente de sinteză în alte domenii. De aceea această cercetare contează atât pentru integrările enterprise AI în general, cât și pentru echipele de chip-uri.
Ce înseamnă evoluția la nivel de repository pentru echipele hardware
Iată partea pe care mă aștept ca liderii de inginerie să o împrumute primii. Git nu este doar logging în HORIZON. Este planul de control. Dif-urile expun schimbarea de stare propusă, commit-urile marchează checkpoint-urile acceptate, iar notele păstrează dovezile evaluatorului. Acest lucru este operațional mai curat decât atașarea unui magazin de memorie separat de un stack de agent și sperarea că rămâne consistent.
Am văzut proiecte de automatizare a workflow-urilor AI eșuând deoarece fiecare rulare lasă în urmă editări parțiale, reîncercări netraceabile și output de test ambiguu. Loop-ul HORIZON este mai strict: inspectează schimbările staged, rulează evaluatorul, face commit dacă trece, loghează dacă eșuează. Acest lucru face rollback-ul, replay-ul și auditul mult mai ușoare.
Pentru echipele hardware, cazurile de utilizare pe termen scurt sunt destul de directe:
- generarea RTL din specificații în limbaj natural
- completarea de cod în interiorul modulelor existente
- modificarea și refolosirea modulelor
- generarea de stimuli de test, checker-e și aserțiuni
- debugging pe baza feedback-ului simulatorului
Acestea se mapează strâns pe categoriile din CVDP și RTLLM-2.0. Se mapează și pe modul în care agenții de automatizare AI sunt deployați în mediile reale de inginerie: nu ca copiloți universali, ci ca lucrători în interiorul loop-urilor delimitate.
Există și un unghi economic. Raportul spune că cele nouă categorii CVDP au consumat 203,9 milioane de token-uri, sau 97,1% din totalul token-urilor utilizate, în timp ce aproximativ 91% din toate token-urile au fost input cache-uit. Acest lucru îmi spune că problema costului s-a mutat. Odată ce corectitudinea devine ridicată, echipele nu mai argumentează dacă agentul poate rezolva sarcina și încep să întrebe câte iterații îi ia să o facă ieftin.
De unde provin câștigurile de benchmark — și de unde nu
Numărul de 100% are nevoie de context. Rata de trecere agregată la prima iterație a HORIZON a fost de 47,8%, nu 100%. Scorul final a venit din reparație iterativă. Acest lucru este o caracteristică, nu o slăbiciune, dar schimbă modul în care aș benchmarka intern dezvoltarea agenților AI.
Dacă o echipă urmărește doar Pass@1, va rata ceea ce acest sistem este construit să facă. HORIZON este proiectat să amâne o parte din debugging pentru iterații ulterioare. Pe suite mai ușoare precum RTLLM-2.0 și Verilog-Eval-v2, convergența a avut loc în două iterații. Pe categorii mai grele, coada a fost lungă. Generarea de checker CVDP CID 013 a pornit de la 3,8% și a urcat la 100% la iterația 19. Completarea de cod CID 002 a avut nevoie de 82 de iterații și 56,0 milioane de token-uri.
Această dispersie este semnalul operațional real. Unele sarcini sunt aproape gata pentru automatizare de rutină. Altele sunt tehnic solvabile, dar suficient de costisitoare încât ai dori o arhitectură de integrare AI mai bună înainte de a deploya la scară.
Cred că detaliul backbone-ului fix contează. Lucrarea spune că GPT-5.3 a rămas fix pe tot parcursul campaniei. HORIZON înregistrează tranzițiile de stare folosind limbaj semi-Markov, dar nu antrenează o nouă politică RL în timpul rulării. Acest lucru înseamnă că îmbunătățirea performanței provine din designul loop-ului, disciplina de evaluare și memoria repository-ului, nu din actualizări de greutăți online.
Pentru echipele enterprise care se uită la servicii de automatizare a workflow-urilor AI, aceasta este lecția transferabilă. Loop-urile mai bune bat adesea mai multă tinkering de model.
Limitele: a trece harnessul nu este același lucru cu a rezolva designul
Aici cred că lucrarea este proaspăt onestă. A trece harnessul vizibil nu este același lucru cu a satisface intenția completă de design. Autorii menționează în mod explicit riscul de reward hacking și over-solving. Dacă evaluatorul vede doar o parte din specificație, agentul poate optimiza pentru testul văzut mai degrabă decât pentru cerința reală.
Această problemă nu este unică pentru RTL. Apare în repo-uri software, automatizări de suport și agenți de tooling interni. Dacă predicatul tău de acceptare este superficial, metrica ta de succes va fi superficială.
Cealaltă limitare este timpul de turnaround. HORIZON arată cel mai puternic acolo unde feedback-ul este relativ rapid: compilează, simulează, aserțiune, repetă. Lucrarea notează că loop-urile orientate spre PPA pot dura zile sau săptămâni. În acel context, aceeași structură nativă de repository poate ajuta în continuare, dar economia și logica de scheduling se schimbă complet.
Deci ce ar trebui să urmărească echipele în continuare? În primul rând, dacă lucrările ulterioare adaugă teste ascunse, verificări randomizate și verificare formală pentru a reduce reward hacking-ul. În al doilea rând, dacă aceste loop-uri native de repository își pot păstra disciplina când evaluatorii devin mai lenți, mai largi și mai scumpi decât harnessurile de benchmark de astăzi.
Lecturi conexe
Martin Kuvandzhiev
CEO and Founder of Encorp.io with expertise in AI and business transformation