Contesto
Tutto è partito da alcuni incontri one-to-one con il mio team lead. Era curioso di sapere come utilizzo gli strumenti AI, come costruisco i miei Harness personali e come strutturo il workflow di AI Coding. Il motivo principale? Consegno i requisiti in modo rapido e accurato, tanto da essere già il referente principale per alcuni progetti. Ho quindi colto l'occasione per mettere ordine nel mio flusso di lavoro quotidiano con l'AI. Attualmente, nel mio team mi occupo principalmente dello sviluppo di Agent, mantenendo al contempo la logica di business backend esistente.
In passato avevo già condiviso workflow simili su Xiaohongshu. All'epoca il contesto era questo: GPT-5.4 e Opus 4.6 riuscivano già a completare bene i task, purché ricevessero un contesto preciso e vincoli ragionevoli. L'ascesa dell'Harness Engineering ha fatto capire a tutti una cosa: aggiungendo vincoli si possono controllare molto meglio anche i modelli più potenti.
Ad esempio, Skill come Superpowers offrono un'implementazione piuttosto corposa, incentrata principalmente su Spec e TDD, che aiuta a organizzare e portare avanti i task con maggiore facilità.
Questo approccio, però, presenta degli svantaggi. La sensazione più evidente è questa: il consumo di Token è rapidissimo. Skill come Superpowers contengono molti Workflow pensati per vincolare l'azione successiva del modello. Anche se, guardando il quadro generale, un certo passaggio non fosse più necessario — ad esempio quando il contesto è già sufficiente e si può passare direttamente all'implementazione — il modello potrebbe comunque continuare a eseguire il processo predefinito fino alla fine.
Con l'uscita dei nuovi modelli, ho visto molti developer iniziare a raccontare che praticamente non usano più queste Skill così pesanti. Il motivo principale è uno: con il potenziamento delle capacità dei modelli, alcuni vincoli e processi che prima ritenevamo utili sono diventati rumore. Quando OpenAI ha rilasciato Astra, ad esempio, ha pubblicato un post sul blog dedicato proprio a come ripulire Skill e system prompt superflui per migliorare l'esperienza d'uso del modello.
In questo articolo, quindi, unisco la mia pratica degli ultimi mesi per condividere i metodi che oggi funzionano davvero per me, spiegando come sfruttare al meglio i vari Agent per aumentare l'efficienza nello sviluppo quotidiano.
1. Le Skill e i Prompt che uso di più
Come divido oggi gli strumenti:
Attualmente uso principalmente Codex + GPT-5.6 Sol per l'implementazione del codice e Astra per la pianificazione. Prima dell'uscita di Astra, affidavo la pianificazione soprattutto a GPT-5.6 Sol Max.
Per i requisiti semplici uso pi + DeepSeek V4 Flash per l'implementazione; la revisione critica (adversarial review) delle soluzioni e il Code Review sono gestiti principalmente da Claude 5 Fable. Nei progetti personali, per definire le soluzioni principali mi affido anche alla versione web di GPT-6 Pro.
Le mie Skill più utilizzate
- think: la Skill di tw93, usata soprattutto per allineare le soluzioni e fare brainstorming.
- grill me / grill with docs: serve principalmente a chiarire i requisiti. Attraverso una serie continua di domande, mette a fuoco obiettivi, vincoli e compromessi, per poi consolidarli in un ADR o in CONTEXT.md in base alle esigenze del processo di sviluppo. Mi aiuta a scovare i punti che non avevo considerato durante l'allineamento iniziale.
- implement: si usa insieme a grill, fa parte della suite di Skill di Matt Pocock e serve a implementare piani o Issue già definiti chiaramente.
- ponytail: utile per ripulire l'over-design dell'AI e semplificare la Review. La uso spesso perché GPT-5.6 Sol tende facilmente a complicare troppo le cose.
- handoff: organizza il contesto attuale in file, facilitando la ripresa del lavoro in nuove sessioni. Di solito la uso per passare il testimone da Codex a Claude Code o all'agent pi.
- check: dedicata al code review, la uso generalmente quando apro una MR.
- Skill nate dal lavoro e dai progetti personali: soprattutto SOP riutilizzabili, come quelle per i test end-to-end. Il mio consiglio è questo: nel lavoro quotidiano, se ripeti un processo più di tre volte, chiedi a Codex di trasformarlo in una Skill da riutilizzare direttamente in futuro.
I miei Prompt più utilizzati
Oggi scrivo raramente blocchi enormi di Prompt. Quando serve, lascio che sia Codex a organizzarli. Ad esempio, dopo vari round di discussione, se voglio passare il contesto attuale a GPT Pro per progettare la soluzione, chiedo prima a Codex di generare un Prompt di handoff completo.
A parte questo, uso spessissimo alcune tipologie di Prompt molto brevi.
A volte bastano a ottenere l'effetto "una frase vale più di mille parole". Li considero delle vere e proprie "scorciatoie di pensiero" per il modello.
Non sono formule magiche, ma metodologie altamente standardizzate nella conoscenza umana. Durante il training, il modello ha analizzato un'enorme quantità di paper, codice, documenti di design e discussioni correlate: spesso non serve scrivere a mano centinaia di righe di Workflow, basta indicargli quale metodo di pensiero adottare. Ecco alcuni prompt che nella pratica si sono rivelati estremamente efficaci:
- Principi primi (First Principles): non continuare a ottimizzare la soluzione esistente, chiediti di nuovo come andrebbe realmente risolto il problema. Ad esempio, se un'interfaccia è lenta, puoi dire:
Non continuare a progettare basandoti sulla soluzione già stabilita di "aggiungere una cache Redis". Analizza secondo i principi primi perché questa interfaccia è lenta e qual è la soluzione minima indispensabile.
Il focus del modello passa da "come dovrei progettare Redis" a:
Il collo di bottiglia è nell'SQL, nella rete, nella serializzazione, nella contesa dei lock o nei calcoli ripetuti? Se aggiungere un indice SQL risolve il problema, perché introdurre Redis?
Questo tipo di Prompt è perfetto quando sospetti che "la domanda stessa sia sbagliata".
- Revisione critica (Adversarial Review): non cercare conferme per la mia soluzione, prova a dimostrare che è sbagliata.
La richiesta classica sarebbe:
Aiutami a capire se ci sono problemi in questa soluzione tecnica.
Ma può essere trasformata in:
Conduci una revisione critica di questa soluzione, dando priorità alla ricerca di controesempi in grado di smontarne le assunzioni fondamentali.
Se la tua soluzione è "introdurre lock distribuiti per risolvere le richieste duplicate", il modello non si limiterà a dirti come impostare il timeout del lock, ma inizierà a chiedere:
Le richieste duplicate hanno davvero bisogno di mutua esclusione? Basta rendere idempotente l'interfaccia? Cosa succede se il servizio di lock va in crash? E se il lock scade prima che la logica di business finisca di eseguirsi? Abbiamo introdotto un nuovo punto di guasto distribuito per risolvere un problema locale?
Questo tipo di Prompt è particolarmente indicato per le revisioni delle soluzioni e i Code Review.
- Esperimenti di ablazione: se il sistema migliora, non significa che ogni singola aggiunta sia stata utile.
Immagina di aver fatto tre ottimizzazioni in un colpo solo:
Dopo aver aggiunto indici, cache Redis e query batch, la latenza dell'interfaccia è scesa da 800ms a 100ms.
A questo punto puoi chiedere direttamente:
Progetta degli esperimenti di ablazione per queste tre ottimizzazioni, per capire da dove derivano realmente i benefici.
Il modello progetterà dei controlli incrociati sulle varie combinazioni, partendo dalla Baseline e confrontando: solo indici, indici + cache, indici + cache + query batch, ecc.
Alla fine potrebbe scoprire che:
I soli indici avevano già abbassato la latenza da 800ms a 120ms; le altre due soluzioni complesse hanno contribuito solo per 20ms.
Così saprai con molta più chiarezza quale codice vale la pena tenere e quale complessità è probabilmente inutile.
- Rasoio di Occam: a parità di risultati, privilegia le soluzioni con meno assunzioni e minore complessità.
Ad esempio, l'Agent progetta una soluzione del genere:
Kafka + Redis + Lock Distribuito + Macchina a Stati + Compensazione temporizzata.
Puoi aggiungere una riga:
Rivedi questo design applicando il Rasoio di Occam, eliminando tutti i meccanismi non essenziali fermo restando il rispetto dei requisiti.
Spesso arriverà a questa conclusione:
Nello scenario attuale ci sono solo scritture su un singolo database: bastano una transazione e un indice univoco.
Questa frase è utilissima con i Coding Agent di oggi, perché i modelli tendono facilmente a complicare troppo le cose in nome della "completezza".
- Alta coesione, basso accoppiamento: ricontrolla responsabilità e confini del codice.
Se noti che un OrderService ha già raggiunto le 2000 righe, puoi chiedere:
Rivedi i confini di responsabilità di OrderService secondo i principi di alta coesione e basso accoppiamento, senza dividere il codice solo per il gusto di farlo.
Di solito il modello inizierà a verificare:
Perché il servizio ordini gestisce contemporaneamente inventario, coupon, SMS, pagamenti e report? Quale logica appartiene davvero al dominio degli ordini e quale dovrebbe essere delegata ad altri moduli tramite interfacce stabili?
Non si limita a "dividere i file", ma attiva un intero set di valutazioni su modularizzazione, information hiding, direzione delle dipendenze e separazione delle responsabilità.
Per questo oggi scrivo raramente cose come:
Step 1 analizza i requisiti, Step 2 verifica le assunzioni, Step 3 cerca alternative, Step 4...
Il modello ha già appreso moltissime metodologie consolidate. Preferisco dirgli direttamente:
Rianalizza tutto partendo dai principi primi e fai una revisione critica della soluzione attuale; i meccanismi chiave devono essere verificati tramite esperimenti di ablazione; la soluzione deve seguire il Rasoio di Occam, il codice mantenere alta coesione e basso accoppiamento.
Dietro queste poche decine di parole si nascondono in realtà cinque azioni cognitive distinte:
Ridefinisci il problema → Attacca le assunzioni → Verifica i contributi → Elimina la complessità → Organizza i confini del sistema.
Ed è proprio questo, a mio avviso, il cambiamento del Prompt Engineering nell'era dei nuovi modelli: invece di scrivere un processo di pensiero fisso e completo per il modello, conviene usare metodologie precise per indicargli "in che modo pensare", aggiungendo poi solo i vincoli davvero necessari per il task specifico.
2. Il mio workflow di sviluppo quotidiano
Quando ricevo un requisito, di solito passo prima il contesto rilevante all'Agent — PRD, verbali delle riunioni, log delle chat, feedback degli utenti — e poi uso grill per allinearlo con lui.
Spesso questi materiali non formano un requisito completo e coerente. Magari il PRD non è aggiornato, in riunione sono stati aggiunti dei vincoli, nelle chat sono cambiate le priorità. Anche la mia comprensione del requisito potrebbe includere assunzioni implicite.
Lascio che l'Agent analizzi questi materiali incrociandoli con la Wiki del team e il codice esistente, per poi chiarire obiettivi, confini e compromessi che impattano sull'implementazione attraverso una serie di domande. Ad alcune riesco a rispondere subito, per altre devo tornare dal product manager o dai colleghi coinvolti.
Qui applico una regola pratica: quando le domande rimaste non cambieranno più in modo significativo la direzione dell'implementazione e i criteri di accettazione, si può iniziare a sviluppare.
Non pretendo che pianifichi ogni dettaglio implementativo in anticipo, altrimenti lo stesso allineamento dei requisiti diventa un processo troppo pesante.
Le conclusioni dell'allineamento vengono consolidate in uno Spec o in CONTEXT.md, dove registro principalmente il problema da risolvere, lo scope, le decisioni chiave e i criteri di accettazione. Questo permette anche agli Agent successivi, responsabili di implementazione e review, di condividere lo stesso contesto senza dover rileggere tutte le conversazioni precedenti.
Definita la soluzione, lascio che sia l'Agent principale a decidere come procedere in base alla complessità del task. I requisiti semplici vengono implementati direttamente; quelli complessi vengono suddivisi in Issue con confini netti e accettazioni indipendenti. Solo le parti che possono procedere in autonomia vengono passate ai subagent per lo sviluppo parallelo in worktree diversi, per poi essere integrate dall'Agent principale.
Il coding Agent completa prima i test. Quando ritiene di essere pronto per la consegna, introduco altri Agent per una revisione critica incrociata, in base alla complessità del task. I problemi emersi vengono riportati in blocco al coding Agent principale, ovvero Codex, che li corregge e li riverifica.
Prima della mia Review personale, eseguo anch'io dei test end-to-end.
Oggi non leggo più riga per riga tutto il codice generato: mi concentro sui risultati dei test e sulla logica di business core. C'è un prerequisito fondamentale: ogni MR deve avere uno scope abbastanza ridotto e i percorsi di business completi vanno verificati gradualmente man mano che lo sviluppo avanza.
MR piccole mantengono le modifiche da comprendere e valutare entro limiti gestibili ogni volta; i test end-to-end aiutano a verificare se queste modifiche reggono quando inserite nei processi di business reali. Durante la Review manuale, mi concentro sul confermare la logica di business e sul capire se i risultati dei test esistenti sono sufficienti a supportare questa consegna.
3. Come costruire test end-to-end a misura di Agent
L'AI è già bravissima a scrivere test case: capita spesso che scriva centinaia di righe di test per un semplice Bugfix (soprattutto 5.6 sol). Scrivere più test di per sé non è un problema, ma dopo il deploy e il rilascio continuiamo comunque a incontrare errori imprevisti.
Nella mia esperienza, il nodo centrale è uno: non fornire all'Agent un ambiente di test end-to-end, togliendogli l'opportunità di scovare questi problemi già durante la scrittura del codice e l'auto-testing.
Se riusciamo a costruire un ambiente simile, permettendo all'Agent di eseguire comodamente i task partendo dal vero entry point dell'ambiente di test e verificando tutto fino ai risultati attesi dagli utenti, potremo far girare con tranquillità il codice scritto dall'AI nei sistemi reali.
Nello sviluppo effettivo ho costruito un set di ambienti di test end-to-end dedicati al nostro business. L'Agent può interrogare comodamente tabelle del database e log, oltre a connettersi alle macchine per il troubleshooting.
L'intero processo di costruzione consiste essenzialmente nel far estrarre all'Agent i miei processi quotidiani di auto-test, integrando strumenti e capacità sparse: ciò che può diventare un tool viene trasformato in MCP o CLI; i processi riutilizzabili vengono scritti sotto forma di Skill.
Richiede sicuramente un po' di sforzo iniziale, ma non farti spaventare. Una volta pronto, accelera notevolmente lo sviluppo, riduce le rilavorazioni e il rischio di problemi in produzione, e non dovrai più passare le giornate a preoccuparti se il codice scritto dall'AI causerà qualche disastro.
Per creare test end-to-end a misura di Agent, mi sono concentrato principalmente su quattro aspetti:
- Far familiarizzare l'Agent con l'ambiente: ad esempio supportare l'avvio con un clic degli ambienti di test, la creazione di dati di test, chiarire versioni attuali, account di test e permessi, e fornire funzionalità di pulizia e reset.
- Far operare l'Agent sui sistemi di business: eseguire processi reali tramite browser, API o CLI.
- Permettere all'Agent di interrogare facilmente tabelle DB e log: confermare i risultati di archiviazione tramite MCP del database in sola lettura, individuare i problemi tramite Skill del sistema di log e query Trace.
- Riutilizzare i processi noiosi ma stabili: trasformare le operazioni consolidate in script, organizzare entry point e metodi di troubleshooting in Skill, riducendo gli interventi manuali ripetitivi e i dialoghi inutili.
Sulla base di questo lavoro, ecco alcuni metodi che oggi trovo davvero efficaci:
- Automazione del browser: quando i sistemi di business richiedono operazioni via browser, consiglio il browser open source ego lite. È comodo e veloce. Abbinato a pi agent + DeepSeek V4 Flash, i test si completano rapidamente, riducendo i tempi di verifica.
- Unificare le operazioni in una CLI: integra Skill riutilizzabili, MCP configurati e script scritti in un'unica CLI di test, offrendo funzionalità per controllo ambiente, preparazione dati, esecuzione scenari, query dei risultati e pulizia. Può diventare anche un ottimo tool interno per l'efficienza. Io ho trasformato questo set in una CLI, ed è comodissima anche per il troubleshooting quando sorge un problema.
- Usare i tool direttamente per l'accettazione: le query DB servono a confermare gli stati, log e Trace a spiegare i fallimenti, ma i risultati attesi devono sempre derivare dai contratti di business. Non lasciare che l'Agent dia per scontato che una cosa sia corretta solo perché ha visto cosa ha restituito il sistema. Con logiche di business complesse, il sistema potrebbe restituire un risultato apparentemente sensato ma in realtà non conforme. I tool ci aiutano a raccogliere prove, non a stabilire le risposte corrette al posto nostro.
- Se il prodotto stesso è un Agent, verifica anche la qualità delle risposte: se il prodotto da testare è a sua volta un Agent, oltre al corretto funzionamento dei processi di business bisogna considerare anche la qualità delle risposte. È quello che chiamiamo comunemente Agent Eval, ma non lo approfondiremo qui.
4. Come fare la Review del codice scritto dall'AI
Nei paragrafi precedenti abbiamo visto come far scrivere codice di alta qualità all'AI, ma alla fine il responsabile principale dei requisiti di business resta sempre lo sviluppatore.
Senza Review, nei sistemi di grandi dimensioni i problemi arrivano facilmente.
E nessuno vuole essere svegliato nel cuore della notte per un On-call, scoprendo poi che la colpa è di un codice scritto dall'AI.
Per quanto riguarda la Review, oggi seguo principalmente queste pratiche:
- Prima i criteri di accettazione, poi i risultati dei test: controllo innanzitutto i criteri forniti dall'Agent, poi li confronto con i risultati dei test end-to-end precedenti per verificare se le aspettative sono state rispettate e se manca qualcosa. Non guardare solo quanti test sono passati, ma verifica se quei test hanno controllato ciò che conta davvero per quel requisito.
- Segui i percorsi di business per leggere l'implementazione, concentrando le energie sulle parti a maggior rischio: controllo soprattutto permessi, cambi di stato, concorrenza, retry, consistenza dei dati e le aree critiche come migrazioni e rollback. Sul CRUD con pattern stabili si può dedicare meno tempo — anzi, oggi una parte non la guardo nemmeno più.
- Verifica specificamente le nuove astrazioni e i nuovi meccanismi: per le astrazioni e i meccanismi appena aggiunti, uso logiche come il Rasoio di Occam per far fare un'altra review all'AI: sono davvero necessari? Esiste un'implementazione più semplice? Abbiamo introdotto troppa complessità per risolvere un problema locale?
- Valuta la creazione di Review Bot dedicati quando le MR sono tante: se nel team ci sono molte MR, si può progettare un Review Bot apposito per gestire le revisioni incrociate. A differenza della chiamata diretta a pi agent / Claude Code per la revisione critica vista prima, qui l'accento è sull'unire le informazioni di modifica di Git a processi di review predefiniti, creando una capacità di revisione ripetibile pensata esclusivamente per le MR.
5. Alcune riflessioni e conclusioni
Il mio collo di bottiglia più evidente nello sviluppo attuale è la velocità di Review.
Gli Agent possono portare avanti diversi task in parallelo, ma la mia velocità nel comprendere il business, valutare le soluzioni e confermare le consegne non cresce proporzionalmente. Se ti limiti a farlo scrivere di più, rischi solo di accumulare altro codice in attesa di revisione.
Quindi, il prossimo miglioramento che voglio apportare è far sì che i problemi ripetitivi vengano individuati e corretti prima ancora di arrivare sulla mia scrivania.
I problemi rilevabili tramite type checking, test e asserzioni di business dovrebbero essere gestiti il più possibile dall'Agent stesso durante lo sviluppo; il mio giudizio deve concentrarsi su: i requisiti sono stati compresi correttamente? La logica di business chiave regge? Quali rischi non verificati restano in questa modifica?
I Review Bot dedicati possono aiutare in questo, ma il loro valore dipende dalla capacità di ridurre le sviste sui problemi reali e il carico manuale, non dal numero di commenti che generano.
Tutto questo ha reso anche la mia idea di Harness molto più concreta: oltre a fornire agli Agent il contesto corretto, servono ambienti capaci di eseguire i task e basi solide per valutarne i risultati.
Ho trasformato le operazioni che ripetevo continuamente negli auto-test quotidiani in CLI, script e Skill, permettendogli di far girare i sistemi, controllare i risultati e trovare da solo le prove dei fallimenti. In task futuri simili, queste capacità potranno essere riutilizzate e, gradualmente, condivise con gli altri colleghi.
Allo stesso tempo, questo workflow ha bisogno di sottrazioni periodiche.
Alcuni passaggi compensano semplicemente i limiti di una determinata generazione di modelli. Quando i modelli cambiano, l'utilità di questi passaggi va rivalutata. I task semplici si fanno direttamente, quelli complessi richiedono pianificazione, suddivisione e revisione incrociata. Ad esempio, dopo gli aggiornamenti di Astra, ho eliminato alcuni vincoli troppo rigidi da AGENTS.md. I modelli evolvono, e i nostri workflow devono evolvere con loro.
Certo, test e Review riducono l'incertezza, ma spetta comunque agli esseri umani fornire i criteri di accettazione corretti. Anche se codice e test combaciano perfettamente, potrebbero aver frainteso i requisiti insieme. I test end-to-end coprono solo i comportamenti negli ambienti e negli scenari selezionati; traffico, concorrenza e distribuzione dei dati in produzione possono comunque generare nuovi problemi.
Da developer alle prime armi come me, spero ancora di acquisire competenze professionali sul campo lavorando. Tuttavia, l'AI ha effettivamente ridotto alcune occasioni di "sbattere la testa" personalmente. Esperienze preziose, che un tempo nascevano affrontando problemi e indagandone le cause, oggi rischiano di ridursi a un'AI che dice:
"Ho sbagliato, sto correggendo."
Per questo,
oggi riservo una parte della giornata allo studio e alla riflessione, chiedendomi: quali competenze servono davvero a chi fa R&D nell'era dell'AI?
Questo articolo raccoglie un insieme di metodi che ho esplorato gradualmente nel mio ambito di lavoro durante i primi mesi. Sto ancora scoprendo fin dove possano applicarsi e quali siano i loro limiti.
Il mio consiglio è di partire da un percorso di auto-test che fate abitualmente, provare a lasciarlo eseguire in autonomia all'Agent, conservare le prove e poi consolidare i passaggi che funzionano.
Per via delle policy di riservatezza aziendale, non posso inserire molti dettagli nell'articolo. Spero che questo pezzo possa stimolare nuove idee: mi farebbe davvero piacere conoscere le buone pratiche che usate voi nello sviluppo di tutti i giorni~
