Shipping a Refactor of Moonshot AI with Kimi Code CLI
A real-world look at how an AI coding agent helped deliver a visual refresh across a production site, from tracing dependencies and matching design specs to reviewing diffs and catching integration risks.Get Kimi CodeIn March 2026, we refreshed the moonshot.ai experience across the platform. The update appeared simple: a new color palette, tighter typography, and updated motion. In practice, it touched shared components, design tokens, routes, and interactive layers across the entire site.
We used Kimi Code CLI, powered by Kimi K2.5, as an AI coding agent to help carry out the rebuild. This project became a practical test of how a terminal-based agent fits into a real production workflow—not a demo environment. This article walks through how we used it and what we learned along the way.
Table of contents
- What this refresh was really about
- Ground rules: making the agent useful
- How we actually used it
- MCP integrations and Skills
- Review Skill
- Things we did not expect
- Lessons learned from rebuilding moonshot.ai
- Conclusion
What this refresh was really about
The moonshot.ai refresh was not about redesigning the brand from scratch. Most of the design work already existed in Figma. The real challenge was applying those updates consistently across an existing codebase.
That meant tracing shared tokens, updating components, checking interactive behavior, and ensuring analytics and accessibility were not affected. Many changes were small individually, but they spanned multiple layers of the site.
This kind of work is not difficult because of algorithmic complexity. It is difficult because of breadth and consistency. The challenge is knowing what a change touches and making sure nothing is missed. To support this, we used a Model Context Protocol (MCP) connection with Figma to better align design specifications with implementation, helping the agent understand the structure and reducing manual interpretation.
Ground rules: making the agent useful
The first step was not writing prompts—it was setting context. We used the /init command to generate an AGENTS.md file, then spent about an hour refining it. In it, we documented what was in scope for the refresh, what could not change, how the project was structured, and how the build process worked. We also added a rules file covering naming conventions, spacing, and contrast requirements.
This setup reduced the need for repeated explanations later and made the Kimi Code CLI workflow more consistent. Without project-specific context, the AI coding agent tends to produce reasonable but generic outputs. With it, the behavior becomes closer to a teammate who already understands the codebase.## Tracing dependencies
How we actually used it
This section breaks down how Kimi Code CLI was used during the refresh in practice—across dependency tracing, design alignment, behavior research, performance checks, and integration risk review. The focus was not on automation, but on reducing uncertainty in a large-scale refactor.
Understand what the change touches
Before editing anything, we asked the agent in Kimi Code CLI to read the target area and list what else depended on it. A single change—like a button color—can affect hero sections, download sections, hover states, and shared tokens, while shared components, motion timing, and analytics hooks can further expand the impact. Getting a dependency list first reduced surprises later and made edits more predictable.
Match code to design spec
We then compared components against the design spec section by section: hero, navigation, product sections, download CTA, and footer. The agent produced property-level change lists by comparing styles against design tokens and layout values. This process felt closer to structured design system automation than manual visual checking. Most differences were small, such as spacing, border radius, or font weight, but occasionally, larger inconsistencies surfaced where components that should have shared variants had drifted apart over time. The result was a concrete list of edits rather than a visual guessing process.
Research new behavior
The refresh introduced new UI behaviors not previously implemented in the codebase: a custom cursor, runtime-driven hero, hover-playing illustration cards, and scroll-triggered entrances.
For each feature, we used Kimi Code CLI as a contextual environment by loading the docs and repository state together. This is where Kimi K2.5 mattered: longer context made it easier to reason across implementation and references in one place.
Questions were practical:
- Should hover animations complete or cancel on exit?
- Should the cursor state interact with the hero canvas?
- What breaks when multiple layers overlap?
The large context window enabled a more continuous kimi code workflow, where design intent and code live in the same session.
Check weight and performance
The refresh introduced a new typeface, more motion, and additional assets, which increased page weight. We used the agent to adapt the existing font subsetting script and verify the output, and later it helped interpret Lighthouse reports so we could identify regressions early. The goal was not to optimize everything at the end, but to make keep-or-cut decisions while changes were still small.
Trace integration risk before merging
Multiple interactive layers—entrance animation, cursor, hero canvas—share ordering and pointer behavior even though they live in separate components, so a change in one layer can still affect others. We also had to account for cross-browser and cross-OS differences, where CSS and rendering behavior may not always match. Before merging batches of changes, we fed diffs into Kimi Code CLI and asked it to trace which interactions might be affected, then checked those paths in the browser and did a light pass across environments.
MCP integrations and Skills
Model Context Protocol (MCP) allowed Kimi Code CLI to connect directly to external systems containing project data. We used mcp Figma to pull design tokens, layout data, and typography directly from Figma, reducing manual translation between design and code, and also connected internal tools, exposing tasks, specs, and edge cases without switching context.
Adding a server is a single command:
The pattern generalizes across the MCP ecosystem. For inspiration, you can connect agents to:
- Figma — official MCP for design context, variables, and layout data from the canvas
- Atlassian Cloud — Confluence pages and Jira work items through Atlassian's remote MCP entry point (documented alongside Rovo)
- Databases, CMS APIs — vendor or community MCP servers; registries list hundreds of options by category
Your stack may look different—a private docs API, an internal design-token service, or a data warehouse. The idea is the same: connect the agent to systems that already hold the relevant data. For config files, server definitions, and other ways to wire up MCP in Kimi Code CLI, see the platform guide.
Review Skill
We also wrote a Skill for code review. It is a rules file that tells Kimi Code CLI how to evaluate a merge request end-to-end: read the diff, trace affected files and components, check for design system violations (raw color literals, spacing off the grid, missing accessibility fallbacks), assess risk by area, and generate a structured report.
The report follows a fixed format:
- A summary of intent and scope
- Findings grouped by severity (critical issues that block merge, recommended improvements, minor consistency suggestions)
- For each finding: evidence from the diff, impact assessment, and a concrete action item
The Skill also flags potential risks that may require a quick browser or device validation—cases where the agent is uncertain but the verification cost is low.
In practice, every PR during the moonshot.ai visual refresh went through this structured pass before review completion. The output always included intent recap, severity-ranked findings, evidence, and fixes.
This helped reduce late-stage churn and improved consistency across the Kimi Code workflow, surfacing issues such as hardcoded URLs next to shared constants, analytics fields that needed alignment, and mobile interaction edge cases.
Things we did not expect
During the refactor, a few patterns emerged that were not obvious at the start.
- Spec-to-code got faster than we expected
With Figma MCP and Kimi Code CLI in the same thread, dimensions and design tokens arrived as structured input rather than being manually transcribed. The result was shorter iteration loops per section—property-level changes and fixes often landed in a single pass instead of bouncing between tools.
- Research prompts paid off more than we expected
The refresh relied heavily on long, doc-driven passes through runtime documentation and reference implementations alongside the repository. Keeping these materials in the same session as the code often proved as valuable as the edits themselves.
- The review Skill turned small inconsistencies into a list
The structured report surfaced the same classes of issues described earlier—hardcoded URLs next to shared constants, analytics fields that needed alignment, and mobile interaction edge cases. Most were minor individually, but easier to address once grouped into a single pass.
- Long threads stayed cheap to resume
Commands like kimi --continue and /compact meant multi-day work did not require rebuilding context each morning. This reduced re-prompting and kept the same Kimi Code workflow moving consistently. For more on resuming sessions, switching between them, and managing context with /compact and related commands, see the Kimi Code CLI sessions guide.
Lessons learned from rebuilding moonshot.ai
If we were to run a similar moonshot.ai visual refresh again, there are a few things we would approach differently.
- Start with context, not code
Spending the first hour documenting scope, constraints, and conventions saved more time than any later prompting. Establishing this upfront made tools like Kimi Code CLI behave more consistently across the workflow.
- Connect a source of truth early
In our case, that was Figma. In other projects, it could be a CMS, internal API, or design system. The key is ensuring the system works with real data rather than inferred assumptions, especially when using an AI coding agent in a frontend refactor context.
- Keep design and task context in the same loop
Bringing tokens, specifications, and implementation into a shared context reduced back-and-forth and made iteration cycles more stable. This is where workflows involving Figma MCP and Kimi Code CLI proved particularly effective, as they helped keep design intent and code changes aligned in one continuous loop.
If you don't want to write code: Kimi Websites
Everything above describes a developer-centric workflow—terminals, diffs, and context files. However, the same outcome—a polished, responsive website—can also be achieved without that stack when speed matters more than framework-level control.
Kimi Websites runs on the same Kimi K2.5 model, but through a visual, no-code interface. You describe what you want in a natural language, refine sections through conversation, and publish with one click. It can also take an existing screenshot as input and reconstruct the layout structure.
For founders prototyping landing pages or marketers shipping campaign sites under tight timelines, this offers a faster path than working directly with a traditional frontend stack.
Conclusion
Kimi Code CLI and Kimi K2.5 were most useful in parts of the project where breadth mattered more than complexity. A visual refresh is rarely about hard problems—it is about many small changes that must remain consistent across a system. That makes it time-consuming for humans, but relatively well-suited for an agent that can trace and compare across files.
We still made the decisions, reviewed every change, and validated the final result. The agent handled repetitive tracing, comparison, and initial review work. In practice, this division of labor turned out to be a practical way to integrate an AI coding agent into a production workflow. For cross-file refactors, design-to-code verification, and large-scale consistency work, this approach proved useful.