Filippo racconta metodo e strumenti per sviluppare app con l'IA: pianificazione, test, Git, red teaming e assistenti come Claude Code e Codex.

Note dell'episodio

Come sempre, se ti è piaciuto quel che hai letto, ascoltato o visto e non l'hai già fatto, ti suggerisco di iscriverti alla mia newsletter. Ti avvertirò dei nuovi articoli che pubblico (oltre ai podcast e video su YouTube) e, mensilmente, ti segnalerò articoli che ho raccolto nel corso del mese ed ho trovato interessanti.

Link

Sinossi e link

Ti ricordo che la sinossi è generata dalla IA in particolare usando la trascrizione del podcast con l'app Transcriber dell'amico Alex Raccuglia che trovi le sue tante applicazioni su Ulti.media e NotebookLM.

Da AnonyMCP al metodo di lavoro

Filippo parte dalla puntata precedente su AnonyMCP e sposta il fuoco: non tanto l'app in sé, quanto il metodo che gli ha permesso di arrivarci. La premessa è chiara: non si presenta come sviluppatore, ma come avvocato che usa l'intelligenza artificiale per trasformare idee e problemi pratici in piccoli strumenti.

Il ruolo che descrive è vicino a quello del product manager: capire cosa deve fare l'applicazione, indicare i vincoli, testare il risultato e correggere la direzione quando l'assistente prende una strada poco sensata.

Local first, prudenza e strumenti interni

Uno dei punti centrali è la regola del local first: quando si lavora in ambito legale, soprattutto con documenti riservati, è meglio partire da strumenti che non mandano dati online. Filippo riprende l'esempio di AnonyMCP proprio per mostrarne il limite: anche se i dati sono pseudonimizzati, una parte del testo può comunque uscire dal Mac.

Da qui il consiglio pratico: usare queste tecniche per applicazioni interne, piccole utility e flussi controllati, possibilmente su macchine pulite e con attenzione ai dati trattati.

Crescere per passaggi incrementali

Il metodo più efficace, racconta Filippo, è procedere per gradi. Anonimator ha fornito la base per AnonyMCP; il lavoro fatto su Electron e sulle build multipiattaforma è stato poi riutilizzato anche per PCT-Link.

Il vantaggio non è solo risparmiare tempo. Ogni progetto crea conoscenza, architetture, soluzioni e codice che gli LLM possono usare come riferimento per il passo successivo. Partire da un progetto enorme, invece, aumenta il rischio di perdersi.

Pianificazione, modelli e ricerche

Prima di far scrivere codice, Filippo insiste sulla pianificazione. In strumenti come Claude Code e Codex conviene usare una fase di plan mode, leggere il piano, criticarlo e correggerlo prima dell'esecuzione.

Qui entrano anche le ricerche aggiornate. Con il Perplexity Web MCP, gli assistenti possono controllare documentazione, fattibilità tecnica e limiti delle librerie invece di basarsi solo sulla memoria del modello.

Regole, contesto e progressive disclosure

Un altro passaggio pratico riguarda i file di istruzioni, come CLAUDE.md o AGENTS.md. Filippo li descrive come regole di lavoro per il repository: spiegano cosa fa il progetto, quali comandi usare, quali vincoli rispettare e dove trovare dettagli più specifici.

La chiave non è scrivere file enormi, ma usare la progressive disclosure: poche regole generali all'inizio e documenti separati per le parti tecniche, così l'assistente legge solo ciò che serve.

Test, Git e supervisione umana

Per evitare sviluppo alla cieca, ogni modifica deve poter essere verificata. I test servono proprio a dare all'LLM un modo concreto per capire se una modifica funziona. Quando c'è un'interfaccia grafica, Filippo consiglia strumenti che permettano all'assistente di vedere screenshot, log e comportamento reale dell'app.

Accanto ai test c'è Git: commit piccoli, branch separati per le funzioni, possibilità di tornare indietro se una strada si rivela sbagliata. La supervisione umana resta comunque decisiva: fare domande, leggere le autorizzazioni richieste e capire quando l'IA sta complicando inutilmente il progetto.

Red teaming e confronto tra strumenti

Filippo dedica spazio anche al red teaming: chiedere all'intelligenza artificiale di criticare un piano o una soluzione in modo avversariale. Non elimina le allucinazioni, ma aiuta a far emergere problemi e punti deboli.

Poi confronta gli strumenti usati: Claude Code, Codex e OpenCode hanno comportamenti diversi, soprattutto su sandbox, autonomia e integrazione con strumenti come LSP. La scelta dipende dal progetto, dal livello di controllo desiderato e dal budget di token.

Architettura, skill e conclusioni operative

Nella parte finale arrivano alcuni trucchi concreti: usare schemi ASCII per immaginare interfacce e flussi, creare file di architettura per spiegare il progetto, partire da una versione terminale prima di costruire una GUI, aggiungere commenti utili nel codice.

La stessa logica, dice Filippo, vale anche per skill e plugin: sono documenti testuali che guidano l'LLM, e quindi beneficiano delle stesse tecniche di pianificazione, test, iterazione e revisione.