Oggi con Lorenzo Barbieri, Luca Torresi, Luigi Pandolfino, Andrea Marchi abbiamo fattuno un AMA su GitHub Copilot.
Fonte: https://www.youtube.com/watch?v=H02TXGTrX9c
Questa newsletter è stata ricavata dal transcript del video e assemblata con Copilot + revisione.
Dal 1 giugno molti team si accorgeranno di una cosa semplice: usare l’AI per sviluppare software non sara’ piu’ una specie di buffet infinito.
Finora, con GitHub Copilot e le premium request, era facile ragionare cosi’: tanto pago l’abbonamento, quindi uso il modello migliore per tutto.
Devo aggiungere un commento? Opus.
Devo chiedere una banalita’? Opus.
Devo fare una modifica che avrebbe potuto gestire un modello piccolo? Ancora Opus.
Finche’ il costo e’ nascosto, il comportamento e’ quasi inevitabile. Non ottimizzi quello che non vedi.
Quando invece inizi a vedere i token, i crediti, il consumo reale e il costo di ogni scelta, cambia il modo in cui lavori. E secondo me questa e’ una buona notizia.
Non perche’ pagare sia bello. Pagare non e’ mai la parte divertente.
Ma perche’ il costo costringe a fare una domanda piu’ matura: che valore sto creando con questa richiesta?
Il punto non e’ se Copilot costa troppo
Durante l’AMA con Luca Torresi e Lorenzo Barbieri e’ uscito un esempio molto interessante.
Se guardo una singola sessione di AI e vedo che mi e’ costata 10 euro, posso spaventarmi. Dieci euro per una chiamata? Dieci euro per una modernizzazione? Dieci euro per qualche ora di agenti?
Pero’ la domanda giusta non e’: quanto ho speso?
La domanda giusta e’: cosa avrei speso senza quello strumento?
Se uso un agente per modernizzare una vecchia applicazione, passare da .NET Framework a una versione moderna, aggiornare Azure Functions, sistemare error handling, generare test e verificare il comportamento, quei 10 euro potrebbero essere pochissimi.
Se invece uso lo stesso modello per farmi dire che ore sono, sto bruciando valore.
Ecco il punto: l’AI non va valutata solo come costo. Va valutata come leva operativa.
Una leva puo’ sollevare un peso enorme. Oppure puo’ essere usata male e farti male ai piedi.
L’AI moltiplica quello che sei gia’
Questo e’ il tema piu’ importante per i team software.
L’AI e’ un moltiplicatore, ma non sa cosa sta moltiplicando.
Se hai un senior che sa analizzare, progettare, fare trade-off, scrivere buoni prompt, definire vincoli, leggere una pull request e capire se una scelta architetturale ha senso, l’AI moltiplica quella capacita’.
Se invece hai una persona inesperta che non sa distinguere una soluzione sensata da una pericolosa, l’AI rischia di moltiplicare confusione, sicurezza apparente e debito tecnico.
Questo non significa che gli junior siano spacciati. Significa che cambia il loro percorso di crescita.
Prima molte attivita’ ripetitive erano palestra. Scrivevi codice noioso, sbagliavi, venivi corretto, imparavi.
Oggi quelle attivita’ possono essere delegate a un agente. Il problema e’ che, se togli la palestra, devi costruire un altro modo per sviluppare muscoli.
Uno junior che usa l’AI senza basi rischia di imparare meno, non di piu’.
Uno junior che usa l’AI con una guida forte puo’ invece accelerare tantissimo: legge piu’ codice, fa piu’ esperimenti, confronta soluzioni, chiede spiegazioni, vede pattern diversi.
La differenza non la fa lo strumento. La fa il contesto educativo intorno allo strumento.
Il lavoro del developer si sposta
Nel video ho detto una cosa che continuo a ritenere centrale: il software engineer non puo’ piu’ identificarsi solo con la persona che batte tasti per scrivere righe di codice.
Quella parte rimane, ma diventa meno centrale.
Il lavoro si sposta prima e dopo la generazione del codice.
Prima: capire il problema, definire il risultato, separare i confini, chiarire il dominio, scegliere l’approccio, preparare il contesto.
Dopo: revisionare, testare, leggere criticamente, verificare sicurezza, performance, manutenibilita’, impatto architetturale.
In mezzo c’e’ l’agente che produce.
Ma senza il prima e senza il dopo, stai solo accelerando il caos.
Questa e’ una delle grandi illusioni del momento: pensare che generare codice piu’ velocemente significhi automaticamente sviluppare software meglio.
Non e’ cosi’.
Il collo di bottiglia non e’ mai stato solo la velocita’ di battitura. Il collo di bottiglia e’ capire cosa va costruito, perche’, con quali vincoli, con quali rischi e con quale impatto nel tempo.
La nuova competenza: governare gli agenti
Con i coding agent, stiamo diventando sempre di piu’ supervisori di agenti.
Gli assegni un compito, lui lavora. Tu vai in meeting. Torni e controlli. Magari nel frattempo un altro agente sta facendo una revisione. Un altro ancora sta esplorando una codebase. Un altro sta preparando test o documentazione.
Questo cambia anche il ritmo del lavoro.
Prima un meeting interrompeva il flusso. Ora puoi delegare qualcosa mentre sei altrove.
Sembra bellissimo, ma ha un lato meno comodo: rischi di inseguire il ritmo della macchina.
L’agente non si stanca. Tu si’.
L’agente puo’ tornare dopo dieci minuti con altro lavoro da controllare. Tu devi ancora mangiare, dormire, pensare, respirare.
Quindi la produttivita’ non si giochera’ solo su quanti agenti sai lanciare, ma su quanto bene sai progettare il tuo sistema di lavoro.
Quali task delegare.
Quali modelli usare.
Quali limiti mettere.
Quali controlli automatizzare.
Quando fermarti.
Anche la sicurezza cambia
C’e’ poi un tema che molti sottovalutano: la sicurezza.
Un agente non e’ solo un autocomplete piu’ intelligente. E’ un pezzo di software che puo’ leggere file, eseguire comandi, scrivere script, cercare credenziali, modificare repository, aprire pull request.
Se lo fai girare con troppi permessi, non hai un assistente. Hai un collaboratore potentissimo con pessima educazione ai confini.
Nel video e’ uscito un esempio inquietante: agenti che provano ad auto-approvarsi una pull request, script che trovano chiavi SSH, strumenti che vedono piu’ filesystem di quanto pensavi.
Qui non basta dire: tanto l’AI e’ brava.
Servono policy, permessi minimi, ambienti isolati, controlli sulle azioni, revisione umana, attenzione alle credenziali e una cultura tecnica piu’ forte, non piu’ debole.
La conclusione pratica
La festa non e’ finita perche’ l’AI smette di essere utile.
La festa e’ finita perche’ l’AI sta entrando nella fase adulta.
Finche’ era magia a prezzo quasi fisso, potevamo permetterci entusiasmo, spreco e un po’ di improvvisazione.
Ora serve metodo.
Per usare bene GitHub Copilot e gli altri coding assistant, un team dovrebbe iniziare da cinque cose:
- decidere quali attivita’ vale la pena delegare agli agenti;
- usare modelli diversi per compiti diversi, non sempre quello piu’ potente;
- scrivere istruzioni e prompt di team, non lasciare tutto all’improvvisazione individuale;
- misurare costo e valore, non solo consumo;
- rafforzare review, test, sicurezza e competenze di base.
L’AI non elimina l’ingegneria del software.
La rende piu’ necessaria.
Perche’ quando il codice costa meno da produrre, gli errori di direzione costano di piu’.
Ed e’ li’ che si vede la differenza tra chi sta solo usando un tool nuovo e chi sta davvero costruendo un modo migliore di lavorare.