Perché questo libro
Questo libro non parla di modelli linguistici.
Parla del giudizio ingegneristico e di come possa essere amplificato senza essere delegato.
L'AI cambia gli strumenti. Il giudizio rimane il patrimonio più importante di un Senior Software Engineer.
La tesi
L'ingegneria agentica non consiste nel sostituire il lavoro del Senior con un agente, ma nel progettare un modello operativo nel quale l'esecuzione possa essere delegata senza delegare giudizio, responsabilità e capacità di apprendimento.
Il libro offre a chi sa già costruire software un modo coerente per collaborare con gli agenti senza rinunciare al proprio mestiere.
I fondamenti
L'apertura del libro: il motivo, il patto con il lettore, l'esigenza e l'esperimento con i suoi principi. È la parte narrativa che precede il modello. Per ciascuno, di che cosa parla e un breve estratto dall'apertura.
Nota dell'autore — perché questo libro
Il Senior amplificato nomina una persona, non uno strumento. Il soggetto è il Senior — chi conosce il lavoro, decide e risponde delle conseguenze — nel momento in cui l'intelligenza artificiale ne estende la portata senza sostituirne il giudizio.
È il framework agentico a collocare il modello in un ciclo e a passargli gli strumenti con cui l'agente tocca il mondo: leggere un file, scriverlo, eseguire un comando, chiamare un servizio.
Patto con il lettore
Questo libro è rivolto a chi conosce la complessità reale dello sviluppo software e, in quello spostamento dalle istruzioni agli strumenti, vede mutare il proprio ruolo: non soltanto scrivere codice, ma orchestrare entità capaci di generarlo.
Del risultato risponde una persona: il Senior.
Introduzione — che cosa deve sopravvivere a una sessione
Una sessione di lavoro con un agente ha un difetto semplice: finisce.
Il costo non è soltanto il tempo necessario a rispiegare. È molto di più. È il rischio di prendere una decisione diversa perché il suo perché è scomparso.
L'esperimento
Gestisco spesso più progetti contemporaneamente, e in ciascuno tengo insieme fronti diversi. Nessuna di queste attività è complessa in sé. Difficile è rientrarci: ritrovare, ogni volta, non solo dove ero ma perché avevo deciso così.
Perché questa relazione funzioni, le decisioni significative devono lasciare tracce strutturate, coerenti e consultabili nel tempo.
Fondamenti — tre livelli da non confondere
Stai lavorando con un agente al modulo di fatturazione di un ERP proprietario. Per risolvere un caso particolare, l'agente propone di aggiungere un parametro booleano al costruttore di TaxCalculator. Sarebbe il decimo parametro. La modifica funziona: il codice compila, il test è verde. Eppure qualcosa non torna.
Questa scelta coinvolge tre livelli diversi: principio, metodo e implementazione. Distinguerli è importante, perché non invecchiano alla stessa velocità e non si delegano nello stesso modo.
Capitoli in anteprima
Sono i capitoli già stabilizzati del manoscritto: apertura della Parte 1, il modello operativo Senior–agente argomentato in astratto. Per ciascuno: la domanda dominante, la tesi e un breve estratto dall'apertura.
La frattura — quando il codice non è più il fattore limitante
Immagina Tommaso e Sandro, due Senior davanti allo stesso ticket Jira: «Aggiungere l'esportazione in CSV alla pagina dei report». Nella mia esperienza, questo passa già per un buon ticket. Hanno a disposizione lo stesso agente e un'ora di lavoro.
L'esperienza del Senior non è soltanto un archivio di risposte: è una gamma di domande con cui riconoscere il sistema nascosto dentro una richiesta locale.
Il giudizio — quando l'esperienza non basta
Immagina Bruno, un esperto DevOps, durante un incidente. Uno dei pod di un servizio, su uno dei nodi del cluster, ha smesso di comportarsi come gli altri: la readiness probe fallisce a intermittenza, il pod entra ed esce dagli endpoint del Service e le richieste che gli erano state instradate tornano indietro con errori.
L'esperienza offre pattern. Il giudizio decide se valgono qui: riconosce ciò che non torna, pesa il compromesso e ne assume la responsabilità.
La cooperazione — una buona conversazione non è ancora un metodo
È venerdì sera. Andrea, SRE esperto, è reperibile e si ritrova in chiamata con il team che sviluppa il prodotto: alcuni utenti continuano a vedere dati vecchi, ma non tutti e non sempre.
Una buona conversazione è un evento. Un metodo rende riconoscibile e riutilizzabile il modo di lavorare anche quando cambiano le persone e il caso.
Questa è un'anteprima dei capitoli stabilizzati. La bozza completa è disponibile su richiesta per copy, editor e reviewer. Il libro sarà pubblicato su Leanpub.