Case · Scale · Organization
I wrote my design judgment down so the agents could read it.
TL;DR
- Role
- Senior Director of Product Design, Conviva
- Scope
- The standards an AI coding agent and every contributor to the product work under
- Team
- A globally distributed design team, plus the engineers, PMs, and contractors who ship to the same surfaces
- Timeframe
- 2025–2026
Scroll sideways to view the full diagram.
The situation
My design team had already moved into the codebase. Designers ship functional code, not mockups, and an AI coding agent does real work in the production codebase alongside them.
That shift shortened the handoff and created a subtler problem. When people and agents are all producing work at speed, what erodes isn't velocity. It's coherence: the product's promise, its voice, the register a customer should feel when they land. Those are the hardest things to write down and the easiest to lose one reasonable commit at a time, and I can't be in every conversation. Designers report to me, but PMs, engineers, and contractors ship to the same surfaces, and I'm accountable for the design and UX of all of it. The question became how a standard survives contact with a fast pipeline when the person who holds it isn't in the room.
The reframe
The usual answers each cover half. Written guidance states the principles but doesn't ensure they're applied when the work is being made. Automatic checks are applied every time but can't settle questions of intent or judgment. Neither, alone, governs the thing that matters.
I stopped treating design governance as one problem. It's two, and they split by what can be checked. Taste and intent, the why behind a decision, require judgment beyond automatic checks. But the design system, the voice rules, and the parts of the behavioral contract that govern the product's own copy are codifiable. So I built two layers: intent written as a mirror that catches drift and opens a conversation, and rules written as checks. And I made the AI coding agent the reader of both, because the agent is doing the work now and the standard has to live where the work happens.
The work
The intent layer is a document written for the agent to reason against, not to obey. It captures the product's promise, the emotional register I want a customer to feel, and the handful of principles that define the product's point of view. It is written as drift signals and pause triggers rather than rules. When the agent senses the work pulling away from intent, its instruction is not to correct but to stop and ask the designer: this feels like a different direction, is that intentional. The document says so explicitly: the goal is not compliance, it is alignment; you are not the authority on taste, you are a useful mirror.
Scroll sideways to view the full diagram.
Underneath intent sits the codifiable layer: per-surface knowledge modules on a shared base, one each for data visualization, navigation, the insights surface, the design system, and the assistant's interface. Each carries the patterns, placement rules, and escalation points for that surface, so the agent loads the right judgment for the thing it's touching.
The behavioral contract I'd written for the assistant feeds this layer in a specific way. Its clauses on confidence and on separating what is measured from what is inferred become copy rules for the assistant's interface: the labels, the hedges, the fixed language around what the model produces. A violation there is a contract violation, and the rule says which clause it enforces. The harness does not check the assistant's generated responses; that's a different problem with different tooling.
Scroll sideways to view the full diagram.
Two more pieces close the loop. At review, the agent reads the diff and drafts the design, engineering, copy, and documentation handoffs from it, so the record comes from the change rather than from a meeting. And the two layers run at two speeds: the codifiable modules are applied during creation and review, while the intent layer stays a conversation while the work is cheap to change. Most rules are routed to the agent with the evidence it has to attach; a narrower set runs as automatic checks on the source. None of it blocks a merge on its own. A person does that.
This didn't come from nowhere. On Bolt.new, I had built Bolt Buddy: an assistant that worked with designers to shape a prompt before it reached the tool, keeping the language consistent, holding the design system and WCAG 2.2 AA, and refusing outright when a request fell outside scope. It caught enough to prove the idea was possible and missed enough to show me the answer was not a better prompt. When we moved off Bolt.new to Claude Code, Bolt Buddy ended with the tool it was built for, and I built the harness instead: not one prompt, but the whole workflow; not scope, but judgment.
The outcome
The harness isn't a document I published and hoped people would read. It lives in the product repo and loads for any agent contributor working there, and I taught it to the team directly, in a session on how it was built and why. The configured mechanical checks flag violations for review. The agent is instructed to raise architectural questions with a designer. Decisions, once made, are recorded for later reference.
What's operating today is the local harness and the review practice around it.
What I'd tell another design exec
Don't try to automate taste. Write down what taste has already decided, and leave the rest a conversation, available where the work is being made.