Latest / M365.FM – Podcast su Microsoft 365, Copilot e IA in italiano / L’IA agentica riscrive il DevOps: come gli agenti IA trasformano .NET, Azure e la produttività degli sviluppatori (Doppiaggio IA)

Transcript

L’IA agentica riscrive il DevOps: come gli agenti IA trasformano .NET, Azure e la produttività degli sviluppatori (Doppiaggio IA) · M365.FM – Podcast su Microsoft 365, Copilot e IA in italiano

0:00
Speaker 2: E se il vostro team di sviluppo software avesse un
0:02
Speaker 2: membro in più, che non si stanca mai, impara più
0:04
Speaker 2: velocemente di chiunque altro e gestisce il lavoro noioso senza lamentarsi,
0:08
Speaker 2: è essenzialmente quello che l'IAgentica sta diventando. In questo video
0:11
Speaker 2: definiremo innanzitutto cosa significa davvero l'IAgentica, mostreremo come si applica
0:15
Speaker 2: ai flussi di lavoro. NET e Azure Reali e infine
0:17
Speaker 2: esploreremo l'impatto che può avere sulla produttività del vostro team.
0:21
Speaker 2: Alla fine conoscerete un piccolo esperimento da provare nella vostra pipeline.
0:23
Speaker 2: NET già questa settimana. ma prima di arrivare alle applicazioni
0:26
Speaker 2: e ai risultati dobbiamo esaminare cosa rende l'IAgentica diversa dagli
0:29
Speaker 2: strumenti di completamento automatico che avete già visto. Cosa rende
0:33
Speaker 2: diversa l'IAgentica? Ciò che distingue l'IAgentica non è solo la
0:37
Speaker 2: capacità di generare codice, ma il fatto che opera come
0:39
Speaker 2: un sistema di compagni di squadra con abilità distinte. Per
0:42
Speaker 2: comprendere meglio possiamo dividerla in tre tratti chiave, il modo
0:45
Speaker 2: in cui ogni agente gestisce contesto e memoria, il modo
0:47
Speaker 2: in cui più agenti si coordinano come un team e
0:50
Speaker 2: la differenza tra semplice automazione e vera autonomia adattiva. Per
0:53
Speaker 2: prima cosa vediamo cosa rende distinto un singolo agente, contesto, memoria,
0:57
Speaker 2: orientamento agli obiettivi. Il completamento automatico tradizionale prevede la parola
1:00
Speaker 2: o la riga successiva ma dimentica tutto il resto una
1:02
Speaker 2: volta effettuata la previsione. Un agente IA invece possiede una
1:06
Speaker 2: comprensione del progetto più ampio. Ricorda ciò che è già
1:09
Speaker 2: stato provato, sa dove si trova il codice e adatta
1:11
Speaker 2: il suo output quando qualcosa cambia. Questa persistenza lo rende
1:15
Speaker 2: simile a lavorare con uno sviluppatore junior, qualcuno che impara
1:17
Speaker 2: nel tempo invece di limitarsi a indovinare cosa volete al momento.
1:21
Speaker 2: La differenza chiave qui sta tra prevedere e pianificare. Invece
1:23
Speaker 2: di reagire a ogni battitura isolata, un agente tiene traccia
1:25
Speaker 2: degli obiettivi e si adatta man mano che le situazioni evolvono.
1:29
Speaker 2: Il prossimo punto è come più agenti lavorano insieme. Un
1:31
Speaker 2: grosso malinteso è pensare all'agentica come a uno script di
1:33
Speaker 2: sviluppo o a una macro che automatizza solo compiti ripetitivi.
1:36
Speaker 2: Ma nei progetti software reali il lavoro è suddiviso tra
1:39
Speaker 2: ruoli diversi. Architetti, revisori, tester, operatori, gli agenti possono rispecchiare
1:44
Speaker 2: questa divisione gestendo ciascuno una parte del ciclo di vita
1:46
Speaker 2: con memoria perfetta e coerenza. Immaginate un agente dedicato alla
1:49
Speaker 2: progettazione del sistema, che propone pateme architetturali e framework adatti
1:53
Speaker 2: agli obiettivi aziendali. Un altro esamina le modifiche al codice,
1:56
Speaker 2: individuando problemi pur rimanendo consapevole dell'intera storia del progetto. Un
2:00
Speaker 2: terzo potrebbe espandere la copertura dei test basandosi sui dati utente,
2:03
Speaker 2: generando casi di test senza che dobbiate richiederli. Ogni agente
2:06
Speaker 2: è specializzato ma si coordinano come una squadra, sempre disponibili,
2:09
Speaker 2: sempre coerenti e facilmente scalabili a seconda del carico di lavoro.
2:12
Speaker 2: Dove gli esseri umani perdono energia, contesto o concentrazione, gli
2:15
Speaker 2: agenti restano stabili e ricordano i dettagli con precisione. L'ultimo
2:19
Speaker 2: tassello è la distinzione tra automazione e autonomia. L'automazione esiste
2:23
Speaker 2: da tempo nello sviluppo. Si pensi a script, pipeline CI,
2:25
Speaker 2: CD e modelli. Questi sono rigidi per progettazione. Seguono istruzioni
2:29
Speaker 2: precise passo dopo passo ma si bloccano quando le condizioni
2:32
Speaker 2: cambiano in modo imprevisto. L'autonomia adotta un approccio diverso. Gli
2:36
Speaker 2: agenti AI possono rispondere ai cambiamenti al volo adattandosi quando
2:39
Speaker 2: cambia la versione di una dipendenza riconsiderando una scelta di
2:41
Speaker 2: servizio quando entrano in gioco vincoli di costo. Invece di
2:44
Speaker 2: eseguire percorsi predefiniti prendono decisioni in condizioni dinamiche È un
2:48
Speaker 2: passaggio dall'esecuzione statica alla risoluzione adattiva dei problemi. L'effetto avvale
2:52
Speaker 2: è che questi agenti non si limitano ad attendere comandi.
2:55
Speaker 2: Possono proporre soluzioni a sorgere di problemi, evidenziare rischi prima
2:58
Speaker 2: che arrivino in produzione e redigere piani che fanno risparmiare
3:01
Speaker 2: ore di configurazione. Se l'odierno GitHub Copilot può completare Snippet,
3:05
Speaker 2: la versione di domani agirà più come un collaboratore di progetto,
3:08
Speaker 2: delineando roadmap, suggerendo strategie di rilascio e segnalando persino decisioni
3:11
Speaker 2: architetturali che potrebbero causare problemi in futuro. Ciò non significa
3:15
Speaker 2: che ogni deployment avverrà senza input umano, ma può ridurre
3:18
Speaker 2: significativamente l'intervento ripetitivo e dare agli sviluppatori più tempo per
3:21
Speaker 2: concentrarsi sulle parti creative di alto valore di un progetto.
3:25
Speaker 2: Per chiarire una precedente formulazione in questo ambito, invece di
3:27
Speaker 2: dire cosa succede quando il provisioning delle risorse Azure non
3:30
Speaker 2: richiede affatto un essere umano nel ciclo, non richiede affatto
3:32
Speaker 2: nel ciclo. Un'affermazione più accurata sarebbe che questi strumenti possono
3:36
Speaker 2: ridurre la quantità di configurazione manuale necessaria, mantenendo comunque sotto
3:39
Speaker 2: controllo umano le principali linee guida. Il risultato è comunque trasformativo,
3:43
Speaker 2: senza suggerire che la supervisione umana scompaia del tutto. La
3:46
Speaker 2: consapevolezza più grande è che l'AI agentica non è solo
3:49
Speaker 2: un altro plugin che accelera un compito qua e là.
3:51
Speaker 2: Inizia a funzionare come un vero membro del team, gestendo
3:54
Speaker 2: il lavoro di background affinché gli sviluppatori non restino bloccati
3:56
Speaker 2: a inseguire dettagli che potevano essere tracciati da una controparte
3:59
Speaker 2: sempre attiva. La capacità dell'Intello Team viene amplificata perché i
4:02
Speaker 2: domini chiave hanno agenti digitali che lavorano a fianco degli
4:04
Speaker 2: specialisti umani. Comprende la teoria importante, ma ciò che conta
4:08
Speaker 2: davvero è come tutto questo si traduce in ambienti familiari.
4:11
Speaker 2: Ecco il divario di curiosità. Cosa cambia effettivamente al primo giorno?
4:14
Speaker 2: Il nuovo progetto quando gli agenti sono attivi fin dall'inizio.
4:17
Speaker 2: Successivamente vedremo uno scenario concreto all'interno dell'ecosistema Dontanet in cui
4:21
Speaker 2: questi cambiamenti iniziano a mostrarsi prima ancora di aver scritto
4:23
Speaker 2: la prima riga di codice. Ripensare il flusso di lavoro
4:26
Speaker 2: dello sviluppatore in Dontanet. Nello sviluppo Dontanet il cambiamento più
4:29
Speaker 2: visibile inizia da come i progetti vengono avviati. Ripensare il
4:33
Speaker 2: flusso di lavoro dello sviluppatore qui si riduce a tre
4:35
Speaker 2: vantaggi tattici. Scaffolding dell'architettura più rapido, critica a livello di
4:39
Speaker 2: progetti in tempo reale e una notevole riduzione della fatica
4:41
Speaker 2: di configurazione. E lo scaffolding accelerato? Invece di aprire Visual
4:45
Speaker 2: Studio e fissare una soluzione vuota, un agente IA può
4:48
Speaker 2: proporre opzioni di architettura adatte al tuo caso d'uso specifico?
4:51
Speaker 2: Pianificando un API web con aggiornamenti in tempo reale, l'agente
4:54
Speaker 2: suggerisce un design a strati pulito e segnala come segnalare
4:57
Speaker 2: si integri naturalmente nel flusso. Per un'app finanziaria, linea Entity
5:00
Speaker 2: Framework con una forte tipizzazione e integrazione con Azure Active
5:02
Speaker 2: Directory prima ancora di aver creato una singola cartella. Ciò
5:06
Speaker 2: che normalmente richiede giri discussioni o ore di ricerca viene
5:09
Speaker 2: condensato in pochi punti di partenza su misura. Tuttavia non
5:11
Speaker 2: si tratta di definitivi. Sono bozze. I team dovrebbero convalidare
5:15
Speaker 2: ogni suggerimento eseguendo una rapida checklist. L'autenticazione soddisfa i requisiti.
5:19
Speaker 2: Il login configurato correttamente. I casi di test di base
5:21
Speaker 2: sono presenti. Questa governance leggera garantisce che la velocità non
5:25
Speaker 2: vada a scapito dalla stabilità. Il secondo vantaggio è la
5:27
Speaker 2: critica costante. Pensalo meno come un completamento del codice e
5:31
Speaker 2: più come un consulente che monitora l'allineamento del design. Se
5:34
Speaker 2: implementi un pattern repository per l'accesso ai dati, l'agente segnala
5:37
Speaker 2: se ti stai allontanando dalla separazione dei compiti. Aggiungi un
5:40
Speaker 2: nuovo controller e lui propone unit test corrispondenti o evidenzia
5:43
Speaker 2: incoerenze con il resto del progetto. Invece di lasciarti con
5:47
Speaker 2: del boilerplate, spinge la struttura del tuo sistema verso pattern
5:50
Speaker 2: manutenibili a ogni commit. Per un esperimento pratico, prova ad
5:53
Speaker 2: abilitare Copilot in Visual Studio su un piccolo prototipo ASP. NET Core.
5:58
Speaker 2: Poi confronta quanto tempo impieghi a servire la prima richiesta significativa,
6:01
Speaker 2: un endpoint con l'autenticazione e persistenza dei dati, rispetto a
6:04
Speaker 2: fare tutto manualmente. Non è una garanzia di risparmio di tempo,
6:07
Speaker 2: ma eseguire l'esercizio comparativo nel tuo ambiente è spesso il
6:10
Speaker 2: modo più rapido per valutare se questi agenti abbiano un
6:13
Speaker 2: impatto concreto. Il terzo vantaggio è la riduzione della configurazione
6:16
Speaker 2: del carico. Gran parte del lavoro iniziale è ripetitivo. Collegare
6:20
Speaker 2: need middleware di autenticazione, importare pacchetti in un GET, configurare
6:23
Speaker 2: il logging con Application Insights, scrivere pipeline YAML. Un agente
6:27
Speaker 2: può creare lo scheletro di queste parti immediatamente, inclusi i
6:29
Speaker 2: staff di test integrazione che conoscono le dipendenze presenti. Questo
6:32
Speaker 2: non rimuove il tuo controllo, sposta solo dove concentri le
6:34
Speaker 2: tue energie. Invece di lottare con i file di configurazione
6:37
Speaker 2: per un giorno, dedichi quel tempo a implementare la logica
6:39
Speaker 2: di business che conta davvero. La fatica del lavoro di
6:42
Speaker 2: setup svanisce lasciando spazio per decisioni di design creativo anziché
6:45
Speaker 2: per compiti meccanici. Ciò che fa sentire la differenza rispetto
6:48
Speaker 2: all'automazione tradizionale è la flessibilità. Un template di progetto ti
6:51
Speaker 2: fornisce dei valori predefiniti statici. Un agente adatta la sua
6:54
Speaker 2: struttura in base al tuo obiettivo di business dichiarato. Se
6:56
Speaker 2: stai creando un'app di collaborazione, strategie di caching come Redis
6:59
Speaker 2: Design Event Driven con Azure Service Bus appaiono nel piano strutturato.
7:04
Speaker 2: Se ti sposti verso carichi di lavoro pianificati, appaiono invece
7:06
Speaker 2: servizi in background e processi di coda. Questa reattività distingue
7:10
Speaker 2: l'IA agentica dal semplice scripting, offrendo suggerimenti che rispecchiano il
7:13
Speaker 2: ruolo di un membro senior del team nel guidare le
7:15
Speaker 2: decisioni iniziali. Il contrasto con l'uso attuale di Copilot è evidente.
7:19
Speaker 2: Al momento la maggior parte degli sviluppatori lo vede come
7:21
Speaker 2: un modo per velocizzare la sintassi comune o il boilerplate.
7:24
Speaker 2: Fanno la domanda e lo strumento completa la riga. Con
7:27
Speaker 2: le funzionalità agentiche, lo strumento inizia a consigliare a livello
7:30
Speaker 2: di sistema, offrendo alternative contestualizzate ed evidenziando i compromessi fin dall'inizio.
7:35
Speaker 2: Il salto di qualità consiste nel passare dalla generazione di
7:37
Speaker 2: snippet alla cura di progetti realizzabili. E questo cambia non
7:40
Speaker 2: solo il modo in cui si scrive il codice, ma
7:41
Speaker 2: anche come i team inquadrano l'intera soluzione prima di impegnarsi
7:44
Speaker 2: in una direzione. Nulla di tutto ciò elimina necessità del
7:47
Speaker 2: giudizio umano. Gli agenti possono suggerire framework e dipendenze pratiche,
7:51
Speaker 2: ma la verifica aspetta sempre il team. Tratta ogni raccomandazione
7:54
Speaker 2: come una proposta preliminare. Accetta le parti in linea con
7:57
Speaker 2: i tuoi standard, rivedi quelle che non lo sono e
7:59
Speaker 2: fai tesoro delle lezioni per la prossima iterazione del progetto.
8:02
Speaker 2: L'IA gestisce il lavoro ripetitivo più pesante, mentre i membri
8:05
Speaker 2: del team restano concentrati sull'allineamento delle scelte tecnologiche con la strategia.
8:08
Speaker 2: Finora abbiamo visto come gli agenti rimodellano l'esperienza di programmazione in. NET,
8:12
Speaker 2: ma il loro coinvolgimento non si ferma alla progettazione o
8:15
Speaker 2: allo scaffolding. Una volta poste le basi, la stessa intelligenza
8:18
Speaker 2: inizia a estendersi al provisioning, al deployment e alla gestione
8:21
Speaker 2: dell'infrastruttura su cui poggiano le applicazioni. È qui che sta
8:24
Speaker 2: prendendo forma un'altra grande trasformazione che non si limita al
8:27
Speaker 2: flusso di lavoro dello sviluppatore locale. Riguarda l'ambiente cloud che
8:30
Speaker 2: lo circonda. Agenti cloud che gestiscono Azure con il pilota automatico.
8:34
Speaker 2: Sostiamo quindi l'attenzione su cosa succede quando la gestione di
8:36
Speaker 2: Azure inizia a funzionare con il pilota automatico grazie agli agenti.
8:40
Speaker 2: Il modo in cui questa discussione viene inquadrata spesso sembra fantascienza.
8:43
Speaker 2: Cosa succede quando il provisioning delle risorse Azure non richiede
8:45
Speaker 2: affatto un intervento umano? Un modo migliore di vederla è questo.
8:50
Speaker 2: Cosa succede quando il provisioning di routine e il rilevamento
8:52
Speaker 2: delle derive richiedono meno interventi manuali perché gli agenti gestiscono
8:56
Speaker 2: compiti ripetibili entro vincoli definiti? Questo cambiamento è importante perché
9:00
Speaker 2: non si tratta di eliminare le persone, ma di sgravare
9:02
Speaker 2: il lavoro ripetitivo mantenendo la supervisione. Se hai mai costruito
9:05
Speaker 2: un ambiente Azure complesso, sai già quanto possa diventare caotico.
9:09
Speaker 2: Ti destreggi tra template, script e YAML di pipeline, passando
9:13
Speaker 2: dai comandi CLI per la velocità al portale per le eccezioni.
9:17
Speaker 2: Ogni scorciatoia diventa un debito tecnico pronto a emergere. Una
9:20
Speaker 2: VM lasciata accesa fuori orario, costi che crescono senza preavviso
9:23
Speaker 2: o uno storage account esposto quando non dovrebbe esserlo. E
9:26
Speaker 2: nelle operazioni cloud anche piccoli passi falsi creano enormi grattacapi.
9:29
Speaker 2: Bollette che aumentano, regioni che compromettono la resilienza o alcune
9:32
Speaker 2: di conformità che scopri nel momento peggiore. Questo è il
9:35
Speaker 2: lavoro logorante da cui molti team cercano sollievo ed è
9:38
Speaker 2: qui che un agente inizia a sembrare un ingegnere di
9:39
Speaker 2: deployment autonomo. L'idea è semplice. Tu fornisci obiettivi di business,
9:43
Speaker 2: requisiti di performance, necessità di ripristino, regole di conformità e
9:47
Speaker 2: limiti di budget e l'agente traduce quell'intento in configurazioni di infrastruttura.
9:52
Speaker 2: Invece di passare da una console all'altra o collegare i
9:54
Speaker 2: D manualmente, vedi i template IASC già allineati ai tuoi
9:56
Speaker 2: obiettivi dichiarati. Da lì lo stesso agente mantiene la sorveglianza,
10:00
Speaker 2: eseguendo controlli di conformità, simulando possibili configurazioni errate e applicando
10:04
Speaker 2: le correzioni proposte prima che i problemi si estendano alla produzione.
10:08
Speaker 2: La differenza rispetto all'automazione esistente risiede nell'adattabilità. Una normale pipeline
10:12
Speaker 2: CA e CGD tratta le tue definizioni YAML come verità assoluta.
10:16
Speaker 2: Funzionano finché la realtà non cambia, un aggiornamento delle dipendenze,
10:18
Speaker 2: un improvviso picco di domanda, un nuovo mandato di conformità
10:21
Speaker 2: e allora quelle istruzioni statiche si rompono o implementano qualcosa
10:24
Speaker 2: che sembra valido ma non soddisfa le esigenze aziendali. Una
10:27
Speaker 2: pipeline basata su agenti si comporta diversamente. Tratta quelle definizioni
10:30
Speaker 2: come linee guida di base ma le aggiorna quando le
10:32
Speaker 2: condizioni cambiano. Invece di aspettare che una persona scali un
10:35
Speaker 2: servizio o modifichi la distribuzione regionale, nota il pattern di carico,
10:39
Speaker 2: prevede le probabili soglie e provvede a creare capacità aggiuntiva
10:42
Speaker 2: in anticipo. Quella adattabilità rende gli scenari meno soggetti errori
10:46
Speaker 2: nella pratica. Immagina un'app. NET che gestisce traffico principalmente negli
10:49
Speaker 2: Stati Uniti. Una settimana dopo appaiono nuovi utenti in Europa.
10:53
Speaker 2: La latenza aumenta, ma nessuno ha previsto un'altra regione in Oiam, l'originale.
10:57
Speaker 2: L'automazione tradizionale ignora. Te ne accorgi solo dopo che arrivano
10:59
Speaker 2: i reclami e i log vengono analizzati. Al contrario, un
11:01
Speaker 2: agente segnala il pattern, distribuisce una replica europea e configura
11:04
Speaker 2: routing tramite Azure Front Door immediatamente. Non si limita a
11:07
Speaker 2: distribuire e sparire. Allinea costantemente le risorse con l'intento. Quasi
11:12
Speaker 2: come un Operatore 24-7 che non si stanca mai, Il
11:14
Speaker 2: vero vantaggio va oltre la scalabilità? La sicurezza e la
11:17
Speaker 2: conformità vengono integrate nei cicli. Potrebbe trattarsi della gente che
11:21
Speaker 2: osserva un container di storage esposto involontariamente e bloccandolo automaticamente,
11:24
Speaker 2: o che nota, una deriva nella base di patching di
11:26
Speaker 2: una VM e la riporta in linea. Si tratta di
11:29
Speaker 2: attività ad alta frequenza e bassa visibilità che gli esseri
11:31
Speaker 2: umani solitamente rilevano in ritardo e solo dopo notevole sforze.
11:34
Speaker 2: Inserendole nel ciclo continuo non elimini gli operatori, li liberi. Liberi.
11:39
Speaker 2: Invece di spendere energia a spegnere incendi, si concentrano sulla
11:42
Speaker 2: pianificazione e sulla strategia a alto livello. Questa è una
11:44
Speaker 2: sfumatura importante. La supervisione umana non svanisce. Il tuo ruolo
11:47
Speaker 2: cambia dal controllare le caselle riga per riga al definire
11:49
Speaker 2: le linee guida fin dall'inizio. Quali regioni sono consentite, quali
11:53
Speaker 2: costi sono accettabili, quali standard di conformità non possono essere violati.
11:57
Speaker 2: Un passo pratico per qualsiasi team curioso di testare tutto
11:59
Speaker 2: ciò e definire presto dei guardrei di policy. Imposta tetti
12:02
Speaker 2: di spesa, designa le regioni approvate e aggiungi confini di conformità.
12:06
Speaker 2: La gente agisce quindi come un esecutore, non come un
12:08
Speaker 2: operatore senza vincoli. Questo è il principio fondamentale. Tu mantieni
12:12
Speaker 2: il controllo della direzione strategica mentre l'agente esegue i dettagli
12:14
Speaker 2: protettivi su larga scala. Non significa nemmeno affidare la produzione
12:17
Speaker 2: nelle mani dell'agente fin dal primo giorno. Se sei avverso
12:20
Speaker 2: al rischio, inizia in un ambiente di test controllato. Esponi
12:23
Speaker 2: l'agente a un carico di lavoro non critico o seleziona
12:25
Speaker 2: un singolo servizio come l'infrastruttura di storage o di logging
12:28
Speaker 2: e lascialo gestire drift e provisioningly. In questo modo acquisisci
12:31
Speaker 2: fiducia su come interpreta le linee guida prima di espandere
12:33
Speaker 2: il suo raggio d'azione. Pensalo come un progetto pilota con
12:36
Speaker 2: uno scopo ben definito e bassi rischi esattamente come maturano
12:40
Speaker 2: molte pratiche DevOps affidabili. Fondamentalmente un approccio gentico ad Azure
12:44
Speaker 2: ERC sembra almeno una scrittura di dozzine di script statici
12:46
Speaker 2: e più la gestione di una checklist dinamica. Genera template,
12:50
Speaker 2: esegui controlli pre- deployment, monitora il drift e proponi soluzioni, tutto
12:54
Speaker 2: entro i confini che configuri. Abbastanza strutturato per essere affidabile,
12:58
Speaker 2: ma abbastanza flessibile da evolversi al mutare delle condizioni. Naturalmente
13:01
Speaker 2: il provisioning e il ridimensionamento dell'infrastruttura sono solo un aspetto dell'affidabilità.
13:04
Speaker 2: Il problema più difficile arriva spesso dopo, garantendo che il
13:08
Speaker 2: codice distribuito in quell'ambiente regga davvero in condizioni reali ed
13:12
Speaker 2: è qui che inizia a manifestarsi la sfida successiva il
13:14
Speaker 2: problema di individuare bug che gli umani semplicemente non vedono
13:16
Speaker 2: finché non sono in produzione test autonomi, bug che gli
13:20
Speaker 2: umani perdono i test coprono solo ciò che gli umani
13:22
Speaker 2: possono immaginare e questo è il limite principale la maggior
13:25
Speaker 2: parte dei fallimenti in produzione non deriva da ciò che
13:27
Speaker 2: è previsto ma da ciò che sfugge all'immaginazione umana gli
13:31
Speaker 2: agenti di test autonomi colmano questa lacuna concentrandosi su casi
13:34
Speaker 2: limite e condizioni dinamiche che non entrerebbero mai in una
13:36
Speaker 2: suite di test tipica considerare le condizioni di risk condition learn. Un'applicazione.
13:40
Speaker 2: NET su Azure può funzionare perfettamente sotto carico durante uno
13:43
Speaker 2: stress test pianificato, ma introducendo eventi di scaling, nuove istanze
13:46
Speaker 2: avviate nel traffico, appaiono improvvisamente errori di gestione delle sessioni.
13:50
Speaker 2: A meno che qualcuno non abbia progettato un test specifico
13:52
Speaker 2: per quella sovrapposizione, passa inosservato. Un agente autonomo individua l'anomalia
13:56
Speaker 2: alla isola e genera un nuovo test di regressione attorno
13:58
Speaker 2: a condizione. La volta successiva che avviene lo scaling, quella
14:01
Speaker 2: protezione è già presente, trasformando quello che era un rischio
14:03
Speaker 2: nascosto in uno scenario monitorato. Un altro esempio è la
14:05
Speaker 2: mutazione dell'input. I tester umani solitamente progettano pensando a dati
14:09
Speaker 2: sicuri o prevedibili. Nomi utente validi, payload, API corretti o
14:13
Speaker 2: ovvi casi limite come stringhe vuote. Un agente, al contrario,
14:17
Speaker 2: inizia a sperimentare varianti che gli sviluppatori non penserebbero di coprire.
14:20
Speaker 2: Richieste sovradimensionate, codifiche strane, lievi ritardi tra chiamate in più passaggi.
14:25
Speaker 2: Così facendo può provocare fallimenti che le suite di test
14:27
Speaker 2: manuali ignorerebbero completamente. Il valore non sta solo nella velocità,
14:30
Speaker 2: ma nella diversità. Gli agenti esplorano angoli remoti degli spazi
14:33
Speaker 2: di input più velocemente di quanto potrebbero fare i casi
14:35
Speaker 2: iscritti dagli umani. Ciò che rende questo cambiamento diverso dall'automazione
14:39
Speaker 2: tradizionale e il modo in cui la suite di test evolve.
14:41
Speaker 2: Un pacchetto di regressione progettato dagli esseri umani rimane relativamente statico,
14:44
Speaker 2: riflette la conoscenza e l'ipotesi del team in un determinato momento.
14:48
Speaker 2: Gli agenti trasformano tutto ciò in un processo comune, espandono
14:51
Speaker 2: la suite man mano che il sistema cambia, sondando costantemente
14:53
Speaker 2: stati non considerati. Invece di sviluppatori che aggiornano faticosamente script
14:57
Speaker 2: fragili dopo ogni iterazione, nuovi casi vengono generati dinamicamente osservando
15:01
Speaker 2: come si comporta realmente il sistema. Tuttavia c'è un'avvertenza importante.
15:05
Speaker 2: Non tutti i test generati dagli agenti meritano di far
15:07
Speaker 2: parte della suite permanente. Test inaffidabili o rilevanti possono accumularsi
15:10
Speaker 2: rapidamente facendo perdere tempo e minando la fiducia nell'automazione. Ecco
15:14
Speaker 2: perché la governance è fondamentale. I team hanno bisogno di
15:16
Speaker 2: un processo di revisione. Gli sviluppatori o i tecnici QA
15:18
Speaker 2: dovrebbero convalidare ogni test proposto per stabilità e rilevanza aziendale
15:22
Speaker 2: prima di aggiungerlo al pacchetto di regressione stabile. Proprio come
15:25
Speaker 2: con qualsiasi automazione, la supervisione garantisce che questi strumenti aumentino l'affidabilità,
15:29
Speaker 2: invece di sommergere i team con rumore. Un altro maninteso
15:32
Speaker 2: da chiarire è l'idea che gli agenti corregano i bug.
15:35
Speaker 2: Non riscrivono il codice di produzione e risolvono difetti autonomamente.
15:38
Speaker 2: Ciò che sanno fare eccezionalmente bene è far emergere scenari
15:40
Speaker 2: riproducibili con dettagli diagnostici chiari. Per uno sviluppatore, disporre di
15:44
Speaker 2: una serie di passaggi acquisiti dagli agenti fa la differenza
15:46
Speaker 2: tra ore di congettura e una risoluzione rapida. In alcuni casi,
15:49
Speaker 2: gli agenti possono suggerire una possibile soluzione basata su pattern noti,
15:52
Speaker 2: ma la decisione finale e la modifica restano in mano umana.
15:56
Speaker 2: Vista in quest'ottica, la divisione del lavoro diventa più chiara.
15:58
Speaker 2: Le macchine si occupano della scoperta, gli esseri umani del
16:00
Speaker 2: giudizio e della riparazione. L'impatto sul business è una migliore
16:02
Speaker 2: gestione delle emergenze. I team... Vedono meno ticket notturni, meno
16:06
Speaker 2: regressioni che riappaiono dopo il rilascio e un callo notevole
16:08
Speaker 2: del tempo perso nella riproduzione dei passaggi. Le anomalie di
16:13
Speaker 2: performance vengono rilevate in ambienti controllati invece di emergere davanti
16:16
Speaker 2: agli utenti finali. Tre ore di sicurezza vengono alla luce
16:18
Speaker 2: durante i test interni, non dopo una scansione di conformità
16:21
Speaker 2: o un test di penetrazione. Questo cambiamento permette al QA
16:24
Speaker 2: di concentrarsi su questioni di livello superiore come l'usabilità, la
16:27
Speaker 2: fluidità del flusso di lavoro e l'accessibilità, aree che nessun
16:30
Speaker 2: motore autonomo può valutare in modo significativo. Per i professionisti
16:33
Speaker 2: interessati a testare il terreno, iniziate in piccolo. Eseguite un
16:36
Speaker 2: agente di test autonomo su un ambiente di staging o
16:38
Speaker 2: di preproduzione per un periodo definito. Confrontate l'elenco dei problemi
16:42
Speaker 2: rilevati con il vostro backlog attuale. Considerate l'esercizio come una
16:45
Speaker 2: raccolta di dati. I nuovi risultati sono normalmente utili. Si
16:48
Speaker 2: sovrappongono ai test sistemi. Rivelano punti ciechi importanti per la
16:51
Speaker 2: vostra attività. Inquadrato in questo modo, state misurando il ritorno sull'investimento,
16:55
Speaker 2: non scommettendo la qualità del rilascio su una tecnica non provata.
16:57
Speaker 2: E quando i team eseguono questi progetti pilota, emerge un pattern...
17:02
Speaker 2: Il vero vantaggio a lungo termine non sta solo nel
17:03
Speaker 2: trovare più bug, ma nella rapidità con cui quelle lezioni
17:06
Speaker 2: vengono reinserite nel ciclo di sviluppo generale. Ogni anomalia rilevata
17:10
Speaker 2: e ogni intuizione registrata rappresentano una conoscenza che non dovrebbe
17:13
Speaker 2: svanire alla fine di uno sprint. La domanda è come
17:15
Speaker 2: tale intelligenza venga archiviata, condivisa e portata avanti affinché gli
17:18
Speaker 2: stessi errori non si ripetano sotto nomi di progetti diversi.
17:22
Speaker 2: Chiudere il ciclo dell'intelligenza nel DevOps. Nel DevOps uno dei
17:25
Speaker 2: problemi più difficili da risolvere è la rapidità con cui
17:27
Speaker 2: la conoscenza svanisce tra uno sprint e l'altro. I problemi
17:29
Speaker 2: vengono segnalati e post- mortem scritti, eppure all'avvio del progetto successivo
17:33
Speaker 2: molte di quelle lezioni non rientrano nel flusso di lavoro.
17:36
Speaker 2: Chiudere il ciclo dell'intelligenza nel DevOps significa interrompere questo ciclo
17:39
Speaker 2: di perdite e assicurarsi che ciò che i team apprendono
17:41
Speaker 2: migliori il lavoro futuro. L'IAgentica supporta questo processo collegandosi ai
17:45
Speaker 2: punti in cui la conoscenza già fluisce. Il primo punto
17:47
Speaker 2: di integrazione è l'acquisizione di log e telemetrici. Invece di
17:50
Speaker 2: costringere l'ingegnere a setacciare dashboard o incidenti archiviati, gli agenti
17:54
Speaker 2: analizzano costantemente metriche, tassi di errore, tracce di prestazioni, collegando
17:58
Speaker 2: le anomalie tra i vari rilasci. Secondo analisi della cronologia
18:01
Speaker 2: delle pull request e le visioni del codice, le decisioni
18:04
Speaker 2: prese nei commenti contengono spesso il contesto su compromessi o
18:06
Speaker 2: rischi che non finiscono mai nella documentazione. Elaborando quelle conversazioni,
18:10
Speaker 2: gli agenti preservano il perché di un evento, non solo
18:12
Speaker 2: ciò che è stato integrato. Il terzo è la mappatura
18:15
Speaker 2: dei guasti osservati rispetto alle raccomandazioni architetturali. Se determinate strategie
18:19
Speaker 2: di caching creano ripetutamente un sovraccarico di memoria o se
18:21
Speaker 2: modelli di scaling causano timeout, tali intuizioni emergono durante la
18:24
Speaker 2: pianificazione prima che gli stessi errori ricorrano a un nuovo sistema. Insieme,
18:28
Speaker 2: questi punti di integrazione migliorano la memoria istituzionale senza promettere
18:31
Speaker 2: la perfezione. Il valore non sta nel fatto che gli
18:33
Speaker 2: agenti ricordino in dettaglio la perfezione, ma che aumentino le
18:36
Speaker 2: probabilità che le lezioni passate riemergano al momento giusto. La
18:39
Speaker 2: supervisione umana rimane fondamentale. Gli sviluppatori dovrebbero convalidare la rilevanza
18:43
Speaker 2: delle intuizioni immerse E le organizzazioni dovrebbero programmare audit regolari
18:46
Speaker 2: su ciò che gli agenti acquisiscono per evitare che derive
18:48
Speaker 2: o rumori si infiltrino nel sistema. Con un'attenta revisione, l'intelligenza
18:52
Speaker 2: diventa azionabile anziché opprimente. La governance è un altro aspetto
18:56
Speaker 2: che non può essere trascurato. Inserire log, pull request e
18:58
Speaker 2: risultati di deployment in un sistema di agenti solleva questioni
19:01
Speaker 2: di privacy, conservazione e conformità. Non ogni artefatto dovrebbe vivere
19:05
Speaker 2: per sempre e non tutti i dati dovrebbero essere accessibili
19:07
Speaker 2: a ogni ruolo. Prima di implementare questo strato di memoria,
19:11
Speaker 2: i team devono definire chiari limiti di conservazione dei dati,
19:13
Speaker 2: stabilire policy di accesso e assicurarsi che i dati sensibili
19:16
Speaker 2: siano ripuliti o mascherati. Senza tali confini, si rischia di
19:20
Speaker 2: creare un archivio ombra non regolamentato della storia aziendale che
19:22
Speaker 2: complica gli audit invece di supportarli. Per gli sviluppatori, l'impatto
19:27
Speaker 2: più evidente si avverte durante l'avvio del progetto. Invece di
19:29
Speaker 2: vaghi ricordi su cosa sia andato storto in passato, le
19:31
Speaker 2: intuizioni appaiono direttamente nel contesto. Avvia una nuova web API. net
19:36
Speaker 2: e il sistema potrebbe suggerire L'anno scorso questa libreria di
19:39
Speaker 2: caching ha causato perdite di memoria sotto carico, valuta un'alternativa. Oppure,
19:43
Speaker 2: durante la pianificazione, potrebbe segnalare che specifici pattern di dependence
19:46
Speaker 2: injection hanno creato instabilità. I promemorie sono tempestivi non retrattivi
19:50
Speaker 2: spostando così il focus dal reggere i problemi al prevenirli
19:53
Speaker 2: così che l'intelligenza di progetto si accumula invece di azzerarsi
19:56
Speaker 2: ogni volta che inizia un nuovo sprint cambia anche la
19:58
Speaker 2: natura delle retrospettive le retrospettive tradizionali raccolgono feedback in un
20:02
Speaker 2: momento preciso per vanno avanti con gli agenti nel loop
20:05
Speaker 2: quella conoscenza non viene accantonata viene continuamente reintegrata nel ciclo
20:09
Speaker 2: di sviluppo I log di questo mese, le anomalie di
20:12
Speaker 2: scaling dell'ultimo trimestre o le regressioni di prestazioni notate due
20:15
Speaker 2: anni fa informano le raccomandazioni odierne. Trasformando ogni rilascio in
20:19
Speaker 2: parti di un ciclo di formazione continua, i team riducono
20:21
Speaker 2: il rischio che errori già visti si ripresentino. Tuttavia i
20:24
Speaker 2: risultati vanno misurati e non dati per scontato. Un primo
20:27
Speaker 2: passo semplice è integrare l'agente con una singola fonte di
20:29
Speaker 2: telemetria come i log dell'applicazione a un feed APM per
20:32
Speaker 2: due sprint. Poi confronta l'agente a fatto emergere pattern che
20:35
Speaker 2: non avevi notato. Quei pattern hanno portato a cambiamenti reali
20:38
Speaker 2: nel codice e nell'infrastruttura. e la qualità del rilascio è
20:40
Speaker 2: migliorata in modo misurabile. Se la risposta è sì, allora
20:43
Speaker 2: espandere lo storico delle PR o alla mappatura architetturale ha senso.
20:47
Speaker 2: In caso contrario, l'esperimento stesso rivela cosa va corretto, che
20:49
Speaker 2: si tratti di fonti dati, governance o processi di revisione.
20:54
Speaker 2: Nel tempo il vantaggio è cumulativo. Migliorando la memoria istituzionale,
20:57
Speaker 2: la velocità di rilascio si stabilizza, l'architettura diventa più resiliente
21:00
Speaker 2: e l'energia ingegneristica non viene sprecata a riscoprire vecchie insidie.
21:05
Speaker 2: La conoscenza smette di andare persa e si accomuna invece
21:07
Speaker 2: come una risorsa utile di cui i team possono fidarsi.
21:10
Speaker 2: A quel punto il ruolo dell'intelligenza artificiale agentica appare diverso.
21:13
Speaker 2: Non è solo un assistente in una fase dello sviluppo.
21:15
Speaker 2: Inizia a unire l'intero processo, trasmettendo le lezioni apprese invece
21:18
Speaker 2: di lasciarle scadere. Questa continuità trasforma il DevOps da un
21:22
Speaker 2: insieme di attività isolate a un ciclo di vita più connesso,
21:24
Speaker 2: preparando il terreno per il cambiamento più ampio che sta
21:27
Speaker 2: avvenendo nei team software. L'IAgentica segnala un cambiamento pratico nello sviluppo.
21:33
Speaker 2: concetto non è un assistente al codice, ma un sistema
21:35
Speaker 2: che trasporta memoria, contesto e obiettivi attraverso l'intero ciclo di vita. Applicazione.
21:40
Speaker 2: I punti di ingresso più chiari per i team. NET
21:42
Speaker 2: e Azure sono la creazione di nuovi progetti, la gestione
21:44
Speaker 2: del provisioning di routine tramite agenti e la sperimentazione della
21:46
Speaker 2: generazione di test automatizzati. Impatto. Se eseguito con cura, ottimizza
21:50
Speaker 2: i flussi di lavoro, riduce i costi di configurazione e
21:53
Speaker 2: abbassa la probabilità che errori già visti si ripetano tra
21:55
Speaker 2: i progetti. Il miglior passo successivo è testarlo nel proprio ambiente.
21:59
Speaker 2: Prova ad abilitare Copilot su un piccolo prototipo o eseguire
22:02
Speaker 2: un agente sullo staging, poi monitora una metrica, tempo risparmiato,
22:04
Speaker 2: bug scoperti o derive prevenute. Se hai una sfida DevOps
22:08
Speaker 2: ricorrente che rallenta il tuo team, scrivila nei commenti così
22:10
Speaker 2: che altri possano confrontarsi. E se desideri consigli più concreti
22:14
Speaker 2: su Dontnet, Azure e l'adozione degli AI, iscriviti per le
22:16
Speaker 2: prossime analisi. I guadagni sembrano piccoli all'inizio, ma si moltiplicano
22:20
Speaker 2: con la governance e la supervisione, in interazione costante.