Curso de Kimi Code

Revisar las formas principales de uso de Kimi Code: cliente CLI para terminal, extensión de VS Code e integración mediante API o herramientas de terceros.

Entender que el CLI está orientado a desarrolladores que prefieren trabajar desde terminal con lectura de archivos, edición, comandos y tareas automatizadas.

Usar la extensión de VS Code cuando el equipo necesita interacción desde el editor, navegación visual del proyecto y cambios más integrados en el flujo diario.

Valorar el uso de Kimi Code con herramientas externas cuando la empresa ya trabaja con clientes agentic o entornos de desarrollo alternativos.

Diferenciar Kimi Code como producto de desarrollo frente al uso general de modelos Kimi en API o chat.

Revisar dependencias de plan, cuenta, API key, disponibilidad, límites, proveedor configurado y política corporativa.

Diseñar qué modalidad conviene por perfil: CLI para automatización, VS Code para desarrollo diario, API para integraciones y terceros para flujos existentes.

Evitar una adopción fragmentada donde cada equipo configura proveedores, permisos y herramientas de forma distinta.

Documentar la arquitectura de uso empresarial con clientes permitidos, modelos aprobados, datos accesibles y canales de soporte.

Crear una matriz de uso recomendada por perfil, tipo de tarea, nivel de riesgo y entorno técnico.

Instalar Kimi Code CLI mediante script oficial o npm según política interna, sistema operativo y control de software de la empresa.

Validar que el ejecutable `kimi` queda disponible en el PATH y que la versión instalada corresponde al entorno aprobado.

Conocer que la instalación por npm requiere Node.js 24.15.0 o superior, según la documentación de Quick Start.

Iniciar Kimi Code dentro de una carpeta de proyecto con `kimi`, diferenciando sesión interactiva, instrucción puntual y reanudación de sesión.

Usar `/login` para configurar credenciales desde el flujo interactivo, seleccionando Kimi Code o Moonshot AI Open Platform según el caso.

Separar cuentas personales y corporativas para evitar uso no autorizado de repositorios, modelos o datos de empresa.

Configurar el primer repositorio de laboratorio con código no confidencial, tests, scripts y documentación mínima.

Verificar comportamiento inicial: lectura de estructura, búsqueda de archivos, resumen de proyecto y propuesta de próximos pasos.

Evitar conectar Kimi Code directamente a repositorios productivos antes de definir permisos, reglas, datos permitidos y revisión humana.

Crear una checklist de onboarding para que cualquier desarrollador instale, autentique, pruebe y use Kimi Code de forma segura.

Revisar la configuración de Kimi Code para entender dónde se definen proveedores, modelos, parámetros, credenciales, sesiones y comportamiento runtime.

Configurar Kimi Code con el proveedor aprobado por la organización, evitando claves personales no auditadas.

Entender que la documentación permite configurar otros proveedores mediante `config.toml` cuando se trabaja con Anthropic, OpenAI, Google u otros.

Separar configuración global, configuración por proyecto y ajustes temporales para evitar cambios accidentales entre repositorios.

Revisar las ubicaciones de datos locales, sesiones, logs, configuración y cachés para saber qué información queda almacenada en el equipo.

Aplicar controles sobre archivos de credenciales, permisos de lectura, copia de seguridad, limpieza y baja de usuarios.

Ajustar modelo, proveedor y parámetros según tipo de tarea: análisis profundo, edición rápida, documentación, testing o automatización.

Evitar cambios de modelo no documentados cuando afectan calidad, coste, latencia o cumplimiento interno.

Documentar una configuración corporativa recomendada con comandos, rutas, variables, políticas y troubleshooting.

Crear un perfil de configuración de laboratorio con proveedor, modelo, logs, sesiones y repositorio de pruebas.

Entender cómo Kimi Code conserva contexto de sesión, conversaciones, estado, historial y trazas para poder reanudar trabajo técnico.

Usar sesiones separadas por tarea para no mezclar bugs, refactorizaciones, investigación, documentación y cambios de arquitectura.

