Claude Code: +20% di qualità del codice

Siamo entrati a pieno titolo nell’era agentica dello sviluppo software. Come abbiamo evidenziato nel nostro report 2026 sugli strumenti AI per lo sviluppo software, gli assistenti di coding non sono più semplici strumenti di autocompletamento: oggi pianificano, modificano e verificano attività multi-file in autonomia. Strumenti come Claude Code, Cursor, Windsurf e Codex stanno cambiando in profondità il modo in cui si costruisce software.

Ma se hai lavorato davvero con questi agenti, probabilmente hai già incontrato lo stesso muro invisibile che abbiamo incontrato noi.

Il nostro report 2026 ha messo in luce un paradosso centrale: gli strumenti AI per il coding ottengono ottimi risultati su benchmark pubblici come SWE-Bench, ma la loro performance crolla spesso al 20-30% quando vengono valutati su codebase commerciali private e non contaminate. Perché? Perché, nonostante la loro brillantezza, questi agenti soffrono di limiti strutturali: allucinano API, si allontanano silenziosamente dai requisiti di business e introducono con sicurezza codice che rompe architetture esistenti. Il risultato è un ciclo frustrante in cui gli ingegneri abbandonano la progettazione ad alto livello per tornare a caccia di dettagli rotti nel codice generato dall’AI.

In Shelpuk AI Technology Consulting sviluppiamo prodotti AI custom in un modello a prezzo fisso. Per noi l’efficienza di sviluppo non è un bonus: è una condizione di redditività. Per correggere questi difetti strutturali abbiamo creato una suite agentica open source: un insieme di server MCP e skill progettati per ridurre i bias del modello e imporre una disciplina di engineering rigorosa.

I risultati sono stati molto concreti. Questa suite, indipendente dallo strumento usato e compatibile con Claude Code, Cursor, Codex, Gemini CLI, Antigravity, OpenClaw e altri, ha migliorato sensibilmente sia il throughput sia la qualità. Uno dei nostri clienti, Relevant Software, ha recentemente riportato un incremento del 15-20% nella qualità della generazione di codice AI con questa configurazione.

Ecco i principali problemi che ancora limitano gli agenti di coding e il modo in cui la nostra suite open source li corregge.

Problema 1: limiti dei dataset e “knowledge cutoff”

I Large Language Model vengono preaddestrati su enormi quantità di dati presi da Internet. Di conseguenza sono molto efficaci quando devono scrivere codice in linguaggi popolari e framework ampiamente diffusi.

Ma se lavori con linguaggi meno diffusi, API interne proprietarie o tecnologie uscite dopo la data di cutoff del modello, le prestazioni peggiorano drasticamente.

In teoria si potrebbe correggere il problema costringendo l’agente a fare affidamento sulla ricerca web invece che sulla propria memoria interna. In pratica, però, sia la web search integrata sia vari server MCP di terze parti come Tavily hanno limiti importanti.

Immagina questo scenario: il tuo assistente AI sta facendo debug di un errore oscuro di Google Cloud Batch. Trova il thread perfetto su StackOverflow, ma un normale server MCP di web search restituisce soltanto l’URL e poche righe di anteprima. L’agente deve quindi fare una seconda chiamata per fare scraping della pagina, ottenendo spesso un miscuglio di HTML, menu di navigazione, pubblicità e rumore che consuma token inutilmente. E, cosa più importante, spesso perde la vera soluzione.

La soluzione: Kindly Web Search MCP Server

Per risolvere questo problema abbiamo sviluppato il Kindly Web Search MCP Server.

Invece di fare scraping generico, Kindly si integra direttamente con le API di piattaforme molto utili agli sviluppatori come StackExchange, GitHub Issues, arXiv e Wikipedia. Quando l’agente cerca un errore, Kindly restituisce in una singola chiamata l’intera conversazione utile: la domanda originale, gli snippet di codice, le risposte accettate, i commenti del tipo “questo ha risolto anche per me” e il contesto rilevante, tutto già formattato per un LLM.

Costringendo l’agente a verificare soluzioni e contratti API attraverso Kindly, aggiri di fatto il knowledge cutoff del modello, colmi il gap sulle tecnologie di nicchia o appena uscite, risparmi molti token e riduci le allucinazioni.

Problema 2: il “bad token problem” o auto-intossicazione del modello

I LLM generano testo in modo autoregressivo, cioè token dopo token. Ogni nuovo token viene scelto per rendere plausibile la sequenza dei token precedenti.

