During the design of our Rovo Desktop app, a familiar problem showed up: the cursor glow animation was implemented at about 80% of the design intent. The basics were there, but the details weren’t. The blur and spread felt off, the colors from the spec in didn’t shine in the shipped product, and small visual bugs only appeared in real code.
These might feel like small issues, but the last 20% of polish of every feature is often where 80% of the time gets burned – in Slack threads and handoff loops. So instead of hashing out details on more Figma files and throwing more prototypes over the wall, the workflow shifted straight to vibe-coding using the real codebase. The missing details and refinements were vibe-coded straight into the app and then shipped as a pull request (PR) for the engineering team to review and merge, increasing engineering productivity and craftsmanship on the product.
Why designers should ship code
Designers don’t need to become full-time engineers to close the efficiency gap on the team. Just by vibe-coding small UI changes you can already feel how we they affect change.
- Bump Craftsmanship: turn an 80% implementation into 100% by tuning motion, styles and layouts, directly in code.
- Eliminate handoff: trying to hit your desired level of polish can leave you stuck in back-and-forth reviews and rework. Shipping code collapses that loop and frees engineering time.
- Test designs in production code: avoid slow design–handoff–rework cycles; iterate where it matters – the running app.
- Clear intent: ship a PR that encodes the exact feel you want, not just specs or prototypes.
Pause before opening a PR for every change. Some updates carry higher risk and are better handled in close partnership with engineering. Avoid vibe-coding when:
- If the change requires altering business logic, like a brand new feature/flow
- If performance is already fragile
- If the component is part of a shared platform library
- If the change touches any security or compliance component
The workflow (at a glance)
This workflow is designed to make the jump into shipping code feel approachable for designers. It leans on AI and keeping changes small, reviewable, and contained in the running app.
1. Get the code:
Clone the repo from your VCS (e.g., Bitbucket). Open it in your AI IDE (e.g., Cursor).
2. Ask the AI to run the app:
Let it infer or determine the necessary build steps and dependencies so you can preview changes live. AI agents are especially effective at interpreting repository README files, translating setup instructions into executable steps, managing dependencies, and configuring development environments.
3. Vibe code:
Feed the assistant a clear prompt (from your prototype/spec) describing the effect or visuals you want, with parameters like delays, margins, blur or any behavior (using tools like Figma MCP can speed up your process).
Polish interactions: adjust easing, timing (e.g., make glow fade gracefully on mouse leave). Remove visual artifacts (e.g., unintended flashing animations).
4. Production clean-up:
Remove logs, unused references, and dead code; check performance; keep diffs small and readable.
5. Create a branch and commit:
Name it clearly (e.g., designer-glow-gradient-polish). Push to remote and open a PR.
6. Request review
Ask engineering to validate production readiness, performance, and code quality before merge.
Best Practices
- Keep diffs small: limit edits to the files that matter; prefer variable-level changes over rewrites.
- Design in runtime: validate changes across themes and states; watch for artifacts or bugs introduced by your changes.
- Name things clearly: use tokens or human readable names for things (e.g., glow.radius, glow.blur) so engineers can reason about your intent.
- Always create Pull Requests, never direct-merge: engineering reviews ensure performance and maintainability.
Key prompts you can reuse
Use these prompts to get started. Begin with the ones that get the app running and as you get more comfortable, try out the ones that let you explore, fine-tune, and clean up your implementation into a mergeable PR.
“Run the app and describe how to start the dev server locally. Then start it.”
“Locate where the cursor glow effect is implemented. Propose a minimal diff to match this spec: [paste spec values]. Explain each change briefly.”
“Add a temporary control panel to tune variables in runtime: glow size, blur, spread, opacity, grid visibility, grid spacing, line width, fade-out duration. Hot-reload changes.”
“Apply these final values: [paste values]. Remove the control panel and any debug code.”
“Make sure all changes are production quality, human readable, variables are not hard coded values when possible – use tokens , clean any unnecessary code and review refactoring opportunities to create simpler changes.”
“Create a new branch named designer-glow-gradient-polish, commit changes with clear messages, push, and open a pull request.”
What to look out for
Even with a super-tight workflow, it’s easy to introduce new problems or miss edge cases that only show up in real use. As you vibe-code, keep one eye on how your changes alter behavior across themes, states, and interactions, and the other on performance and accessibility so you aren’t trading out a design that “looks right” for one that “feels broken” somewhere else.
- Theme parity: check light/dark modes.
- Accessibility problems, keyboard navigation.
- Interaction edge cases, like empty states or long strings, different zoom levels
- Performance: Ask the AI agent to always propose solutions that optimize performance and work with the constrains of the platform you’re working with
Done means
You’re done when you have a clear end state that’s polished across all themes and states.
- Effect matches the prototype/spec visually across themes and states.
- Behavior is correct and no performance regression is observed.
- Code is cleaned, minimal, and explained via commit/PR notes.
- Engineers can safely review and merge without guessing design intent – recording a Loom or video showing the changes is a great way.
There’s more to explore from our design team — ideas, craft, and the people shaping our products.