Limitar el contexto enviado al agente para que trabaje con archivos relevantes y no arrastre supuestos de conversaciones anteriores.

Reanudar sesiones cuando se necesita continuar una investigación o implementación sin reconstruir todo el contexto desde cero.

Cerrar o limpiar sesiones obsoletas cuando contienen decisiones antiguas, rutas, logs o información que ya no debe influir.

Nombrar y documentar sesiones importantes cuando forman parte de un análisis técnico, spike o preparación de PR.

Revisar el contexto antes de pedir cambios sensibles para evitar que el agente use información desactualizada.

Gestionar historial local según política de privacidad, retención y confidencialidad de la empresa.

Evitar usar una única sesión interminable para todo el proyecto, porque reduce precisión y aumenta riesgo de confusión.

Diseñar una práctica de gestión de sesiones para bugs, features, refactorizaciones, documentación y soporte.

Pedir a Kimi Code que explore estructura, directorios, dependencias, puntos de entrada, módulos, tests y documentación antes de proponer cambios.

Solicitar mapas de arquitectura que distingan componentes reales del repositorio, supuestos y zonas no revisadas.

Analizar proyectos grandes por capas, bounded contexts, paquetes, servicios, librerías, scripts, pipelines y archivos de configuración.

Detectar dependencias internas, librerías externas, acoplamientos, duplicidad, puntos calientes y zonas sin cobertura de tests.

Usar búsquedas dirigidas para localizar reglas de negocio, errores recurrentes, llamadas a APIs, configuración o código legacy.

Pedir explicaciones orientadas a onboarding: qué hace cada módulo, cómo se ejecuta, dónde están los tests y qué riesgos tiene.

Evitar que el agente genere conclusiones arquitectónicas sin citar archivos, rutas, funciones o evidencias revisadas.

Convertir análisis de codebase en documentación útil: mapa de módulos, comandos, riesgos, owners y próximos pasos.

Usar el análisis inicial como base antes de pedir implementación, testing o refactorización.

Construir un informe de comprensión de repositorio con estructura, arquitectura, dependencias y recomendaciones accionables.

Redactar instrucciones con objetivo, contexto, alcance, restricciones, criterios de aceptación y comandos de validación esperados.

Separar tareas de investigación, planificación, implementación, testing y documentación para evitar cambios improvisados.

Pedir al agente que proponga un plan antes de tocar código cuando la tarea afecta a varios archivos o decisiones técnicas.

Limitar el alcance explícitamente: qué carpetas puede revisar, qué archivos puede modificar y qué cambios quedan fuera.

Exigir evidencias: archivos leídos, cambios realizados, tests ejecutados, errores encontrados y supuestos pendientes.

Evitar prompts vagos como “mejora este proyecto” o “arregla todo”, porque favorecen cambios amplios y difíciles de revisar.

Crear prompts reutilizables para bugs, features, tests, documentación, refactorización, análisis de logs y revisión de PR.

Incorporar restricciones de seguridad: no leer `.env`, no tocar secretos, no ejecutar comandos destructivos y no modificar producción.

Revisar si el resultado responde a la petición completa o si el agente ha resuelto una versión simplificada del problema.

Construir una biblioteca de prompts internos para tareas frecuentes de desarrollo, QA, DevOps y arquitectura.

Usar Kimi Code para convertir una petición amplia en pasos pequeños, verificables y ordenados por riesgo.

Pedir planes que separen análisis, cambios de código, pruebas, documentación, revisión de seguridad y validación final.

Evitar que el agente implemente directamente una solución compleja sin entender dependencias, contratos y efectos laterales.

Revisar planes con criterio humano antes de aprobar modificaciones en repositorios reales.

Dividir tareas grandes en subtareas por módulo, capa, archivo, prueba o entrega para facilitar revisión.

Identificar riesgos antes de actuar: cambios de API, migraciones, permisos, rendimiento, compatibilidad y datos.

Usar checkpoints intermedios para evaluar progreso antes de que el agente acumule demasiados cambios.

Documentar decisiones descartadas cuando el agente propone varias alternativas técnicas.

