Em março de 2026, renovamos a experiência da moonshot.ai em toda a plataforma. A atualização parecia simples: uma nova paleta de cores, tipografia mais ajustada e movimentos atualizados. Na prática, ela afetou componentes compartilhados, tokens de design, rotas e camadas interativas em todo o site.
Usamos Kimi Code CLI, com tecnologia Kimi K2.5, como um agent de codificação com IA para ajudar a executar a reconstrução. O projeto se tornou um teste prático de como um agent baseado em terminal se encaixa em um fluxo de trabalho real de produção — não em um ambiente de demonstração. Este artigo mostra como o utilizamos e o que aprendemos ao longo do caminho.
O real propósito desta atualização visual
A atualização visual da moonshot.ai não consistiu em redesenhar a marca do zero. A maior parte do trabalho de design já existia no Figma. O verdadeiro desafio era aplicar essas mudanças de forma consistente em uma base de código existente.
Isso significava rastrear tokens compartilhados, atualizar componentes, verificar comportamentos interativos e garantir que analytics e acessibilidade não fossem afetados. Muitas mudanças eram pequenas isoladamente, mas atravessavam várias camadas do site.
Esse tipo de trabalho não é difícil por causa de complexidade algorítmica. É difícil pela amplitude e pela necessidade de consistência. O desafio é entender tudo o que uma mudança afeta e garantir que nada fique para trás. Para apoiar esse processo, usamos uma conexão Model Context Protocol (MCP) com o Figma para alinhar melhor as especificações de design à implementação, ajudando o agent a compreender a estrutura e reduzindo a interpretação manual.
Regras básicas: como tornar o agent útil
O primeiro passo não foi escrever prompts — foi definir o contexto. Usamos o comando /init para gerar um arquivo AGENTS.md e então dedicamos cerca de uma hora a refiná-lo. Nele, documentamos o que fazia parte do escopo da atualização visual, o que não podia mudar, como o projeto estava estruturado e como o processo de build funcionava. Também adicionamos um arquivo de regras cobrindo convenções de nomenclatura, espaçamento e requisitos de contraste.
Essa configuração reduziu a necessidade de explicações repetidas depois e tornou o fluxo de trabalho com Kimi Code CLI mais consistente. Sem contexto específico do projeto, o agent de codificação com IA tende a produzir resultados razoáveis, mas genéricos. Com ele, o comportamento fica mais próximo ao de um colega de equipe que já entende a base de código.
Como o usamos na prática
Esta seção detalha como Kimi Code CLI foi usado na prática durante a atualização visual — no rastreamento de dependências, no alinhamento com o design, na investigação de comportamentos, nas verificações de desempenho e na revisão de riscos de integração. O foco não estava na automação, mas em reduzir a incerteza em uma refatoração de grande escala.
Entender o que a mudança afeta
Antes de editar qualquer coisa, pedimos ao agent no Kimi Code CLI que lesse a área-alvo e listasse tudo o que dependia dela. Uma única mudança — como a cor de um botão — pode afetar seções hero, seções de download, estados de hover e tokens compartilhados, enquanto componentes compartilhados, timing de movimento e hooks de analytics podem ampliar ainda mais o impacto. Obter primeiro uma lista de dependências reduziu surpresas depois e tornou as edições mais previsíveis.
Ajustar o código à especificação de design
Em seguida, comparamos os componentes com a especificação de design, seção por seção: hero, navegação, seções de produto, CTA de download e rodapé. O agent gerou listas de mudanças no nível de propriedades ao comparar estilos com tokens de design e valores de layout. Esse processo pareceu mais próximo de uma automação estruturada de design system do que de uma checagem visual manual. A maioria das diferenças era pequena, como espaçamento, raio de borda ou peso da fonte, mas às vezes surgiam inconsistências maiores em componentes que deveriam compartilhar variantes e que, com o tempo, haviam se distanciado. O resultado foi uma lista concreta de edições, não um processo visual de tentativa e erro.
Investigar novos comportamentos
A atualização visual introduziu novos comportamentos de UI que ainda não existiam na base de código: cursor personalizado, hero orientado em tempo de execução, cards ilustrados que animam no hover e entradas acionadas por rolagem.
Para cada recurso, usamos Kimi Code CLI como um ambiente contextual, carregando a documentação e o estado do repositório juntos. Foi aí que Kimi K2.5 fez diferença: um contexto mais longo facilitou raciocinar sobre implementação e referências em um só lugar.
As perguntas eram práticas:
As animações de hover devem terminar ou ser canceladas ao sair?
O estado do cursor deve interagir com o canvas do hero?
O que quebra quando várias camadas se sobrepõem?
A grande janela de contexto permitiu um fluxo de trabalho Kimi Code mais contínuo, em que a intenção de design e o código convivem na mesma sessão.
Verificar peso e desempenho
A atualização visual introduziu uma nova família tipográfica, mais movimento e assets adicionais, o que aumentou o peso da página. Usamos o agent para adaptar o script existente de subsetting de fontes e verificar a saída; depois, ele ajudou a interpretar relatórios do Lighthouse para identificarmos regressões cedo. O objetivo não era otimizar tudo no fim, mas decidir o que manter ou cortar enquanto as mudanças ainda eram pequenas.
Mapear riscos de integração antes do merge
Várias camadas interativas — animação de entrada, cursor, canvas do hero — compartilham ordenação e comportamento de ponteiro, mesmo vivendo em componentes separados; por isso, uma mudança em uma camada ainda pode afetar outras. Também tivemos de considerar diferenças entre navegadores e sistemas operacionais, em que CSS e comportamento de renderização nem sempre coincidem. Antes de fazer merge de lotes de mudanças, inserimos diffs no Kimi Code CLI e pedimos que ele rastreasse quais interações poderiam ser afetadas; em seguida, verificamos esses caminhos no navegador e fizemos uma revisão leve em diferentes ambientes.
Integrações MCP e Skills
O Model Context Protocol (MCP) permitiu que Kimi Code CLI se conectasse diretamente a sistemas externos com dados do projeto. Usamos mcp Figma para puxar tokens de design, dados de layout e tipografia diretamente do Figma, reduzindo a tradução manual entre design e código; também conectamos ferramentas internas, expondo tarefas, especificações e casos de borda sem trocar de contexto.
Adicionar um servidor exige um único comando:
O padrão se aplica a todo o ecossistema MCP. Para se inspirar, você pode conectar agents a:
Figma — MCP oficial para contexto de design, variáveis e dados de layout do canvas
Atlassian Cloud — páginas do Confluence e itens de trabalho do Jira pelo ponto de entrada MCP remoto da Atlassian (documentado junto ao Rovo)
Bancos de dados, APIs de CMS — servidores MCP de fornecedores ou da comunidade; registros listam centenas de opções por categoria
Sua stack pode ser diferente — uma API privada de documentação, um serviço interno de tokens de design ou um data warehouse. A ideia é a mesma: conectar o agent aos sistemas que já contêm os dados relevantes. Para arquivos de configuração, definições de servidor e outras formas de configurar MCP no Kimi Code CLI, consulte o guia da plataforma.
Skill de revisão
Também escrevemos uma Skill para revisão de código. Trata-se de um arquivo de regras que orienta Kimi Code CLI sobre como avaliar uma merge request de ponta a ponta: ler o diff, rastrear arquivos e componentes afetados, verificar violações do design system (literais de cor brutos, espaçamento fora da grade, fallbacks de acessibilidade ausentes), avaliar o risco por área e gerar um relatório estruturado.
O relatório segue um formato fixo:
Um resumo de intenção e escopo
Achados agrupados por severidade (problemas críticos que bloqueiam o merge, melhorias recomendadas, pequenas sugestões de consistência)
Para cada achado: evidências do diff, avaliação de impacto e uma ação concreta
A Skill também sinaliza riscos potenciais que podem exigir uma validação rápida em navegador ou dispositivo — casos em que o agent tem incerteza, mas o custo de verificação é baixo.
Na prática, todo PR durante a atualização visual da moonshot.ai passou por essa etapa estruturada antes da conclusão da revisão. A saída sempre incluía recapitulação da intenção, achados classificados por severidade, evidências e correções.
Isso ajudou a reduzir retrabalho nas etapas finais e melhorou a consistência em todo o fluxo de Kimi Code, trazendo à tona questões como URLs hardcoded ao lado de constantes compartilhadas, campos de analytics que precisavam de alinhamento e casos de borda em interações mobile.
O que não esperávamos
Durante a refatoração, surgiram alguns padrões que não eram óbvios no início.
A passagem da especificação para o código foi mais rápida do que esperávamos
Com Figma MCP e Kimi Code CLI na mesma conversa, dimensões e tokens de design chegavam como entrada estruturada, em vez de serem transcritos manualmente. O resultado foram ciclos de iteração mais curtos por seção — mudanças e correções no nível de propriedades muitas vezes entravam em uma única passada, sem idas e vindas entre ferramentas.
Os prompts de pesquisa renderam mais do que esperávamos
A atualização visual dependeu bastante de passadas longas, guiadas por documentação, pela documentação de runtime e por implementações de referência junto ao repositório. Manter esses materiais na mesma sessão que o código muitas vezes se mostrou tão valioso quanto as próprias edições.
A Skill de revisão transformou pequenas inconsistências em uma lista
O relatório estruturado revelou as mesmas classes de problemas descritas antes — URLs hardcoded ao lado de constantes compartilhadas, campos de analytics que precisavam de alinhamento e casos de borda em interações mobile. A maioria era pequena isoladamente, mas ficou mais fácil de resolver depois de agrupada em uma única passada.
Retomar threads longas continuou barato
Comandos como kimi --continue e /compact fizeram com que trabalhos de vários dias não exigissem reconstruir o contexto todas as manhãs. Isso reduziu a necessidade de novos prompts e manteve o mesmo fluxo de Kimi Code avançando de forma consistente.
Para saber mais sobre como retomar sessões, alternar entre elas e gerenciar contexto com /compact e comandos relacionados, consulte o guia de sessões do Kimi Code CLI.
Lições aprendidas ao reconstruir moonshot.ai
Se fôssemos realizar uma atualização visual semelhante da moonshot.ai novamente, há algumas coisas que abordaríamos de outro modo.
Comece pelo contexto, não pelo código
Dedicar a primeira hora a documentar escopo, restrições e convenções economizou mais tempo do que qualquer prompt posterior. Estabelecer isso de início fez ferramentas como Kimi Code CLI se comportarem de forma mais consistente ao longo do fluxo de trabalho.
Conecte uma fonte da verdade desde cedo
No nosso caso, foi o Figma. Em outros projetos, poderia ser um CMS, uma API interna ou um design system. O essencial é garantir que o sistema trabalhe com dados reais, não com suposições inferidas, especialmente ao usar um agent de codificação com IA em um contexto de refatoração frontend.
Mantenha design e tarefas no mesmo ciclo de contexto
Trazer tokens, especificações e implementação para um contexto compartilhado reduziu idas e vindas e tornou os ciclos de iteração mais estáveis. Foi aqui que fluxos envolvendo Figma MCP e Kimi Code CLI se mostraram especialmente eficazes, pois ajudaram a manter a intenção de design e as mudanças de código alinhadas em um ciclo contínuo.
Se você não quer escrever código: Kimi Websites
Tudo acima descreve um fluxo de trabalho centrado em desenvolvedores — terminais, diffs e arquivos de contexto. No entanto, o mesmo resultado — um site polido e responsivo — também pode ser alcançado sem essa stack quando a velocidade importa mais do que o controle no nível do framework.
Kimi Websites roda no mesmo modelo Kimi K2.5, mas por meio de uma interface visual e no-code. Você descreve o que deseja em linguagem natural, refina seções por conversa e publica com um clique. Ele também pode receber uma captura de tela existente como entrada e reconstruir a estrutura do layout.
Para founders prototipando landing pages ou profissionais de marketing entregando sites de campanha com prazos apertados, isso oferece um caminho mais rápido do que trabalhar diretamente com uma stack frontend tradicional.
Conclusão
Kimi Code CLI e Kimi K2.5 foram mais úteis nas partes do projeto em que a amplitude importava mais do que a complexidade. Uma atualização visual raramente envolve problemas difíceis — envolve muitas pequenas mudanças que precisam permanecer consistentes em todo um sistema. Isso a torna demorada para humanos, mas relativamente adequada para um agent capaz de rastrear e comparar arquivos.
Ainda assim, fomos nós que tomamos as decisões, revisamos cada mudança e validamos o resultado final. O agent cuidou do rastreamento repetitivo, das comparações e da revisão inicial. Na prática, essa divisão de trabalho se mostrou uma forma viável de integrar um agent de codificação com IA a um fluxo de produção. Para refatorações entre arquivos, verificação de design para código e trabalhos de consistência em larga escala, essa abordagem se mostrou útil.