Filed under Design · Intelligence Apache-2.0 · Made on Earth
Agent · Kilo

Kilo Code for design.

Kilo Code is an open-source, model-agnostic AI coding agent for your IDE and CLI. Because you can point it at almost any model and bring your own provider keys, it becomes a real design tool once you give it references, conventions, and a verification loop. Open Design wires it into an open-source design workflow: your provider keys, your files, local-first.

Kilo Code design feedback loop: an agent in the IDE and terminal reading a reference image, a browser rendering the UI, and a workspace, with a feedback arrow looping back

Open Design turns Kilo Code into a local-first, open-source design agent — your provider keys, your files, a curated skill and design-system library around it.

Kilo Code is an open-source AI coding agent that runs in VS Code, JetBrains IDEs, and the terminal. Two things make it interesting for design specifically: it is model-agnostic, so you can drive it with whichever frontier vision-capable model best reads a screenshot; and it is BYOK across many providers, so you keep control of cost and credentials. Paired with the right references, conventions, and a verification loop, it builds real, responsive UI. This is a practical, end-to-end guide to using Kilo Code for UI, frontend, and design-system work, and to wiring it into a structured design workflow with Open Design.

It covers what Kilo Code actually is, why a model-agnostic, open agent fits design, how to set it up from zero, the screenshot-to-UI loop, how custom rules and MCP extend it, how it compares to Codex, Claude Code, Cursor, and Gemini CLI, the pitfalls that make AI output look generic, and how Open Design closes the gap as an open, local-first design layer — a natural pairing, since both are open-source and run on your own machine.

What Kilo Code actually is

Kilo Code is an open-source AI coding agent built by Kilo Code, Inc. It runs as a VS Code extension, in JetBrains IDEs, and as a command-line interface — reading your repository, editing files, running commands, and planning and verifying work from natural-language tasks rather than just completing lines. Its defining trait is that it is model-agnostic: you choose which model drives it, and you bring your own provider keys.

For design work, two properties stand out. Because it is model-agnostic, you can point it at whichever strong vision-capable model best reads a reference screenshot and reasons about layout. And because it is open-source and BYOK, you can inspect exactly what context is sent and keep credentials and cost under your own control.

  • Agent modes: Kilo ships specialized modes — Architect for planning, Code for building, Debug for fixing, and Ask for questions — plus custom modes, so you can plan a design and then implement it in separate, focused passes.
  • Custom rules + MCP: It reads project-level custom rules for persistent context and supports MCP servers (with an MCP marketplace), so you can add external context like a live Figma file or design tooling.
  • Bring your own keys: Kilo is BYOK across many providers — Anthropic, OpenAI, Google, OpenRouter, and more — or you can use Kilo's own gateway, which exposes 500+ models at provider cost.
  • Vendor: Kilo Code, Inc. (open source)
  • Credential: your own provider API key (BYOK — Anthropic, OpenAI, Google, OpenRouter, and more) or Kilo's own gateway
  • License: open source

Why an open, model-agnostic agent fits design

Kilo Code’s design edge comes from openness and model choice — but, as with every agent, taste still has to be supplied.

  • Model-agnostic by design: Because you choose the model, you can drive Kilo with whichever vision-capable model reads reference screenshots best — and switch when a better one appears, without changing your workflow.
  • Open and inspectable: Kilo is open-source, so you can see exactly what context and prompts are sent — useful when you want the agent to reuse your real design primitives rather than invent one-off styles.
  • Conventions in custom rules: Project custom rules (plus an MCP server for Figma) point the agent at your tokens, components, and real specs, so it works against a brand instead of a default look.
Diagram showing design system, skill, and reference image converging into good design output
Taste comes from three inputs you provide: a design system, a skill, and real reference images.

The lesson is the same one every agent teaches: Kilo Code does not have taste by default. It produces good design when you give it constraints — a design system, an aesthetic skill, and concrete references. Open Design packages exactly those inputs, which is why the two fit together (more below).