Convertir el plan final en checklist de PR, issue, tarea técnica o documentación de implementación.

Construir un plan completo para una feature empresarial con backend, frontend, tests, documentación y despliegue.

Pedir cambios pequeños y focalizados para que cada diff sea comprensible, revisable y fácil de revertir.

Revisar archivos modificados antes de aceptar resultados, prestando atención a lógica de negocio, seguridad, nombres y efectos colaterales.

Controlar que el agente no modifique archivos no solicitados, formatee zonas completas sin necesidad o cambie contratos públicos.

Exigir que cada cambio venga acompañado de explicación técnica, motivación y validación ejecutada.

Trabajar con ramas Git específicas para aislar experimentos, spikes, correcciones y tareas generadas con IA.

Comparar propuestas del agente con el estilo existente del proyecto antes de aceptar patrones nuevos.

Pedir refactorizaciones graduales cuando una mejora afecta a muchas clases o módulos.

Evitar aceptar código que compila pero no respeta arquitectura, seguridad, rendimiento o convenciones internas.

Usar revisión manual, tests y herramientas estáticas como filtros obligatorios antes de abrir PR.

Construir una práctica de edición asistida donde Kimi Code propone y el desarrollador decide, valida y documenta.

Usar Kimi Code para ejecutar comandos de build, test, lint, formateo, generación, inspección y diagnóstico dentro de un repositorio.

Revisar cada comando antes de aprobarlo cuando puede modificar archivos, instalar dependencias, borrar datos o cambiar configuración.

Conocer que, por defecto, las operaciones de solo lectura pueden ejecutarse automáticamente y las de modificación o shell requieren confirmación.

Crear listas de comandos seguros para tareas frecuentes: instalar dependencias, ejecutar tests, levantar entorno local o comprobar formato.

Bloquear comandos peligrosos relacionados con producción, credenciales, borrado masivo, migraciones destructivas o cambios de infraestructura.

Usar terminal como evidencia: salida de tests, errores, logs, warnings, métricas y resultados de ejecución.

Pedir al agente que explique un error de terminal antes de cambiar código para evitar correcciones especulativas.

Automatizar cadenas de comandos repetibles mediante scripts versionados en lugar de depender de instrucciones conversacionales.

Documentar comandos recomendados por proyecto para build, test, start, lint, seed, migrate y clean.

Construir un flujo de diagnóstico terminal con error reproducido, hipótesis, comando de validación y corrección mínima.

Usar Kimi Code para generar pruebas unitarias, integración, contrato, API, UI o end-to-end según la capa afectada.

Revisar que las pruebas generadas validan comportamiento real y no replican simplemente la implementación existente.

Pedir tests de regresión a partir de un bug reproducido antes de aplicar la corrección definitiva.

Ejecutar suites de pruebas desde CLI y usar la salida para guiar el diagnóstico.

Crear datos sintéticos y fixtures controlados cuando una prueba necesita contexto realista.

Evitar que el agente marque una tarea como terminada sin ejecutar pruebas relevantes o justificar por qué no se han podido ejecutar.

Pedir cobertura de caminos negativos, errores, límites, permisos, nulos y casos de concurrencia cuando proceda.

Integrar validación con linters, analizadores estáticos, formateadores y comprobaciones de seguridad.

Documentar evidencias de prueba en el resumen final: comandos, resultado, fallos corregidos y riesgos pendientes.

Construir una suite de pruebas para una feature añadida por Kimi Code, incluyendo happy path, errores y regresión.

Usar Kimi Code para analizar stack traces, logs, errores de compilación, fallos de test y comportamiento inesperado.

Pedir hipótesis ordenadas por probabilidad, archivos implicados y forma concreta de verificar cada una.

Reproducir el error antes de modificar código, evitando soluciones basadas solo en intuición del agente.

Aislar causa raíz diferenciando fallo de código, datos, configuración, dependencia, entorno, permisos o versión.

Generar cambios mínimos para corregir el bug sin reescribir módulos completos.

Añadir test de regresión cuando el bug revela un caso no cubierto por la suite existente.

Documentar causa raíz, solución, archivos modificados y validaciones ejecutadas.

