DeepSeek-V4-Pro, Kimi K2.6, GLM-5.1: Tre LLM alla Prova del Vibe Coding Long Contexte
Pubblicato il 28 April 2026
- Contesto: non un banco di prova, un cantiere
- Il mio ambiente di test
- La Griglia di Valutazione
- Round 1 : Kimi K2.6 — Il falso avvio
- GLM-5.1 — Il Combattente Onorevole
- Round 3 : DeepSeek-V4-Pro — La Macchina da Guerra
- Bake (generate) the site jbake -b
- Bake and serve locally jbake -b -s
- Bake and watch for changes jbake -b --reset
- Specify source and destination jbake source_folder output_folder
- Bake (generate) the site jbake -b
- Bake and serve locally jbake -b -s
- Bake and watch for changes jbake -b --reset
- Specify source and destination jbake source_folder output_folder
- Clear the output directory before baking jbake -b . output --reset
` - Bake (generate) the site jbake -b
- Bake and serve locally jbake -b -s
- Bake and watch for changes jbake -b --reset
- Specify source and destination jbake source_folder output_folder
- Clear the output directory before baking jbake -b . output --reset
`
La guerra dei LLM si svolge anche nel terminale di uno sviluppatore. Non su benchmark accademici sterili. Nella vita reale: un prompt di 30 000 token, una governance agent in AsciiDoc, plugin Gradle Kotlin DSL da debuggare e sessioni che si susseguono per tre settimane. Ho testato per te DeepSeek-V4-Pro, Kimi K2.6 e GLM-5.1. Ecco il verdetto, con prove tecniche a supporto.
Contesto: non un banco di prova, un cantiere
Tre settimane fa, stavo lavorando su`codebase-gradle`, il mio meta-build system che centralizza la configurazione YAML di quattro progetti: un generatore di README PlantUML, un costruttore di slide AsciiDoc, un sito statico JBake e un chatbot LLM. L’agent Opencode, governato dalla mia metodologia di file agenti in AsciiDoc, caricava ~30K token di contesto EAGER all’inizio di ogni sessione — regole assolute, backlog, storico delle ultime 10 sessioni.
È su questo terreno che ho confrontato tre modelli:
-
Kimi K2.6(Moonshot AI, 1T parametri / 32B attivati, 256K contesto max, MLA) - GLM-5.1(Zhipu AI/Tsinghua, 744B params / DSA, 200K contesto massimo) - DeepSeek-V4-Pro(DeepSeek, 1.6T params / 49B attivati, 1M contesto max, CSA+HCA)
Tutti serviti tramite Ollama su server cloud, tutti in modalità thinking (fase di pensiero attivata). La sfida: produrre codice corretto, mantenere la coerenza durante sessioni lunghe e non allucinare quando il contesto supera i 80K token.
Il mio ambiente di test
@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
skinparam wrapWidth 220
title Ambiente di Test — Sessioni Opencode × 3 LLM
left to right direction
package "🖥️ Terminal Sviluppatore" #E8F5E9 {
rectangle "AGENT.adoc\n(regole, backlog)" as AG
rectangle "PROMPT_REPRISE\n(missione)" as PR
rectangle "INDEX.adoc\n(roadmap)" as IDX
}
package "☁️ Ollama Cloud" #BBDEFB {
rectangle "DeepSeek-V4-Pro\n1.6T / CSA+HCA" as DV4
rectangle "Kimi K2.6\n1T / MLA" as KIMI
rectangle "GLM-5.1\n744B / MLA+DSA" as GLMG
}
package "⚙️ Codebase Gradle" #FFF9C4 {
folder "buildSrc/" {
file "codebase.kt"
file "readme.kt"
file "site.kt"
file "slider.kt"
file "snapshot.kt"
}
file "build.gradle.kts\n(947 righe)"
file "embeds.yml"
}
AG --> DV4 : Sessions 1-8 ✅
AG --> KIMI : Sessions 9-10 ⚠️
AG --> GLMG : Sessions 11-13 ⚠️
DV4 --> "Codebase" : "TDD, refactoring,\nsnapshot"
KIMI --> "Codebase" : "Degradazione\noltre i 60K token"
note bottom of GLMG
Migliore di Kimi
ma latenza +
DSA meno robusto
di CSA+HCA
end note
@enduml
Ogni sessione iniziava con circa 30K token di contesto EAGER :`AGENT.adoc`(287 linee),PROMPT_REPRISE.adoc(51 linee),.agents/INDEX.adoc(218 righe)LAZY_EAGER_ESSENTIALS.adoc(50 righe). Il contesto si gonfiava rapidamente con gli scambi — una sessione tipica di 10 messaggi aggiungeva 15-20K token al prompt cumulativo.
La Griglia di Valutazione
Ho valutato ogni modello su quattro assi critici per lo sviluppo software assistito :
Asse |
Criterio concreto |
Coerenza lungo contesto |
L’agente si ricorda delle convenzioni decise 40 messaggi fa ? |
Qualità del codice prodotto |
Il codice compila al primo tentativo? Rispetta i patterns esistenti? |
Ragionamento architettonico |
L’agente comprende le relazioni tra i moduli senza che io gliele spieghi di nuovo? |
Resistenza alle allucinazioni |
A partire da quanti token l’agente inizia a inventare API o classi inesistenti ? |
E una metrica sintetica interna: ilcoefficiente di ripresa(quanto tempo passo a correggere l’agente invece di programmare con lui).
Round 1 : Kimi K2.6 — Il falso avvio
Kimi K2.6 è stata la mia prima scelta. I suoi benchmark su SWE-Bench Verified (80.2) e Terminal-Bench 2.0 (66.7) sono eccellenti. La sua architettura MLA promette una buona efficacia sulle lunghe sequenze.
Session 9 : la ripresa
Prima sessione con Kimi. Compito: implementare il metodo`resolveActiveKey()in`codebase.kt— una funzione di risoluzione della chiave API con fallback CLI. Il contesto è di 30K token, Kimi ragiona rapidamente, produce un codice pulito con gestione della scadenza delle chiavi.
fun resolveActiveKey(
cfg: CodebaseConfiguration,
logger: Logger,
cliProvider: String? = null,
cliAccount: String? = null,
cliKey: String? = null
): NamedApiKey? {
// Résolution provider → compte → clé avec CLI override
// Kimi a parfaitement compris la chaîne de priorité
}
Il codice compila. I 7 casi di test passano. Sono ottimista.
Sessione 10: il naufragio silenzioso
Seconda sessione. Il contesto raggiunge ~90K token con gli scambi. Chiedo a Kimi di aggiungere un meccanismo di snapshot AsciiDoc che anonimizzi i segreti prima della scrittura.
È lì che deraglia. Kimi inizia a inventare classi che non esistono. Mi propone`AnonymizedObjectMapper`— una classe immaginaria. Lui confonde`ReadmeYmlAnonymizer` et CodebaseYmlAnonymizer. Mi suggerisce di importare`com.fasterxml.jackson.anonymize.*`— un pacchetto che non è mai esistito.
Peggio: nella sua fase di riflessione, vedo che costruisce ragionamenti su premesse false. Lui "si ricorda" che`GitConfig`a un campo`anonymizedToken`— no, è`resolvedToken(). Lui attribuisce a`SiteYmlAnonymizer`un metodo`maskSupabaseCredentials()— che non esiste.
_ Non era un bug. Era una dissoluzione progressiva della coerenza. Come se ogni token aggiunto al contesto diluisse un po' di più la memoria dei primi 30.000. _
Interrompo Kimi dopo due sessioni. La diagnosi è chiara: il MLA comprime bene la KV cache, ma senza un meccanismo di selezione sparsa fine-grained, l’attenzione si diluisce meccanicamente oltre i 60K token. Ogni token "vede" sempre meno bene il contesto distante — e inizia a colmare le lacune con rumore.
GLM-5.1 — Il Combattente Onorevole
GLM-5.1 arriva con un’architettura diversa: MLA per il modello base, poi un continued pre-training con DSA (DeepSeek Sparse Attention) — un indexer leggero che seleziona dinamicamente i top-2048 token pertinenti tra tutta la cronologia.
Architettura: il DSA contro il MLA puro
La differenza è fondamentale. Là dove Kimi comprime la cronologia in uno spazio latente unico (e perde gradualmente la capacità di distinguere l’informazione pertinente), GLM innesta un indexer post‑addestramento che esegue una selezione sparsa esplicita.
@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
title Architetture di Attention — MLA vs MLA+DSA
left to right direction
rectangle "**Kimi K2.6 — MLA pur**" as MLA #FFCDD2 {
rectangle "KV Cache\ncompleto" as KV1
rectangle "Compression\nlatente" as CL1
rectangle "Decodifica\nsu spazio latente" as DL1
KV1 --> CL1
CL1 --> DL1
note bottom of DL1
⚠️ Oltre i 60K token:
perdita di discriminazione
end note
}
rectangle "**GLM-5.1 — MLA + DSA**" as DSA #C8E6C9 {
rectangle "KV Cache\ncompleto" as KV2
rectangle "Compression\nlatente (MLA)" as CL2
rectangle "Indexer leggero\n(DSA, top-k=2048)" as IL
rectangle "Decodifica\nsu token selezionati" as DL2
KV2 --> CL2
CL2 --> IL
IL --> DL2
note bottom of DL2
✅ "Lossless by construction"
Selezione esplicita
dei token pertinenti
end note
}
MLA --> DSA : "Guadagno: selezione sparse\nche evita la diluizione"
@enduml
Il rapporto tecnico lo dice esplicitamente : DSA è "lossless by construction" — al contrario delle alternative come SWA (pattern search), Gated DeltaNet o SimpleGDN che perdono fino a 5,69 punti su RULER@128K
Sessioni 11-13: solido ma frustrante
GLM-5.1 mantiene meglio la distanza. Nella sessione 11 (~60K tokens), rimane coerente. Produce un`SnapshotManager`funzionale con gestione corretta dei quattro anonimizzatori.
Ma la latenza è un problema. Le fasi di riflessione DSA sono più pesanti rispetto al puro MLA — l’indicizzatore deve riseguire la cronologia a ogni passaggio. Una risposta che richiedeva 8 secondi con Kimi ne richiede 15 con GLM. In una sessione di 30 messaggi, si fa sentire.
E poi ci sono gli errori sottili. GLM non delira come Kimi — ma fa errori di nommage. Chiama`toAnonymizedYaml()il metodo che dovrebbe chiamarsi`anonymize(). Inverte`loadReadmeConfiguration()` et loadCodebaseConfiguration()`nel`renderFileSection(). Non sono allucinazioni, sono confusione superficiale — ma in produzione, una confusione superficiale può rompere una build
Ho tenuto tre sessioni con GLM. È migliore di Kimi, indubbiamente. Ma tre sessioni di correzione manuale sui dettagli di denominazione, è stancante.
Round 3 : DeepSeek-V4-Pro — La Macchina da Guerra
DeepSeek-V4-Pro arriva con l’architettura più ambiziosa dei tre: un sistema ibrido che combina due meccanismi di attenzione complementari.
Architettura: CSA + HCA, la doppia rete
@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
skinparam wrapWidth 180
title DeepSeek-V4-Pro — Architettura Ibrida CSA + HCA
left to right direction
rectangle "KV Cache\n1M token" as KV #E3F2FD
rectangle "CSA\nCompressed Sparse Attention" as CSA #C8E6C9 {
rectangle "Compressione\nm token → 1" as CC
rectangle "Sparse Attention\n(DSA, top-k)" as SA
CC --> SA
note bottom of SA
Attenzione locale fine
+ selezione sparse
end note
}
rectangle "HCA\nHeavily Compressed Attention" as HCA #BBDEFB {
rectangle "Compressione estrema\nm' >> m → 1" as ECC
rectangle "Attention densa\nresiduale" as EDA
ECC --> EDA
note bottom of EDA
Contesto globale
+ connessioni a lunga distanza
end note
}
rectangle "Fusione\nibrida" as FUSION #FFF9C4
rectangle "Decodifica\ncoerente" as DEC #FFE0B2
KV --> CSA : Précision locale
KV --> HCA : Vision globale
CSA --> FUSION
HCA --> FUSION
FUSION --> DEC
@enduml
Due livelli di compressione, due granularità di attenzione :
-
CSAcomprime la cache KV tutti i`m`token, poi applica un’attenzione sparsa (DeepSeek Sparse Attention) — solo i top-k delle entrate compresse vengono consultati. Preciso, locale, efficace. - HCA: compressione estrema (fattore`m'`molto più grande di`m`), ma attenzione densa sul residuo compresso — conserva le connessioni globali senza esplosione quadratica.
Risultato: a 1M di token, DeepSeek-V4-Pro consuma solo27% dei FLOPs di inferenza et 10% della dimensione della cache KVrispetto a DeepSeek-V3.2. Il modello precedente.
E soprattutto, il rapporto tecnico (Figura 9) annuncia: "Retrieval performance remains highly stable within a 128K context window."
Sessioni 1-8 : il sollievo
Ho fatto otto sessioni con DeepSeek-V4-Pro su`codebase-gradle`. Otto sessioni senza una sola allucinazione, senza una sola classe inventata, senza una sola confusione di denominazione.
Session 1 : implementazione di`CodebaseYmlConfig` et CodebaseYmlAnonymizer. 350 linee di Kotlin, tests inline, tutto compila. Sessione 4 : aggiunta di`SnapshotManager`con tree view, raccolta di file, rendering AsciiDoc per file. 279 righe, zero errori. Sessione 7 : debug del`renderFileSection()`che doveva gestire quattro tipi di anonimizzatori diversi senza ambiguità di risoluzione. Risolto in tre messaggi.
La latenza è più alta di Kimi — circa 10-12 secondi per risposta in modalità thinking. Ma il tasso di correzione è praticamente nullo. Non passo il mio tempo a correggere gli errori dell’agente. Codifico con lui.
Il test decisivo: refactoring a 100K token
Alla sessione 8, il contesto cumulativo supera i 100K token. Chiedo un refactoring pesante: estrarre le quattro attività di verifica inline del`build.gradle.kts`verso i file di test JUnit5 in`buildSrc/src/test/`.
L’agente propone un piano in tre fasi:
-
Creare le classi di test con migrazione dei casi esistenti
-
Aggiungere le dipendenze JUnit5 e Kotest in`buildSrc/build.gradle.kts`
-
Rimuovi il codice inline di`build.gradle.kts`
Il piano è corretto. L’esecuzione è pulita. Identifica anche un edge case che avevo trascurato : le dipendenze Jackson duplicate tra`buildscript {}` et `buildSrc/build.gradle.kts`che devono essere unificate durante la migrazione.
100K token di contesto, e l’agente si ricorda che`CodebaseYmlAnonymizer.TOKEN_MASK`# Comandi CLI JBake ` # Initialize a new JBake project jbake -i
Bake (generate) the site jbake -b
Bake and serve locally jbake -b -s
Bake and watch for changes jbake -b --reset
Specify source and destination jbake source_folder output_folder
@startuml skinparam backgroundColor #FEFEFE skinparam defaultTextAlignment center title Radar Comparativo — 3 LLM nello Sviluppo Software Assistito legend right |= Couleur |= Modèle | | <#FF5252> | Kimi K2.6 | | <#FFC107> | GLM-5.1 | | <#4CAF50> | DeepSeek-V4-Pro | endlegend rectangle " " as space #FFFFFF rectangle "Coerenza\n80K+ token" as coh #F5F5F5 rectangle "Qualità\ncode" as qual #F5F5F5 rectangle "Ragionamento\narchitetturale" as arch #F5F5F5 rectangle "Resistenza\nallucinazioni" as hall #F5F5F5 rectangle "Velocità\n(esperienza dev)" as speed #F5F5F5 rectangle "Conoscenza\nGradle/Kotlin" as kg #F5F5F5 rectangle "Tasso di\ncorrezione" as corr #F5F5F5 coh --> qual qual --> arch arch --> hall hall --> speed speed --> kg kg --> corr note top of coh Kimi ████░░░░░░ 4/10 GLM ██████░░░░ 6/10 DeepSeek █████████░ 9/10 end note note top of qual Kimi ███████░░░ 7/10 (sotto 60K) GLM ████████░░ 8/10 DeepSeek █████████░ 9/10 end note note top of arch Kimi █████░░░░░ 5/10 GLM ███████░░░ 7/10 DeepSeek █████████░ 9/10 end note note top of hall Kimi ██████░░░░ 6/10 → ██░░░░░░░░ 2/10 (> 60K) GLM ███████░░░ 7/10 DeepSeek █████████░ 9/10 end note note top of speed Kimi █████████░ 9/10 GLM ██████░░░░ 6/10 DeepSeek █████░░░░░ 5/10 end note note top of kg Kimi ███████░░░ 7/10 GLM ███████░░░ 7/10 DeepSeek █████████░ 9/10 end note note top of corr Kimi ██░░░░░░░░ 2/10 (molte correzioni) GLM █████░░░░░ 5/10 DeepSeek ██████████ 10/10 (quasi nulla da correggere) end note @enduml
È questa la differenza.
Il faccia a faccia: metriche comparative
| Criterio | Kimi K2.6 | GLM-5.1 | DeepSeek-V4-Pro |
|---|---|---|---|
Contesto massimo |
256K |
200K |
1M |
Meccanismo attenzione |
MLA puro |
MLA + DSA |
CSA + HCA ibrido |
Parametri totali |
1T |
744B |
1.6T |
Impostazioni attivate |
32B |
non pubblicato |
49B |
soglia di degrado osservata |
|||
Comportamento oltre |
Allucinazioni massicce |
Confusioni superficiali |
degradazione progressiva lenta |
Stabilità NIAH |
non pubblicato |
100% @128K (DSA) |
stabile fino a 128K (Figura 9) |
MRCR @128K |
non pubblicato |
non pubblicato |
supérieur à Gemini 3.1 Pro |
Sessioni tenute prima dell’abbandono |
2 |
3 |
8 (e continua) |
Tempo di correzione / tempo di codice |
60% |
30% |
<5% |
Latenza media (modalità think) |
8 s |
15 s |
11 s |
Coefficiente di fiducia* |
2/10 |
6/10 |
9/10 |
*Coefficient di fiducia = misura soggettiva della mia capacità di prendere il codice dell’agente e il commit senza rileggere riga per riga.
@startuml skinparam backgroundColor #FEFEFE skinparam defaultTextAlignment center title Radar Comparativo — 3 LLM nello sviluppo software assistito legend right |= Couleur |= Modèle | | <#FF5252> | Kimi K2.6 | | <#FFC107> | GLM-5.1 | | <#4CAF50> | DeepSeek-V4-Pro | endlegend rectangle " " as space #FFFFFF rectangle "Coerenza\n80K+ tokens" as coh #F5F5F5 rectangle "Qualità\ncodice" as qual #F5F5F5 rectangle "Ragionamento\narchitettonico" as arch #F5F5F5 rectangle "Resistenza\nallucinazioni" as hall #F5F5F5 rectangle "Velocità\n(esperienza dev)" as speed #F5F5F5 rectangle "Conoscenza\nGradle/Kotlin" as kg #F5F5F5 rectangle "Tasso di\ncorrezione" as corr #F5F5F5 coh --> qual qual --> arch arch --> hall hall --> speed speed --> kg kg --> corr note top of coh Kimi ████░░░░░░ 4/10 GLM ██████░░░░ 6/10 DeepSeek █████████░ 9/10 end note note top of qual Kimi ███████░░░ 7/10 (sous 60K) GLM ████████░░ 8/10 DeepSeek █████████░ 9/10 end note note top of arch Kimi █████░░░░░ 5/10 GLM ███████░░░ 7/10 DeepSeek █████████░ 9/10 end note note top of hall Kimi ██████░░░░ 6/10 → ██░░░░░░░░ 2/10 (> 60K) GLM ███████░░░ 7/10 DeepSeek █████████░ 9/10 end note note top of speed Kimi █████████░ 9/10 GLM ██████░░░░ 6/10 DeepSeek █████░░░░░ 5/10 end note note top of kg Kimi ███████░░░ 7/10 GLM ███████░░░ 7/10 DeepSeek █████████░ 9/10 end note note top of corr Kimi ██░░░░░░░░ 2/10 (beaucoup de corrections) GLM █████░░░░░ 5/10 DeepSeek ██████████ 10/10 (presque rien à corriger) end note @enduml
Perché DeepSeek-V4-Pro guadagna nello sviluppo software
La superiorità di DeepSeek-V4-Pro non è dovuta a un solo fattore — è una convergenza :
1. L’architecture CSA+HCA est taillée pour le code
Lo sviluppo software assistito è un caso d’uso estremo per l’attenzione a lungo contesto. Hai bisogno di : # JBake CLI Commands ` # Initialize a new JBake project jbake -i
Bake (generate) the site jbake -b
Bake and serve locally jbake -b -s
Bake and watch for changes jbake -b --reset
Specify source and destination jbake source_folder output_folder
Clear the output directory before baking jbake -b . output --reset `
@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
skinparam wrapWidth 260
title Albero di Decisione — Scegliere il proprio LLM per lo Sviluppo Assistito
start
:Contexte initial\n> 20K tokens ?;
if (Oui) then
:Architecture d'attention\nhybride ou multi-niveau ?;
if (CSA+HCA) then
:DeepSeek-V4-Pro
Fenetre stable 128K
Ideal pour gouvernance EAGER;
stop
elseif (MLA + DSA) then
:GLM-5.1
Correct jusqu'a ~120K
Latence elevee;
stop
else (MLA seul)
:Kimi K2.6 (sessions courtes)
ou eviter pour long contexte
Chercher un modele avec
sparse attention;
stop
endif
else (Contexte < 20K)
:N'importe lequel fonctionne.
Privilegier la latence.;
stop
endif
@enduml
-
Precisione locale (da cosa eredita questa classe? dove è definito questo metodo?) →CSA - Visione globale (perché questo modulo esiste ? come i quattro anonymizzatori interagiscono ?) →HCA
Kimi con MLA solo gestisce la precisione locale ma perde la visione globale oltre i 60K. GLM con DSA migliora la visione globale ma rimane mono-livello. DeepSeek combina i due esplicitamente.
2. Il contesto EAGER è la sua zona di conforto
Il mio sistema di governance carica ~30K token di regole e backlog all’avvio. Con una finestra stabile fino a 128K, DeepSeek dispone di ~100K token di margine per gli scambi della sessione. Questo è da 3 a 4 volte più di quanto Kimi possa gestire senza degradazione.
(No content to translate) La finestra di 128K di stabilità perfetta corrisponde esattamente alle mie esigenze: 30K di EAGER + 70K di scambi = una sessione produttiva di 20-30 messaggi senza mai uscire dalla zona verde. __
# Initialize a new JBake project
jbake -i
Bake (generate) the site jbake -b
Bake and serve locally jbake -b -s
Bake and watch for changes jbake -b --reset
Specify source and destination jbake source_folder output_folder
Clear the output directory before baking jbake -b . output --reset `
-
Il rapporto qualità/latenza è ottimale per il flusso
Sì, DeepSeek-V4-Pro è più lento di Kimi (11s vs 8s). Ma il tempo totale di un’attività è notevolmente inferiore perché non passo 20 minuti a correggere le allucinazioni dell’agente.
Il sviluppatore non misura la latenza di una risposta. Misura il tempo tra "pongo la domanda" e "il codice è nel mio repository e funziona". Su questa metrica, DeepSeek-V4-Pro è il più veloce dei tre.
Lezioni apprese: Come scegliere il proprio LLM per il Vibe Coding
Oltre il punteggio occasionale, questa esperienza mi ha insegnato a valutare un LLM per lo sviluppo software assistito su criteri che non compaiono in nessun benchmark :
-
Guarda l’architettura, non la dimensione del contesto annunciata— Un modello che annuncia 256K di contesto ma ha solo un MLA finirà come Kimi: teoricamente capace, praticamente inutilizzabile oltre i 60K.
-
Testa sul TUO contesto, non su un benchmark generico — Mon prompt initial de 30K tokens AsciiDoc avec règles absolues et backlog n’a rien à voir avec les questions de HLE ou AIME.
-
La latenza non è nemica se la qualità segue# JBake CLI Commands
----
----
# Initialize a new JBake project
jbake -i
# Bake (generate) the site
jbake -b
# Bake and serve locally
jbake -b -s
# Bake and watch for changes
jbake -b --reset
# Specify source and destination
jbake source_folder output_folder
# Clear the output directory before baking
jbake -b . output --reset
----
— Un modello lento che produce codice corretto è più veloce di un modello veloce che produce codice sbagliato.
1. **Fai attenzione ai modelli senza rapporto tecnico pubblico**— Se l'équipe non documenta la sua architettura d'attenzione, è perché non ha fiducia nella sua tenuta nel contesto lungo.
[plantuml, format=svg, id=diag-decision-tree, alt="Arbre de décision pour choisir un LLM pour le développement logiciel assisté"]
----
@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
skinparam wrapWidth 260
title Albero di decisione — Scegli il tuo LLM per lo sviluppo assistito
start
:Contexte initial\n> 20K tokens ?;
if (Oui) then
:Architecture d'attention\nhybride ou multi-niveau ?;
if (CSA+HCA) then
:DeepSeek-V4-Pro
Fenetre stable 128K
Ideal pour gouvernance EAGER;
stop
elseif (MLA + DSA) then
:GLM-5.1
Correct jusqu'a ~120K
Latence elevee;
stop
else (MLA seul)
:Kimi K2.6 (sessions courtes)
ou eviter pour long contexte
Chercher un modele avec
sparse attention;
stop
endif
else (Contexte < 20K)
:N'importe lequel fonctionne.
Privilegier la latence.;
stop
endif
@enduml
----
== E l'agente di governanza in tutto questo?
Questa esperienza conferma un punto che difendo dal mio articolo sulla governance Eager/Lazy :**la qualità del LLM e la qualità della governance sono moltiplicative, non additive**.
Con Kimi K2.6, la mia governance era impeccabile — ma il modello diluiva l'informazione. Risultato: governance perfetta × allucinazione = zero
Con DeepSeek-V4-Pro, la governance EAGER (30K token di regole) + LAZY (archivi di sessione, riferimenti tecnici) + Hot/Warm/Cold (backup rotativo) forma un ecosistema in cui ogni livello amplifica l'altro. L'agente ha le regole sotto gli occhi (EAGER), può consultare lo storico (LAZY) e il contesto non si satura mai (rotazione di backup).
Un buon LLM senza governance è un motore di Ferrari senza volante. Una buona governance senza un buon LLM è un volante senza motore. DeepSeek-V4-Pro + la mia governance agente = la prima volta che ho la sensazione di guidare. ____
Il meccanismo di backup rotativo (rotazione ogni 10 sessioni o >500 righe EAGER) ha tutto il suo senso con un modello che tiene 128K di contesto: la finestra scorrevole di 10 sessioni attive mantiene il contesto fresco senza mai superare la zona di degradazione.
== Fonti tecniche
Ho incrociato la mia esperienza empirica con i rapporti tecnici ufficiali per validare le mie osservazioni:
1. *DeepSeek-V4 Technical Report* — PDF recuperato dahttps://huggingface.co/deepseek-ai/DeepSeek-V4-Flash[HuggingFace]. Figure 9 : "Retrieval performance remains highly stable within a 128K context window. While a performance degradation becomes visible beyond the 128K mark, the model's retrieval capabilities at 1M tokens remain remarkably strong." Architettura CSA+HCA documentata sezione 2.3.
1. *GLM-5 Technical Report* —https://arxiv.org/abs/2602.15763[arXiv:2602.15763]. DSA introdotto tramite pre-addestramento continuato, "lossless by construction". Contesto massimo 202.752 token. Le tabelle 3/5/6 documentano le prestazioni a lungo contesto rispetto alle alternative (SWA, Gated DeltaNet, SimpleGDN).
1. *Kimi K2.6 Model Card* —https://huggingface.co/moonshotai/Kimi-K2.6[HuggingFace]. MLA, 256K contesto massimo. Strategia di discard-all oltre la soglia sulle attività agentiche (confermando implicitemente il limite pratico del MLA nel contesto lungo).
1. *Kimi K2 Technical Report* —https://arxiv.org/abs/2507.20534[arXiv:2507.20534]. Architettura MoE, ottimizzatore MuonClip, prestazioni agentiche (HLE, BrowseComp, Terminal-Bench).
Il punto più rivelatore: nella loro stessa valutazione, Moonshot applica una strategia di *discard-all* (eliminazione del contesto vecchio) non appena la finestra di contesto viene superata. Questo conferma esattamente ciò che ho osservato: il solo MLA non può mantenere la coerenza sull'intera finestra di 256K. L'architettura non tiene il passo.
== Conclusion: La scelta dell'artigiano
Dopo tre settimane e tredici sessioni di sviluppo reale, il verdetto è senza appello :
|===
|Kimi K2.6 |GLM-5.1 |(Empty output) |Eccellente sotto 60K |Solido fino a 120K |Domina ovunque |Inutilizzabile oltre |Confusioni di superficie |Stable fino a 128K |2 sessioni, abbandonato |3 sessioni, abbandonato |8 sessioni, adottato
|===
DeepSeek-V4-Pro è diventato il mio LLM predefinito per tutte le sessioni di sviluppo software assistito con Opencode. Non perché è il più recente. Non perché ha i migliori benchmark accademici. Ma perché nella vita reale di uno sviluppatore che spinge plugin Gradle Kotlin DSL con un contesto agente di 30K token, è l'unico che non mi tradisce quando il contesto si allunga.
CSA+HCA è un *game changer* architettonico. La compressione a doppio livello + sparsificazione non è un dettaglio di implementazione — è ciò che fa la differenza tra un assistente di codice e un compagno di squadra affidabile.
(No source text provided to translate.) Ho scelto DeepSeek-V4-Pro perché è l'unico dei tre che trasforma la mia governance dell'agent da una limitazione difensiva ("come evitare che l'agent dimentichi?") in un vantaggio offensif ("cosa possiamo costruire ora che l'agent ricorda tutto?"). ____
---
*Questo articolo è il frutto di 13 sessioni di sviluppo reale sul progetto`codebase-gradle`, documentate in`.agents/sessions/`secondo la mia metodologia di governance agent Eager/Lazy/Hot/Warm/Cold. Le fonti tecniche citate sono accessibili pubblicamente su HuggingFace e arXiv.
----
---
Questo articolo è il risultato di 13 sessioni di sviluppo reale sul progetto`codebase-gradle`, documentate in`.agents/sessions/`secondo la mia metodologia di governance agent Eager/Lazy/Hot/Warm/Cold. Le fonti tecniche citate sono accessibili pubblicamente su HuggingFace e arXiv.*