Rillet, o platformă ERP nativă AI, a triplat ritmul de livrare a codului în trei luni și a ajuns să livreze modificări cerute de clienți în producție în doar două ore, folosind agenți construiți pe eve și rulați pe Vercel. Cazul, publicat de Vercel, arată că standardizarea contează mai mult decât framework-ul ales.

Ce a făcut Rillet, în fapte verificabile

Sursa (Vercel Blog) descrie o echipă de frontend de două persoane care a închis peste 800 de tichete Linear în primele patru luni și care, potrivit unui anunț al CEO-ului citat în material, a livrat mai mult în ultimele săptămâni decât în tot primul semestru din 2026. Agenții sunt construiți pe eve, framework open-source de agenți al Vercel, rulați pe Vercel, cu acces la Slack și Linear prin Vercel Connect și rutare de modele prin AI Gateway. Accesul builderilor e administrat prin Enterprise Managed Users, SSO prin Google Workspace și Directory Sync.

Asta e tot ce putem lua ca fapt. Restul e comentariu și merită tratat ca atare.

Standardizarea bate framework-ul

Partea interesantă nu e că au ales eve. E motivul pentru care l-au ales. Anthony Liang, inginerul citat în material, spune că a evaluat aproape toate framework-urile de agenți de pe piață, de la SDK-urile marilor furnizori de modele până la ecosistemul open-source, și că fiecare îi dădea primitive pentru bucla modelului, dar îl lăsa să decidă singur unde stau instrucțiunile, cum se înregistrează tool-urile și cum ajunge agentul la Slack sau GitHub.

Aceeași problemă o are orice echipă care trece de la un agent de demo la zece agenți de producție. Nu modelul e blocajul. Blocajul e lipsa de convenții. Când fiecare builder își face propriul pattern, onboarding-ul unui om nou durează săptămâni, iar mentenanța devine arheologie.

Rillet a rezolvat-o structural: un agent e un director. Instrucțiuni în markdown, tool-uri în fișiere TypeScript, skill-uri, subagenți, canale, programări. Cine știe ce trebuie să facă agentul poate scrie în markdown fără să atingă TypeScript. Cine construiește tool-ul îl scrie în cod, iar numele fișierului devine API-ul. E o convenție simplă care rezolvă exact problema de scalare.

Merită spus clar: asta e o constatare din materialul publicat, nu o dovadă că modelul funcționează la fel în orice companie. Rillet are un context specific, o echipă mică și un produs unde ciclul de feedback e scurt. Ce se transferă e principiul, nu rețeta.

Fluxul de la cererea clientului la pull request

Partea cea mai concretă din caz e fluxul de livrare. Echipa de customer success deschide o extensie Chrome lângă aplicația Rillet, evidențiază ce vede clientul și descrie schimbarea. Agentul din extensie capturează contextul și, dacă schimbarea e sigură și bine delimitată, o pasează unui agent de cod care scrie specificația, face modificarea și deschide un pull request. Agenții pornesc și un browser în sandbox pentru testare, atașează capturi ca dovadă, iar omul revizuiește și face merge. Dacă cere modificări, agentul reia sesiunea și le adresează.

Trei lucruri fac acest flux demn de studiat, indiferent de stack.

Primul: intrarea în flux e la persoana cea mai apropiată de client, nu la inginer. Asta reduce drastic pierderea de context. Înainte, spune materialul, cererea se împrăștia între un tichet Linear, un thread de Slack și o discuție de recuperare cu un inginer, iar până se aduna tot contextul, partea rapidă rămânea scrierea codului.

Al doilea: există o condiție explicită, „dacă schimbarea e sigură și bine delimitată". Automatizarea nu e oarbă. Asta e diferența dintre un agent util și un incident de producție.

Al treilea: omul rămâne la poarta finală. Agentul propune, omul aprobă și face merge. Nu e o formalitate, e mecanismul care ține sistemul onest.

Dacă lucrezi cu agenți în producție, verifică separat trei lucruri înainte să te entuziasmezi: ce permisiuni are agentul, ce se întâmplă când greșește și cine răspunde când ceva ajunge prost în producție. Cazul Rillet descrie un flux, nu un set de garanții. Fără propria verificare, nu poți ști dacă aceleași limite se aplică și în contextul tău.

Accesul la modele și administrarea identității

Două decizii operaționale merită extrase din material.

Prima: modelele trec prin AI Gateway, cu o singură integrare pentru Anthropic și OpenAI. Schimbarea modelului înseamnă schimbarea unui string în configurația agentului. În material, exemplul folosește zai/glm-5.3, dar nu trebuie citit ca recomandare de model. Ideea e arhitecturală: separă alegerea modelului de integrarea tehnică. Când modelul e doar un string, poți testa altă variantă pentru un task fără să rescrii nimic. Iar vizibilitatea asupra consumului devine posibilă.

