Skip to content

HARNESS.md — Design Engineering at SageOx

Companion to DESIGN.md §0. §0 says what we believe. This document is how we work — the practice of being a design engineer at SageOx in 2026.

Audience: Design engineers at SageOx and any agent helping one ship. This doc goes deep on the harness; if you want a shorter entry point matched to your role, jump to one of:

State: v0.1, May 2026. The whole industry is in this transition; our practice will change every few months. When reality drifts from this doc, edit the doc.

TL;DR

The traditional design role — make a Figma, hand off pixels, review what engineering built — assumed engineering was the bottleneck. An 18-month ~40× engineering speedup (AI-assisted coding, agentic SDLC, autonomous feature shipping) moved the bottleneck to design. Most surfaces in 2026–2027 will be created by agents and ship to customers without a human reviewer ever seeing them.

The job changes shape. A design engineer at SageOx:

  1. Builds the harness — DESIGN.md, tokens, components, lint rules, contrast checks, motion budgets, studio, and the CLAUDE.md context that tells agents how to consume all of it.
  2. Ships features end-to-end — no engineer handoff. You write the production code yourself. If you can't, you can't ship.
  3. Spot-audits, doesn't gate — sample agent-produced surfaces, find drifts, codify rules. Reviews are non-blocking.
  4. Treats the system as the product — one polished screen is worth less than the lint rule that produces ten thousand acceptable ones.

If you're a designer who optimized your career around pixel polish in Figma, this transition is uncomfortable. It's also the work of the next decade.

Part 1 — Why the old model breaks

The 2024 design loop was:

Designer (Figma)  →  Engineer (translate to code)  →  Designer (review for fidelity)  →  Ship

That loop assumes: - An engineer is available, queued, and slower than the designer's spec. - A reviewer can keep up with everything being built. - Pixel-fidelity-to-Figma is a meaningful quality bar.

By mid-2026, none of those hold at AI-native companies.

Engineering throughput exploded. A single engineer running Claude Code with a well-built harness ships features in a day that would have taken a ten-person team a sprint. Industry data: McKinsey reports up to 40% efficiency gains from AI tooling; MIT estimates 50% productivity boosts; multi-agent workflows show 10× gains in specific workflows. Inside SageOx the speedup is consistent with the high end of those ranges. Engineering is no longer the rate-limiter.

Reviewers cannot scale linearly. When agents ship a hundred surfaces a week, no human reviewer can meaningfully gate them. The Figma-spec-then-review model assumed a human throughput we no longer have.

Pixel-fidelity is now a category error. When a surface is built by an agent reading DESIGN.md and the tokens, the meaningful quality test is "does this conform to the system?" not "does this match the mockup?" There usually isn't a mockup. The system is the mockup.

What dies: design-review-as-gate, Figma-as-source-of-truth, the translator engineer, the weekly Figma kanban. What replaces it: a system that produces acceptable output by construction, plus a small team of design engineers who build that system and ship the features no agent can yet handle.

This isn't a SageOx idiosyncrasy. Vercel's design engineering team describes the same dissolution: "Design Engineers work closely with designers to implement designs, skipping the traditional handoff process. Instead of handing off a completed design, a Designer sketches the start and iterates with a Design Engineer in Figma or code to produce the final design." Stripe, Linear, and Vercel are the canonical references for what premium UI looks like when shipped by integrated design-engineering teams.

Part 2 — What the new model is

The mental model that maps cleanly onto our situation is harness engineering — Mitchell Hashimoto's Agent = Model + Harness (2026), applied to design directly.

A harness is the constraints, primitives, feedback loops, and observability that wrap a non-deterministic system to make it produce reliable output. For an AI agent: the tools it can call, the rules it must follow, the eval that catches drift. For SageOx design: a dedicated repo plus the interlocking layers below — together they let any agent in any SageOx repo produce on-brand, accessible, themed UI without further prompting.

The layers

