Era l’inizio del 2025.
La funzione standard di completamento del codice in GitHub Copilot era ormai consolidata. ChatGPT stava sostituendo la ricerca su Google per le ricerche di riferimenti al codice — e forniva persino suggerimenti piuttosto utili sui blocchi di codice — ma per lo più ci facevamo una risata della programmazione assistita dall’IA perché era o troppo semplicistica, o priva di un contesto di codice evidente, oppure ridicolmente complicata.
Tutto questo è cambiato nella primavera del 2025, quando alcuni importanti aggiornamenti ai modelli di base hanno reso molto più affidabili gli strumenti di programmazione basati sull’IA come Cursor, GitHub Copilot Agent, Windsurf, Claude Code e Cline. Le nostre critiche non sembravano più reggere, e se non ci fossimo adeguati, saremmo finiti nel ridicolo.
Noi di Bitly Engineering ci siamo resi conto che o ci buttavamo a capofitto o saremmo rimasti indietro.
Nel maggio 2025 abbiamo lanciato un’iniziativa di formazione per il reparto di ingegneria di Bitly. L’obiettivo: far passare i nostri 60 ingegneri dall’autocompletamento di GitHub Copilot a pratiche di programmazione completamente assistite da agenti IA il più rapidamente possibile.
Sapevamo che non potevamo fermare il mondo e mandare tutti a seguire un corso di formazione, e in effetti la formazione formale non esisteva nemmeno ancora, così abbiamo deciso di crearne una nostra.
Il nostro approccio è stato quello di sviluppare un programma di “IA nell’ingegneria” che combinasse struttura, formazione informale, sperimentazione e valutazioni, partendo dal presupposto che avremmo apportato modifiche man mano che andavamo avanti. Dovremmo asfaltare la strada mentre ci passiamo sopra.
Questa è la nostra storia: cosa ha funzionato, cosa no e cosa abbiamo imparato lungo il percorso.
Scegliere gli strumenti di IA
I nostri criteri di selezione degli strumenti di IA erano molto chiari: Metti a disposizione degli ingegneri strumenti all’avanguardia. Con gli strumenti giusti, potremmo esplorare le nostre potenzialità, imparare insieme e migliorare rapidamente. Abbiamo scelto strumenti che offrissero un buon equilibrio tra maturità e usabilità e che avessero il minor impatto possibile sul nostro ciclo di sviluppo. La rosa dei candidati comprendeva:
- Cursor (livello aziendale con modalità privacy abilitata)
- ChatGPT (Piano Team per la chat con IA generica)
La privacy era un punto fermo. Siamo stati molto rigorosi sui nostri principi di privacy, includendo la conformità SOC2 come requisito imprescindibile, attivando la modalità privacy in Cursor per garantire la totale assenza di conservazione dei dati e verificando che i dati dei prompt non venissero utilizzati per l’addestramento dei modelli.
Il lancio
Abbiamo dato il via al progetto nel maggio 2025 e ci siamo prefissati i seguenti obiettivi:
- Fai in modo che tutto il team acquisisca dimestichezza con l’IA: tutti dovrebbero sapere come utilizzare gli strumenti di programmazione basati sull’IA nei propri flussi di lavoro
- Condividi le tue esperienze e documenta le migliori pratiche
- Valuta costantemente l’impatto
- Crea una cultura dell’apprendimento e della sperimentazione
Un punto di forza fin dall’inizio: Sessioni “a spalla”
Una delle nostre strategie più efficaci è stata quella di organizzare delle sessioni “Over the Shoulder” (OTS), ovvero sessioni di lavoro in cui gli ingegneri condividevano i loro schermi e mostravano in tempo reale come si lavora con l’IA nella pratica.
Abbiamo chiesto ai volontari che già utilizzano agenti di IA di condividere il loro lavoro, dalla configurazione degli strumenti, ai prompt e alle regole, fino a come hanno perfezionato i risultati quando qualcosa è andato storto. Nelle prime due settimane abbiamo organizzato sessioni quotidiane in diversi fusi orari, sia a livello globale che regionale. Man mano che il numero di partecipanti cresceva, siamo passati a sessioni settimanali e poi mensili.
Si è trattato di vere e proprie sessioni di lavoro su progetti reali, come lo sviluppo di funzionalità, la rifattorizzazione, i test e il debug, non di demo patinate. Abbiamo cercato di promuovere un clima di apertura e sincerità in queste sessioni affidando le prime sessioni a ingegneri più esperti che, a loro volta, non avevano ancora familiarità con gli strumenti di programmazione per l’IA. Questo ha contribuito a creare uno spazio sicuro in cui le persone potessero confrontarsi con l’incertezza in pubblico. Questo ha ribadito una verità importante: qui non ci sono ancora esperti, ma solo persone che stanno imparando.
We tried to encourage a sense of openness and vulnerability in these sessions by having more senior engineers who were also new to the AI coding tools run the early sessions.”
– Michael Richman, VP, Engineering at Bitly
Cosa abbiamo imparato: Il lato positivo
Gli strumenti che hanno vinto:
- Cursor è diventato famoso per la sua perfetta integrazione con l’IDE, il contesto completo del codice e la funzione di chat direttamente all’interno dell’ambiente di sviluppo.
- ChatGPT è diventato il punto di riferimento per le discussioni di architettura, la documentazione, la redazione di testi tecnici e come alternativa quando altri strumenti si “bloccavano”.
- GitHub Copilot si è rivelato utile per la revisione delle pull request, individuando piccoli problemi che ai revisori umani potrebbero sfuggire. Man mano che il programma si è evoluto, Copilot ha aggiunto le “Agent Tasks” e modelli più avanzati, dimostrando ancora una volta la sua efficacia e la sua attualità.
- Claude Code si è poi rivelato una scelta di prim’ordine per chi lo ha adottato, dimostrandosi eccellente nell’affrontare problemi complessi.
Abbiamo provato anche ChatGPT Codex e ne siamo rimasti entusiasti per il suo potenziale, ma la mancanza di immagini personalizzate lo ha reso inutilizzabile per le nostre esigenze. OpenAI, ti aspettiamo con ansia…
I punti di forza dell’IA:
- Attività ripetitive e operazioni di “trova e sostituisci” su codici di grandi dimensioni
- Calcolo della copertura di test per il codice esistente
- Lavorare su parti del codice che non conosci
- Documentazione e redazione tecnica
- Brainstorming e discussioni sull’architettura
- Test unitari del backend secondo modelli consolidati
Un ingegnere è riuscito a rifattorizzare 275 file in un unico progetto durante una hackweek. Altri due hanno usato l’IA per creare in una settimana una bozza completa di un pannello di controllo amministrativo interno. Non si è trattato di piccoli miglioramenti in termini di produttività. In alcuni casi si stavano rivelando rivoluzionarie.
Detto questo, l’esperienza ha sicuramente messo in luce anche alcune difficoltà.
These weren’t minor productivity gains. They were proving transformative in some cases.”
– Michael Richman, VP, Engineering at Bitly
Cosa abbiamo imparato: Il lato negativo
Non è andato tutto liscio, ma gli ostacoli ci hanno insegnato tanto quanto i successi.
I problemi di qualità sono emersi fin dall’inizio. L’IA riusciva a generare codice velocemente, ma gran parte di esso richiedeva una profonda rifattorizzazione per soddisfare i nostri standard. Spesso gli ingegneri dedicavano alla revisione e alla correzione del codice tanto tempo quanto ne avrebbero impiegato per scriverlo da soli.
È necessaria la revisione da parte di una persona. Il codice generato dall’intelligenza artificiale non dovrebbe essere inviato per la revisione senza che prima sia stato controllato dall’«autore» umano.
I limiti di contesto erano una vera seccatura. Gli strumenti spesso perdevano il filo delle conversazioni lunghe, costringendoci a ricominciare da capo o a ripetere le spiegazioni, il che rappresentava un vero ostacolo per le modifiche complesse.
Il lavoro sul frontend è stato più impegnativo. L’IA tendeva a complicare troppo le soluzioni, a ripetere il codice e a non rispettare gli standard dell’interfaccia utente, mentre le attività di backend hanno dato risultati migliori.
Cosa abbiamo imparato: L’incerto
Oltre alle questioni tecniche, abbiamo riscontrato delle difficoltà di tipo culturale.
Alcuni si sentivano sotto pressione all’idea di usare l’IA e temevano di essere sostituiti. Altri hanno interpretato il programma come un’adozione “forzata” piuttosto che come un’esplorazione. Alcuni ingegneri temevano di perdere il contatto con il proprio mestiere, soprattutto i più giovani che stanno ancora acquisendo le competenze di base.
Per chi non è uno sviluppatore, in particolare per i tecnici e gli analisti del controllo qualità, le indicazioni non erano chiare. In che modo un ingegnere QA dovrebbe utilizzare gli strumenti di programmazione basati sull’intelligenza artificiale? E gli analisti di dati? Condividere le conoscenze è stato più difficile del previsto. Anche oggi, il flusso di suggerimenti e buone pratiche non è ancora come vorremmo.
Ma abbiamo trovato una metafora che ci ha aiutato: Pensa all’IA come a un ingegnere di talento all’inizio della sua carriera. Veloce, a volte sbagliato, va sempre ricontrollato. Quella frase mi è rimasta impressa. Ha creato le giuste aspettative e ha spostato il focus dalla “sostituzione” alla “collaborazione”.
La sfida di misurare il successo
È difficile valutare l’impatto degli strumenti di programmazione basati sull’intelligenza artificiale. Si basa sul confronto “prima e dopo” del numero di righe di codice scritte? Quante richieste di pull? Quanti commit ci sono? Velocità del team?
Sappiamo che c’è un impatto, ma non sappiamo bene quanto sia. Dire che «il 30% del nostro codice è ora scritto dall’IA» dà un falso senso di certezza. Abbiamo adottato un approccio misto alla valutazione, combinando valutazioni soggettive e oggettive.
A livello soggettivo, abbiamo intervistato gli ingegneri su precisione, velocità, sicurezza nell’affrontare codice sconosciuto, carico cognitivo e soddisfazione generale. Abbiamo chiesto un parere sull’IA prima e dopo il programma.
Obiettivamente, stiamo valutando tutti i fattori sopra menzionati sia prima che dopo l’adozione dell’IA, pur riconoscendo che si tratta di un’analisi orientativa piuttosto che definitiva.
Misurare gli aumenti di produttività è complicato: ci sono troppe variabili e i dati non sono abbastanza affidabili. Per ora, l’andamento del mercato e il sentiment degli operatori sono i nostri migliori indicatori.
Sono passati sei mesi…
La corsa agli strumenti
A sei mesi dall’inizio, non c’è ancora un vincitore indiscusso nella corsa agli strumenti. Ogni strumento è perfetto per un compito specifico, e molti ingegneri ne usano più di uno. Personalmente preferisco Claude Code per i lavori di programmazione più impegnativi e Cursor quando ho bisogno di valutare il codice e ottenere un output ben formattato.
Sono spuntati anche nuovi strumenti. È stato rilasciato Codex, sono state lanciate le attività di GitHub Copilot Agent e il panorama continua a cambiare sotto i nostri piedi. Ancora oggi esitiamo a sottoscrivere contratti annuali per gli strumenti di programmazione basati sull’intelligenza artificiale, per paura che ne emerga uno diverso come chiaro vincitore.
Insiemi di regole
Stiamo lavorando sui “Rule Sets“, ovvero dei file di configurazione che insegnano all’IA i nostri standard di codifica, i modelli architetturali e le insidie più comuni. Stiamo sviluppando una serie di regole sia per gli standard di codifica interni che per attività specifiche, come la valutazione dei ticket di Jira o l’esecuzione di un “controllo qualità manuale” in base alle modifiche apportate al codice.
Definire le aspettative
Stiamo anche chiarendo meglio le nostre aspettative. Anche se all’inizio l’uso dell’IA era incoraggiato ma non obbligatorio, come organizzazione ci stiamo evolvendo fino a richiedere che l’uso dell’IA diventi una competenza fondamentale per tutti gli ingegneri e per tutti i dipendenti.
Adattamento continuo
Entro agosto 2025, gli strumenti di IA sono passati gradualmente dall’essere un “progetto speciale” a diventare semplicemente parte integrante del nostro modo di lavorare, soprattutto grazie al valore immediato che hanno dimostrato una volta che le persone hanno imparato a usarli.
Un buon indicatore era che quando a qualcuno finivano le richieste Premium su uno strumento di programmazione, improvvisamente aveva l’impressione di non riuscire più a svolgere il proprio lavoro con la stessa efficacia. Certo, non siamo ancora arrivati a un’adozione totale, ma ormai quasi il 95% degli ingegneri di Bitly usa regolarmente gli strumenti di programmazione basati sull’IA.
We haven’t achieved universal adoption, but there is now close to 95% utilization of AI coding tools by Bitly engineers on a regular basis.”
– Michael Richman, VP, Engineering at Bitly
Abbiamo smesso di considerare gli strumenti di programmazione basati sull’IA come qualcosa di sperimentale e abbiamo iniziato a integrarli nei flussi di lavoro quotidiani degli ingegneri: pianificazione, programmazione, rifattorizzazione, analisi interna, documentazione e revisione del codice. L’obiettivo ora non è “completare l’implementazione” degli strumenti di programmazione basati sull’IA, ma continuare a evolversi insieme a loro. Ora il compito è quello di adattarsi continuamente.
E adesso?
Abbiamo scelto l’approccio “imparare man mano” e, in questo senso, stiamo ancora imparando.
Dobbiamo fare i conti con alcune considerazioni sui costi. Siamo un team di ingegneri relativamente piccolo, ma pagare per tre strumenti che si sovrappongono in gran parte non è una buona strategia a lungo termine. Pensiamo di ridimensionarci presto.
Ora ci concentreremo sull’approfondimento delle competenze e sulla sistematizzazione di ciò che abbiamo imparato. Questo significa sviluppare corsi di formazione strutturati per chi desidera una guida più pratica, perfezionare le linee guida per codificare gli standard e migliorare il modo in cui misuriamo l’impatto.
Questo significa anche spingersi oltre i limiti per aumentare la produttività:
- Qual è il modo migliore per gestire più sessioni di agenti contemporaneamente?
- Come si fa a trovare un equilibrio tra i risultati generati dagli agenti di programmazione basati sull’IA e la verificabilità?
- Come possiamo combinare più agenti per coordinare attività in parallelo?
- Quanta autonomia possiamo concedere ai nostri agenti di programmazione basati sull’intelligenza artificiale?
Un tempo mi prendevo gioco dei risultati prodotti dagli strumenti di programmazione basati sull’intelligenza artificiale. Di solito rimango sbalordito (e solo ogni tanto mi viene da ridere).
Nel bene e nel male, questa è la nuova realtà dell’ingegneria del software, e gli strumenti non potranno che diventare sempre più potenti d’ora in poi. Per me, la questione non è se adottare strumenti di programmazione basati sull’IA, ma come continuare a evolversi insieme a loro e massimizzarne il valore.
