Platform WatchJune 25, 2026via Vercel Blog
Teaching agents product design at Vercel
Why it matters
As AI agents move into product development workflows, the bottleneck shifts from speed to judgment. Vercel's product-design skill system shows how to embed product context, design reasoning, and standards into repositories so agents can make decisions that require human judgment—not just copy patterns from code.
Key signals
- Vercel treats agents as native to their workflow, with product decisions stored in repository alongside code
- Three-part system: skill routing, traceable findings, and evidence-intake workflow
- Separates deterministic checks (linters) from judgment-based agent guidance
- Tests agent behavior on unseen interfaces using evals with shipped examples and holdouts
- Weekly evidence-intake workflow collects design feedback from Slack, Figma, GitHub for skill updates
- Lint rules encode product guidelines as deterministic checks; agent guidance handles decisions requiring context
- Coverage-gap list makes missing guidance explicit for continuous improvement
- Stable rule IDs link to examples and sources; human approval required before changing guidance
The hook
Vercel just solved the hardest part of coding agents: teaching them *why* decisions exist, not just what shipped.
Coding agents can produce working UI fast, but what's harder is a different shape. They can copy your product's style, match its patterns, and try to follow its conventions. What they cannot do is understand why those patterns exist. Code shows agents what shipped, not why one component, phrase, or interaction became your standard. That reasoning lives in design reviews, PR comments, Slack threads, and with the people who were in the room. For an agent, context that isn't in the codebase doesn't exist.
Vercel is an agent-native team. We treat accepted product decisions like code, keeping them in the repository, reviewing changes against them, and making them available to every agent working there.
The way we do this is through . It's a system with three parts:product-design
Any team can build the same structure around their own standards.
The skill lives inside the repository alongside the code it governs. Here's a simplified view of its structure:
resolves the request mode first: shape, implement, review, copy, or harden. This keeps audits from becoming edits and copy passes from expanding into redesigns. It skips backend-only work, telemetry, console errors, generated files, and tests with no shipped UI impact.SKILL.md
The skill routes to canonical sources instead of duplicating them. Component APIs, design-system rules, accessibility criteria, and interaction guidance stay with their owners.
Routing is specific to both task and surface. Material changes load product-judgment and interface-quality first. Copy, component, layout, interaction, accessibility, and resilience work each route to focused references. A modal loads destructive-action patterns and canonical verbs. A settings form loads labels, validation, progressive disclosure, and accessible-name guidance.
You can use this simplified structure as a starting point and replace the paths and standards with your own:
Routing is only part of what makes the skill useful. The other part is how findings stay tra...