One thing I didn’t expect after moving most of my prototyping into code was that it would make me appreciate design reviews even more.
For the last year, most of my work has lived inside Claude Code, Cursor, VS Code, and agents patiently sitting in the corner of my editor. The biggest change isn’t that I can build faster. It’s that I can finally hand developers something that actually runs instead of a collection of mockups they have to imagine.
It’s incredible.
It’s also surprisingly dangerous.
Because somewhere between agents and pull requests, I realized I had accidentally removed design reviews from my own process.
The traditional workflow was surprisingly good at forcing us to slow down. We researched. We designed. We reviewed. Developers implemented. QA reviewed it again. There were multiple opportunities for someone to ask, “Does this actually follow the decisions we made?”
Today my workflow looks very different. I build a feature. Change my mind halfway through. Redesign the flow. Prompt an agent to implement something else. Fix a component. Add another screen. Open a pull request. Then repeat the entire process again tomorrow.
What’s interesting is that I’ve become my own designer, developer, researcher, and product manager. What I forgot to become was my own design reviewer.
The Funny Thing About AI and Design
The funny thing is, AI doesn’t usually break design dramatically.
It breaks it one micro-decision at a time.
A hardcoded color because the token lived two folders away. A duplicated component because both implementations looked equally reasonable. An empty state that was never designed because the mock data happened to contain three perfect records. A different icon family introduced three sessions ago that nobody noticed because it looked good enough.
Every decision is reasonable in isolation.
The accumulation isn’t.
That’s what design drift looks like in the age of AI.
And surprisingly, it took only one week for me to experience it.
Why Documentation Isn’t Enough
Initially, I thought documentation would solve most of these problems.
I had markdown files documenting constraints. Design tokens were defined properly. Agent instructions were loaded into every session. Everything that should have prevented drift existed.
And drift happened anyway.
The more I observed these failures, the more I realized we might be expecting the wrong thing from AI agents. Instructions aren’t memory. They’re context. Somewhere between “reuse the existing component” and “finish building this screen”, the task usually wins.
Documentation raises the floor.
It doesn’t close the loop.
Something has to look back at what actually got built.
Building /design-review
That’s exactly why I built /design-review.
npx skills add manish-uxai/design-review -yIt’s an open-source skill that audits design drift directly in your codebase before opening a pull request. Instead of interrupting your workflow repeatedly, it acts as the final checkpoint between building and committing.
Think of it as bringing design reviews back into an agentic workflow.
The goal isn’t to impose taste.
It’s to enforce decisions.
One thing I was very intentional about while building the skill was that I didn’t want another design linter.
Good design reviews aren’t about finding things that are wrong. They’re about understanding what was intentional.
Sometimes the right answer is fixing the implementation. Sometimes it’s updating the documentation. Sometimes it’s leaving things exactly as they are.
Preserving design decisions is just as important as correcting design drift.
Two Categories of Findings
The skill separates its findings into two categories.
The first is mechanical drift — things that have already been decided but weren’t consistently implemented. Hardcoded values where tokens exist. Duplicate components. Mixed icon families. Missing states. These are mechanical problems and can be fixed mechanically.
The second category is judgment calls. An off-palette color might be a deliberate accent. A particular spacing choice may have been intentional. These shouldn’t be automatically fixed because they’re still design decisions.
Good design reviews shouldn’t remove judgment from the process.
They should preserve it.
Every audit reviews eleven dimensions of design quality:
- Token adherence
- System consistency
- Component reuse
- Visual craft
- Typography and numerics
- States and edge cases
- Accessibility
- Motion coherence
- Layout and responsiveness
- Iconography
- Content and microcopy
The goal isn’t to create another linting tool.
It’s to answer a much simpler question:
Does this implementation still respect the thousands of decisions that make up the system?
Every finding must cite files and line numbers because a finding you can’t navigate to is simply an opinion. Severity is forced to discriminate because if everything becomes critical, nothing actually is.
And where genuine design decisions are missing, the skill proposes options and hands the decision back to you.
What I Actually Found
The most surprising part wasn’t that it found problems.
It was watching it disagree with me.
Last week, I rebuilt my portfolio with AI. The design system existed before writing any code. Every change was reviewed by the person who wrote the rules. Total build time: one week.
I expected to find a few small issues.
I didn’t expect to find drift across eight of the eleven dimensions.
Four different whites across dark surfaces had been introduced across separate sessions, each perfectly reasonable in isolation. The newest content on the site had quietly drifted away from the typographic standards used everywhere else. A sorting function would silently misfile my tenth post despite behaving perfectly today. Dead code that had already caused shipping mistakes once before was still waiting patiently for its next opportunity.
Nothing catastrophic.
Everything accumulative.
Which, I think, perfectly describes design drift itself.
There were also moments where I expected the review to recommend changing the implementation, only for it to suggest changing the documentation instead. In other places, it refused to make the decision altogether because both solutions were defensible and handed the judgment back to me.
Ironically, that might be my favorite feature.
Good design reviews shouldn’t win arguments.
They should preserve intent.
One Week Was All It Took
One week.
That’s all it took for good decisions to start drifting apart.
The portfolio was intentionally a small experiment.
The real surprise came when I pointed the same audit at a much larger enterprise prototype. Unlike my portfolio, this project spans multiple workflows, contextual experiences, shared primitives, responsive layouts, accessibility requirements, and AI-assisted interactions. The design system was already in place. Semantic tokens existed. Shared components existed. The architecture was significantly more mature.
And drift still happened.
The review identified token drift across feature surfaces, bespoke controls that silently diverged from shared primitives, missing edge-case handling, accessibility gaps in icon-only interactions, mixed iconography, motion inconsistencies, and responsive risks across fixed-width layouts.
None of them were dramatic failures.
All of them were reasonable decisions made across separate implementation sessions.
That realization reinforced something I’ve been slowly learning while building with agents.
AI doesn’t usually break design in one bad session.
It breaks it across a hundred good ones.
The Bigger Picture
We’re moving faster than ever before, making more decisions than ever before, and increasingly building things directly in code. The question is no longer whether AI can design beautiful interfaces.
It’s whether we can reliably preserve thousands of design decisions over time.
Because design was never the pixels.
It was always the decisions behind them.
Those decisions deserve reviews too.
/design-review is free and open-source under the MIT license. It runs anywhere skills are supported — Claude Code, Cursor, or any agentic coding environment that can consume markdown-based skills.
Build the way you already build.
Just don’t forget to review what you’ve built before you commit.