AI-Native Product Workflow

Overview

This case study is about a way of working, not a single screen. I run product work with AI agents, mainly Claude and Grok. I design the screens and set the direction. Agents build the mockups and code, check them and critique them. I decide what ships, how it looks, and when it is done.

Musterhall

A part-time, pre-launch side venture: a trends and knowledge learning platform. I’m a co-founder and I lead product and UX/UI. The full build loop runs here.

Mookie’s Mushrooms

A pre-launch client engagement. I’m the design lead: brand identity, packaging, Amazon assets and the waitlist website. The same standard for done and the same human gates apply here.

The loop

Every change request on Musterhall runs the same seven steps.

It starts with reconciling. The ticket, the spec and the mockup are claims until the current code agrees with them, so the first job is to read all of it and check every claim. Then Claude builds and runs every automated check: types, code style, tests and the build. That is checking, not reviewing. Next it breaks each new test on purpose: undo the line the test protects, watch the test fail, put the line back. A test that has never failed hasn’t proven anything.

After that the work leaves the builder. An automatic check blocks any broken build before it’s pushed, the ticket moves to ready to test, and it lands with me for design acceptance. A human merges. The AI session never merges to main.

Where design fits

I design the screens. Agents build the mockups and the code from my direction, and what they build comes back to me to accept against the design.

On Musterhall, the design system (colors, type, spacing and component rules) is packaged as an agent skill: a set of instructions the agent loads before any design work starts. So agents build on the system instead of near it. Here is how it reads, quoted from the skill:

Colour encodes; it never decorates.Green may write, it may not outline.Borders are never green.Never hardcode a colour, radius or type value. Consume the tokens by name.Spacing comes from `--space-0..9` only.An undefined custom property is silently dropped and the element inherits.To check a token exists: grep the emitted CSS, not the spec.For cross-file consistency sweeps, write a deterministic script, don't ask an agent to eyeball 29 mocks.

The skill tells an agent what the rules are. Code backs them up. A lint rule that runs before every push rejects hardcoded hex colors and raw z-index values. A test fails on bare references in the app’s code to tokens that don’t exist. And a script checks each HTML mockup’s spacing, type, radius and color use, written after agent judgment missed a dozen off-scale values in a single mock.

The split of ownership is clear. I own what we build and how it looks and feels. My mockups live as prototypes that never merge into the product. Engineering owns the production wiring. When a ticket is built and reviewed, it comes back to me, and it isn’t accepted until the design is.

One ticket, end to end

One real change request, traced from spec to merge: a Share control on the course page.

1. Spec. I wrote the build spec: share controls on five public surfaces, a fallback sheet where the phone’s share sheet isn’t available, and link attribution that counts arrivals without tracking people. It cites the code it builds on, line by line, so the builder starts from what is actually there.
2. Mockup. The handoff mockup is built from the real tokens and passes the same mockup checks. Share is an outline control with no green, next to the page’s one filled primary, Buy.
3. Pattern pass, then a split. Before building, a sourced look at 13 products showed share living on the detail page or behind an overflow menu. Only one put it on cards. So I split the ticket: the control ships now and the measurement work waits. The ruling also moved Share beside the title, never beside Buy.
4. Build. Claude built it, reusing the existing share button and moving its off-scale gap onto the spacing scale. It goes icon-only on phones, and a review fix made it a 48px square on touch.
5. Review. Grok, with read-only access, flagged a high-severity issue. After a copy, the button’s visible text changed to “Link copied” but its accessible name still said “Share”, and nothing announced the change. A screen reader user got no confirmation that anything happened.
6. Fix. The name now leads with the visible label, and a polite status region announces the copy, matching the copy-link button the product already had. A test pins it, and the fix was reverted on purpose to prove the test fails without it.
7. Merge. A human merged it. The AI session never merges.

-      aria-label={ariaLabel}+      // WCAG 2.5.3 while copied: the visible text becomes "Link copied", so the+      // name must contain it too (the CopyLinkButton idiom, Grok refute+      // 2026-09-24). The status region below is what announces the change.+      aria-label={ariaLabel ? (copied ? `${copiedLabel}, ${ariaLabel}` : ariaLabel) : undefined}     ...+    <span className="sr-only" role="status" aria-live="polite">+      {copied ? copiedLabel : ""}+    </span>

It’s a small bug, and the kind no visual review catches: the screen looked right. It was caught by a reviewer that could only read the code and was told to break it.

How it all connects

The loop doesn’t live in a chat window. Agents work inside the same tools the team uses: they read specs from the vault, update ClickUp with evidence, and their activity shows up in Slack next to everyone else’s.

Two families, used on purpose

I don’t run everything through one assistant. Claude works through Cowork and Claude Code. Grok works through Grok Bot: my own, always on and running scheduled jobs on my build box, plus the team’s shared bot. Most tasks could go to either, and I move work between them on purpose.

Why builder and reviewer are different models

A model checking its own work is mostly checking its own assumptions. It shares its own blind spots. So Claude builds and Grok, a different model family, reviews. Grok gets read-only access and one job: try to break the work, not bless it.

Its findings are claims, not verdicts. Claude checks each one against the actual code, fixes the real ones, and sends any fixes back for another review. The rule exists because on early tickets, reviewers on other models caught serious bugs the builder had already shipped.

What the loop actually catches

These are more real catches from the loop, told without product details. Most are the quiet kind of bug that looks fine in a demo.

One rule sits on the design side. Once a spec is frozen for sign-off, the words on screen have to match the approved copy exactly. If a build needs a new line of text, it ships flagged for my sign-off. It never slips in quietly.

Routing agents by task

Not every task needs the strongest model. The rule: the cheapest model that does the job at full quality.

Two principles settle the edge cases. First, the harder something is to undo, the more effort it gets. Scoping a product is hard to walk back, so it gets a top model thinking hard. A repetitive edit is easy to redo, so it gets a small, fast one. Second, when two models disagree, I escalate instead of averaging their answers. And anything with one right answer doesn’t get a model at all. It gets a script.

Rules as code

When a rule keeps getting broken, I don’t write another reminder. I build a check that makes the mistake fail loudly, so nobody has to remember. Written instructions come last.

The evidence ladder

“Done” is the easiest word for an agent to say. A checkmark is easy to produce. So every claim of done sits on a ladder, and only the top rung counts. This part runs on both products.

Tier 1 means someone opened the actual file or export and can point to the exact place. That is the only basis for proposing that a task is closed. A commit message, a checkmark or someone saying it’s done is Tier 2, and it isn’t enough. Neither is a guess. Agents can flag candidates. A human closes. On the client engagement the same idea has its own name: submitted is not accepted.

What this means for a team I join

You get a designer who designs the screens and can take them from spec to a reviewed, working prototype. Review is built into the loop, not bolted on at the end. And things don’t get called done before they are, because done has a standard and a human signs it.