# Code Review **Is Not** Visual Review Published: 2026-05-04T09:00:00.000-04:00 Tags: llm, agents, claude-code, gemini, design-review, open-source Canonical: https://voodootikigod.com/gemini-plugin-cc > AI coding agents are very good at producing working code quickly. The harder problem is whether that code has the right visual shape. I built gemini-plugin-cc to bring Gemini into the workflow as a design-review companion for Claude Code and agent skills. --- [Claude Code](https://docs.anthropic.com/en/docs/claude-code/overview?ref=voodootikigod.com) has been shipping a lot of working UI for me. [Codex](https://github.com/openai/codex?ref=voodootikigod.com) has been catching the implementation mistakes. And I was still ending up with interfaces that were technically correct and visually off. Not broken. Worse than broken. Plausible. That is the uncomfortable category for generated UI. The code compiles. The page renders. The buttons work. The layout is responsive enough to pass a quick glance. But something about it is wrong, and the thing that is wrong is not always visible in the code review. The more I have used AI agents for real implementation work, the more obvious one pattern became. The agent that writes the code should not be the only agent that reviews the code. That sounds obvious when we talk about humans. Nobody argues that the developer who wrote the feature should be the only reviewer before it ships. We know review works because another person brings different assumptions, different attention, and different failure detection. When Codex announced the [Codex Plugin for Claude Code](https://github.com/openai/codex-plugin-cc) that brought Codex into my Claude Code session as an adversarial reviewer, I was happy because the same is true for AI agents, you get better results from different entities reviewing the same thing. Claude Code is very good at driving implementation. Codex has been very good at adversarial review of that implementation. It catches weak assumptions, missing tests, edge cases, and places where generated code is plausible, but wrong. That split has produced real benefits for me: better accuracy, fewer bugs, and a much higher level of confidence in generated work. But there was still a gap and one that I, as a self admitted non-designer, kept running into and was not able to self solve for. The visual layer needed its own reviewer. ## Code review is not visual review Most coding agents can produce a working interface. They can build and wire up components, add Tailwind classes, make the layout responsive, and get something on the screen that works, but a working UI is not the same thing as good UI. The failures are often subtle: - The spacing is almost consistent, which somehow makes it worse. - The colors are valid CSS and still completely wrong for the brand. - The hierarchy exists, but it does not tell the eye where to go. - The buttons all work, but they look like they came from three different products. - The page passes the "it renders" test, which is the lowest possible bar. These are not always code architecture problems. They are design judgment problems. And I have found the [Gemini](https://ai.google.dev/gemini-api/docs/models?ref=voodootikigod.com) model family to be particularly strong here. It has been useful not just for catching visual defects, but for improving the cleanliness, creativity, and coherence of the design itself. The pattern showed up enough times that I stopped treating it as taste. A generated dashboard would be responsive, accessible-ish, and wired correctly, but the density was wrong. Or the CTA hierarchy fought itself. Or the mobile view technically fit while feeling like a squeezed desktop layout. Claude or Codex would tell me the component abstraction was fine. Gemini could tell me the screen was not. Taking a page from the Codex in Claude Code book, I built a plugin to make that part of the workflow. ## Meet gemini-plugin-cc `gemini-plugin-cc` is a visual design companion for AI coding agents. It uses [Gemini CLI](https://geminicli.com/?ref=voodootikigod.com) to generate and review a project's visual design system via an open [Stitch](https://stitch.withgoogle.com/?ref=voodootikigod.com) `DESIGN.md` file, if available, screenshots, and UI source. The goal is not to replace code review. The goal is to give visual review its own lane. The plugin can: - Generate a Stitch-format `DESIGN.md` from the current UI. - Review rendered screens against brand fidelity, color tokens, typography, spacing, accessibility, and component variants. - Propose alternative visual directions with token-level differences, not just vague "make it better" advice. - Run a three-pass visual second opinion: advocate, critic, and synthesis. That last one has been especially interesting. Instead of asking for a single verdict, Gemini makes the strongest honest case to ship, then the strongest honest case to redesign, then synthesizes the actual cruxes. That is the kind of review loop I want before I let generated UI harden into product surface area. ## The pattern: Claude builds, Codex reviews, Gemini designs The important part is not the plugin itself. The important part is the operating model. I do not want one model doing everything. One giant assistant with a bigger prompt and more permissions is not the end state I want. That just recreates the solo developer problem with a more expensive autocomplete. I want a small working team with clear responsibilities: - Claude Code drives implementation. - Codex reviews the work product. - Gemini reviews and corrects the visual design. That separation matters because each model brings different strengths. It also reduces the risk of the original author grading its own homework. This is the same reason human teams separate implementation, review, QA, design, and product judgment. The boundaries are not bureaucracy. They are how you keep one person's blind spots from becoming the product's blind spots. AI coding workflows need the same thing. ## DESIGN.md as the contract The plugin uses the open [Stitch](https://stitch.withgoogle.com/?ref=voodootikigod.com) `DESIGN.md` format as a contract for visual identity. The frontmatter captures machine-readable tokens: colors, typography, spacing, radii, and component rules. The body explains the human rationale. That part matters because this is not just my private convention. Google describes `DESIGN.md` as an agent-friendly markdown file for moving design rules between Stitch and other design or coding tools in its [Stitch product update](https://blog.google/innovation-and-ai/models-and-research/google-labs/stitch-ai-ui-design/?ref=voodootikigod.com). That is exactly the kind of bridge agent workflows need: a readable design contract that a model can inspect before it starts making visual decisions. That gives the reviewer something concrete to evaluate against. Without a design contract, visual review becomes vibes. Sometimes useful vibes, but still vibes. With a `DESIGN.md`, Gemini (and eventually other LLMs, I would assume) can ask better questions: * Does this UI uphold the brand? * Are these colors coming from the token system? * Do these component variants match the design rules? * Are we drifting across screens? * Do the contrast ratios meet [WCAG AA](https://www.w3.org/TR/WCAG22/#contrast-minimum)? That is a much better review surface than "make it look better." ## Why I built it I built this because I kept seeing the benefit in my own work. Claude Code could produce the feature. Codex could make the implementation better. Gemini could make the interface better. Each role improved the output in a different way. This is where I think agent workflows are going. Not one giant undifferentiated assistant, but multiple agents and models with explicit responsibilities, narrow contracts, and the ability to challenge each other. The human stays in the loop. The human decides what ships. But the work product going into that decision is better. Right Tool, Right Task. `gemini-plugin-cc` is available here: [https://github.com/voodootikigod/gemini-plugin-cc](https://github.com/voodootikigod/gemini-plugin-cc)