600 archivos, un comando: lo que la refactorización de moonshot.ai dice sobre los agentes de IA en el trabajo

En marzo de 2026, moonshot.ai lanzó un nuevo aspecto. El registro de cambios parecía la lista de deseos de un diseñador: paleta de colores fresca, tipografía más ajustada, movimiento actualizado. Detrás de escena, el trabajo no era nada glamoroso.

La renovación tocó componentes compartidos, tokens de diseño, rutas y capas interactivas en todo el sitio. Ninguna edición individual fue algorítmicamente difícil. El desafío era la amplitud. Saber qué tocaba cada cambio y asegurarse de que nada se escapara. Ese tipo de trabajo es exactamente donde un agente de codificación de IA puede ganarse su sustento, o quemar su presupuesto en ruido.

El equipo de ingeniería de Moonshot utilizó Kimi Code CLI, impulsado por Kimi K2.5, como asistente principal para esta refactorización. El proyecto se ejecutó en una base de código de producción con restricciones reales: sin sandboxes de demostración, sin tareas seleccionadas. Los resultados, publicados en un análisis detallado posterior, ofrecen una visión realista de lo que un agente basado en terminal hace realmente bien, y lo que aún exige la intervención humana. minimax-launches-m27-model-with-strong-software-engineering-and-office-productivity-skills

La idea central: amplitud sobre complejidad

La renovación de moonshot no se trataba de reescribir la lógica central. Se trataba de rastrear tokens compartidos, actualizar componentes, verificar el comportamiento interactivo y asegurarse de que la analítica y la accesibilidad sobrevivieran. Individualmente trivial. Colectivamente, agotador. how-local-llms-like-gemma-and-qwen-are-taming-open-source-repository-triage-at-scale

El primer movimiento del equipo no fue escribir un prompt. Ejecutaron /init para generar un archivo AGENTS.md, luego dedicaron aproximadamente una hora a refinarlo: qué estaba dentro del alcance, qué no podía cambiar, cómo estaba estructurado el proyecto, cómo funcionaban las compilaciones. También agregaron un archivo de reglas para nombres, espaciado y contraste.

Esa inversión inicial valió la pena. Sin contexto específico del proyecto, un agente de IA tiende a producir resultados razonables pero genéricos. Con él, el comportamiento del agente se alineó más al de un compañero de equipo que ya entendía la base de código.

Cómo se usó realmente el agente

Seis flujos de trabajo distintos definieron la refactorización. Cada uno se enfocaba en una fase específica del proceso de producción, no en automatización por sí misma, sino en reducción de incertidumbre.

Rastrear dependencias antes de tocar el código

Antes de editar cualquier cosa, el equipo pidió a Kimi Code CLI que leyera un área objetivo y listara qué dependía de ella. Un cambio de color de botón, por ejemplo, podría repercutir en secciones de héroe, CTAs de descarga, estados de hover y tokens compartidos. Obtener ese mapa primero hizo que las ediciones fueran predecibles y redujo roturas sorpresa.

Igualar código con especificaciones de Figma

Usando una conexión Model Context Protocol (MCP) con Figma, el agente extrajo tokens de diseño, datos de diseño y tipografía directamente de la herramienta de diseño. La comparación componente por componente se convirtió en un proceso estructurado: héroe, navegación, secciones de producto, pie de página. El agente produjo listas de cambios a nivel de propiedad al igualar estilos contra tokens de diseño y valores de diseño. La mayoría de las diferencias eran pequeñas (espaciado, radio de borde, peso de fuente), pero el agente descubrió inconsistencias mayores donde componentes que deberían haber compartido variantes se habían desviado con el tiempo.

Investigar nuevo comportamiento interactivo

La renovación introdujo características no presentes en la base de código existente: un cursor personalizado, un héroe impulsado por tiempo de ejecución, tarjetas de ilustración que reproducen al pasar el ratón y entradas activadas por desplazamiento. Para cada una, el equipo cargó documentación y estado del repositorio en la misma sesión. La gran ventana de contexto de Kimi K2.5 permitió al agente razonar a través de la implementación y las referencias en una sola pasada.