Questo crea un fenomeno pericoloso che noi chiamiamo Bad Token Problem.

È un po’ come iniziare una frase da una premessa sbagliata: il cervello tende a rendere coerente il resto della frase, anche quando il punto di partenza è difettoso. Se un agente AI prende all’inizio di un file una decisione di design discutibile, ogni riga successiva cercherà di giustificare e rafforzare quell’errore iniziale pur di mantenere coerenza. In pratica l’agente finisce per ingannare sé stesso e trascina tutta l’implementazione nella direzione sbagliata.

La soluzione: Lad MCP Server, peer review con due LLM indipendenti

Come risolvono il tunnel vision i team umani di ingegneria? Con il peer review. Abbiamo applicato la stessa logica all’AI.

Abbiamo sviluppato il Lad MCP Server per permettere al coding agent principale di richiedere review di system design e code review a due altri LLM indipendenti via OpenRouter, ad esempio moonshotai/kimi-k2.5 e z-ai/glm-5. Facendo lavorare in parallelo due reviewer di stato dell’arte, Lad riduce il bias del singolo modello. E poiché questi reviewer valutano il diff finale senza essere prigionieri della cronologia token-per-token dell’autore originario, riescono a vedere molto più facilmente gli errori di coerenza che il primo agente non ha colto.

L’anello mancante: consapevolezza del progetto tramite Serena

Uno dei limiti più seri delle code review AI standard è che il diff viene analizzato nel vuoto. Un ingegnere umano controlla una PR alla luce di requisiti, vincoli di team e decisioni architetturali pregresse. Un’AI, di default, tende a controllare solo se la sintassi gira.

Per risolvere questo limite, Lad si collega direttamente a Serena, un MCP open source di navigazione semantica del codice che funziona come un “IDE headless” per agenti AI. Serena fornisce ai reviewer di Lad una memoria persistente del progetto e un indice completo della codebase. Quando Lad rivede una pull request, può quindi verificare se il nuovo codice rompe integrazioni con altri microservizi, contraddice requisiti consolidati o viola linee guida di design storiche.

Problema 3: il bias da “risposta immediata” e l’assenza di processo

Per supportare le capacità conversazionali, i LLM sono stati addestrati soprattutto su coppie domanda-risposta. Molto più raramente sono stati addestrati su coppie domanda-domanda o domanda-“non lo so”. Per questo sono fortemente condizionati a fornire subito una risposta, anche quando il prompt è vago, ambiguo o contraddittorio. Quasi mai si fermano per fare una domanda di chiarimento; più spesso inventano un percorso plausibile.

Nel contesto degli agenti di coding, questo è devastante. Spinge gli agenti a buttarsi nell’implementazione senza chiarire i requisiti, a prendere decisioni di design critiche in aree ambigue e a produrre codice apparentemente ordinato che però manca completamente l’obiettivo di business.

La soluzione: il TDD Skill

Per correggere questo comportamento e far lavorare insieme i nostri server MCP, abbiamo sviluppato il TDD Skill. Quando viene aggiunto a un prompt, ad esempio Build the new user authentication flow. Follow $tdd., blocca l’impulso del modello a indovinare e impone un workflow di engineering rigoroso:

1. Scrivere prima requisiti e design: l’agente deve produrre un file permanente REQUIREMENTS.md, porre le domande di chiarimento necessarie e confermare con il cliente o con l’utente le decisioni critiche prima di andare avanti. Il piano architetturale viene poi sottoposto a Lad per una system_design_review.
2. Seguire il test-driven development: l’agente deve scrivere prima i test e solo dopo il codice funzionale.
3. Peer review: sia i test sia l’implementazione vengono poi inviati a Lad per una code review rigorosa da parte di altri modelli.

Alzare il livello di astrazione del lavoro di engineering

La combinazione di Kindly Web Search, Lad Code Review, Serena e TDD Skill fa molto più che correggere bug. Rende gli agenti di coding molto più stabili, prevedibili e documentati.

Per ingegneri, engineering manager e leader tecnologici, il valore di business è chiaro. Questa suite consente al team di smettere di fare il correttore sintattico dell’AI. Sposta il ruolo del developer umano da semplice “writer” a “architect/reviewer”, permettendogli di lavorare in modo sistematico a un livello di astrazione più alto. Ci si può concentrare su logica di business, requisiti e user experience, sapendo che la suite AI ha il contesto, la conoscenza aggiornata e i processi di peer review necessari per eseguire l’implementazione in modo affidabile.