Sviluppare un'Applicazione Enterprise Completa con l'Agente di Codifica harnext

“L’IA scrive la maggior parte del nostro codice” sembra uno slogan di startup. Può essere reale per un’applicazione enterprise — clienti live, fatturazione live, un monorepo dove un merge sbagliato costa soldi? In QualityUnit lo è. Ecco il percorso di dieci mesi di prove, e le regole che lo rendono possibile.

TL;DR: In dieci mesi, il lavoro scritto da agenti è passato dai primi PR sperimentali a 133 di 144 PR di sviluppo uniti a maggio (92%) — verificato da un audit forense a tre vie di tutti i 1.409 PR uniti, fino ai commit trailer e un’ispezione manuale di ogni PR non marcato del 2026. Non è accaduto “lasciando che l’IA codifichi”: è accaduto aggiungendo regole — una configurazione di harness con risk tier, una pipeline di agenti in stadi con cicli di revisione limitati, percorsi protetti e un umano che gestisce ogni merge. Le regole sono il prodotto. E con un context engine che alimenta gli agenti, lo stesso lavoro ora costa circa il 30% in meno per compito (misurato qui ).

Cosa serve davvero

Non uno strumento. Una pipeline, un file di policy e un gate — gestiti da harnext .

La pipeline: agenti in stadi, un umano

L’harness è harnext — l’harness per agente di codifica open-source e provider-agnostic di QualityUnit. Nel nostro monorepo di produzione, ogni issue che entra nella pipeline esegue lo stesso percorso di stadi di agenti attivati da CI, il suo progresso tracciato attraverso etichette che un umano può leggere a colpo d’occhio:

Due dettagli contano più del numero di stadi. Il ciclo è limitato: i difetti trovati nella revisione tornano allo stadio di implementazione un numero limitato di volte — gli agenti convergono o escalano a un umano, non si bloccano. Nulla inizia al buio: prima di scrivere una riga, l’agente che implementa deve caricare le convenzioni del progetto ed emettere un blocco di conferma che i revisori possono controllare.

Il file di policy

L’altra metà è una policy leggibile da macchina: ogni percorso nel repo classificato in risk tier, ogni tier con gate eseguibili. CI la legge; la policy di merge la legge; agli agenti viene data una briefing su di essa. Non è un consiglio:

Percorsi protetti — migrazioni, pagamenti, auth — sono file che nessun agente può toccare. I confini architettonici sono applicati, non suggeriti. Togli queste regole e un agente di codifica è un generatore molto veloce di passività plausibili.

Dieci mesi, un grafico

Il percorso di adozione, misurato dal repository stesso.

Il grafico conta, per ogni mese, quanti PR di sviluppo uniti portano qualsiasi segnale duro dell’agente — il footer dell’agente di codifica, le etichette della pipeline, la convenzione di tier dell’harness, i trailer di co-autore dei commit, le email dei commit dell’agente, o l’account della pipeline stesso come autore. I PR di dependency-bot (circa l'8% di tutti i merge) sono completamente esclusi dal grafico — non sono né lavoro umano né lavoro di agente di codifica. Abbiamo controllato i segnali in tre modi indipendenti: metadati PR per tutti i 1.409 merge, trailer a livello di commit su oltre 5.000 commit, e un passaggio forense manuale su ogni singolo PR non marcato del 2026. Tre letture contano:

L’entusiasmo svanisce; l’infrastruttura rimane. L’era del 2025 era adozione ad-hoc e personale — e oscillava esattamente come fanno le abitudini personali: 44% un mese, a malapena il 4% a novembre quando gli utenti più pesanti hanno fatto una pausa. L’harness ha cambiato la forma della curva: entro un mese dall’arrivo dei risk tier, la quota misurata ha saltato all'89%; con la pipeline completa ha raggiunto il 92% e vi è rimasta. Ogni strato di regole ha aumentato l’adozione più di quanto l’entusiasmo di qualsiasi individuo abbia mai fatto. I due toni raccontano la stessa storia all’interno della quota dell’agente: la banda leggera è sviluppatori che si abbinano con l’agente a mano; la banda scura — lavoro che ha eseguito la pipeline completa da issue a PR revisionato — appare solo quando l’harness si attiva, e a maggio porta la maggior parte del lavoro dell’agente.

Abbiamo ispezionato il resto, PR per PR. Per aprile-giugno 2026, i PR senza alcun marcatore si scompongono in: automazione di dependency-bot, lavoro dell’agente la cui unica attribuzione è sopravvissuta nei trailer dei commit, e un residuo di cambiamenti plausibilmente scritti a mano — circa l’11% dei merge non di automazione. Quindi la frase onesta è: ~89% dei merge di sviluppo reali nell’ultimo trimestre mostrano coinvolgimento verificabile dell’agente — e anche questo è un minimo, poiché l’assistenza IA a livello di editor non lascia traccia. Abbiamo anche inviato auditor scettici nei tre mesi più deboli, PR per PR: il conteggio di novembre è salito da 1 a 3 provati (più 3 sospetti di stile), quello di gennaio è sceso da 10 a 8 dopo aver catturato due falsi positivi, e dicembre è stato confermato esattamente — con una piega: per volume di codice, gli otto PR marcati di dicembre hanno consegnato il 39% delle linee inserite quel mese. L’agente stava già scrivendo le grandi feature; il conteggio semplicemente non poteva vederlo. L’adozione inoltre non è uniforme: alcuni sviluppatori eseguono quasi al 100% con assistenza dell’agente, un paio ancora per lo più scrivono a mano — la pipeline porta una quota crescente comunque.

La qualità non è andata indietro. La stessa finestra ha spedito cambiamenti di Tier-3 — integrazione del provider LLM, lavoro adiacente ai pagamenti, un’espansione i18n — sotto gate che sono diventati più ristretti nel periodo, non più lenti. E quando abbiamo misurato la coerenza della revisione dell’agente direttamente, 21 di 22 agenti di revisione indipendenti hanno raggiunto lo stesso verdetto sullo stesso PR.

Allora chi è l’autore?

L’articolazione migliore di dove questo lascia l’umano viene da una tesi di ingegneria che ha studiato lo sviluppo guidato da harness su un progetto di grado aviazione:

Nel momento in cui un cambiamento ha raggiunto l’autore umano, i problemi di qualità di routine erano stati risolti — la revisione dell’autore si è concentrata su decisioni architettoniche e di livello di dominio. Il merge era la decisione dell’autore. L’autorialità del codice unito rimane con l’autore umano, indipendentemente da quale attore abbia prodotto la bozza iniziale.

— Štefan Moravík, Design and Implementation of a Drone Mission Planning Module for Airport Lighting Inspection (tesi, 2026)

Questo è l’accordo anche in produzione: gli agenti fanno la bozza e il lavoro di qualità di routine; l’umano fa architettura, giudizio di dominio e possiede il merge.