Trei tool-uri de producție în patru luni: un studiu de caz despre dezvoltarea agentică

Mare parte din ce se scrie despre dezvoltarea asistată de AI argumentează pornind de la benchmark-uri sau de la impresii. Noi preferăm să argumentăm pornind de la artefacte. Între aproximativ februarie și mai 2026, echipa noastră mică a proiectat, construit și livrat trei tool-uri open-source de infrastructură, cu agenți AI de programare făcând marea majoritate a scrisului efectiv. Toate trei sunt publice, așa că fiecare afirmație din acest articol poate fi verificată în repo-uri.

Aceasta este relatarea sinceră: ce au făcut agenții, ce nu au putut face și cât a costat.

Cele trei tool-uri

nftably — o interfață web pentru nftables care gestionează firewall-ul prin modelul lui real de obiecte: tabele → lanțuri → reguli, fiecare opțiune fiind un control tipizat și explicat. Modificările se aplică ca o singură tranzacție atomică, cu un auto-revert armat, astfel încât o regulă greșită nu te poate bloca în afara mașinii pe care tocmai o editezi. Articolul de lansare.

birdy — o interfață web pentru daemonul de rutare BIRD, care rulează chiar pe router. Modelează peer-ii, politicile, RPKI, RTBH și BFD într-o bază de date, generează întregul bird.conf și îl aplică cu același auto-revert armat — plus un dashboard live cu ce face de fapt fiecare sesiune BGP. Articolul de lansare.

meerkat — o consolă pentru Suricata a cărei pagină principală este o listă de adrese sursă, nu un potop de alerte. Îmbogățește fiecare alertă cu ASN și geografie, agregă zgomotul per sursă și transformă fiecare sursă într-o decizie: blochezi, confirmi, pui pe allowlist sau ignori. Articolul de lansare.

Fiecare este un singur binar Go cu SQLite în spate, cu interfață web încorporată, packaging pentru systemd și Docker, CI, documentație și changelog. Fiecare a pornit de la un PLAN.md scris de un om, cu milestone-uri condiționate de o singură regulă: fiecare milestone este utilizabil de sine stătător și nu poate strica nimic din ce cel anterior nu atinsese deja. Workflow-ul complet este documentat în articolul nostru despre dezvoltarea asistată de AI.

La ce au fost cu adevărat buni agenții

Tiparul a fost remarcabil de consistent în toate cele trei proiecte. Agenții au excelat la munca voluminoasă, convențională și verificabilă:

• CRUD și plumbing de UI. Handlere, formulare, liste, filtre, paginare — grosul oricărei interfețe de administrare, ca număr de linii. Aici s-a dus cea mai mare parte din scris, iar agenții au fost rapizi și de încredere.
• Renderere. Atât nftably, cât și birdy transformă un model din baza de date într-un fișier de configurare complet (ruleset-uri nft, bird.conf). Rendererele sunt munca ideală pentru agenți: funcții pure, cu o specificație precisă și teste golden ușor de scris.
• Scheletul de teste. Teste Go table-driven, fixture-uri, servere false de control-socket pentru protocolul pe linii al BIRD. Agenții au ținut acoperirea în pas cu codul, în loc să rămână în urma lui.
• Packaging și release engineering. Dockerfile-uri, fișiere docker-compose, configurații nfpm pentru deb/rpm, unit-uri systemd, workflow-uri de CI. Migăloase, bine documentate pe internet și exact genul de lucru pe care agenții îl nimeresc din prima.
• Ținerea hârtiilor la zi. CHANGELOG-uri, documentație de utilizare, actualizări de README, toate în același diff cu funcționalitatea. Agenții nu consideră documentația sub demnitatea lor, ceea ce se dovedește a fi un avantaj competitiv real față de majoritatea inginerilor, noi incluși.

Ce a rămas la oameni

Tot ce ar putea face rău cuiva, în sens larg:

