Kimi K3 para agentes de código: harness, contexto y verificación
K3 en producción es primero un problema de harness: permisos, qué metes en el contexto de 1M y gates antes del merge — no otro resumen de benchmark.
La corrida del agente se veía verde hasta que alguien vio migrations/ en el diff. K3 no “se descontroló”: dejamos escritura en la raíz del repo y metimos 900k tokens de logs al contexto esperando que el modelo “lo resolviera”. El modelo hizo exactamente lo pedido: editó con confianza en la capa equivocada.
Por eso existe este artículo. Las notas de lanzamiento de Kimi K3 cubren specs; aquí cubrimos el loop alrededor de K3 — API Moonshot o Kimi Code, disciplina de contexto 1M y gates antes del merge. Snapshot DevCove 2026-07-25: K3 rank #7, index 57, ~161s de primer chunk en la misma tabla — planifica batch/agente, no chat nervioso en el IDE salvo que tu wrapper oculte la latencia.
Layout del harness (lo que dibujamos en la pizarra)
┌──────────────────────────────────────────────┐
│ Humano: alcance + tests de aceptación │
├────────────────────┬─────────────────────────┤
│ Entrada de │ Superficie de tools │
│ contexto │ (shell, MCP, red) │
│ (paths curados) │ │
├────────────────────┴─────────────────────────┤
│ K3 (tier de razonamiento explícito en API) │
├──────────────────────────────────────────────┤
│ CI + review humano del diff (obligatorio) │
└──────────────────────────────────────────────┘
Harness débil, cualquier frontier parece roto. Arregla la caja antes de cambiar modelo.
| Capa | Default malo | Default mejor |
|---|---|---|
| Alcance | “Arregla el servicio” | Paquetes + archivos permitidos nombrados |
| Contexto | Repo entero pegado | Slice de spec + test fallando + un ADR |
| Tools | Shell sin límite | Allowlist; cmds destructivos piden humano |
| Salida | Volcado multi-archivo enorme | Parches pequeños por paso |
Contexto 1M: presupuesto, no vertedero
La ventana 1,05M de K3 tienta a subir todo. Basura entra, basura sale — escala MoE no inventa disciplina.
| Alimenta esto | Evita esto |
|---|---|
| User story + non-goals | node_modules completo o SDKs generados |
| Un ancla de arquitectura | Cincuenta READMEs sin orden |
| Extracto del fallo reciente en CI | Historial entero de logs |
| Golden test como ejemplo | Suite entera inline |
Limitamos armado de contexto a 15 minutos por tarea de agente. Si curar tarda más que el fix, la tarea no estaba acotada para agente.
Kimi Code vs HTTP API
| Vía | Elige cuando |
|---|---|
| Kimi Code | Quieres defaults de agente terminal de Moonshot |
HTTP API (kimi-k3) | Lo embebes en un orquestador interno |
| IDE de terceros | Solo con soporte oficial — revisa residencia de datos |
La revisión de seguridad aplica a permisos, no al rank del leaderboard. K3 bien en benchmark no aprueba acceso a DB de producción.
Loop de verificación (no opcional)
Tomado de Verification gates for AI coding agents:
Ticket de tarea
→ agente (K3) con tools acotadas
→ tests unit + integración
→ lint / types
→ humano lee diff (no resumen)
→ ship checklist en ramas de release
K3 a veces ensancha parches versus nuestro modelo anterior. Parches más anchos = review más ancho, no merge más rápido.
Cuándo seguimos eligiendo Opus
Si Claude Code ya está aprobado, Opus 5 high suele sentirse más rápido en loops interactivos en el mismo snapshot — mira Kimi K3 vs Claude Opus 5. Probamos K3 cuando Moonshot está en contrato, importa el costo por tarea a 1M, o Kimi Code encaja en ops.
Regla de ops: Sin overwrite parcial de snapshot GitHub en rate limit — conserva último stars/models bueno; misma paciencia en retries de agente (no apagues gates porque el modelo “casi siempre funciona”).
Enlaces: Rankings · Pilar de metodología · Ship checklist
Fecha de evidencia: snapshot DevCove 2026-07-25; verifica campos API en doc Moonshot antes de producción.