Evitar parches que ocultan síntomas sin resolver el problema principal.

Usar logs y comandos de diagnóstico para confirmar que el error desaparece sin introducir nuevas regresiones.

Construir una práctica completa de debugging asistido desde error inicial hasta PR validado.

Pedir a Kimi Code que identifique deuda técnica con evidencias concretas: duplicidad, acoplamiento, clases grandes, nombres pobres o tests ausentes.

Priorizar refactorizaciones por riesgo, frecuencia de cambio, impacto en bugs, dificultad de mantenimiento y valor para el equipo.

Crear pruebas de caracterización antes de modificar código legacy o reglas de negocio sensibles.

Refactorizar por pasos pequeños, ejecutando tests y revisando diffs después de cada fase.

Evitar refactorizaciones cosméticas grandes que no reducen riesgo ni mejoran comprensión real.

Separar cambios funcionales y refactorización para que el PR sea más fácil de revisar.

Pedir al agente alternativas de diseño con pros, contras y migración gradual.

Documentar deuda aceptada cuando no conviene resolverla en la entrega actual.

Usar Kimi Code para generar mapas de dependencias y detectar seams antes de extraer módulos.

Construir un plan de reducción de deuda sobre un módulo legacy con fases, pruebas y rollback.

Usar Kimi Code para generar o actualizar README con instalación, comandos, estructura, variables y flujo de desarrollo.

Crear documentación de arquitectura basada en archivos reales revisados, evitando textos genéricos sin relación con el repositorio.

Generar runbooks para arranque local, troubleshooting, despliegue, rollback, migraciones, jobs y errores frecuentes.

Pedir resúmenes de cambios para pull requests, releases, auditorías técnicas o handoffs entre equipos.

Documentar decisiones técnicas con formato ADR cuando afectan a arquitectura, dependencias, seguridad o contratos.

Validar documentación ejecutando comandos y revisando que rutas, nombres y ejemplos existen realmente.

Evitar documentación generada que suena correcta pero no coincide con el proyecto.

Mantener documentación como parte del Definition of Done de cambios relevantes.

Usar Kimi Code para detectar documentación obsoleta comparando instrucciones con estructura actual del repositorio.

Construir un paquete documental completo para un proyecto: README, ADR, runbook, troubleshooting y guía de contribución.

Usar Kimi Code para resumir cambios de una rama, explicar diffs y preparar descripción de pull request.

Pedir revisión previa de PR enfocada en comportamiento, tests, seguridad, rendimiento, estilo y mantenibilidad.

Generar commits con mensajes claros, separados por intención y compatibles con la convención del equipo.

Evitar que el agente ejecute operaciones Git destructivas sin aprobación explícita, como reset, rebase complejo o force push.

Revisar conflictos de merge con ayuda del agente sin aceptar soluciones automáticas que pierden cambios.

Crear checklists de PR con tests ejecutados, riesgos, capturas, migraciones, documentación y cambios de configuración.

Usar el agente para detectar archivos modificados fuera de alcance antes de abrir la revisión.

Preparar respuestas a comentarios de PR con explicaciones técnicas y cambios concretos.

Documentar cuándo un cambio fue asistido por IA si la política interna lo requiere.

Construir un flujo completo desde issue hasta rama, commits, resumen de PR, revisión y cierre.

Comprender MCP como mecanismo para conectar Kimi Code con herramientas, datos y servicios externos de forma estructurada.

Revisar que Kimi Code CLI soporta conexión con servidores MCP para ampliar capacidades del agente.

Diseñar MCP servers de solo lectura para empezar: documentación interna, catálogos, issues, repositorios, métricas o sistemas de soporte.

Permitir acciones de escritura solo cuando existan permisos mínimos, validación de entrada, logs y confirmación humana.

Configurar MCP con cuidado, documentando nombre, transporte, credenciales, variables, owner y finalidad de cada servidor.

Proteger tokens y credenciales usados por MCP, evitando guardarlos en repositorios o compartirlos en prompts.