A doua: accesul builderilor. Enterprise Managed Users, SSO prin Google Workspace, Directory Sync care adaugă și scoate acces pe baza atribuirilor din furnizorul de identitate. Materialul citează un om din echipa Rillet care spune că asta îl ajută să doarmă mai bine. Traducem: când agenții au acces la date și sisteme interne, guvernanța identității nu mai e opțională.

Aici se leagă direct de un subiect pe care îl tratăm separat: cum ții agenții AI în limitele permisiunilor lor. Standardizarea framework-ului rezolvă consistența, nu securitatea. Sunt două straturi diferite și e o greșeală frecventă să le amesteci.

Ce înseamnă pentru tine, antreprenor sau marketer român

Dacă ai un ecommerce, un SaaS mic sau o agenție cu echipă de 3 până la 15 oameni, întrebarea nu e „cum replicăm Rillet". Întrebarea e ce proces al tău seamănă cu fluxul lor.

Gândește-te la cererile recurente care vin din zona de customer success sau suport: schimbări de copy, mici ajustări de configurare, rapoarte, verificări repetitive. Acelea sunt candidate naturale pentru un pipeline cu agent și aprobare umană la final. Nu tot ce face un om e candidat. Doar ce e repetitiv, bine delimitat și verificabil.

Al doilea lucru de luat: standardizează înainte să scalezi. Dacă fiecare om din echipă construiește altfel, ai o problemă de mentenanță, nu de AI. Scrie convenția, pune-o într-un loc comun, fă-o obligatorie.

Al treilea: măsoară înainte să te lauzi. Rillet a triplat ritmul de livrare peste o perioadă de trei luni, cu contextul lor. Dacă nu ai o linie de bază proprie, nu poți afirma nimic despre propriile rezultate. Aici e locul unde multe echipe se entuziasmează pe baza unui studiu de caz extern și apoi raportează o senzație, nu o cifră.

Al patrulea, pentru marketeri specific: dacă folosești agenți pentru automatizări de campanii sau raportare, ai aceeași problemă de identitate și permisiuni. Un agent care are acces la contul tău de ads și la datele de conversie are nevoie de scope minim, token-uri scurte și un log clar. Materialul Vercel menționează token-uri de scurtă durată și refresh prin SDK, cu argumentul că un token scurs are o fereastră limitată de utilizare. Principiul e valid și în marketing, chiar dacă implementarea diferă.

Dacă lucrezi pe zona de vizibilitate în răspunsurile AI, cazul ăsta e și un exemplu de conținut citabil: fapte măsurate, un citat, un flux descris pas cu pas. Se leagă de ce discutăm în Google Search Console: raportul de performanță, întârziat peste 64 de ore, unde viteza datelor contează la fel de mult ca datele în sine.

Limite și scenarii ipotetice

Ce nu știm din material și n-ar trebui să presupunem: costul total al infrastructurii, cât timp a consumat echipa pentru a ajunge la acest nivel, câte pull request-uri generate de agenți nu ajung niciodată în producție, ce se întâmplă când agentul greșește o evaluare de siguranță.

Ipoteză, marcată ca atare: în multe echipe mici, câștigul real nu vine din viteza agentului, ci din faptul că fluxul forțează o definire clară a procesului. Dacă asta e adevărat, valoarea se obține chiar dacă agentul e înlocuit ulterior cu altceva. E o ipoteză, nu o concluzie susținută de datele din sursă.

A doua ipoteză: un asemenea pipeline are nevoie de un proprietar clar. Fără cineva responsabil de calitatea instrucțiunilor și de revizuirea output-ului, sistemul produce volume, nu calitate.

FAQ

E nevoie de echipă tehnică mare ca să faci asta? Nu neapărat. Cazul descrie o echipă de două persoane pentru frontend, cu builderi din afara ingineriei care contribuie prin instrucțiuni markdown. Totuși, cineva trebuie să dețină arhitectura și securitatea.

Pot folosi asta în marketing, nu doar în dezvoltare? Da, principiul se transferă: intrare aproape de client, agent care pregătește lucrul, aprobare umană la final. Fluxul exact din material e specific livrării de cod.

Ce verifici înainte să lași un agent în producție? Permisiunile minime necesare, durata de viață a credențialelor, cine aprobă rezultatul și unde ajunge logul. Fără răspunsuri clare la toate patru, nu lansa.

Arcul ALLSoft Agency

AI-ul ajută real la analiză, la structurarea unui flux și la pregătirea muncii repetitive. Ce nu face este să decidă ce merită automatizat, ce risc îți asumi și cine răspunde când ceva iese prost. Acolo intervine omul, iar în marketingul plătit acel om e media buyer-ul care citește datele, validează ipotezele și oprește lucrurile care nu funcționează.

La ALLSoft Agency, pasul concret e simplu: pornim de la procesele tale reale, identificăm unde un agent aduce câștig măsurabil și unde doar adaugă complexitate, apoi construim cu aprobare umană la fiecare poartă. Fără promisiuni de triplare a ritmului până nu avem linia ta de bază. Detalii pe allsoftagency.ro.