Metaminds
EN RO
Contactați-ne

Metaminds ResearchAI Dark Factory · Open source

uzi: o fabrică AI cu luminile stinse.

Intră specificații. Ies pull requesturi. O fabrică de software open source care funcționează cu luminile stinse: etichetați un issue, aprobați planul, iar uzi deschide un pull request trecut prin review, fără să atingă vreodată main.

1.200+Rulări
finalizate
20+ mld.Tokeni
consumați
MITLicență
open source
Coridorul unei fabrici cu luminile stinse: un panou iluminat din spate cu textul „uzi — Specs in. Pull requests out. / Plan · Build · Ship”, un robot umanoid alb etichetat „Lead” care supraveghează hala și o bandă de brațe robotice etichetate „coder” și „tester” care asamblează lăzi de cod strălucitoare, de culoarea chihlimbarului, pe fundalul unui oraș noaptea

01Ideea

Intră issue-uri,
ies pull requesturi.

Chiar și cu agenții de astăzi, „programarea cu AI” vă ține la volanul unei singure sesiuni: o porniți, o urmăriți cum lucrează, o corectați când deviază și porniți chiar dumneavoastră următoarea sarcină. Banda rulantă sunteți dumneavoastră.

uzi inversează această logică. Unitatea de lucru este un issue, nu un mesaj. uzi citește issue-ul, planifică modificarea, o implementează, îi face review și deschide un pull request dintr-un branch nou, în timp ce dumneavoastră rămâneți în afara buclei până la cele două decizii care contează.

P1 Issue-ul este unitatea de lucru Etichetați un issue pe forge-ul dumneavoastră, iar uzi îl tratează ca pe o comandă de onorat: citește, planifică, implementează, face review și deschide un pull request.
P2 Forge-ul rămâne sursa de adevăr Munca apare acolo unde echipa dumneavoastră se uită deja: ca issue-uri, branch-uri și pull requesturi, sincronizate în ambele sensuri.
P3 Workeri izolați Fiecare rulare se execută în propriul container, care vede un singur checkout al repository-ului și o singură rulare, așa că o greșeală strică un branch, nu mașina dumneavoastră.
P4 Două puncte de decizie umană Dumneavoastră aprobați planul și faceți merge la pull request. Tot ce se întâmplă între ele ține de hala fabricii, cu luminile stinse.
Cum livrează uzi un issue: issue-ul intră în preluare și planificare, trece prin poarta de aprobare umană a planului, apoi un coder implementează, în timp ce reviewerul, auditorul, testerul și fact-checkerul validează în paralel până când modificarea rezistă; un branch și un pull request ajung apoi la review uman și merge. Un pipeline roșu declanșează o rulare Fix CI, iar comentariile din pull request declanșează o reluare a lucrului.
Cum livrează uzi un issue: de la un issue etichetat, prin poarta planului, bucla dintre coder și revieweri, un pull request și review-ul uman, până la merge. Două decizii rămân umane; tot ce este între ele ține de hala fabricii.

02Pipeline-ul

Două decizii rămân umane.
Restul ține de hala fabricii.

Întâi planul Un worker preia issue-ul și elaborează un plan. Rularea se oprește la o poartă de aprobare. Aprobați planul sau îl respingeți motivat, iar uzi îl reface. Nu se scrie nimic până nu dați undă verde.
Implementare și review După aprobare, lead-ul trimite un coder, apoi pornește în paralel reviewerul, auditorul, testerul și fact-checkerul, revenind la coder până când rezultatul rezistă. Urmăriți în direct fluxul fiecărui agent.
Branch și pull request, niciodată main La final, uzi deschide un branch și un pull request, le leagă de rulare și de card și mută issue-ul în review uman. Prin concepție, branch-ul main nu este atins niciodată.
Board-ul uzi: issue-uri etichetate, sub formă de carduri care se mută între coloane sincronizate cu etichetele din forge
Board-ul este ușa de intrare: un kanban pentru fiecare repository, cu issue-urile din forge-ul dumneavoastră. Coloanele de lucru sunt etichete din forge, așa că mutarea unui card reetichetează issue-ul.

03Echipa

Un lead care deleagă și specialiști care îi verifică munca

O sarcină nu este gata doar pentru că un agent spune asta. Lead-ul orchestrează, iar o echipă organizată pe roluri implementează și validează în paralel, reluând bucla până când modificarea rezistă.

Lead Orchestrare

Planifică rularea și deleagă în loc să facă totul singur, parcurgând planul aprobat câte o etapă pe rând.

Coder Implementare

Scrie modificarea pentru etapa curentă și face commit pentru fiecare etapă ca increment separat, cu review propriu.

Reviewer · Auditor Validare

Citesc diff-ul în paralel, urmărind corectitudinea, securitatea, reutilizarea și simplificarea.

Tester · Fact-checker Validare

Pun modificarea la încercare și îi verifică afirmațiile în raport cu codul existent, revenind la coder până când rezistă.

O rulare oprită la poarta de aprobare a planului, cu planul propus afișat
Poarta planului: uzi se oprește și cere acordul înainte de a scrie ceva.
Fluxul de activitate al rulării, grupat pe agenți, fiecare cu pasul și etapa curentă
Un flux de activitate pentru fiecare agent: extindeți orice intrare pentru a urmări în direct transcrierea agentului respectiv.