• Modelele de obiecte. Ce este un „peer", ce este un „policy chain", ce este o „sursă" în agregarea din meerkat — aceste decizii modelează tot ce urmează și au fost luate de oameni, pe hârtie, înainte să înceapă generarea.
• Semantica de siguranță. Auto-revert-ul armat din nftably și birdy există pentru că un om a rămas blocat în afara unei mașini remote din cauza propriei reguli de firewall. Regula de proprietate asupra configurației — fiecare tool generează și deține întregul fișier și o spune răspicat în README — este o decizie umană în favoarea onestității, în detrimentul comodității. Birdy refuză să genereze o configurație despre care crede că este un route leak; un agent nu ar propune niciodată din proprie inițiativă acea constrângere, pentru că datele de antrenament sunt pline de configurații care fac leak.
• Decizia de a nu construi ceva. Agenții nu se opun niciodată extinderii scope-ului; ceri, construiesc. Fiecare „nu" din aceste proiecte — fără fleet management, fără scriere pe mai multe routere, fără expunerea fiecărui buton din BIRD — a venit de la un om.
• Review-ul. Fiecare diff a fost citit. Disciplina de review care face totul posibil este un subiect în sine — vezi ghidul nostru practic pentru review-ul codului scris de AI.

Ce ne-a surprins

E normal ca planul să diverge de ce s-a livrat — și e în regulă. PLAN.md-ul lui birdy se deschide acum cu o notă care recunoaște exact cum s-a îndepărtat realitatea de plan: metricile Prometheus și lookup-urile PeeringDB au fost livrate, deși planul scotea metricile în afara scope-ului; alertarea a crescut mult peste „un webhook, fără SMTP", ajungând la Slack, Discord, email și destinații filtrate; mai multe tabele din schema planificată nu au fost construite niciodată, iar funcționalități livrate — BMP, expandare IRR, RTBH, BFD, graceful restart — nu apar nicăieri în plan. Păstrăm documentul oricum, cu tot cu nota de divergență. Planul este o consemnare a intenției de design, nu un contract, iar diferența dintre plan și produs este locul unde s-a făcut de fapt inginerie.

Blocajul s-a mutat, definitiv. Cu scrisul aproape gratuit, resursele noastre rare au devenit timpul de design și atenția la review. Zilele au semănat mai puțin cu „scrie funcționalitatea" și mai mult cu „specifică precis milestone-ul, apoi citește diff-urile cu atenție". Schimbul merită, dar este un schimb, nu un prânz gratuit.

Avântul e un risc în sine. Când implementarea e atât de ieftină, tentația e să construiești totul. Condiționarea milestone-urilor și lista de non-obiective sunt ce a ținut trei tool-uri mici și terminate, în loc de un singur tool întins la nesfârșit și abandonat.

Costurile, sincer

• Timpul de review e real. Cea mai mare parte din timpul de scris recuperat a fost reinvestit în citit diff-uri. Sărind peste pasul ăsta ajungi să livrezi pe un firewall codul plauzibil-dar-greșit al unui agent.
• Calitatea de beta e reală. Toate cele trei README-uri spun „așteaptă-te la bug-uri" și chiar așa e. Aceste tool-uri nu au trecut prin anii de călire pe care infrastructura de rutare și firewall îi merită — dezvoltarea agentică a comprimat construcția, nu maturizarea.
• Judecata nu se comprimă. Tool-urile au durat luni în loc de — realist — un an și ceva pentru o echipă de mărimea noastră. Ce nu a devenit mai rapid a fost să știi ce să construiești și când e greșit. Asta rămâne meseria.

Concluzii

1. Argumentează pornind de la artefacte — trei repo-uri publice valorează mai mult decât orice benchmark; verifică-ne afirmațiile în cod
2. Agenții dețin volumul — CRUD, renderere, teste, packaging, documentație; oamenii dețin modelele, siguranța și scope-ul
3. Condiționează milestone-urile pe încredere — fiecare utilizabil de sine stătător, niciunul capabil să-l strice pe cel dinainte; asta a permis unui software beta să atingă routere reale
4. Așteaptă-te ca planul să diverge — păstrează-l oricum și consemnează sincer diferența
5. Economiile se reinvestesc — timpul de scris devine timp de design și review; bugetează-l sau nu te apuca

Dacă vrei acest workflow — guardrail-urile, disciplina milestone-urilor, practica de review — instalat în propria ta echipă, te putem ajuta.