Prevenir prompt injection cuando el agente lee contenido externo como issues, documentación, páginas web o registros de soporte.

Diseñar tools MCP pequeñas y explícitas, con entradas tipadas y salidas limitadas.

Auditar uso de MCP para saber qué herramienta se invocó, con qué objetivo y qué datos devolvió.

Construir una integración MCP de laboratorio para consultar documentación o tickets simulados desde Kimi Code.

Usar hooks para añadir controles automáticos en momentos relevantes del flujo de Kimi Code cuando la funcionalidad está disponible.

Diseñar hooks que ejecutan tests, linters, formateadores, análisis de secretos o validaciones de estructura.

Crear hooks de bloqueo para impedir cambios en archivos sensibles, rutas prohibidas, configuraciones productivas o secretos.

Usar hooks informativos para generar evidencias, resúmenes, métricas o advertencias sin bloquear el flujo innecesariamente.

Evitar hooks lentos o ruidosos que hacen que el equipo los desactive por frustración.

Documentar cada hook con evento, propósito, comando, owner, riesgo cubierto y procedimiento de mantenimiento.

Probar hooks en repositorios de laboratorio antes de activarlos en proyectos reales.

Coordinar hooks con CI/CD para que controles locales y controles de pipeline sean coherentes.

Revisar periódicamente hooks obsoletos, comandos rotos o validaciones que ya no aportan valor.

Construir una estrategia de hooks para seguridad, calidad, formato y validación técnica del equipo.

Diseñar Skills como capacidades reutilizables para guiar al agente en tareas frecuentes, procesos técnicos o estándares de equipo.

Crear Skills para revisión de código, generación de tests, documentación, análisis de logs, refactorización o soporte técnico.

Redactar instrucciones claras con propósito, límites, ejemplos, entradas esperadas y formato de salida.

Incluir recursos auxiliares como plantillas, checklists, guías de estilo, comandos del proyecto o criterios de calidad.

Evitar Skills demasiado amplias que intentan cubrir todo el ciclo de desarrollo y terminan generando resultados imprecisos.

Versionar Skills en repositorio para revisar cambios, mantener historial y compartirlas entre miembros del equipo.

Probar Skills con casos reales de laboratorio antes de recomendarlas a toda la organización.

Definir owner funcional o técnico de cada Skill para actualizarla cuando cambian herramientas, arquitectura o procesos.

Medir si una Skill reduce retrabajo, mejora consistencia o acelera tareas sin degradar calidad.

Construir una Skill corporativa para revisión de PR o generación de tests alineada con estándares internos.

Usar plugins cuando la empresa necesita distribuir capacidades más completas que una instrucción aislada.

Agrupar Skills, hooks, configuraciones, MCP y convenciones en paquetes reutilizables por equipo, stack o tipo de proyecto.

Diseñar plugins por finalidad: desarrollo backend, frontend, QA, DevOps, documentación, seguridad o modernización.

Versionar plugins con changelog, owner, pruebas, compatibilidad y procedimiento de actualización.

Evitar instalar plugins no revisados o de origen desconocido en repositorios corporativos.

Probar plugins en sandbox para detectar conflictos de configuración, permisos, hooks, MCP o instrucciones.

Documentar instalación, uso, límites, herramientas incluidas, datos accesibles y procedimiento de retirada.

Definir qué plugins son obligatorios, recomendados u opcionales según tipo de repositorio.

Revisar periódicamente plugins para eliminar capacidades obsoletas o inseguras.

Construir un plugin interno de laboratorio que incluya Skill, hook y configuración MCP de solo lectura.

Usar agentes y subagentes para dividir análisis grandes en tareas independientes: módulo, capa, bug, documentación, tests o migración.

Asignar a cada subagente una tarea concreta, con contexto limitado, salida esperada y restricciones claras.

Evitar lanzar subagentes sin coordinación, porque pueden duplicar trabajo, generar conclusiones contradictorias o tocar zonas relacionadas.

Pedir resultados comparables: archivos revisados, hallazgos, riesgos, recomendaciones y evidencias.

Consolidar conclusiones de varios subagentes antes de tomar una decisión arquitectónica o implementar cambios.