Set up Kilo Code for design work, from zero

Here is the full path from a clean machine to a Kilo Code that can build and verify UI.

# 1. Install the Kilo Code extension from the VS Code
#    (or JetBrains) marketplace, or install the CLI.

# 2. Open your project and sign in / add a provider key
cd your-project
kilo              # connect your provider (BYOK) or Kilo's gateway

# 3. Add project context
#    create custom rules for this project's design conventions

# 4. Wire the Figma MCP server (optional, for design handoff)
#    add it from the MCP marketplace / MCP settings
Five-step setup flow: install, authenticate, add custom rules, add a skill, verify
The setup sequence: install → connect a provider → add custom rules → add a skill → enable browser verification.
  • Encode your design rules: Put your tokens, primitives, and conventions in Kilo's custom rules and point the agent at them, so output matches a brand instead of defaulting to a generic look.
  • Add browser verification: Wire a Playwright or browser MCP so Kilo renders in a real browser and checks its output across breakpoints instead of only confirming the build passes.

The screenshot-to-UI workflow

The highest-leverage design loop with Kilo Code is turning a reference image into working, responsive UI and iterating until it matches — leaning on a vision-capable model to compare output back to the reference.

  1. Start from the clearest visual references you have — and include multiple states (desktop and mobile, hover, empty, loading), not just one hero shot.
  2. Be specific in the prompt; vague prompts produce generic UI even with a strong model.
  3. Keep your design system and conventions in Kilo's custom rules, and tell the agent where the tokens and canonical primitives live.
  4. Run a dev server and have Kilo render in a real browser, resizing to breakpoints to check the result.
  5. Iterate by having Kilo compare its implementation back to the screenshots — not merely confirm it builds.

Use Architect mode to plan the build, then switch to Code mode and attach your references with concrete constraints:

# Plan in Architect mode, then build in Code mode:
> Implement this design from @reference-desktop.png and
  @reference-mobile.png in React + Vite + Tailwind + TypeScript.
  Reuse my existing design-system components and tokens
  from the custom rules.
  Match spacing, layout, and hierarchy; make it responsive.
  Render it in the browser and iterate until it matches the
  references across breakpoints.

Keep prompts small and focused, commit good iterations and revert bad ones (telling Kilo when you revert), so each pass builds on a clean base.

Modes, custom rules, and MCP

Three extension points make Kilo Code practical for sustained design work, and all three map cleanly onto an open design workflow.

  • Modes (Architect → Code): Plan the structure of a screen in Architect mode, then implement it in Code mode and fix issues in Debug mode — separating design intent from implementation. Custom modes let you encode a design-review pass of your own.
  • Custom rules: Project custom rules are the durable home for your design conventions — tokens, primitives, and review checklists — read on every run so the agent works against your brand.
  • MCP servers: Kilo supports MCP servers via its marketplace — the portable way to bring in design context and external tools, most relevantly a Figma MCP server, that work across agents, not just Kilo.

These are portable, multi-agent capabilities — exactly the kind of thing Open Design is built to orchestrate, rather than re-create per project.

Kilo Code vs Codex vs Claude Code vs Cursor vs Gemini CLI for design

There is no single winner for design work — each agent has a different strength, and experienced teams stack them. A fair summary:

AgentDesign strengthBest for
Kilo CodeOpen-source and model-agnostic with BYOK across many providers; Architect/Code modes and MCPChoosing your own model per task and keeping cost and credentials under your control
CodexStrong visual polish with a frontend skill; sandboxed async buildsDelegated async builds and portable AGENTS.md rules
Claude CodeSpecific design decisions (hex, spacing, type) and codebase-aware UXFrontend reasoning and large-context refactors
CursorVisual build-and-see loop with live preview and inline editsTight iterate-and-watch UI work inside an IDE
Gemini CLIStrong multimodal image understanding and a 1M-token contextScreenshot-heavy work and holding a whole design system in context

