06-reference

every polish agent built software

2026-07-13·reference·source: Every·by Kieran Klaassen
agentic-engineeringcompound-engineeringsoftware-qualityhuman-in-the-loopdeveloper-workflow

Why this is in the vault

Klaassen defines "polish" as the irreducibly human quality gate in an agentic software workflow — the step that can't be delegated because it requires tasting the running product against your own intention.

The core argument

Code writing is no longer the constraint — agents handle it overnight. What remains is the human judgment call: is the thing on screen the thing you meant to build? Klaassen calls this polish, and frames it as the final step in compound engineering, the multi-agent loop he and Dan Shipper have been developing.

His workflow:

  1. Plan — subagents draft a structured spec
  2. Work — agents write code, run tests, fix failures, open a PR
  3. Review — parallel reviewer agents each look for a different class of issue
  4. Polish — human uses the running app; no agents involved
  5. Compound — lessons from polish get codified into standing rules for future iterations

Polish is deliberately anti-orchestration: every other step fans out to agents with templates and rubrics; polish is intentionally solo. The tooling exists only to collapse friction — /ce-polish checks out the branch, starts the dev server, and opens the running app beside the agent so the conversation between human, app, and agent stays unbroken.

The worked example: he opened an email card in Cora and knew instantly the animation was wrong — it slid in from the top instead of resolving toward the click point. He said so (via Monologue, a voice-to-text tool); the agent fixed it; he clicked again — better. No plan could have specified that. He had to see it and decide.

What polish changes about the rest of the loop:

Because agents commoditize the build, the cost of saying "replan the whole thing" has all but disappeared. The job shifts from protecting your time to protecting the quality of what you've built.

Mapping against Ray Data Co

Ray's /verify skill — which exercises changes end-to-end before committing — is the RDCO implementation of exactly what Klaassen calls polish. The skill exists because IC-mode Claude Code builds are "functional but forgettable" without a human running the actual surface; the "no slop cannon" / production-mode discipline is the policy that enforces the gate. Klaassen's article provides the theoretical frame for why that rule is load-bearing: agents can pass all automated checks and still get the animation wrong, the density wrong, the feel wrong. Only the human with intent can close that gap.

The parallel to MEMORY.md + skill refinement cycles is precise. When Ray catches something in a verify run and updates CLAUDE.md or a skill file, that is /ce-compound: a murmur at the browser becoming a standing rule. The feedback memories in MEMORY.md (e.g., "iMessage file attachments — MCP files param unreliable; use the shell script") are exactly Klaassen's "taste lessons" — started as a complaint, now applied automatically.

For the phData DSA role: enterprise clients deploying AI agents need someone to play the polish role at the system level. Ray's value-add is not the code the agents write — it's the human quality gate that distinguishes "functional AI" from "AI worth putting a name on." The article supports positioning the human DSA as the irreplaceable polish layer, not just a deployment coordinator.

One gap surfaced: RDCO doesn't yet have a /compound equivalent that codifies taste back into the agent harness systematically. Feedback memories exist, but they're reactive (filed when something breaks) rather than extracted proactively after each verify session. A lightweight post-verify compound step would close this.

Related