Separar trabajo paralelo de solo lectura y trabajo que modifica archivos, aplicando más control sobre este último.

Usar subagentes para análisis de legacy, revisión de tests, documentación o exploración de alternativas.

Revisar coste, latencia, límites y consumo cuando se trabaja con múltiples tareas concurrentes.

Documentar cuándo un equipo puede usar subagentes y qué tipos de tareas están permitidas.

Construir una revisión multi-módulo donde varios subagentes analizan áreas distintas y el agente principal consolida resultados.

Instalar y configurar la extensión de Kimi Code para VS Code cuando el equipo prefiera trabajar desde editor.

Usar el panel del editor para revisar archivos, pedir cambios, navegar contexto y validar propuestas con mayor control visual.

Comparar cuándo conviene CLI y cuándo conviene VS Code según tipo de tarea, perfil y necesidad de interacción.

Mantener consistencia entre configuración de CLI y extensión para no obtener comportamientos distintos entre usuarios.

Usar Kimi Code en VS Code para cambios localizados, explicación de fragmentos, generación de tests y revisión de errores.

Evitar aceptar cambios masivos desde el editor sin revisar diff completo, tests y alcance.

Coordinar Kimi Code con extensiones existentes de linting, testing, Git, Docker, notebooks o frameworks específicos.

Documentar atajos, flujo de uso y buenas prácticas para desarrolladores que trabajan en VS Code.

Probar tareas equivalentes en CLI y VS Code para entender ventajas y límites de cada interfaz.

Construir una práctica de uso diario en VS Code: análisis de archivo, cambio asistido, test, diff y resumen de PR.

Explorar opciones de uso de Kimi Code en herramientas de desarrollo externas cuando la organización ya tiene un ecosistema consolidado.

Entender que otros editores o agentes pueden conectarse mediante protocolos o configuraciones específicas documentadas por Kimi Code.

Diseñar una política de herramientas permitidas para evitar que cada equipo conecte Kimi Code a clientes no revisados.

Validar compatibilidad de flujos con IDEs JetBrains, Zed, terminales Zsh y clientes agentic de terceros.

Revisar cómo cambian permisos, historial, contexto, logs y ejecución de comandos según herramienta usada.

Evitar soporte interno ilimitado para combinaciones de herramientas que la empresa no ha aprobado.

Documentar configuraciones estándar por entorno: CLI oficial, VS Code, JetBrains, Zed o terminal.

Probar integraciones en repositorios de laboratorio antes de incorporarlas al flujo de desarrollo diario.

Crear criterios para aceptar nuevas herramientas: seguridad, soporte, compatibilidad, productividad, logs y facilidad de baja.

Construir una matriz de compatibilidad y soporte para Kimi Code en entornos de desarrollo corporativos.

Definir qué datos pueden compartirse con Kimi Code y qué información queda prohibida: secretos, credenciales, datos personales o código sensible.

Bloquear lectura de archivos como `.env`, claves privadas, certificados, dumps, tokens, credenciales y configuración productiva.

Revisar comandos antes de ejecutarlos cuando pueden enviar datos fuera, instalar dependencias, borrar archivos o modificar infraestructura.

Usar repositorios de laboratorio y datos sintéticos para formación, pruebas y experimentación.

Definir reglas de revisión humana para cambios en autenticación, autorización, cifrado, permisos, dependencias e infraestructura.

Evitar pegar logs productivos sin anonimizar, especialmente si contienen usuarios, emails, tokens, IPs o información de clientes.

Documentar política de retención local de sesiones, logs y configuraciones.

Revisar MCP, plugins, hooks y Skills como superficies de riesgo, no solo como ayudas de productividad.

Crear proceso de respuesta si se comparte accidentalmente información sensible o se ejecuta un comando no deseado.

Construir una checklist AppSec para uso de Kimi Code en repositorios corporativos.

Usar Kimi Code para analizar pipelines, errores de CI, scripts de build, despliegue, contenedores y configuración de entornos.

Pedir propuestas de mejora de CI/CD con cambios pequeños, pruebas y explicación de impacto.