The recurring community verdict is that taste comes from humans: all of them default to a generic aesthetic without skills, references, and constraints. That is the real problem to solve — and it is design-tool-shaped, not model-shaped.

Pitfalls, and how to avoid the “AI slop” look

The most common complaint about AI-generated design is that it looks generic — soft gradients, floating panels, oversized rounded corners, dramatic shadows, an Inter-and-purple vibe that “screams an AI made this.” Other reported issues include broken mobile layouts and instructions leaking into UI copy. None of these are unique to Kilo Code; they are what happens when any agent runs without a curated design context.

  • Add an aesthetic skill: A curated design skill forces the agent to commit to a real direction instead of the default look.
  • Verify in a real browser: Use a vision-capable model to render and self-check across breakpoints so layouts do not silently break on mobile.
  • Supply tokens and references: Real design tokens and reference screenshots are the single biggest lever on output quality.
  • Encode rules in custom rules: Put “no hero cards, max two typefaces, brand-first hierarchy” style rules where the agent reads them every run.

Notice that every mitigation is about giving the agent a curated design context. Maintaining that context by hand, per project, is the toil Open Design removes.

Designing with Kilo Code inside Open Design

Open Design is the open-source design layer the workflow above keeps asking for. It treats Kilo Code as a first-party adapter and wraps it in a curated skill and design-system library, a structured render pipeline, and a local desktop UI — so the design context that makes Kilo good is there from the first run, not assembled by hand each time. Both are open-source and local-first, which makes the pairing a natural fit.

  1. Install Open Design and select Kilo Code as your agent.
  2. Authenticate with your own provider key (BYOK) or Kilo's gateway — credentials stay on your machine and are never proxied through us.
  3. Pick a design system and a skill, then generate decks, prototypes, and landing pages with consistent taste.
  4. Every artifact and DESIGN.md file lives in your own repo, not a hosted cloud.

Same Kilo Code agent, same keys — plus a real, portable, open-source design workflow around it. It is local-first and open-source, so nothing about your work or your credentials leaves your machine.

Frequently asked questions

  1. 01 Can Kilo Code really do design work?

    Yes — with an aesthetic skill, a design system, and real reference images in context, Kilo Code produces production-quality, responsive UI, and a vision-capable model verifies output against references. Without that context it tends to default to a generic look, which is the gap Open Design fills.

  2. 02 Do I need to pay to design with Kilo Code?

    Kilo Code is open-source and free to install. You bring your own provider API key (BYOK) and pay that provider directly, or use Kilo's own gateway at provider cost. Open Design never proxies your credentials either way.

  3. 03 What makes Kilo Code good for design specifically?

    It is model-agnostic and open-source, so you can drive it with whichever vision-capable model reads reference screenshots best, inspect exactly what context is sent, and keep cost and credentials under your control. Taste still comes from the design system, skill, and references you supply.

  4. 04 Kilo Code or Claude Code for frontend design?

    Both are strong. Claude Code is known for specific, codebase-aware design decisions; Kilo Code's edge is being open-source and model-agnostic with BYOK, so you choose the model. Many teams use both — Open Design lets you switch agents without changing your design workflow.

  5. 05 How do I connect Kilo Code to Figma?

    Add a Figma MCP server from Kilo's MCP marketplace or MCP settings. Kilo can then pull real design context — components, variables, layout data — so the generated code matches the source instead of approximating it.

  6. 06 Is Open Design affiliated with Kilo Code?

    No. Kilo Code is a product of Kilo Code, Inc.; Open Design is an independent open-source project that supports it as a first-party adapter. Both happen to be open-source, but they are separate projects.

  7. 07 Are my files and credentials safe?

    Yes — Open Design is local-first and open-source. Your files, artifacts, and DESIGN.md stay in your own repo, and your provider credentials are used directly by your agent, never routed through Open Design servers.

Design with Kilo Code, the open way.

Bring your own provider key, keep every file local, and get a curated design library around the agent you already use.

● Apache-2.0 Local-first · BYOK See all supported agents