Vai al contenuto
SwankyForge
SwankyForge
Tutti gli insights
Articolo9 min di lettura

Con un assistente IA in ogni repository, automatizziamo i controlli e lasciamo cinque decisioni alle persone

Come lavora il team di ingegneria con gli assistenti di coding IA: cosa viene eseguito automaticamente a ogni modifica, cosa decide sempre una persona e cosa non abbiamo ancora misurato.

La maggior parte del lavoro di ingegneria nei nostri repository oggi inizia con un assistente di coding IA che scrive una prima bozza. Niente di tutto ciò va in produzione sulla parola dell'assistente. Questa nota descrive la configurazione così com'è nel repository dietro questo sito, perché è quella che possiamo mostrare pubblicamente. Elenca anche le decisioni che lasciamo alle persone, e il numero che non possiamo ancora darvi.

La versione breve, se state acquistando

Siamo un piccolo laboratorio di due ingegneri, con specialisti aggiunti per progetto. Un assistente IA lavora accanto a entrambi. Scrive bozze di codice, test, documentazione e resoconti di routine. Controlli automatici vengono eseguiti a ogni modifica e bloccano quelle che violano una regola. Una persona legge ogni modifica prima che venga integrata. Niente arriva in produzione o al pubblico senza un sì esplicito.

Cosa ne ottenete: gli stessi due ingegneri coprono una parte maggiore del lavoro di routine che i team piccoli tendono a saltare, come test, documentazione e controlli di rilascio. Questo lascia più budget per le parti che richiedono giudizio: scegliere la metrica, decidere se vale la pena costruire un modello e inserirlo nel vostro processo.

Cosa non dichiariamo: un dato di accelerazione. Non ne abbiamo misurato uno, e le prove esterne dicono che le accelerazioni dichiarate dagli interessati sono inaffidabili. Le ultime sezioni dicono cosa misureremmo e cosa significa per un cliente.

Cosa dice la ricerca: il guadagno non è lo strumento

Quattro studi del 2025 hanno orientato il modo in cui abbiamo impostato tutto questo.

  • Il programma DORA di Google ha intervistato quasi 5.000 professionisti della tecnologia per il rapporto 2025. Il 90% usa l'IA al lavoro, e più dell'80% ritiene che li abbia resi più produttivi. Eppure il 30% dichiara poca o nessuna fiducia nel codice che genera. La sintesi del rapporto è che l'IA "amplifica ciò che c'è già": i team solidi migliorano, i team in difficoltà vedono i loro problemi intensificarsi.
  • Il Technology Report 2025 di Bain ha rilevato che i team che usano assistenti di coding IA vedono guadagni di produttività del 10–15%. Alcune aziende riportano il 25–30%, ma solo quando l'IA è abbinata a una riprogettazione dell'intero processo. Un motivo per cui il primo numero è piccolo: scrivere e testare il codice occupa circa il 25–35% del tempo dall'idea al lancio.
  • Lo Stack Overflow Developer Survey 2025 ha rilevato che l'84% degli intervistati usa o intende usare strumenti IA, e il 46% non si fida dell'accuratezza dell'output. La frustrazione più comune era un output quasi giusto, ma non del tutto.
  • METR ha condotto uno studio randomizzato con 16 sviluppatori open source esperti su 246 attività reali. Con gli strumenti IA consentiti, le attività hanno richiesto il 19% di tempo in più. Gli sviluppatori si aspettavano un'accelerazione del 24%, e dopo erano ancora convinti di essere stati più veloci del 20%. Gli autori avvertono che il risultato è specifico del loro contesto: progetti open source grandi e maturi e sviluppatori con esperienza limitata dello strumento usato.

Letti insieme, gli studi dicono tre cose. Adottare un assistente è facile. Il guadagno dipende dal processo che lo circonda. E l'impressione di chiunque sulla propria velocità non è una prova. Per questo mettiamo l'impegno nel processo (istruzioni, controlli e punti di approvazione) e non nella scelta dello strumento.

Cosa fa l'assistente nel nostro repository

Usiamo Claude Code. Cinque elementi rendono prevedibile il suo lavoro.

Istruzioni di progetto. Un file nella radice del repository dice all'assistente cosa si trova dove, quali regole sono rigide e quali comandi eseguire. È versionato come il codice, quindi una modifica alle regole compare in review come qualsiasi altra modifica. Chiunque abbia accesso al repository può leggere esattamente cosa è stato detto all'assistente.

Skill per compiti ricorrenti. Una skill è una breve procedura scritta che l'assistente segue per un tipo di compito. Ne abbiamo otto: redigere un case study con il suo record di prova, scrivere la bozza di una nota di ingegneria, scrivere la bozza di un post per la pagina aziendale, generare un profilo per una piattaforma esterna, controllare un testo per nomi riservati e dati personali, un audit in sola lettura dei segnali di affidabilità del sito, un report settimanale di stato e lo smistamento delle richieste in arrivo. Ogni skill dichiara dove si ferma. Nessuna termina con la pubblicazione di qualcosa.

Hook. Le azioni dell'assistente passano attraverso script scritti da noi. Dopo che modifica un file, quel file viene scansionato per nomi riservati e dati personali, e un riscontro rimanda l'assistente a correggerlo. Prima che possa eseguire un git commit o un push, una guardia esegue la scansione di riservatezza e il lint delle affermazioni su ciò che sta per lasciare il working tree. Qualsiasi riscontro blocca il comando. Un normale hook git pre-commit applica gli stessi controlli ai commit fatti a mano.