Revisar workflows de GitHub Actions, GitLab CI, Azure Pipelines, Jenkins o herramientas equivalentes.

Analizar logs de pipeline para detectar causa raíz de fallos de tests, dependencias, permisos o entorno.

Generar documentación de despliegue, rollback, variables, secretos, entornos y troubleshooting.

Evitar que el agente modifique pipelines productivos sin revisión DevOps y ejecución en entorno de prueba.

Integrar validaciones locales con checks de CI para que el equipo reciba feedback coherente.

Usar Kimi Code para crear scripts repetibles en lugar de procedimientos manuales frágiles.

Revisar costes y riesgos de automatizaciones que ejecutan tareas largas o concurrentes.

Construir una mejora de pipeline con análisis, cambio controlado, validación y documentación operativa.

Usar Kimi Code para comprender aplicaciones legacy, dependencias, módulos críticos, scripts antiguos y zonas sin documentación.

Generar pruebas de caracterización antes de refactorizar o migrar funcionalidad sensible.

Identificar seams para extraer módulos, actualizar dependencias, separar responsabilidades o crear capas anticorrupción.

Planificar migraciones por fases, con compatibilidad, rollback, métricas y validación funcional.

Evitar reescrituras completas propuestas por el agente sin justificación de negocio, riesgos y capacidad del equipo.

Detectar APIs obsoletas, librerías abandonadas, patrones inseguros y configuraciones que bloquean evolución.

Documentar decisiones de modernización mediante ADRs, mapas de impacto y backlog técnico.

Usar subagentes para analizar áreas distintas de un monolito sin mezclar conclusiones.

Medir progreso por reducción de riesgo, tests añadidos, dependencias retiradas y módulos estabilizados.

Construir un plan de modernización legacy con Kimi Code, pruebas, fases y criterios de éxito.

Diseñar un piloto controlado con repositorios no críticos, usuarios técnicos senior y objetivos medibles.

Definir casos de uso permitidos, restringidos y prohibidos según riesgo, datos, permisos y madurez del equipo.

Crear estándares de configuración, prompts, MCP, hooks, Skills, plugins, revisión de PR y protección de secretos.

Formar a desarrolladores, QA, DevOps, arquitectura y AppSec con ejemplos adaptados a sus tareas reales.

Establecer owners de la plataforma, soporte, documentación, seguridad y catálogo de capacidades reutilizables.

Medir impacto por tiempo ahorrado, bugs resueltos, tests añadidos, reducción de retrabajo y satisfacción del equipo.

Revisar incidentes, falsos positivos, malos usos y gaps de política para mejorar el modelo de adopción.

Evitar imponer la herramienta sin explicar límites, responsabilidades y beneficios concretos por perfil.

Crear una comunidad interna para compartir prompts, Skills, plugins, flujos y aprendizajes.

Construir un plan de adopción de 30, 60 y 90 días para Kimi Code en una organización técnica.

Seleccionar un repositorio de laboratorio con código, tests, documentación, pipeline, issues simulados y deuda técnica controlada.

Configurar Kimi Code CLI, credenciales, provider aprobado, sesiones, repositorio, herramientas y política de comandos seguros.

Realizar análisis inicial de codebase con mapa de módulos, comandos, dependencias, riesgos y oportunidades de mejora.

Resolver un bug mediante reproducción, hipótesis, cambio mínimo, test de regresión, ejecución de pruebas y resumen técnico.

Implementar una feature pequeña con plan previo, cambios revisables, tests, documentación y descripción de PR.

Crear una Skill interna para una tarea recurrente del equipo, con instrucciones, límites, ejemplos y criterios de calidad.

Configurar un MCP de laboratorio para consultar documentación o tickets simulados con permisos de solo lectura.

Diseñar un hook o control de validación para tests, formato, secretos o archivos sensibles.

Preparar un plugin o paquete de configuración reutilizable con estándares de equipo, Skill y controles aprobados.

Presentar el modelo final con resultados, métricas, riesgos, checklist de seguridad, guía de uso y roadmap de adopción.