Secondo Antirez, nell'estate 2025 i modelli di frontiera come Gemini 2.5 Pro amplificano le capacità di un programmatore esperto, a condizione che l'umano comunichi con chiarezza e resti nel ciclo. Nel suo post Coding with LLMs in the summer of 2025 (an update), aggiornamento di quello del 2024, la tesi è netta: la collaborazione tra persona e modello produce il lavoro migliore, il modello lasciato solo no. Ne riassumo i punti, con alcune considerazioni.
Dove gli LLM aiutano davvero
Antirez elenca benefici concreti, nati dal suo lavoro sui Vector Sets di Redis:
- Eliminare i bug in modo preventivo. Le revisioni condotte da Gemini e Claude hanno individuato e fatto risolvere molti errori prima che raggiungessero gli utenti finali.
- Esplorare soluzioni in modo rapido. I modelli generano codice di scarto per verificare in poco tempo se un'idea funziona e come si comporta: si provano più strade prima di sceglierne una.
- Collaborare al design. L'esperienza umana e la conoscenza "da dottorato" codificata nei modelli si combinano, e il confronto aiuta a evitare errori e minimi locali.
- Lavorare più in fretta. Si può far scrivere al modello parti di codice a partire da specifiche dettagliate, o muoversi in tecnologie vicine alla propria competenza ma non padroneggiate, accelerando lo sviluppo.
Il filo comune è che il modello funziona come estensione delle capacità del programmatore, non come sostituto.
Il giusto equilibrio
Antirez avverte contro l'affidamento esclusivo ai modelli. Lasciato solo su obiettivi non banali, un LLM tende a produrre codice fragile, gonfio e localmente ottimale; il vibe coding è sconsigliato, con l'eccezione di piccoli strumenti e test usa e getta. Allo stesso tempo mette in guardia dal rifiuto ideologico o abitudinario: ignorare questi strumenti significa perdere competenze utili.
Restare nel ciclo ha un vantaggio preciso: si mantiene il controllo sulla qualità del codice, sulle scelte di design e sulla comprensione della codebase. Per questo il lavoro migliore nasce dalla collaborazione e dipende dalla qualità della comunicazione con il modello.
Il contesto esaustivo
La parte più operativa riguarda il contesto. Per ottenere risultati ottimali bisogna dare al modello una visione d'insieme dettagliata:
- ampie porzioni della codebase, articoli e documentazione per tecnologie nuove o poco note;
- una sorta di "scarico di cervello": soluzioni che sembrano buone e perché falliscono, approcci promettenti, invarianti, obiettivi e stile del codice;
- l'indicazione esplicita di evitare dipendenze non necessarie.
Antirez cita un caso eloquente: aggiungere il README dei Vector Sets ha permesso al modello di usare la funzionalità a livello da esperto. La documentazione fornita al modello fa la differenza tra una risposta generica e una utile.
Modelli e modalità di lavoro
Nel post Antirez indica Gemini 2.5 Pro come più forte semanticamente e migliore nei bug sottili, e Claude Opus 4 come più piacevole da usare e a volte migliore nel codice nuovo. Per i problemi complessi suggerisce di usare almeno due modelli, per allargare lo spazio delle soluzioni.
Sul metodo la sua scelta è controcorrente: preferisce evitare agenti ed editor con agenti integrati, e passare il codice a mano tra il terminale e l'interfaccia web del modello. In questo modo controlla esattamente cosa vede il modello e segue ogni passaggio. Prevede che gli agenti gestiranno bene molti compiti, con l'umano a definire cosa e come, ma per ora promuove un uso esplicito e supervisionato.
Perché non agenti e RAG
Antirez è esplicito su un punto: mostrare il codice direttamente al modello di frontiera, invece di passare da un sistema RAG che espone solo una parte del contesto, evita un calo di prestazioni. Aggiunge che, per evitare dipendenze superflue, il C gli ha dato risultati migliori del Python. Non è una posizione di principio contro gli agenti: li prova periodicamente e torna alla programmazione manuale assistita ogni volta che non reggono, ricordando che quando si è più bravi senza aiuto conviene scrivere da soli.
Valutazione
La sostanza è condivisibile: questi strumenti premiano chi sa spiegarsi e sa riconoscere una cattiva soluzione. Gli LLM non eliminano la competenza, la rendono più visibile. Sul tema dei limiti dei modelli quando si tratta di costruire software, vale la pena leggere anche la capacità del programmatore di costruire modelli mentali chiari.
Fonte: Antirez, Coding with LLMs in the summer of 2025 (an update).



