Ecco la traduzione del testo dall'inglese all'italiano:
Nel febbraio 2025, Andrej Karpathy ha descritto il vibe coding come la pratica di descrivere l'intento in linguaggio naturale, accettare le modifiche di un LLM con una revisione minima e lasciare che il codice cresca oltre la tua solita comprensione. Ha fornito una velocità impressionante per progetti personali e prototipi.
Un anno dopo ha osservato che le capacità degli agenti erano avanzate e ha proposto "agentic engineering" come nome preferito per la pratica evoluta di orchestrare agenti mantenendo al contempo una forte supervisione umana su architettura e processo. L'obiettivo, come lo ha inquadrato, è ottenere la leva degli agenti senza compromettere la qualità del software.
Questa distinzione è importante. Il vibe coding funziona bene per un singolo utente su lavori personali a basso rischio, ma accumula rapidamente debito nascosto, lacune di sicurezza e problemi di manutenibilità nel momento in cui altre persone dipendono dal risultato. L'agentic engineering mantiene la velocità e la leva degli agenti moderni, ma ancora tutto a una struttura chiara, artefatti tracciabili e responsabilità umana.
Il Flusso di Lavoro dell'Agentic Engineering
Si inizia con un intento approssimativo e si proseguono conversazioni di progettazione con l'IA, documentando la funzionalità in note di riunione di design che descrivono la funzionalità nelle sue parti componenti. Una volta che il design sembra solido, si cattura la visione di alto livello e la mappa dei componenti in una gerarchia di design (è ciò che le persone mostrano quando mostrano un "cervello" di Obsidian), una struttura navigabile che fornisce sia a te che all'agente un accesso immediato al contesto circostante, alle decisioni correlate e alle dipendenze. È anche qui che risiedono i diagrammi di progettazione, come UML (linguaggio di modellazione universale), flussi di codice o di interazione dell'utente, insieme ai collegamenti ai record di decisioni architetturali (ADR) dove chiariscono come i componenti si relazionano.
Per ogni modulo o blocco funzionale più piccolo, crea un spec.md mirato all'interno della LLD che definisce il comportamento preciso, le firme delle funzioni, i casi limite, le aspettative di test e i punti di integrazione. Utilizzando l'intera struttura come un prompt di contesto di progettazione, invita l'IA a creare una gerarchia in stile ticket con tracciabilità diretta alle pagine wiki e alle specifiche. Implementa ticket per ticket con l'agente che segue il relativo spec.md come suo contratto. Quindi esegui i cancelli di verifica, distribuisci, osserva e aggiorna gli artefatti viventi man mano che i requisiti evolvono.
Esempio Reale: Verificatore di Backup Giornaliero
Considera un piccolo strumento CLI di livello produttivo che verifica i backup giornalieri su S3 e invia avvisi Slack in caso di fallimento.
Inizia con l'obiettivo approssimativo: "Ho bisogno di qualcosa di affidabile che controlli ogni giorno che i miei backup siano sani." Poi prosegui conversazioni architetturali con l'IA per far emergere requisiti e casi limite:
- Quali sono le modalità di fallimento realistiche per i backup S3 nella pratica?
- Cosa dovremmo verificare esattamente (età, conteggio file, dimensione, tasso di successo) e quali soglie hanno senso?
- Come dovrebbero essere gestiti la configurazione e i segreti tra lo sviluppo locale e i ruoli IAM di produzione?
- Quali comandi CLI e formati di output sarebbero utili giorno per giorno?
- Quali requisiti non funzionali sono più importanti per uno strumento giornaliero schedulato?
Queste conversazioni chiariscono l'ambito e aiutano a scomporre lo strumento nei suoi componenti principali: recupero metadati S3 con logica di ripetizione, un motore di regole di verifica, un sistema di notifica, un caricatore di configurazione, un'interfaccia CLI, logging strutturato e gestione degli errori.
Con il design chiaro, documenti la visione di alto livello e la mappa dei componenti nella wiki della gerarchia di design, dove ogni pagina è versionata e collegabile.
La wiki fornisce ai lettori futuri il contesto circostante che un documento piatto non può fornire. Come parte dello stesso lavoro di progettazione, crei un spec.md mirato a livello di sub-LLD per ogni modulo. Ecco il contratto per il recuperatore di metadati S3.
Questo spec.md è il contratto che consegni all'agente, ad esempio: "Implementa esattamente secondo spec.md nella directory s3_client/, segui gli standard di progetto e includi test completi." Con la wiki e le specifiche dei moduli in posizione, inviti poi l'IA a generare la gerarchia dei ticket direttamente da esse. Ogni voce risale a un requisito funzionale e alla specifica che ne definisce il contratto.
L'implementazione procede quindi ticket per ticket, ciascuno consegnato all'agente con il suo spec.md corrispondente come contratto. Ecco cosa produce in pratica: un'esecuzione schedulata che rileva un set di backup corto e attiva l'avviso.
L'esecuzione esce con codice non zero in modo che il cron job se ne accorga e attivi l'avviso che finisce su Slack.
L'avviso trasporta il contesto della regola di cui un ingegnere di turno ha bisogno per agire: quale controllo è fallito, cosa è stato trovato, cosa era previsto e quale set di backup.
Vantaggi di Questo Approccio a Strati
- Gli agenti gestiscono il volume di implementazione mentre gli umani possiedono architettura e qualità a ogni livello.
- La wiki fornisce rilevabilità e decisioni a livello di progetto, mentre i file spec.md forniscono contratti precisi a livello di modulo senza gonfiare il design di alto livello.
- Requisiti e decisioni fluiscono direttamente dalle pagine wiki e dalle specifiche nei ticket e nel codice.
- Le modifiche iniziano da artefatti di progettazione viventi piuttosto che dal reverse engineering del codice.
- Una chiara separazione delle preoccupazioni supporta il lavoro parallelo, l'onboarding e gli audit.
- I professionisti a forma di T navigano con ampiezza e interrogano con precisione, e l'agente fornisce profondità su richiesta senza costringere nessuno a tenere l'intero sistema in testa.
Il vibe coding rimane una modalità eccellente per l'esplorazione e la prototipazione rapida personale. L'agentic engineering è il modo in cui incanali quella stessa potenza conversazionale in sistemi che altre persone possono fidarsi e mantenere.
Il Ruolo del Professionista a Forma di T
Questo flusso di lavoro è particolarmente potente per i professionisti a forma di T: ingegneri che mantengono una conoscenza ampia in tutto lo spazio applicativo con la capacità di approfondire dove necessario.
Perché non hai bisogno di tenere un modello mentale completo e aggiornato al minuto di come l'intera applicazione funziona in ogni momento. L'agente può portare quella profondità e rispiegare qualsiasi parte su richiesta, purché abbia il contesto giusto dalla wiki, dai file spec.md e dalla cronologia della conversazione.
Ciò di cui hai bisogno è la capacità di sapere cosa cercare e dove cercare, più la disciplina di continuare a fare domande precise finché non capisci l'elemento specifico su cui stai lavorando. La parte ampia della T ti fornisce la mappa del sistema; l'agente IA supporta le competenze necessarie per approfondire il modulo, il caso limite o il punto di integrazione esatto che conta in questo momento. L'agente fornisce il dettaglio esaustivo ogni volta che lo chiedi.
Questo sposta il ruolo umano da "Devo capire tutto tutto il tempo" a "So come navigare, interrogare e validare all'altitudine giusta." Questa è la vera abilità dell'agentic engineering.
