DeepSeek-V4-Pro, Kimi K2.6, GLM-5.1 : Tres LLMs a la prueba del Vibe Coding Long Contexto

Primera sesión con Kimi. Tarea: implementar el método`resolveActiveKey()dentro`codebase.kt— una función de resolución de clave API con fallback CLI. El contexto es de 30K tokens, Kimi razona rápido, produce un código limpio con gestión de expiración de claves.

El código compila. Los 7 casos de prueba pasan. Soy optimista.

Segunda sesión. El contexto se incrementa a ~90K tokens con los intercambios. Pido a Kimi que agregue un mecanismo de captura instantánea AsciiDoc que anonimice los secretos antes de la escritura.

Es aquí donde se desvía. Kimi empieza a inventar clases que no existen. Me propone`AnonymizedObjectMapper`— una clase ficticia. Él confunde`ReadmeYmlAnonymizer` et CodebaseYmlAnonymizer. Él me sugiere importar`com.fasterxml.jackson.anonymize.*`— un paquete que nunca ha existido

Peor: en su fase de reflexión, veo que construye razonamientos basados en premisas falsas. Él "se recuerda" que`GitConfig`a un campo`anonymizedToken`— no, es`resolvedToken(). Él atribuye a`SiteYmlAnonymizer`un método`maskSupabaseCredentials()— que no existe.

_ No era un error. Era una disolución progresiva de la coherencia. Como si cada token añadido al contexto diluyera un poco más la memoria de los primeros 30 000. _

Detengo a Kimi después de dos sesiones. El diagnóstico es claro: el MLA comprime bien el caché KV, pero sin un mecanismo de selección sparsa de grano fino, la atención se diluye mecánicamente más allá de 60K tokens. Cada token 've' cada vez peor el contexto distante — y comienza a rellenar los huecos con ruido.

La diferencia es fundamental. Donde Kimi comprime el historial en un único espacio latente (y pierde gradualmente la capacidad de discriminar la información pertinente), GLM añade un indexador post-entrenamiento que realiza una selección esparsa explícita.

El informe técnico lo dice explícitamente: DSA es "lossless by construction" — a diferencia de alternativas como SWA (búsqueda de patrones), Gated DeltaNet o SimpleGDN que pierden hasta 5.69 puntos en RULER@128K.

GLM-5.1 mantiene mejor la distancia. En la sesión 11 (~60K tokens), sigue siendo coherente. Produce un`SnapshotManager`funcional con gestión correcta de los cuatro anonimizadores.

Pero la latencia es un problema. Las fases de reflexión DSA son más pesadas que el MLA puro — el indexador debe volver a escanear el historial en cada paso. Una respuesta que tardaba 8 segundos con Kimi ahora tarda 15 con GLM. En una sesión de 30 mensajes, se hace sentir.

Y luego están los errores sutiles. GLM no delira como Kimi — pero comete errores de nommage. Él llama`toAnonymizedYaml()el método que debería llamarse`anonymize(). Él invierte`loadReadmeConfiguration()` et loadCodebaseConfiguration()`en el`renderFileSection(). No son alucinaciones, son confusiones superficiales — pero en producción, una confusión superficial puede romper un build.

He tenido tres sesiones con GLM. Es mejor que Kimi, sin duda. Pero tres sesiones de corrección manual sobre detalles de nomenclatura, resulta agotador.

Dos niveles de compresión, dos granularidades de atención:

Resultado: a 1M de tokens, DeepSeek-V4-Pro solo consume27% de los FLOPs de inferencia et 10% del tamaño del caché KVen comparación con DeepSeek-V3.2. El modelo anterior.

Y sobre todo, el informe técnico (Figura 9) anuncia: "Retrieval performance remains highly stable within a 128K context window."

Sesiones 1-8: el alivio

He pasado ocho sesiones con DeepSeek-V4-Pro en`codebase-gradle`. Ocho sesiones sin una sola alucinación, sin una sola clase inventada, sin una sola confusión de nomenclatura.

Sesión 1 : implementación de`CodebaseYmlConfig` et CodebaseYmlAnonymizer. 350 líneas de Kotlin, pruebas en línea, todo compila. Sesión 4 : adición del`SnapshotManager`con vista de árbol, recolección de archivos, renderizado AsciiDoc por archivo. 279 líneas, cero error. Sesión 7 : depuración de`renderFileSection()`que tenía que gestionar cuatro tipos de anonimizadores diferentes sin ambigüedad de resolución. Resuelto en tres mensajes.

La latencia es más alta que Kimi — aproximadamente 10-12 segundos por respuesta en modo thinking. Pero la tasa de corrección es prácticamente nula. No paso mi tiempo reparando los errores del agente. Codifico con él.

En la sesión 8, el contexto acumulado supera los 100K tokens. Solicito un refactor intensivo: extraer las cuatro tareas de verificación en línea del`build.gradle.kts`a los archivos de prueba de JUnit5 en`buildSrc/src/test/`.

El agente propone un plan en tres fases :

El plan es correcto. La ejecución es limpia. Incluso identifica un caso límite que yo había pasado por alto: las dependencias Jackson duplicadas entre`buildscript {}` et `buildSrc/build.gradle.kts`que deben ser unificadas durante la migración.

100K tokens de contexto, y el agente recuerda que`CodebaseYmlAnonymizer.TOKEN_MASK`es`"*"`, que`GitConfig.resolvedToken()es una función de extensión definida en`readme.kt, y que`SnapshotManager.PRUNED_DIRS`excluye`build`, .gradle et .git.

Así es, la diferencia.

El desarrollo de software asistido es un caso de uso extremo para la atención de largo contexto. Necesitas: - Precisión local (¿De qué hereda esta clase? ¿Dónde está definido este método?) →CSA - Visión global (¿por qué existe este módulo? ¿cómo interactúan los cuatro anonimizadores?) →HCA

Kimi con MLA solo gestiona la precisión local pero pierde la visión global más allá de 60K. GLM con DSA mejora la visión global pero sigue siendo mono-nivel. DeepSeek combina ambos explícitamente.

Mi sistema de gobernanza carga ~30K tokens de reglas y de backlog al iniciar. Con una ventana estable de hasta 128K, DeepSeek tiene ~100K tokens de margen para los intercambios de la sesión. Es de 3 a 4 veces más de lo que Kimi puede manejar sin degradación.

</think> La ventana de 128K de estabilidad perfecta corresponde exactamente a mis necesidades: 30K de EAGER + 70K de intercambios = una sesión productiva de 20-30 mensajes sin nunca salir de la zona verde. __

Sí, DeepSeek-V4-Pro es más lento que Kimi (11s vs 8s). Pero el tiempo total de una tarea es mucho menor porque no paso 20 minutos corrigiendo las alucinaciones del agente.

El desarrollador no mide la latencia de una respuesta. Mide el tiempo entre « me hago la pregunta » y « el código está en mi repositorio y funciona ». Con esta métrica, DeepSeek-V4-Pro es el más rápido de los tres.