Layer What it is Where it lives at SageOx
Design system repo A single, dedicated repository owning the canonical system. Not buried inside a product repo. sageox/sageox-design
Spec — canonical The rules agents read before generating UI DESIGN.md here
Spec — per-repo mirror Lightweight design guidance for agents inside each consuming repo <repo>/.claude/rules/design.md (example: sageox-monorepo)
Decision records (DDRs) Numbered, drillable rationale for design system decisions — what we chose, what we considered, what we rejected and why. Three tiers: global (this repo), surface-specific, implementation. decisions/ here (Tier 1); Tier 2 lives in each consuming repo
Tokens The values agents reach for (color, type, spacing, motion) tokens/*.yaml canonical → mirrored into each surface repo
Components Pre-built primitives with great defaults Per-surface component packages (e.g. packages/ui/ in sageox-mono)
Themes Light + dark + calm — every surface implements the full theme matrix; calm is the new ambient mode from KB v2 (§11 Rule 2) Per-surface theme files; tokens have a calm variant
Lint / CI Automatic enforcement of contrast, token usage, motion budgets, theme coverage CI checks in product repos + contrast-check.html
Agent context The framing that tells agents how to read the spec CLAUDE.md here + <repo>/CLAUDE.md + <repo>/.claude/rules/design.md per repo
Designer subagents Claude Code subagents that review agent-produced UI through different lenses — ui-designer.md, hci-expert.md, perceptual-ux.md <repo>/.claude/agents/ per repo, or shared via the SageOx team coworker context
Studio Dated mockups stress-testing ideas before codifying proposals/ → sageox-design.netlify.app
Catalogs A live, agent-iterable design catalog on every surface (required — §11 Rule 7) catalog/<surface>/ (snapshot) · /internal/design-catalog (live web) · <cli> dev catalog (TUI)
Distribution How the system propagates: each consuming repo can pull the latest tokens, components, and DESIGN.md from sageox-design bash scripts/sync-design-system.sh (per-repo) or pnpm sageox-design:sync
Portal The website that ties it all together — readable by humans and agents alike sageox-design.netlify.app (this repo's portal/ + /docs/ + /catalog/ + /inspire/)
Eval Spot audits of what agents produced — the feedback signal that drives Loop A Random sampling, see Part 4 below
Brand contracts Pixel-exact assets that can't be regenerated brand/logos/v4/

Each row is something a design engineer authors and maintains. Every hour improving one raises the floor of every agent-produced surface in the company.

Anthropic's own framing of harness design is worth reading directly (engineering blog post on harnesses for long-running apps): the harness is "the complete infrastructure that governs how the agent operates — the tools it can access, the guardrails that keep it safe, the feedback loops that help it self-correct." Substitute "design system" for "tools," "DESIGN.md rules" for "guardrails," "contrast CI" for "feedback loops," and you have our job description.

Seven cross-cutting principles

Some properties of the harness don't fit in a single layer — they cut across the whole system and need to be true everywhere or they're true nowhere.

1. Two-layer spec: canonical + per-repo mirror

sageox-design/DESIGN.md is the canonical spec — the rules every agent reads before producing UI. It's guidance, best-effort; nothing forces conformance at runtime. The harness around it (tokens, lint, CI, subagents, eval) is what turns the guidance into reliable output. Agents working inside a product repo shouldn't traverse out to read it, so every consuming repo ships a .claude/rules/design.md — a lightweight mirror of the rules most relevant to that surface, with a pointer back to canonical DESIGN.md for depth. Under 200 lines, regenerated by the Distribution sync script, pinned by the canonical commit SHA. When the two disagree, canonical wins — fix it at the source.

2. Theme matrix is a first-class harness layer

Every SageOx surface must implement the full theme matrix:

  • Light and dark — mandatory; checked by CI; every screen must look correct in both.
  • Calm — the ambient mode pioneered in the KB v2 exploration. Calm reduces motion, mutes badges to 50% opacity with hover-to-reveal, hides "via ✦ agent" bylines and file chips, and reduces information density without going silent. (Full spec: DESIGN.md §11 Rule 2.) Calm is not optional for new surfaces — it's how SageOx will feel different from competitors.

Themes are a harness layer, not optional polish. Agents must verify their output covers all theme states, and without a theme switcher in the catalog they can't check. The catalog requirement (§11 Rule 7) exists in part to serve theme verification.

3. Distribution — how the system propagates

A design system only some humans remember to check isn't a system. Every consuming repo must pull the latest with one command. The distribution layer:

  • A scripts/sync-design-system.sh (or pnpm sageox-design:sync) in every product repo that fetches the current tokens, the current DESIGN.md (or its relevant subset), and the current .claude/rules/design.md mirror.
  • A pinned reference (commit SHA or version tag) committed alongside the synced files so reviewers can see what version is in use.
  • An optional --check mode that fails CI if the local copy has drifted from canonical without an explicit sync commit.

A design system you can't pull goes stale. Sync is harness, not convenience.

4. Designer subagents — multiple expert lenses, not one

A single human reviewing every agent-produced surface is the bottleneck Loop A is meant to break. The leverage move is Claude Code subagents that each specialize in one design lens, invoked on demand:

Subagent What it reviews for
ui-designer.md General visual hierarchy, token usage, spacing rhythm, component selection
hci-expert.md Affordances, signifiers, information scent, error recovery
perceptual-ux.md Contrast, motion sensitivity, attention budget, perceptual load
accessibility-expert.md Keyboard nav, ARIA, focus order, screen reader output
agent-ux.md Whether the surface is legible to other agents (see Principle 5)

These live as .claude/agents/*.md in each product repo, or as shared coworkers in the SageOx team context so any repo can summon the same expert. An agent shipping a feature calls @ui-designer review the settings page before landing. Five fast specialist passes beat one slow pass by an overloaded human.

5. Designs for agents are different from designs for humans

A SageOx surface in 2026 has two audiences with two UX requirements:

  • Humans — visual layer, click path, affordances, calm-mode density. Everything DESIGN.md covers.
  • Agents — coding agents iterating in ralph loops; extraction agents pulling structured state; orchestration agents acting on behalf of users. These aren't "users" — they're peer systems consuming our UI as input.

Agent-facing UX is a new discipline with different anti-patterns and success criteria. What we know so far:

  • Stable semantic class names + ARIA beat pretty-but-opaque markup. An agent needs data-component="primary-button" to identify a button; visual cues alone are insufficient.
  • Predictable text output structure in CLI surfaces beats decorative formatting. The ox CLI emits both human-formatted output and --json output for agent consumption from the same code path.
  • Stable, surface-appropriate entry points for catalogs, status, and diagnostics so agents find them without out-of-band knowledge. Web: /internal/design-catalog, /internal/healthz, /internal/diag. CLI: <cli> dev catalog, <cli> dev healthz, <cli> dev diag. Embedded: the test-harness routes (/test/ui/show, /ui/screenshot) that the catalog capture script drives. Email: the rendered template + the email-registry. Different surfaces, same contract.
  • Idempotent UI actions when possible, so an agent that retries doesn't double-submit.
  • Designs survive being copied to a prompt as text — if your important UI state lives in a <canvas> an agent can't read, the agent can't help fix it.

A "DESIGN.md for agent-facing UX" doesn't exist yet; it's on the roadmap. Until then the litmus test is: can a future agent read my UI's state, modify it correctly, and verify the result — with no human in the loop? If not, you're under-investing in agent UX.

6. Designers are coaches, not crafters

The biggest day-to-day change isn't the tooling — it's the role. The job is no longer "make a pixel-perfect mockup and review what engineering built." The job is coaching a swarm of agents to ship surfaces that hit the bar, then auditing the output and tightening the rules that produced the misses.

A 2026 SageOx designer's week:

  • Writing rules and rationales — DESIGN.md entries LLMs reliably follow at edges. "Do X because Y" beats "consider X."
  • Delegating to specialist subagents — @ui-designer into a code review, @perceptual-ux onto a motion ticket, @accessibility-expert onto a form. Each delegation is leveraged review.
  • Coaching by example — when an agent gets a surface wrong, the fix is usually a worked example in proposals/ or a new anti-pattern entry in DESIGN.md, not a one-off correction.
  • Auditing many surfaces — spot-checking Loop A across catalogs and shipped UI, not deep-reviewing one screen.
  • Hands-on coding on the high-leverage 10% — the components agents can't yet produce reliably, the brand contracts, the chrome that compounds everywhere.

Hands-on pixel-tweaking is now ~10% of the job. The other 90% is coaching. This rebalances who's a great hire: the strongest candidates have led design teams or run agent swarms at scale — they already know how to delegate, give feedback that scales, and communicate intent through guidance rather than execution. Senior IC pixel-polishers are valuable but secondary; we need design leaders who code.

If you can't articulate a principle clearly enough that an agent reading it cold can apply it correctly to an unseen edge case — you're not yet a SageOx design engineer. The principle is the work.

7. Decision records preserve the rationale trail

DESIGN.md tells you what the system is right now. It is intentionally thin and scannable — progressive disclosure for agents. DDRs (Design Decision Records) in decisions/ tell you why it is what it is, in numbered, drillable files that don't bloat the canonical doc.

The pattern mirrors the ADR series in sageox-mono/docs/human/adr/. When a design decision either (a) introduces or removes a vocabulary primitive, (b) reverses a previously-codified rule, or (c) cuts across surfaces and needs cross-team alignment, file a DDR. Routine taste calls and individual mockups stay in PR descriptions and proposals/ — DDRs are for decisions with vocabulary or scope consequences.

Three tiers (full convention in DDR-000):

  1. Tier 1 — Global, lives here in decisions/. Verb taxonomies, color additions, motion policy.
  2. Tier 2 — Surface-specific, lives in the surface's own repo. Scribe LED state machine, cast TV remote-control gestures.
  3. Tier 3 — Implementation taste, lives inside the package. A surface-local React or CSS pattern.

What to write where:

  • DESIGN.md — current state, scannable, one paragraph per concept with a link to the relevant DDR.
  • DDR-NNN — the moment we decided, what we considered, what we rejected, what changes downstream.
  • PR description — the implementation work that follows the DDR.

A future agent reading DESIGN.md should always be one click away from the rationale. A future agent reading the rationale should always be one click away from the cross-referenced ADR in sageox-mono. Bidirectional cross-links are mandatory in the DDR template.

Part 3 — How we do this at SageOx today (May 2026)

The toolchain

Tool What it's for Where it fits
Claude Code (Opus 4.7) Primary agent for shipping features end-to-end. Reads DESIGN.md + CLAUDE.md. Every product repo.
Claude Design (Anthropic Labs, launched 2026-04-17) Visual exploration. Reads our codebase + DESIGN.md and applies the system to whatever you prompt. Replaces most of what we used Figma for. Pre-implementation exploration; rapid prototyping; one-pagers and decks.
DESIGN.md + tokens/ Canonical system. Read by every agent before any UI work. This repo.
Pencil (.pen files, pencil.dev) Design-as-code canvas. primitives.lib.pen is compiled from tokens/*.yaml; surface libraries import it. This repo + per-surface .pen files.
proposals/ studio Dated mockups that stress-test the system before codifying. This repo, published to sageox-design.netlify.app.
portal/thumbs/ + render scripts Visual record of what shipped. Auto-rendered from live deploys. This repo.
CLAUDE.md (this repo + per-product) Agent context: what to read, what to do, what to never do. Every repo touching UI.
Contrast / token CI Automatic enforcement. Catches drift without a human in the loop. Per-product CI.

What's not in the toolchain anymore: a Figma file as the canonical reference, a hand-maintained Storybook, a JSON token export pipeline. Those still have niches (Figma for ideation, component-level Storybooks for demo) but none is where the work happens.

Designs sprout from English-language prompts. No wireframe, no Figma mock, no whiteboard sketch before Claude Design or Claude Code renders something. A SageOx designer starts at "a settings page for KB ownership controls — three sections, density-conservative, calm-mode friendly" and ends at a working surface within an hour. Wireframes, when they exist, are themselves generated from prompts; they aren't the seed. The seed is intent expressed in prose. If you reach for Figma to "wireframe first," you're avoiding the real work — being precise enough in language that the agent produces the right wireframe directly.

Claude Design as the new ideation surface

Claude Design (Anthropic Labs, April 2026) is the most consequential designer tool change in 18 months. It reads your codebase and design files at setup, derives a system, and applies it to every visual it generates. From TechCrunch's launch coverage and the buildfastwithai guide:

  • Start from a text prompt, an image, a DOCX/PPTX/XLSX, or by pointing it at the codebase.
  • Use the web capture tool to grab elements from the live product so prototypes look like the real thing.
  • Refine with inline comments, direct text edits, or adjustment knobs (spacing, color, layout).
  • Export to PDF, URL, PPTX, Canva. Hand off to Claude Code for implementation.

Brilliant's design team reported "20+ prompts" → "2 prompts" for complex prototype iterations. That's the speedup.

How we use it at SageOx:

  1. Greenfield exploration — prompt with intent ("a settings page for KB ownership controls"); let it read DESIGN.md + the live product; iterate visually. Output already conforms to tokens.
  2. Variant studies — generate 4–6 directions in one session; promote the strongest 1–2 into proposals/ as proper mockups.
  3. Decks and one-pagers — stop maintaining a slide template. Prompt it.
  4. Hand off to Claude Code — once a direction is chosen, ship via Claude Code with the visual exploration as context.

Claude Design is not canonical — the codebase, DESIGN.md, and tokens are. It's an ideation amplifier. Treat its outputs as throwaway unless you promote them to proposals/.

DESIGN.md as the agent contract

The DESIGN.md pattern — a single markdown file that encodes the design system, lives in the repo, and is read by every agent — was popularized by Google Stitch and is now standard practice across Claude Code, Cursor, v0, and Stitch. When CLAUDE.md points at DESIGN.md, every UI change in the repo is preceded by an agent reading the system.

What this means for how you write DESIGN.md:

  • Every rule has a Why and a How to apply. A rule without a rationale gets violated when an agent meets an edge case. Our existing §11 cross-cutting rules follow this format — copy it.
  • Anti-patterns are first-class. Name them, name the failure mode, give an example. Agents drift toward the average of their training data; the anti-pattern callouts are how you keep them out of common failure modes.
  • Worked examples beat prose. When in doubt, write a small <div> example with the right tokens.
  • Token references everywhere. Never #7a8f78; always --sage-500. Agents will copy whichever form you use.
  • Cross-link section numbers. §11 Rule 5 is a real reference; "the contrast section above" is not.
  • Version the language. SageOx is on v2.4 today (May 2026). When something changes meaningfully, bump it and note the diff. The version is visible on the homepage.

The Design Systems Collective writeup of the DESIGN.md workflow is the canonical external reference. Read it.

Designing with Pencil (.pen)

We design on a canvas, not just in code — but the canvas is itself code. SageOx uses pencil.dev: .pen files edited through the Pencil MCP. The point is that the canvas reads the same tokens the product ships, so what you draw is what builds.

primitives.lib.pen is the shared library — brand colors, font families/weights, the spacing and radius scales. It is generated from tokens/*.yaml by scripts/compile-pen.ts, the peer of compile-tokens.ts. The flow is one-way:

tokens/*.yaml  ──compile──▶  primitives.lib.pen      (the canvas you design on)
                          ▶  tokens.css, tokens.ts    (the code product ships)

The loop, concretely. You want a slightly warmer mid-sage. You don't nudge a swatch on the canvas — you edit --ox-sage-500 in tokens/colors.yaml, run npm run compile, and the sage.500 variable updates everywhere it's placed, on canvas and in code, in one move. Nudging the swatch directly would be drift: the next compile overwrites it, and until then the canvas lies about what ships. The YAML is the source of truth; the canvas is a view of it.

Shared vs. surface-scoped. primitives.lib.pen holds only what every surface inherits. Web-scoped tokens — px type sizes, breakpoints, z-index, containers — are not in it; they live in web.lib.pen, which imports primitives.lib.pen. A new surface (cast, device, mobile) gets its own <surface>.lib.pen that imports the same primitives and defines its own scaled sizes. This is the DDR-011 split made physical: families, weights, and role names are shared; px sizes belong to the surface.

Variables carry canonical token identity — sage.500, surface.quiet, space.5, font.heading — mapping deterministically to the code's --ox-* / --space-* / --font-* names. Placing a variable references the same primitive the code ships, so a design and its implementation can't quietly disagree.

The agent-facing version of these rules is .claude/rules/pencil.md; the decision is DDR-012.

The two loops you'll run

Loop A — Tighten the harness (most of your time)

Run this weekly. It's how the system gets better.

  1. Observe drift. Sample 10–20 agent-produced surfaces from the last week across all SageOx products. Random sampling, not curated; you want to see what's actually shipping.
  2. Find what slipped. A misaligned spacing, a non-token color, a motion that ignored the budget, a contrast violation that the CI didn't catch.
  3. Hypothesize the rule. What rule, if it existed in DESIGN.md or as a lint check, would have prevented this?
  4. Stress-test in proposals/. Create a dated mockup that exercises the proposed rule. Include the edge cases.
  5. Codify. Add the rule to DESIGN.md (with Why and How to apply). Add the token/component if one is needed. Update the CLAUDE.md guidance.
  6. Automate where possible. Tokens-only lint rule, contrast CI check, motion budget. The system fails loudly, not silently.
  7. Ship the harness change. Push to this repo. Every downstream product picks it up on git pull.
  8. Verify. Sample the next week's shipped surfaces. Did the drift class drop?

Every iteration raises the floor for every surface shipped after. The leverage compounds.

Loop B — Ship a feature end-to-end (a fraction of your time)

  1. Open Claude Design. Prompt with intent. Iterate to a direction.
  2. Open Claude Code in the relevant product repo. Hand it the direction + the feature scope. Let it implement against DESIGN.md.
  3. Review the code yourself (you're the engineer now). Fix what's wrong. Run the lint + contrast checks.
  4. Ship.
  5. If anything about the experience exposed a gap in the harness, run Loop A on it before moving on.

No separate engineer in this loop. No separate designer reviewing for fidelity. You are both. If you can't write the TypeScript, the Svelte, the Go — whatever the stack is — the design doesn't ship.

Part 4 — What "non-deterministic design" means in practice

Old design was deterministic: a designer specced padding: 14px, an engineer set padding: 14px, the artifact matched the spec. Variance zero by construction.

New design is non-deterministic. The same prompt produces slightly different outputs across runs; the same DESIGN.md rule is interpreted slightly differently across files. Not a bug — a property to design around. Figma put it concisely in State of the Designer 2026: designers are "leaning into the messy middle."

Three implications for how you work:

1. Your spec is a distribution, not a target. A DESIGN.md rule doesn't specify one output — it specifies a band of acceptable ones. The question isn't "is this exactly right?" but "is this in the band?" Too many outside? Narrow the rule or tighten the token.

2. Eval matters more than spec. A beautifully written rule that's never measured is theatre. Every important rule needs a check — contrast CI, token-usage lint, visual regression, periodic spot-audit. Without eval, you don't know if the rule is working.

3. External evaluators beat self-evaluation. Anthropic's harness-design article: "separating the agent doing the work from the agent judging it proves to be a strong lever." Apply to design: don't let the agent that built the surface review it. Run a separate pass.

Part 5 — The mindset shift

What you give up: - The pride of one pixel-perfect artifact you can hold up. - Control over every visual decision. - The status that came from being the visual bottleneck.

What you gain: - 100–1000× leverage. The rule you wrote today shapes ten thousand surfaces this quarter. - The ability to ship a feature without filing a Jira ticket for someone else to build. - Work that compounds. A token is forever; a Figma file is for next week. - A new kind of craft — the craft of writing rules a non-deterministic system will follow well.

This is harder than the old job, not easier. The old job was bounded by taste and patience. The new job is bounded by your ability to think systemically about taste at scale, and to write code. It's also more interesting.

If the transition feels uncomfortable, you're paying attention. If it feels impossible, the role isn't for you anymore — that's a real conversation, not a failure.

Part 6 — A 30-day onboarding for a new SageOx design engineer

Who we're hiring for. Strongest candidates have led design teams or run agent swarms at scale. The work is coaching, delegation, and writing principles that generalize — not hand-aligning to a 1px grid. Design managers, art directors, tech leads who coached a team to ship, and people running agent swarms in personal projects have the right instincts. The plan below assumes you know how to give feedback that scales.

Week 1 — Absorb the system. Read DESIGN.md cover to cover, twice. Read HARNESS.md (this doc). Read every dated proposal in proposals/. Read the last 90 days of commits in this repo and skim the commit messages. Read CLAUDE.md in this repo and one product repo. Read DESIGN.md §0 one more time.

Week 2 — Spot-audit. Sample 20 agent-produced surfaces across the SageOx products you have access to. Note every drift you see. Categorize them. Propose 2 system fixes (rule additions, new tokens, new lint checks) in a short writeup. Discuss with the team.

Week 3 — Stress-test a rule. Pick one of your proposed fixes. Build a mockup in proposals/YYYY-MM-DD-<your-slug>/ that exercises it across edge cases. Render thumbnails. Publish. If it survives review, codify it into DESIGN.md.

Week 4 — Ship a real feature end-to-end yourself, no engineer handoff. Pick a small one. Use Claude Design for exploration, Claude Code for implementation. Update CLAUDE.md with anything you learned about how agents in this product respond to our DESIGN.md framing.

Throughout: resist the urge to make a Figma. If you reach for Figma in week 1–4, ask yourself what tool in the harness should have replaced that reach, and propose adding it.

Part 7 — Sources and further reading

This document is built on direct evidence; everything below is worth reading.

On Claude Design (Anthropic Labs, the most important tool change of 2026): - Introducing Claude Design — Anthropic announcement - Anthropic launches Claude Design — TechCrunch (2026-04-17) - Claude Design: Complete Guide for Non-Designers (2026) - Anthropic Brings Claude AI Directly Into Adobe, Autodesk, and Blender

On the DESIGN.md workflow: - The DESIGN.md Workflow — Abhi Chatterjee, Design Systems Collective (April 2026) - How to Use DESIGN.md with Claude Code — DesignMD - Design Systems in 2026: Turn Your System into a Claude Skill — Garima Agarwal (May 2026)

On harness engineering as a discipline: - Harness design for long-running application development — Anthropic Engineering - What Is Harness Engineering? — NxCode 2026 guide - The Harness Model — AI Engineering Maturity Matrix, Q1 2026

On design engineering as a role: - Design Engineering at Vercel — the canonical reference for what the role looks like at a peer company - How Stripe, Linear, and Vercel Ship Premium UI — Mantlr - State of the Designer 2026 — Figma Blog

On the broader AI-native operating model: - How to build an AI-native company and harness AI growth — WEF (January 2026) - How agentic AI will reshape engineering workflows in 2026 — CIO - AI-Assisted Development in 2026: Best Practices, Real Risks — dev.to

People worth following in this space: the curated list lives at /inspire/ — start with Maggie Appleton (GitHub Next), Geoffrey Litt (Notion / Ink & Switch), Linus Lee (Thrive Capital), Amelia Wattenberger (Sutter Hill / Intent), and the GitHub Next team. That page also lists our game-design influences for the Cast surface (Jenova Chen, Hidetaka Miyazaki, Riot, Among Us, the loading-mask lineage) — multiplayer / team-coordination / latency-masking patterns from games are one of our most underweighted lineages and directly shape how Cast should feel.

Part 8 — What we don't know yet

This is the start of a journey, not the end. Open questions we don't have great answers to in May 2026:

  • Where does human review still matter? Safety-critical surfaces, regulated flows, anything involving money or identity probably still need a human in the loop. The boundary is fuzzy and will move.
  • What happens to taste in a non-deterministic pipeline? Today we encode taste as rules. Some taste resists encoding. We don't yet know how to express "this feels heavy" in DESIGN.md.
  • How do we evaluate brand consistency at scale? Visual regression on every shipped surface is expensive. Sampling misses things. The eval layer of the harness is the least-built layer at SageOx today.
  • What do we lose by not pixel-polishing? Probably some moments of delight that came from a designer obsessing over a single transition. Worth keeping a small budget of hand-polished surfaces — the hero moments — and accepting the rest will be agent-produced and merely good.
  • How does the role evolve as agent capability evolves? A 2026-Q2 design engineer's job will look different from a 2027-Q4 design engineer's job. Reread this doc in six months; it will be wrong in important places.

When you have a better answer than this document, edit it. That's the harness improving itself.

Cross-references: DESIGN.md §0 (philosophy) · README.md (overview) · CLAUDE.md (agent-facing context) · proposals/AUTHORING.md (mockup format) · sageox-design.netlify.app (live studio).