Latest / M365.FM – Podcast su Microsoft 365, Copilot e IA in italiano / Basta debugging a toppe: la modalità agente di GitHub Copilot per .NET e Azure (Doppiaggio IA)

Transcript

Basta debugging a toppe: la modalità agente di GitHub Copilot per .NET e Azure (Doppiaggio IA) · M365.FM – Podcast su Microsoft 365, Copilot e IA in italiano

0:00
Pronto per dieci giorni di Microsoft 365, Copilot EA, azzurre le persone che stanno plasmando il futuro del lavoro?
0:07
Questo gennaio, M365 con ritorne e puntiamo ancora più in alto.
0:13
Unisciti a noi per sessioni dal vivo, demo reali e conoscenze pratiche da MVP ed esperti del settore in tutto il mondo.
0:18
Niente slide generiche, niente giardin finito.
0:22
Affrontiamo le sfide reali, Copilot Studio, agenti EA, Fabric, sicurezza, governance e automazione.
0:28
Che tu sia un professionista IT, uno sviluppatore, un leader aziendale, ci sono sessioni pensate per te.
0:35
Con dieci giorni interi puoi esplorare molteplici tecnologie e connetterti con una community globale.
0:40
Guardala al vivo e porta approfondimenti pratici nella tua organizzazione.
0:45
Gennaio 2027, dieci giorni, un'unica community Microsoft.
0:49
Le registrazioni sono aperte.
0:51
Vai su m365con.net e assicurati il tuo posto oggi stesso.
0:55
Il sito è m365con.net
0:58
Iscriviti ora su m365con.net e ci vediamo.
1:03
Dal vivo a gennaio.
1:05
Se hai mai aperto una soluzione sentendoti sopraffatto dalla rete di file, riferimenti e bug pronti ad assalirti, non sei solo.
1:12
La maggior parte degli sviluppatori lavora in modo reattivo, riparando qui e correggendo.
1:15
La modalità agente di GitHub Copilot mira a mantenere un contesto più ampio e a coordinare le modifiche tra i file.
1:19
In questo video mostreremo come appare quel flusso di lavoro all'interno di un progetto reale podcast.net e Azure.
1:25
Analizzeremo una soluzione dal vivo mostrando il prima e dopo l'intervento dell'agente.
1:28
Vedrai come generare codice su più file con meno impegno, risolvere errori tra file più velocemente e usare specifiche in linguaggio naturale per definire funzionalità.
1:36
Prima di arrivare a questo iniziamo con il costo nascosto del ciclo di debug in cui molti di noi vivono ogni giorno.
1:40
Il costo nascosto del debug attento ti siedi per correggere un errore che sembra abbastanza semplice.
1:46
L'applicazione non viene compilata e la console segnala una riga nel tuo file di progetto principale.
1:50
Modifichi il metodo, ricompili e pensi di aver risolto finché lo stesso messaggio riappari in una forma leggermente diversa.
1:56
Passa un'altra mezz'ora prima di individuare il vero problema.
1:59
Una dipendenza mancante è nascosta in un'altra cartella di progetto.
2:02
Quando il riferimento viene corretto e ridistribuisci gran parte del tuo pomeriggio svanita e rotoppi.
2:07
Il lavoro sulle funzionalità che avevi pianificato, rimandato domani.
2:09
Questo schema è così comune che sembra normale?
2:12
In superficie sta andando avanti perché ogni bug che l'inni sembra una vittoria.
2:16
In pratica stai girando in tondo.
2:17
Il ciclo è scrivi codice, compila errore, correggi, ripeto.
2:21
Le ore svaniscono inseguendo una scea di cause ed effetto e il risultato netto è un progresso reattivo anziché miglioramenti significativi.
2:27
Quanti di voi hanno perso un pomeriggio in questo preciso ciclo?
2:29
Lascia un commento veloce e leggerò le risposte principali.
2:32
Ciò che rende estenuante questo ciclo è che gli strumenti attorno a noi avanzano, mentre il modello no.
2:36
Gli editor aggiungono nuove funzioni, i framework si evolvono, le integrazioni diventano più profonde, ma il debugging richiede ancora un approccio reattivo.
2:44
È come cercare di fermare un incendio che avanza con un secchio d'acqua.
2:47
Ogni focolaio viene gestito sul momento, ma le condizioni sottostanti che l'hanno scatenato rimangono, garantendo quasi certamente il prossimo incendio.
2:52
E con ogni cambio di scheda il costo nascosto aumenta.
2:55
Passi da una classe di servizi a un file di configurazione, poi salti su un grafo delle dipendenze.
3:00
Ogni spostamento ti strappa dal filo logico che stai seguendo, costringendoti a un reset mentale.
3:04
Non sono solo i secondi spesi a cambiare finestra, è il carico mentale di ricostruire il contesto ancora e ancora.
3:10
Nel corso della giornata quei piccoli resetti si accumulano, diventando un pesone.
3:12
Per i singoli sviluppatori la stanchezza si manifesta come frustrazione e tempo sprecato.
3:17
Per i team che lavorano su progetti enterprise l'impatto si moltiplica.
3:20
I cicli dei debug fanno deviare gli obiettivi degli sprint, ritardano i lanci delle funzioni e creano un backlog che cresce più velocemente di quanto si riduca.
3:26
L'aumento del debito tecnico è solo un altro effetto collaterale delle ore persa a spegnere incendi.
3:31
Molti team riferiscono che una gran parte del loro tempo di sviluppo viene prosciugata dal debugging reattivo.
3:36
Non è la parte entusiasmante dell'ingegneria.
3:37
Nessuno pianifica una roadmap basandosi su inseguire 5 volte la stessa incompatibilità di dipendenza.
3:41
Eppure è qui che finisce la larghezza di banda, settimana dopo settimana.
3:44
Quando correggere gli errori diventa la definizione di progresso, costruire nuove funzionalità diventa secondario all'architettura, soffre silenziosamente in background.
3:51
La scomoda verità è che il debugging frammentario non rallenta solo le cose.
3:55
Rafforza una cultura della reazione invece che della progettazione.
3:58
Passi il tempo a spegnere fiamme, non a costruire sistemi.
4:02
Questo può mantenere il prodotto vivo a breve termine, ma limita quanto un team può scalare e con quanta sicurezza può rilasciare.
4:08
Soffermiamoci su questa immagine, spegnere incendi.
4:09
Corri al punto critico, butti acqua e vai avanti.
4:12
Il problema non è che gli sviluppatori non siano la vefa, lo sono.
4:16
Il problema è che le fiamme non si fermano mai davvero.
4:18
Si spostano solo, divampando i nuovi file, nuovi progetti, nuove configurazioni, mantenendo tutti in modalità risposta invece che modalità creazione.
4:25
Questo solleva la domanda.
4:26
Cosa succede se il ciclo non dipende solo da te?
4:28
Se le parti ripetitive, il loop di tracciamento, cambio finestra e patch potessero essere gestite diversamente mentre tu rimani concentrato sul costruire?
4:36
Perché, sebbene lo stress e spegnere incendi sia ovvio, c'è un altro punto di pressione che non abbiamo ancora toccato.
4:41
Il peso vero arriva quando il tuo progetto non è più un solo file o un solo modulo.
4:44
E' quando la correzione necessaria coinvolge più livelli contemporaneamente.
4:48
Immagina di sederti ad aprire una soluzione in cui la logica si estende su diversi progetti, servizi e librerie.
4:55
La parte che ti serve vive in tre posti diversi e tenerne traccia a mente è una battaglia a sé.
5:01
Chaos Multify contro il controllo del contesto tramite IA.
5:04
Quando i progetti abbracciano più livelli, la vera sfida non è scrivere codice e far sì che tutte le parti mobili restino collegate.
5:10
Che la tensione tra Chaos Multify e il controllo del contesto guidato dagli IA appare più chiaramente.
5:16
Prendi una grande soluzione .NET con una dozzina o più di progetti.
5:19
Qualsiasi nuova funzionalità tocca solitamente diversi livelli, una volta solo.
5:22
Un controller in un posto, un servizio in un altro, un insieme di file di configurazione che risiedono oltrove.
5:27
Prima di scrivere una sola riga, passi il tempo a tracciare riferimenti e controllare le dipendenze,
5:31
sperando che una piccola modifica non causi rotture a catena inaspettate.
5:36
Questo flusso di lavoro non è un'eccezione.
5:37
È la norma dell'applicazione Enterprise, specialmente quando entrano in gioco i servizi e le integrazioni Azure.
5:42
La struttura di questi sistemi non è piatta.
5:45
Interfacce, mappature di dependency injection e riferimenti tra progetti giocano tutti un ruolo.
5:49
Con Azure nel mix alcune dipendenze escono completamente dalla cartella della soluzione
5:53
Function App, Binding del Service Bus, Impostazioni delle Risorse, Connessioni di Storage, Connessioni di Store.
5:59
Devi coordinarti tra il codice nel Tweed, i file di configurazione su disco e i servizi definiti nel cloud.
6:03
A nessuno di loro importa che tu vorresti fare meno click.
6:06
Ogni volta che cambi contesto, bruci energia per ricostruire il quadro ed insieme.
6:10
La maggior parte di noi cerca di gestire quel contesto nel mare di lavoro.
6:13
All'inizio è gestibile, ma man mano che il progetto cresce, gli errori si insinuano.
6:16
Aggiungi un nuovo metodo nel servizio, ma dimentichi la sua registrazione.
6:19
Il programma è una funzione Azure e solo dopo ti accorgi che il binding non è stato aggiunto a host.json, al template di deployment.
6:25
Non le ti avvisa fino a runtime quando sei impegnato a fare debugging invece di costruire.
6:28
Il codice in sé non è la parte difficile.
6:30
È il coordinamento tra i file?
6:32
Tutti conoscono la sensazione di saltare da una scheda all'altra.
6:34
Da un controller a un servizio, poi a un modello, poi nei file di configurazione e di nuovo indietro,
6:38
solo per perdere il filo del perché avevi aperto quel file.
6:42
È una piccola interruzione ripetuta decine di volte al giorno.
6:45
Queste interazioni si accumulano, creando attrito che rallenta il progresso reale.
6:48
Il risultato è un rilascio più lento, non perché scrivere sia lento, ma perché mantenere tutto sincronizzato ruba concentrazione.
6:54
Questo sovraccarico cresce nei progetti cloud first.
6:56
Azure distribuisce le impostazioni chiave in più punti, file di configurazione locali, variabili d'ambiente, modelli ARM, OBSEP, pipeline, CISCD.
7:07
Ciò che sembra una singola richiesta di funzionalità spesso si estende su quattro livelli di estrazione.
7:11
La complessità non è facoltativa, è integrata nel modo in cui funziona l'ecosistema.
7:15
Ora è qui che la modalità agente si presenta come un potenziale cambiamento.
7:18
Invece di lasciare a te tutta l'orchestrazione, è progettata per mantenere un contesto più ampio tra più file.
7:22
Ciò significa che quando richiede una modifica in un livello, non ignora gli altri.
7:27
Nella demo creerò una nuova funzione Azure e mostrerò come l'agente aiuta generando il corpo del metodo,
7:31
producendo la configurazione di binding, aggiornando host e suggerendo persino la corretta registrazione di AI.
7:38
Di solito è un processo in più passaggi disperso in diversi file.
7:41
Un agente può semplificarlo in un unico flusso.
7:43
Non si tratta di sostituire il tuo giudizio, ma di eliminare la contabilità ripetitiva
7:47
affinché tu possa concentrarti sulle scelte di progettazione reali.
7:50
Gli esseri umani possono tenere uno schema approssimativo nella mente o abbozzato su una lavagna.
7:54
Unia può tracciare i dettagli file per file senza perdere il filo del discorso.
7:58
Ciò che sembra un enorme carico cognitivo per noi è solo contesto di base per l'agente.
8:02
La differenza pratica sta nel passare dal destreggiarsi tra schede frammentate a modifiche orchestrate che rimangono sincronizzate.
8:07
Mostrerò anche la pull request o il diff creato dall'agente durante la demo,
8:10
così potrai vedere esattamente quale modifiche sono state apportate.
8:12
Questa visibilità è importante.
8:14
Hai il controllo totale per rivedere e approvare,
8:16
mentre il lavoro sporco di aggiornare più file viene svolto per te.
8:19
Quindi invece di passare un pomeriggio a cucire frammenti insieme,
8:21
dirigi la modifica una volta, confermi gli aggiornamenti generati e passi alla progettazione di alto livello.
8:26
Il sollievo non sta solo nei clic con i tasti risparmiati,
8:29
vanno a rimanere concentrati sulla risoluzione di problemi reali
8:31
invece di ricostruire come si collegano una dozzina di file.
8:34
Questo vantaggio appare più chiaramente quando le cose si rompono,
8:36
perché anche con una gestione del contesto più forte i sistemi falliscono,
8:39
le configurazioni divergono, i riferimenti non corrispondono e divergono.
8:42
Ed è qui che inizia il prossimo test,
8:43
come gli errori vengono rintracciati e risolti una volta che emergono.
8:47
Dalla caccia agli errori alle correzioni autonome.
8:49
Pensa a quante volte ti imbatti in un messaggio di errore
8:51
che punta direttamente a un singolo file.
8:53
Segui lo stack trace fino al metodo che nomina,
8:55
fai una piccola regolazione e premi ricostruisci.
8:58
Sembra la soluzione ovvia,
8:59
finché lo stesso errore non appare di nuovo,
9:01
solo in una forma leggermente diversa.
9:03
È allora che ti rendi conto che lo stack trace mostrava solo il sintomo.
9:05
Il problema reale risiede altrove,
9:07
forse in una classe di supporto nascosto in un file di configurazione
9:10
che non aprivi da tutta la settimana?
9:12
Ogni sviluppatore ha affrontato quel tipo di depistaggio.
9:14
Ciò che sembra il problema non è dove risiede la soluzione.
9:17
Questo consuma tempo rapidamente.
9:18
Regoli una cosa, ricompili, attendi.
9:20
Poi un nuovo errore ti accoglie
9:21
portandoti a un altro file, un'altra modifica, un'altra ricompilazione.
9:24
Il ciclo sembra produttivo,
9:26
perché ti muovi, scrivi, ricompili,
9:27
ma sotto la superficie è più tentativi ed errori
9:30
che una vera risoluzione.
9:32
Quel ciclo puoi inghiottire ore
9:33
lasciandoti con minuscole correzioni superficiali,
9:35
ma senza veri progressi sulla funzionalità da cui sei partito.
9:38
Il vero costo qui è l'opportunità.
9:41
Mentre sei intrappolato nel ritmo di ricostruzione e riprova,
9:43
non risolvi i problemi aziendali
9:44
né rilasci le funzionalità che i tuoi utenti attendono.
9:48
Lo slancio viene speso in congettura invece che nella progettazione.
9:50
Sembra di essere attivi al momento,
9:52
ma quelle ore non portano a molto oltre
9:53
a evitare che il sistema si rompa.
9:56
In un team, questo movimento superficiale rallenta tutto
9:58
e crea un arretrato di funzionalità che continuano a slittare.
10:02
Ecco dove un flusso di lavoro basato su agenti
10:03
inizia a sembrare diverso.
10:04
L'idea non è fermarsi alla singola riga evidenziata dallo stack trace.
10:08
Invece, è progettato per mantenere il contesto a livello di sistema,
10:11
chiedendosi non solo cosa debba fare questo file,
10:13
ma quale sequenza di modifiche serva
10:15
tra le parti collegate per ripristinare la coerenza.
10:18
In pratica, significa che potresti vederlo proporre modifiche
10:20
che abbracciano più file.
10:22
Ad esempio, vedrai nella demo che quando un metodo richiede modifiche
10:25
può suggerire modifiche corrispondenti in configurazioni correlate
10:27
o template di distribuzione,
10:29
invece di lasciarti a cercarle.
10:30
Questo è il salto dall'autocompletamento a qualcosa di più ampio.
10:34
L'autocompletamento finisce le righe,
10:35
un agente coordina tra i file e quel coordinamento
10:37
conta soprattutto quando gli errori non si trovano direttamente in un unico post.
10:40
Prendiamo un comune scenario azur.
10:42
Hai creato una nuova function app,
10:44
ma una volta distribuita il trigger della coda fallisce
10:46
perché il binding non corrisponde alla firma del metodo.
10:47
Normalmente scavi nei log, capisci quale binding è rato,
10:51
aggiusti il JSON della funzione a mano.
10:53
Magari alteri anche il tuo template di infrastruttura
10:55
se lì c'è un valore non corrispondente.
10:58
Ogni passaggio, una caccia separata e ogni correzione
10:59
inesco come altre esecuzioni di test.
11:01
Con la modalità agente, il flusso di lavoro è diverso.
11:04
Può proporre la modifica del codice,
11:05
generare il corretto binding JSON della funzione
11:07
e mostrare modifiche per gli scritti di distribuzione
11:09
se non sono lineati.
11:10
Tu rivedi, confermi e vai avanti
11:12
senza passare ora a mettere insieme ogni livello.
11:14
La fiducia è la chiave qui.
11:15
Nessuno dovrebbe sentirsi come se stessero avvenendo
11:17
modifiche invisibili in background.
11:19
Ecco perché il flusso di revisione è importante.
11:20
In questa demo lo esamineremo insieme.
11:22
L'agente suggerisce le modifiche coordinate.
11:24
Apriremo il diff per esaminare esattamente ciò che è stato generato.
11:27
Eseguiremo i nostri unit test.
11:28
Convalideremo la building locale
11:29
e solo allora sceglieremo se accettare o rifiutare le modifiche.
11:33
Questo ciclo di convalida ti mantiene in pieno controllo
11:35
eliminando al contempo il lavoro più ripetente.
11:37
Vale la pena sottolineare che gli agenti
11:38
possano aiutare a muoversi più velocemente
11:40
ma non sostituiscono le buone pratiche di ingegneri.
11:42
Dovresti comunque considerare il code review e la CI come controlli rinunciabili.
11:45
Lascia che lia riduca il tempo dedicato al lavoro investigativo
11:48
ma mantieni i controlli automatizzati
11:49
e la revisione umana come rete di sicurezza.
11:51
Questo equilibrio risolve il problema della fiducia
11:53
e è sicura che l'aumento di velocità non compromette la stabilità.
11:56
La differenza di velocità non è teorica.
11:58
Laddove la caccia agli errori e le patch manuali
11:59
possono consumare mezza giornata
12:00
i suggerimenti coordinati possono ridurla a pochi minuti.
12:03
E il tempo recuperato fluisce nel lavoro
12:05
su cui vuoi davvero spendere le tue energie.
12:07
Le funzionalità che i tuoi utenti notano
12:09
sono le decisioni architetturali che migliorano la tua base di code.
12:11
Specie di spegnere incendi durante l'esecuzione
12:13
puoi progettare con sicurezza fin dall'inizio.
12:15
Quindi il ciclo di debug non deve più definire la tua giornata.
12:18
Con un agente che suggerisce aggiornamenti tra diversi file
12:20
passi da una ricerca casuale a un ritmo di revisione e approvazione.
12:24
Smetti di girare a vuoto tra gli errori
12:25
e inizi a trattare il debug come un passaggio strutturato
12:27
e quasi automatizzato del tuo flusso di lavoro.
12:30
Questo cambiamento libera spazio cognitivo
12:32
e ore di calendario per costruire funzionalità
12:33
non solo per correggere difetti.
12:34
E una volta che correggere gli errori diventa meno una caccia ai sintomi
12:39
come potresti iniziare intere funzionalità
12:41
nello stesso modo strutturato.
12:43
Immagina se lo stesso flusso di lavoro
12:44
che propone correzioni coordinate
12:45
potesse anche prendere una specifica in linguaggio naturale
12:48
e modellarci attorno a una struttura funzionante.
12:50
È qui che inizia la fase successiva dello sviluppo.
12:53
Sviluppo guidato dalle specifiche senza il carico di nuovo.
12:56
Uno dei cambiamenti più interessanti
12:57
arriva quando smetti di pensare solo in termini di file e metodi
13:00
iniziando invece a formulare il lavoro in linguaggio semplice.
13:03
È qui che entra in gioco lo sviluppo guidato dalle specifiche senza i costi di...
13:06
Immagina di scrivere una semplice richiesta di funzionalità.
13:07
Aggiungi un flusso di lavoro di reportistica
13:10
che generi gli epiloghi mensili, gli archivi
13:11
e li renda disponibili tramite una pagina di amministrazione.
13:14
Invece di ottenere solo alcuni frammenti isolati
13:16
ottieni una struttura funzionante già mappata in tutta la tua applicazione.
13:20
Controller impostati, modelli creati, servizi registrati
13:22
e configurazione collegata.
13:24
Passare dalla descrizione dell'intento
13:26
al vedere un'impalcatura concreta apparire nel tuo progetto
13:28
è ciò che rende questo approccio finalmente pratico
13:30
anziché teorico, anziché teorico.
13:32
Nelle configurazioni tradizionali
13:33
lo sviluppo spec-first ha una reputazione pesante.
13:35
Nelle grandi organizzazioni solitamente significa lunghi documenti di requisiti
13:38
fogli di progettazione multipagine
13:40
e diagrammi rigidi che rallentano tutti.
13:42
Hanno senso in settori regolamentati o in team distribuiti a livello globale
13:45
ma per la programmazione quotidiana
13:46
la maggior parte degli sviluppatori lieviti.
13:47
Scrivere e mantenere specifiche dettagliate comporta costi
13:50
per cui nessuno ha pazienza o tempo.
13:52
È un lavoro extra che si aggiunge al rilascio delle funzionalità
13:54
e con l'avvicinarsi delle scadenze
13:55
quei cicli supplementari vengono solitamente sacrificati.
13:58
Ironia è evidente, agli sviluppatori piace pensare per grandi linee.
14:00
Conoscere la struttura in anticipo è rassicurante.
14:04
Il problema non è l'intenzione ma la manutenzione.
14:06
Una volta che le specifiche iniziano a non essere più sincronizzate con la realtà
14:09
il mantenimento diventa un peso.
14:10
Ecco perché gran parte del lavoro reale vira verso l'improvvisazione
14:13
piuttosto che verso una progettazione completa
14:15
anche nelle aziende che tecnicamente sostengono una pianificazione rigorosa.
14:17
Un flusso di lavoro basato su agenti offre un'alternativa.
14:20
Invece di richiedere un documento di design rifinito
14:22
puoi aiutare a tradurre una specifica in linguaggio semplice
14:24
in una struttura di base che puoi perfezionare.
14:26
Non servono diagrammi UML o mappe di interfaccia scritte a mano.
14:29
puoi semplicemente dire di creare un modulo di reportistica
14:31
con un nuovo endpoint API, collegarlo allo storage
14:34
e proteggerlo con un accesso basato sui ruoli.
14:36
Il sistema genera una base tra i file nella tua soluzione Don't Met.
14:40
Nella demo leggerò ad alta voce una specifica in linguaggio semplice.
14:43
Poi mostrerò i file prodotti dall'agente, controller, modelli e registrazione dei servizi
14:47
e indicherò i punti che richiedevano ancora un perfezionamento manuale.
14:51
In questo modo potrei giudicare la qualità da solo.
14:53
Questo crea una via di mezzo tra due modalità di sviluppo.
14:56
Da un lato c'è il vibe coding, veloce a forma libera ma fragile per i sistemi a lungo termine.
15:01
Dall'altro lato c'è la progettazione basata sulle specifiche, affidabile ma incredibilmente lenta.
15:06
Con il supporto dell'agente delinei sull'idea con parole naturali,
15:08
la struttura appare e puoi iterare quasi velocemente quanto nel vibe coding
15:12
mantenendo i vantaggi di una struttura organizzata.
15:14
Prendiamo di nuovo quel flusso di lavoro di reportistica.
15:16
Di solito dovresti creare il modello, costruire il servizio dati, collegare il controller,
15:21
configurare la sicurezza e connettere tutto all'avvio.
15:23
Ciò significa saltare da un file all'altro sperando che la correnza venga mantenuta.
15:27
Con questo approccio l'imparcatura viene posizionata tutta in una volta.
15:29
Il vero risparmio deriva meno dallo scrivere meno righe e più dall'evitare errori tra i file.
15:34
Come dimenticare di registrare un nuovo servizio dopo averlo già creato.
15:37
Certo c'è sempre la questione dello stile.
15:39
Nian porrà del codice standard e ignorerà le convenzioni.
15:41
In pratica gli agenti spesso rispecchiano i pattern di progetto esistenti e nei loro suggerimenti.
15:46
Nella demo vedrai entrambi i lati.
15:48
Punti in cui hai rispecchiato perfettamente la struttura dei nostri controller
15:51
e punti in cui le sue ipotesi non erano allineate.
15:54
Questo mix è importante.
15:55
Saprai cosa puoi fidarti e cosa devi ancora correggere.
15:58
Il risultato finale non è codice per confezione.
16:00
Sembra ancora il tuo progetto solo con meno lavoro manuale di configurazione.
16:04
Mantieni la velocità potendo contare su una base solida
16:06
che potrai perfezionare per la crescita futura.
16:09
Invece di essere limitato agli architetti con pazienza per i diagrammi
16:11
il lavoro di specifica diventa uno strumento per ogni sviluppatore
16:14
che voglia sperimentare rapidamente senza sacrificare l'ordine.
16:18
E quando questo diventa parte del flusso quotidiano
16:20
la specifica smette di sembrare un passaggio aziendale formale
16:22
e diventa una sorta di stenografia leggera.
16:25
Descrivi le tue intenzioni, il sistema getta le basi
16:27
e tu ti concentri sulla definizione dei dettagli.
16:29
L'impatto maggiore non deriva solo dal codice generato
16:31
ma da ciò che risparmia di tempo significa settimana dopo settimana.
16:35
Più ore per le funzionalità, meno fatica nella configurazione.
16:38
Questo ci porta direttamente alla domanda
16:39
che sta più a cuore a ogni sviluppatore.
16:41
A cosa corrispondono effettivamente questi cambiamenti in termini di produttività?
16:45
Il ritorno in termini di produttività.
16:47
La vera domanda non è se si risparmino pochi minuti qua e là
16:49
ma come più piccoli spostamenti si accumulino in ore significative durante la settimana.
16:55
Questo è il ritorno in termini produttivi.
16:56
Recuperare tempo che solitamente sfugge inosservato
16:58
tra cambio di contesto, cicli di build ripetuti e patch manuali.
17:02
La maggior parte degli sviluppatori accetta queste piccole perdite come parte del lavoro.
17:05
Dieci minuti qui a cercare un valore di configurazione
17:07
e altri 15 a rieseguire dopo un riferimento mancato
17:09
saltare tra i file per controllare le connessioni.
17:12
Presi singolarmente sembrano trascolabili.
17:14
Ma sommati durante un intero sprint determinano quanto valore effettivo viene consegnato.
17:18
Ciò che sembra un movimento di routine
17:19
nasconde un vero rallentamento sui tempi di consegne.
17:22
Il peso nascosto non è nei tempi di compilazione
17:23
o nella velocità di digitazione.
17:25
È nel ritmo di stop and go imposto alla tua concentrazione.
17:27
Ogni volta che passi da un file all'altro il tuo cervello si resetta.
17:31
Quella resetta ha un costo.
17:32
Delegare le correzioni ripetitive a un agente alleggerisce quel peso.
17:35
Invece di ricostruire costantemente il contesto
17:37
concentri l'attenzione dove conta
17:39
risolvendo i problemi di progettazione più grandi.
17:42
Molti team non tracciano questi microcosti
17:43
perché non appaiono i ticket gira o nella cronologia git.
17:47
Lavoro che non porta a nulla non viene registrato
17:48
ma consuma comunque energie.
17:50
E man mano che le basi di codice crescono
17:51
questa frizione non aumenta solo linearmente.
17:53
Più livelli significano più dipendenze
17:55
da tenere in memoria maggiori probabilità di perdere tempo
17:57
semplicemente ad allineare la struttura prima di procedere.
18:00
I flussi di lavoro con agenti cambiano i calcoli
18:01
affrontando direttamente questi sprechi.
18:03
Non si limitano a riempire più velocemente gli stupi.
18:05
Riducono i cicli di ricerca, patch e riesecuzione
18:08
che divorano i pomeriggi.
18:09
I team che utilizzano flussi di lavoro con agenti
18:11
segnalano in molti casi tempi di sblocco più brevi.
18:14
In questo video mostreremo un'attività prima dopo
18:16
affinché tu possa valutarne l'impatto.
18:18
Registrerò il tempo necessario per implementare manualmente
18:20
la stessa funzionalità azzurro e poi di nuovo con l'agente
18:23
così potrai vedere il guadagno di produttività in termini concreti.
18:26
Dal punto di vista aziendale
18:27
il valore si riflette nella velocità del progetto.
18:29
Cicli più rapidi non riguardano solo la soddisfazione di sviluppatore.
18:32
Determinano se le funzionalità verranno rilasciate ora o posticipate di mesi.
18:35
Influenzano il debito tecnico
18:36
riducendo hack e regressioni nel backlog.
18:39
Un flusso costante permette ai team di avanzare
18:41
evitando di dover correggere il lavoro precedente.
18:45
Questa coerenza si traduce in meno emergenze
18:46
e consegne più solide nel tempo.
18:49
C'è anche il fatto romano.
18:50
Una giornata persa a inseguire errori sfinisce chiunque.
18:53
Con la stanchezza la progettazione ne risente
18:55
e gli errori diventano inevitabili.
18:58
Delegando le correzioni meccaniche a un agente
18:59
gli sviluppatori mantengono alta la concentrazione.
19:02
Questa attenzione extra migliora sia la produttività che la qualità.
19:06
Senza attriti ripetitivi
19:07
sei libero di pensare in grande e pianificare meglio.
19:11
Ecco come appare la differenza in una pratica.
19:13
Una nuova funzione Azure con integrazioni complesse
19:15
può richiedere due giorni interi senza aiuto.
19:17
Tra configurazione, test e correzioni di riferimenti
19:21
il compito si trascina.
19:24
Con l'aiuto di un agente la stessa funzione può richiedere solo mezza giornata.
19:28
Non perché si tagliano i tempi ma perché il setup e l'orchestrazione funzionano al primo colpo.
19:32
Le tempistiche si riducono eliminando partenze false e sforzi superflui.
19:35
Alcuni sviluppatori esprimono preoccupazioni lì.
19:38
Fidarsi all'IA per la manutenzione indebolisce le proprie competenze?
19:41
Questa prospettiva spesso non coglie il vero cambiamento.
19:44
Delegare i setup ripetitivi preserva la tua esperienza per il design e l'architettura.
19:50
In realtà guadagni spazio per risolvere problemi complessi
19:53
invece di correggere errori banali?
19:55
Se provi, scrivi nei commenti quante ore hai recuperato in uno sprint.
19:58
Includerò le risposte più interessanti nei prossimi video.
20:00
Ascoltare le esperienze di altri team offre una visione più chiara del valore reale.
20:07
Una nota di cautela a automazione aiuta ma la sicurezza rimane fondamentale.
20:10
Esegui sempre i test e usa le code review per validare i cambiamenti dell'agente.
20:15
Fidati della riduzione del lavoro ripetitivo ma mantieni le dovute precauzioni.
20:18
Il vantaggio della velocità si ottiene solo se la qualità rimane alta.
20:21
Test solidi e PR review intelligenti proteggono la pipeline da automazioni fragili.
20:25
Il beneficio non è scrivere codice velocemente
20:28
ma avere spazio per soluzioni migliori.
20:31
Con meno fatica e meno...