Las preguntas eran prácticas: ¿deberían las animaciones de hover completarse o cancelarse al salir? ¿El estado del cursor interactúa con el lienzo del héroe? ¿Qué se rompe cuando se superponen múltiples capas? Mantener la intención del diseño y el código en la misma sesión hizo que esas respuestas fueran más rápidas de alcanzar.

Verificar peso y rendimiento

La renovación introdujo un nuevo tipo de letra, más movimiento y activos adicionales. El agente adaptó el script de subconjunto de fuentes existente, verificó la salida y ayudó a interpretar los informes de Lighthouse desde el principio. El objetivo no era optimizar todo al final; era tomar decisiones de mantener o cortar mientras los cambios aún eran pequeños.

Rastrear riesgo de integración antes de fusionar

Múltiples capas interactivas (animaciones de entrada, cursor, lienzo del héroe) compartían ordenamiento y comportamiento del puntero. El agente rastreó posibles conflictos de interacción entre lotes de diferencias, señalando casos donde un cambio en una capa podría romper otra. Las diferencias entre navegadores y sistemas operativos agregaron otra dimensión.

Revisiones de código estructuradas a través de una Skill personalizada

El equipo escribió una Skill, un archivo de reglas que le dice a Kimi Code CLI cómo evaluar una solicitud de fusión de principio a fin. El agente leyó la diferencia, rastreó los archivos y componentes afectados, verificó violaciones del sistema de diseño (literales de color sin procesar, espaciado fuera de la cuadrícula, respaldos de accesibilidad faltantes), evaluó el riesgo por área y generó un informe estructurado con hallazgos agrupados por gravedad.

Cada PR durante la renovación pasó por esta verificación antes de completar la revisión. La salida siempre incluía un resumen de intención, hallazgos clasificados por gravedad con evidencia y elementos de acción concretos. Problemas como URLs codificadas junto a constantes compartidas, campos de analítica que necesitaban alineación y casos extremos de interacción móvil surgieron aquí, detectados antes de llegar a la bandeja de entrada de un revisor. cuga-ibms-open-source-agent-harness-lets-you-build-apps-with-just-a-prompt-and-tool-list

Lo que sorprendió al equipo

Surgieron tres patrones que no eran obvios al inicio.

La especificación a código se volvió más rápida de lo esperado. Con Figma MCP y Kimi Code CLI en el mismo hilo, las dimensiones y los tokens de diseño llegaron como entrada estructurada. Los ciclos de iteración por sección se redujeron. Los cambios a nivel de propiedad y las correcciones a menudo aterrizaban en una sola pasada en lugar de rebotar entre herramientas.

Los prompts de investigación rindieron más de lo anticipado. La renovación dependió en gran medida de pasadas largas y basadas en documentos a través de documentación de tiempo de ejecución e 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 manejable. URLs codificadas, alineación de analítica, casos extremos móviles. La mayoría eran menores individualmente, pero más fáciles de abordar una vez agrupados en una sola pasada. Los hilos largos se mantuvieron económicos para reanudar mediante los comandos kimi, continue y /compact, evitando la reconstrucción del contexto cada mañana. the-hidden-bottleneck-in-ai-inference-why-deepseeks-dspark-rewrites-the-rules-of-speculative-decoding

La línea divisoria: quién hace qué

El equipo es explícito sobre la división del trabajo: ellos tomaron las decisiones, revisaron cada cambio y validaron el resultado final. El agente manejó el rastreo repetitivo, la comparación y el trabajo de revisión inicial. Esa distinción importa porque define el límite práctico para los agentes de codificación de IA en flujos de trabajo de producción.

Para refactorizaciones entre archivos, verificación de diseño a código y trabajo de consistencia a gran escala, este enfoque resultó útil. El agente eliminó la parte tediosa (la parte donde un humano tendría que mantener 600 archivos en su cabeza y comparar cada desviación mentalmente). Pero no reemplazó al arquitecto, al revisor ni a la persona que da el visto bueno a la experiencia final.

Para equipos que consideran un flujo de trabajo similar, las lecciones son claras: invierta en contexto del proyecto desde el principio, conecte una fuente de verdad temprano (Figma, CMS, API interna) y mantenga la intención del diseño y el código en el mismo bucle. El agente amplifica la consistencia en toda la amplitud. El humano es dueño de las decisiones que importan. ibms-open-source-cuga-agent-harness-lets-you-build-apps-with-just-a-prompt-and-tool-list