04Responsabilitate

Fiecare rulare este evaluată, măsurată și contabilizată

Nimic dintr-o rulare nu este o cutie neagră. Rularea este evaluată ulterior, urmărită cât timp se desfășoară și contabilizată până la ultimul token.

Evaluatorul rulăriiO retrospectivă opțională citește întregul istoric al rulării și oferă un verdict și recomandări concrete. Este un sfat, nu o poartă: nu modifică niciodată codul.
EtapeLead-ul bifează fiecare increment pe măsură ce este livrat, așa că și o rulare lungă arată progresul real, nu doar un indicator de încărcare.
Cost completFiecare rulare raportează tokenii de intrare și de ieșire, cache hit-urile, durata și costul în dolari, defalcate pe fază și pe agent, pe propriul dumneavoastră token Anthropic.
Pauză la limităDacă atinge o limită în timpul lucrului, uzi face o pauză cu numărătoare inversă, apoi reia singur când se resetează fereastra, pe același branch, fără o nouă aprobare.
Evaluarea unei rulări finalizate: un verdict, o retrospectivă și statistici de tokeni și costuri
Evaluatorul rulării: un verdict și o retrospectivă pentru fiecare rulare finalizată.
Statisticile de cost și de tokeni ale unei rulări, defalcate pe fază și pe agent
Costul și tokenii fiecărei rulări, defalcate pe fază și pe agent.

05Stadiul actual

Încă în alfa, dar funcționează —
își construiește singur următoarea versiune.

1.200+
Rulări finalizate până acum
20+ mld.
Tokeni consumați pe parcurs
3
Forge-uri: GitLab, GitHub, Forgejo
0
Commituri pe main, prin concepție

Iar partea cea mai interesantă: uzi îl construiește pe uzi. Se creează issue-uri, se aprobă planuri și se deschid pull requesturi, așa că o parte tot mai mare a fabricii se scrie singură, în timp ce un om face review-ul.

06Sarcini programate

Fabrica se construiește singură

Îndreptate spre propriul repository, automatizările permanente ale lui uzi formează o buclă de autoîmbunătățire prin care uzi își caută propriile bug-uri, își consolidează testele, își păstrează documentația corectă și își propune următoarea funcționalitate. Când nu are nimic care merită livrat, fiecare sarcină se încheie cu un simplu raport, așa că o săptămână liniștită nu produce pull requesturi goale.

Sarcină Ce face Frecvență
bug-triage parcurge issue-urile etichetate bug zilnic
planned-sweep parcurge issue-urile etichetate Planned zilnic
docs-hygiene corecturi mecanice ale documentației săptămânal
test-improvement adaugă doar teste noi, fără cod de producție săptămânal
bug-hunt un audit aprofundat al unui subsistem, o singură corecție țintită săptămânal
self-improve analizează codul și deschide un pull request de autoîmbunătățire ~2 zile
feature-bingo generează idei pentru o funcționalitate nouă și o propune săptămânal

Prin feature-bingo, fabrica își proiectează singură următoarea mașinărie.

O dată pe săptămână, citește ideile existente, verifică ce există deja ca să nu se repete și propune exact o funcționalitate nouă și concretă — problema pe care o rezolvă, o schiță a modului în care funcționează și locul în care se integrează — sub forma unui pull request. O parte din roadmap-ul lui uzi sosește sub formă de pull requesturi pe care le găsiți dimineața.

Pagina de programări, cu automatizările permanente, inclusiv feature bingo

07Urmăriți-l de oriunde

Urmăriți hala fabricii din
terminal sau de pe telefon.

Vizualizarea unei rulări în TUI-ul uzi: echipa, etapele, indicatoarele limitelor de utilizare și transcrierea în direct a agentului
uzi tui — echipa, etapele, indicatoarele limitelor de utilizare și transcrierea în direct, în terminalul dumneavoastră.
uzi pe telefon: dashboard-ul general
Întreaga interfață web este responsivă: puteți aproba un plan direct de pe telefon.

08De unde a pornit

Un proiect de cercetare AI, lansat ca open source

uzi a început ca inițiativă de cercetare AI la Metaminds și de atunci a fost dezvoltat atât în timpul programului, cât și în timpul liber. Metaminds tratează open source-ul cu seriozitate, așa că decizia de a-l publica pe uzi a fost ușoară. Are licență MIT și se instalează cu un helm install pe Kubernetes sau cu un docker compose up pe un laptop.

Utilizați pe propria răspundere.

uzi rulează agenți autonomi care vă citesc codul, execută comenzi în workerii lor și deschid pull requesturi folosind propriii dumneavoastră tokeni pentru modele. Rulați-l pe repository-uri care vă aparțin. Prin concepție, controlul rămâne la dumneavoastră: verificați planul înainte de a-l aproba și diff-ul înainte de a face merge — uzi deschide pull requesturi, dar nu le face niciodată merge și nu atinge niciodată main.

Încercați fabrica

Dați‑i o stea. Încercați să‑l stricați. Spuneți‑ne.

uzi este open source și evoluează rapid. Încercați-l, deschideți issue-uri și cereri de funcționalități, trimiteți pull requesturi și ajutați-ne să stabilim încotro se îndreaptă fabrica de acum înainte.