En marzo de 2026, renovamos la experiencia de moonshot.ai en toda la plataforma. La actualización parecía sencilla: una nueva paleta de colores, una tipografía más ajustada y movimiento actualizado. En la práctica, impactó componentes compartidos, tokens de diseño, rutas y capas interactivas en todo el sitio.
Usamos Kimi Code CLI, impulsado por Kimi K2.5, como agent de programación con AI para llevar adelante la reconstrucción. Este proyecto se convirtió en una prueba práctica de cómo encaja un agent basado en la terminal dentro de un flujo de trabajo real de producción, no en un entorno de demostración. En este artículo contamos cómo lo usamos y qué aprendimos en el proceso.
De qué trataba realmente esta renovación
La renovación de moonshot.ai no consistía en rediseñar la marca desde cero. La mayor parte del trabajo de diseño ya existía en Figma. El verdadero desafío era aplicar esas actualizaciones de forma consistente en una base de código existente.
Eso implicaba rastrear tokens compartidos, actualizar componentes, revisar el comportamiento interactivo y asegurarnos de no afectar la analítica ni la accesibilidad. Muchos cambios eran pequeños por separado, pero atravesaban varias capas del sitio.
Este tipo de trabajo no es difícil por su complejidad algorítmica. Lo es por su amplitud y por la necesidad de consistencia. El reto está en saber qué toca cada cambio y asegurarse de que no se pase nada por alto. Para apoyarnos, usamos una conexión de Model Context Protocol (MCP) con Figma para alinear mejor las especificaciones de diseño con la implementación, lo que ayudó al agent a entender la estructura y redujo la interpretación manual.
Reglas de base: cómo hacer útil al agent
El primer paso no fue escribir prompts, sino establecer el contexto. Usamos el comando /init para generar un archivo AGENTS.md y luego dedicamos cerca de una hora a refinarlo. Allí documentamos qué incluía la renovación, qué no podía cambiar, cómo estaba estructurado el proyecto y cómo funcionaba el proceso de build. También agregamos un archivo de reglas con convenciones de nombres, espaciado y requisitos de contraste.
Esta configuración redujo la necesidad de repetir explicaciones más adelante e hizo más consistente el flujo de trabajo con Kimi Code CLI. Sin contexto específico del proyecto, el agent de programación con AI tiende a producir resultados razonables, pero genéricos. Con ese contexto, su comportamiento se acerca más al de un compañero que ya entiende la base de código.
Cómo lo usamos en la práctica
Esta sección desglosa cómo se usó Kimi Code CLI durante la renovación en la práctica: rastreo de dependencias, alineación con el diseño, investigación de comportamiento, revisiones de rendimiento y evaluación de riesgos de integración. El foco no estuvo en automatizar, sino en reducir la incertidumbre en una refactorización a gran escala.
Entender qué afecta el cambio
Antes de editar cualquier cosa, le pedimos al agent en Kimi Code CLI que leyera el área objetivo y enumerara qué más dependía de ella. Un solo cambio —como el color de un botón— puede afectar secciones hero, secciones de descarga, estados hover y tokens compartidos; además, los componentes compartidos, los tiempos de movimiento y los hooks de analítica pueden ampliar aún más el impacto. Obtener primero una lista de dependencias redujo las sorpresas posteriores e hizo que las ediciones fueran más predecibles.
Ajustar el código a la especificación de diseño
Luego comparamos los componentes con la especificación de diseño, sección por sección: hero, navegación, secciones de producto, CTA de descarga y footer. El agent generó listas de cambios a nivel de propiedades comparando estilos con tokens de diseño y valores de layout. Este proceso se sintió más cercano a una automatización estructurada de un sistema de diseño que a una revisión visual manual. La mayoría de las diferencias eran pequeñas, como espaciado, radio de borde o peso tipográfico, pero a veces aparecían inconsistencias mayores en componentes que debían compartir variantes y que con el tiempo se habían desalineado. El resultado fue una lista concreta de ediciones, no un proceso de conjeturas visuales.
Investigar nuevos comportamientos
La renovación incorporó nuevos comportamientos de UI que no estaban implementados antes en la base de código: un cursor personalizado, un hero controlado en tiempo de ejecución, tarjetas ilustradas que se reproducen al hacer hover y entradas activadas por scroll.
Para cada función, usamos Kimi Code CLI como un entorno contextual cargando juntos la documentación y el estado del repositorio. Aquí fue donde Kimi K2.5 marcó la diferencia: un contexto más largo facilitó razonar sobre la implementación y las referencias en un solo lugar.
Las preguntas eran prácticas:
¿Las animaciones hover deben completarse o cancelarse al salir?
¿El estado del cursor debe interactuar con el canvas del hero?
¿Qué se rompe cuando se superponen varias capas?
La ventana de contexto amplia habilitó un flujo de trabajo con kimi code más continuo, en el que la intención de diseño y el código conviven en la misma sesión.
Revisar peso y rendimiento
La renovación incorporó una nueva tipografía, más movimiento y recursos adicionales, lo que aumentó el peso de la página. Usamos el agent para adaptar el script existente de subsetting de fuentes y verificar el resultado; más tarde, también ayudó a interpretar reportes de Lighthouse para identificar regresiones temprano. El objetivo no era optimizar todo al final, sino tomar decisiones de conservar o recortar mientras los cambios aún eran pequeños.
Rastrear riesgos de integración antes de fusionar
Varias capas interactivas —animación de entrada, cursor, canvas del hero— comparten ordenamiento y comportamiento de puntero aunque vivan en componentes separados, de modo que un cambio en una capa puede afectar a otras. También tuvimos que contemplar diferencias entre navegadores y sistemas operativos, donde el comportamiento de CSS y del renderizado no siempre coincide. Antes de fusionar lotes de cambios, pasamos los diffs a Kimi Code CLI y le pedimos que rastreara qué interacciones podían verse afectadas; luego revisamos esas rutas en el navegador e hicimos una pasada ligera en distintos entornos.
Integraciones MCP y Skills
Model Context Protocol (MCP) permitió que Kimi Code CLI se conectara directamente con sistemas externos que contenían datos del proyecto. Usamos mcp Figma para extraer tokens de diseño, datos de layout y tipografía directamente desde Figma, reduciendo la traducción manual entre diseño y código; también conectamos herramientas internas, lo que dejó expuestas tareas, especificaciones y casos límite sin cambiar de contexto.
Agregar un servidor requiere un solo comando:
El patrón se generaliza en todo el ecosistema MCP. Como inspiración, puedes conectar agents a:
Figma — MCP oficial para contexto de diseño, variables y datos de layout del canvas
Atlassian Cloud — páginas de Confluence y elementos de trabajo de Jira mediante el punto de entrada MCP remoto de Atlassian (documentado junto con Rovo)
Bases de datos, API de CMS — servidores MCP de proveedores o de la comunidad; los registros listan cientos de opciones por categoría
Tu stack puede ser distinto: una API privada de documentación, un servicio interno de tokens de diseño o un data warehouse. La idea es la misma: conectar el agent con los sistemas que ya contienen los datos relevantes. Para archivos de configuración, definiciones de servidor y otras formas de conectar MCP en Kimi Code CLI, consulta la guía de la plataforma.
Skill de revisión
También escribimos una Skill para revisión de código. Es un archivo de reglas que le indica a Kimi Code CLI cómo evaluar una merge request de punta a punta: leer el diff, rastrear archivos y componentes afectados, comprobar infracciones del sistema de diseño (literales de color sin abstraer, espaciado fuera de la grilla, fallbacks de accesibilidad faltantes), evaluar el riesgo por área y generar un reporte estructurado.
El reporte sigue un formato fijo:
Un resumen de la intención y el alcance
Hallazgos agrupados por gravedad (problemas críticos que bloquean el merge, mejoras recomendadas, sugerencias menores de consistencia)
Para cada hallazgo: evidencia del diff, evaluación del impacto y una acción concreta
La Skill también señala posibles riesgos que pueden requerir una validación rápida en navegador o dispositivo: casos en los que el agent tiene incertidumbre, pero el costo de verificar es bajo.
En la práctica, cada PR de la renovación visual de moonshot.ai pasó por esta revisión estructurada antes de completarse. La salida siempre incluía recapitulación de la intención, hallazgos ordenados por gravedad, evidencia y correcciones.
Esto ayudó a reducir el retrabajo en etapas tardías y mejoró la consistencia en todo el flujo de Kimi Code, al sacar a la luz problemas como URL hardcodeadas junto a constantes compartidas, campos de analítica que necesitaban alinearse y casos límite de interacción móvil.
Lo que no esperábamos
Durante la refactorización, surgieron algunos patrones que no eran evidentes al inicio.
Pasar de la especificación al código fue más rápido de lo esperado
Con Figma MCP y Kimi Code CLI en el mismo hilo, las dimensiones y los tokens de diseño llegaban como entrada estructurada en vez de transcribirse manualmente. El resultado fueron ciclos de iteración más cortos por sección: los cambios y correcciones a nivel de propiedades a menudo quedaban listos en una sola pasada, sin ir y venir entre herramientas.
Los prompts de investigación rindieron más de lo esperado
La renovación dependió en gran medida de pasadas largas, guiadas por documentación, por la documentación de runtime y las implementaciones de referencia junto con el repositorio. Mantener estos materiales en la misma sesión que el código a menudo resultó tan valioso como las ediciones mismas.
La Skill de revisión convirtió pequeñas inconsistencias en una lista
El reporte estructurado expuso los mismos tipos de problemas descritos antes: URL hardcodeadas junto a constantes compartidas, campos de analítica que necesitaban alinearse y casos límite de interacción móvil. La mayoría eran menores por separado, pero fueron más fáciles de abordar una vez agrupados en una sola pasada.
Los hilos largos siguieron siendo baratos de retomar
Comandos como kimi --continue y /compact permitieron que el trabajo de varios días no exigiera reconstruir el contexto cada mañana. Esto redujo la necesidad de volver a prompt-ear y mantuvo el mismo flujo de Kimi Code avanzando de forma consistente.
Para más información sobre cómo retomar sesiones, cambiar entre ellas y gestionar el contexto con /compact y comandos relacionados, consulta la guía de sesiones de Kimi Code CLI.
Lecciones aprendidas al reconstruir moonshot.ai
Si volviéramos a realizar una renovación visual similar de moonshot.ai, abordaríamos algunas cosas de otra manera.
Empezar por el contexto, no por el código
Dedicar la primera hora a documentar alcance, restricciones y convenciones ahorró más tiempo que cualquier prompt posterior. Establecerlo desde el principio hizo que herramientas como Kimi Code CLI se comportaran con mayor consistencia durante todo el flujo de trabajo.
Conectar temprano una fuente de verdad
En nuestro caso, fue Figma. En otros proyectos, podría ser un CMS, una API interna o un sistema de diseño. La clave es asegurarse de que el sistema trabaje con datos reales y no con supuestos inferidos, especialmente cuando se usa un agent de programación con IA en una refactorización frontend.
Mantener el contexto de diseño y de tareas en el mismo ciclo
Llevar tokens, especificaciones e implementación a un contexto compartido redujo el ida y vuelta e hizo más estables los ciclos de iteración. Aquí fue donde los flujos con Figma MCP y Kimi Code CLI resultaron especialmente efectivos, ya que ayudaron a mantener alineadas la intención de diseño y los cambios de código en un ciclo continuo.
Si no quieres escribir código: Kimi Websites
Todo lo anterior describe un flujo centrado en desarrolladores: terminales, diffs y archivos de contexto. Sin embargo, el mismo resultado —un sitio web pulido y responsivo— también puede lograrse sin ese stack cuando la velocidad importa más que el control a nivel de framework.
Kimi Websites funciona con el mismo modelo Kimi K2.5, pero mediante una interfaz visual sin código. Describes lo que quieres en lenguaje natural, refinas secciones conversando y publicas con un clic. También puede tomar una captura de pantalla existente como entrada y reconstruir la estructura del layout.
Para fundadores que prototipan landing pages o equipos de marketing que lanzan sitios de campaña con plazos ajustados, esto ofrece un camino más rápido que trabajar directamente con un stack frontend tradicional.
Conclusión
Kimi Code CLI y Kimi K2.5 fueron más útiles en las partes del proyecto donde la amplitud importaba más que la complejidad. Una renovación visual rara vez se trata de problemas difíciles: consiste en muchos cambios pequeños que deben mantenerse consistentes en todo un sistema. Eso la vuelve demandante para las personas, pero relativamente adecuada para un agent que puede rastrear y comparar entre archivos.
Nosotros seguimos tomando las decisiones, revisamos cada cambio y validamos el resultado final. El agent se encargó del rastreo repetitivo, la comparación y el trabajo inicial de revisión. En la práctica, esta división del trabajo resultó ser una forma práctica de integrar un agent de programación con IA en un flujo de producción. Para refactorizaciones entre archivos, verificación de diseño a código y trabajo de consistencia a gran escala, este enfoque demostró ser útil.