CI a ogni push e pull request. La pipeline esegue lint, controlli di tipo e una build, poi tre guardie:

  • la scansione di riservatezza, su sorgenti, contenuti e HTML generato. Se manca la sua configurazione, fallisce invece di passare in silenzio;
  • il lint delle affermazioni, che rifiuta un elenco di superlativi e di frasi che prendono in prestito autorevolezza;
  • il validatore dei contenuti, che rifiuta un case study senza record di prova, un reference design che dichiara numeri misurati e una cifra in homepage che non rimanda al caso da cui proviene.

Queste regole sono meccaniche di proposito. Un assistente produce rapidamente testo plausibile, e il plausibile-ma-sbagliato è esattamente il fallimento che descrivono i sondaggi. Una regola eseguita a ogni commit non dipende dal fatto che qualcuno, persona o modello, si ricordi di stare attento.

La pipeline dei contenuti. Tutto ciò che è destinato al pubblico passa per tre cartelle: bozze, approvato, pubblicato. Una skill può scrivere nelle bozze e da nessun'altra parte. Solo il titolare esegue il passo di approvazione, che riesegue entrambe le scansioni prima di spostare il file. La pubblicazione è manuale: un post approvato viene inviato al titolare come testo pronto da incollare, e una nota approvata va online solo con il successivo push approvato su main. Questa nota ha seguito quel percorso. Un assistente ne ha scritto la bozza a partire dai file del repository, le scansioni sono state eseguite su di essa, ed è arrivata su questa pagina dopo l'approvazione di una persona.

Cosa non deleghiamo mai

Cinque decisioni restano alle persone, qualunque cosa sappiano fare gli strumenti.

  1. Concordare la metrica con il cliente. Quale numero definisce il successo, come si misura e quale soglia conta come lavoro concluso. La scriviamo nel contratto prima che inizi l'addestramento. Un assistente può elencare metriche candidate. Non può sapere su quale agirà il vostro business.
  2. Giudicare se il ML ne vale la pena. A volte la risposta onesta è una regola, un report o un cambiamento di processo. "Niente ML per ora" è una raccomandazione che facciamo, ed è un giudizio sulla vostra situazione, non un compito di generazione di testo.
  3. Approvare i rilasci. Un merge su main fa il deploy. Niente viene pushato su main senza un sì esplicito del titolare, e i permessi dell'assistente escludono il force push.
  4. Parlare con il cliente. Call, risposte scritte, cattive notizie. Una skill può scrivere la bozza di una risposta a una richiesta; una persona la legge, la modifica e la invia. Nessuno script contatta un lead.
  5. Decidere cosa diventa pubblico. Post, note, profili, case study e rilasci di codice. La pipeline rende la pubblicazione un passo deliberato anziché un default.

Il filo comune è la responsabilità. Ognuna di queste decisioni ha conseguenze di cui qualcuno deve rispondere, e quel qualcuno deve essere una persona. In un progetto, è l'unico ingegnere nominato che resta sul lavoro dall'inizio alla fine.

Cosa non abbiamo misurato

Non abbiamo un dato prima/dopo sulla nostra produttività, e non ne citeremo uno. Il motivo è il risultato di METR: sviluppatori più lenti del 19% credevano di essere più veloci del 20%. Un'impressione, compresa la nostra, non è una misurazione.

Se pubblicheremo un numero, porterà la stessa etichetta sulle prove dei nostri case study (misurato, stimato o illustrativo), e verrà da registrazioni come queste, raccolte su una finestra dichiarata:

  • tempo dall'apertura di una issue a una modifica rivista e integrata, per tipi di attività comparabili;
  • quota di modifiche integrate annullate o corrette entro 14 giorni;
  • problemi intercettati da hook e CI prima del merge, rispetto ai difetti trovati dopo;
  • tempo di review per modifica, perché la review è il punto in cui l'output di un assistente costa tempo alle persone;
  • ore per milestone rispetto alla stima del nostro calcolatore.

Fino ad allora, l'affermazione onesta è più circoscritta. I controlli vengono eseguiti a ogni modifica, e le cinque decisioni sopra le prendono persone.

Cosa significa per voi

Si fa una parte maggiore del lavoro di routine. Con un budget fisso, test, documentazione, monitoraggio e controlli di rilascio sono le prime cose che i team piccoli tagliano. Un assistente le rende più economiche da scrivere, e i controlli le rendono difficili da saltare.

Il prezzo va al giudizio. Le nostre tariffe e le ore dietro ogni ruolo sono pubblicate nella pagina dei prezzi, e il calcolatore mostra l'aritmetica. Le ore che contano di più sono quelle spese sulla metrica, sulla valutazione e sull'integrazione con il vostro processo: le parti che nessun assistente fa al posto nostro. Se non siete sicuri che il ML sia la risposta giusta, il teardown gratuito dà un primo verdetto in sei domande, e una breve discovery a pagamento chiude la questione prima di addestrare qualsiasi modello.

Potete ispezionare la configurazione. Il repository sta nella vostra organizzazione dal primo giorno. Se un assistente ci lavora, anche le sue istruzioni e i suoi controlli stanno in quel repository, accanto alla storia di ogni modifica, dove potete leggerli.

Fate a ogni fornitore le stesse domande. Quali strumenti IA vedranno il vostro codice e i vostri dati, e a quali condizioni? Quali controlli vengono eseguiti a ogni modifica, e bloccano o si limitano ad avvisare? Chi approva un rilascio? Il fornitore ha misurato la propria accelerazione, e come? Le risposte dicono se l'IA nel loro processo amplifica la disciplina o la sua mancanza.

Fonti

Ha un processo che costa troppo?

Ce ne parli. La prima call è gratuita e, se l'AI non è la risposta, glielo diciamo.

Parliamo del suo caso