Don't Migrate Your Proven AI Workflow to DeepSeek Harness Yet

Introduction

DeepSeek Harness launched four days ago and quickly gained traction, with many articles proclaiming "Everything is a plugin" and urging developers to assemble their own agents. The author, who has a battle-tested frontend development workflow ( ai-frontend-dev-workflow v3.3) running in Cursor, Claude Code, and Codex, asked whether to port it to Harness. The conclusion: no need to migrate now .

Core Distinction: Runtime vs Methodology

The confusion stems from conflating two layers:

Runtime (Harness) – handles "how the agent runs": model integration, tool calling, sandbox, trajectory logging.

Methodology (Workflow) – defines "how a requirement gets done reliably": stages, gates, role isolation, acceptance sources.

DeepSeek states Agent = Model + Harness. That covers the agent's hands and feet, but frontend delivery depends on phases, gates, role separation, and verification sources – not just the runtime.

DeepSeek Harness Overview

Released August 13, 2026 under MIT as a developer preview. Official warning: core plugins and APIs will have breaking changes. Design: Everything is a plugin (model, tools, skills, session, sandbox, storage, loop, scheduler, UI) on the Cordis kernel. Four run modes:

Standard – full coding agent (file edit, shell, search, skills, planning, sub-agents); comparable to Cursor/Claude Code default.

Code – tools exposed as SDK; model orchestrates multi-turn calls in TypeScript.

Minimal – only bash + file edit; for benchmarking, not delivery.

Creator – inspect runtime, try plugins in memory, assemble new presets; entry point for "build your own agent".

Key feature: full run trace (system prompt, reasoning, tool calls, sub-agent scheduling, context injections) in append-only logs, replayable and forkable – useful for debugging.

Harness is a general-purpose agent runtime, on par with Cursor Agent, Claude Code, Codex. It does not include frontend delivery methodology or business gates.

Existing Workflow: ai-frontend-dev-workflow v3.3

Orchestrated by Cursor Agent + workflow-orchestrator. Core phase chain:

Roles are separated: Maker (writes code, reworks on feedback), Checker (contract & 7-dim technical verification), Auditor (read-only acceptance, forbidden to modify business code).

Three tiers by complexity: Full (multi-module, OpenSpec + 4a + 4b), Lite (single-page, Loop as acceptance source, no OpenSpec but still 4b), Mini (small changes, Loop + acceptance report, default skips 4b). Author notes Mini is now most used because AI capability has improved.

Hard gates: no direct src/ coding before gate; delivery must pass validate-workflow-artifacts.sh. Scripts enforce what models may skip.

Regression cases: special-order-inherit, demo-task-tracker – the latter failed 4b on first run because technical verification passed but business AC was incomplete, proving 4a pass ≠ 4b pass .

Comparison: Harness vs Workflow

Layer : Runtime/Kernel vs Methodology/Delivery Contract

Core Question : Agent perception/tools/traces vs Requirement alignment/coding/verification/acceptance

Pluggable : Model, sandbox, UI, loop plugins vs Phase cards, role Skills, gate scripts

Maturity : 4 days open source, preview, breaking changes expected vs v3.3, project regressions, mechanical checks

Loss if replaced : Launch UX, trace view, plugin assembly vs Pause points, AC source, Maker cannot self-review, artifact contracts

Harness can at best become another host for the workflow, not a replacement.

Five Reasons Not to Migrate Now

High-value assets must be rewritten with near-zero short-term delivery gain. The real value lies in contracts: Pause Point C (human sign-off before coding), Acceptance Source (OpenSpec/Loop, agent cannot arbitrate conflicts), Role Isolation (writer ≠ reviewer), Mechanical Gates ( check-pre-coding-gate.sh, validate-workflow-artifacts.sh), Three-tier execution (pay tokens per complexity). Each must be re-implemented on Harness; user perception unchanged; risk of breakage.

Workflow is deeply bound to Cursor/Claude Code/Codex. Dependencies: Phase 1e browser-tested interaction HTML ( 交互行为分析.md), Phase 4a Toolkit code-verify 7-dim verification, Phase 4b deliverable-acceptance-audit + AC evidence chain, YApi/Figma/MasterGo MCP for interface/design alignment. Harness Standard mode is a generic coding agent and lacks these gates, artifact directories, and MCP topology. Migration cost = rewrite orchestration layer, re-test, re-verify.

"Assemble your own agent" is already done. Current workflow structure is already modular: workflow-orchestrator (phase machine), maker-agent / checker-agent / auditor-agent (roles), verification-loop / acceptance-audit-loop (bounded loops), Shell hard gates (second execution layer outside model). Re-assembling in Harness would be isomorphic replication, not an upgrade.

Skills are the portable layer; no need to rewrite methodology for a new Harness. Industry converging on

SKILL.md</strong>; Cursor, Claude, Codex, and Harness all recognize Skills. Community plugins map Cursor/Claude Skills into Harness. Correct direction: keep methodology as Skills so it can mount on any future Harness. Wrong direction: rewrite workflow as Cordis plugins just to claim Harness adoption.</li><li><strong>Preview kernel should not carry production orchestration.</strong> A v3.3 workflow with regression suites bound to a kernel that explicitly promises breaking changes is poor engineering judgment. Analogy: Vue 1.x/2.x/3.x or early React versions were not drop-in compatible.</li></ol><h2>When to Evaluate DeepSeek Harness</h2><p>Only when a <strong>runtime bottleneck</strong> appears, not a methodology bottleneck. Signals:</p><ul><li>Need to run the same flow outside Cursor/Claude/Codex (headless CI, self-hosted, cost optimization with DeepSeek models). Missing a second runtime, not a second phase definition.</li><li>Cursor/Claude/Codex session and tool loop become bottlenecks; Harness Trajectory (replay/fork) could cut "why did the agent go off track" debugging time.</li><li>Need kernel-level sandbox/model/scheduler swaps; Skills layer insufficient; must modify loop and tool protocols.</li><li>Team's goal is building Harness engineering – selling runtime, not frontend delivery. Then Harness is the experiment subject, not the workflow host.</li></ul><p>Most frontend teams' real bottlenecks: agents coding all-in without gates, token waste from always running Full tier, documented constraints ignored by model, scope creep, 4a pass mistaken for completion, mental fatigue from "vibe coding". These are methodology problems; switching Harness won't fix them.</p><h2>Three Paths Forward</h2><ol><li><strong>Path A (Recommended):</strong> Keep refining workflow on Cursor/Claude/Codex. Harden gates, slim Lite/Mini, stabilize 4b evidence, make Skills more portable. Highest ROI for "customizing your development needs". After kernels reach baseline, IQ 80 vs 90 matters little.</li><li><strong>Path B (Optional):</strong> Use Harness as a second runtime probe without changing workflow core. Run <code>npx @deepseek-ai/dsh web

on a Mini-tier task. Check: Skill discoverability, MCP/browser/script gate drop rate, whether trajectory replay actually helps debug. Decide later on multi-Harness adaptation. Forbid rewriting workflow-orchestrator etc. One day of exploration max.

Path C (Don't do now): Deep customization/re-assembly on Harness. Migrate proven orchestrator to unstable kernel. High cost, compatibility risk, no short-term delivery gain. This is rewriting yourself with current hype.

For ai-frontend-dev-workflow the choice is A, with a touch of B . Same criterion for any phase-based workflow in Claude Code or Codex: if it already has orchestrator, roles, gates, acceptance source – don't rebuild for Harness; if not, fix methodology first on your familiar tool, don't swap kernels first.

What a Real Workbench Looks Like

Many imagine a custom UI with plugin market. The real workbench for frontend delivery is a set of constraints the AI cannot bypass – constraints for the AI agent. Cursor, Claude Code, Codex, Harness are merely hosts. Hosts can change; constraints shouldn't be rewritten for the host. The learning fees paid (skipped phases, false completions, ignored gates, conflating 4a/4b) are embedded in the workflow. Switching hosts doesn't transfer those fees unless you bring the contracts, not just the kernel.

Recommendations

If you're a user, not a workflow author: Stick with your most familiar stack. Play with Harness, but don't make it this week's delivery path.

If you've written a similar workflow: Prioritize: standardize Skills, script gates, clarify Full/Lite/Mini. These add value on any Harness; switching to Harness does not.

If you want to study Harness itself: Run Creator mode, inspect Trajectory, write a no-business plugin. Treat it as a lab, not a production base. Official says preview, breaking changes coming.

Final Verdict

One-line judgment: Workflows already working in Cursor/Claude/Codex do not need to move to DeepSeek Harness to "customize your agent workbench".

Separate the layers: Harness = how the agent runs. Workflow = how the requirement gets done. Swapping the former doesn't strengthen the latter.

Real migration cost: Rewrite orchestration, re-integrate MCP, re-do gates; delivery capability doesn't increase short-term; must absorb preview breaking changes.

Do now: Polish methodology – phases, roles, gates, acceptance sources, portable Skills.

Re-evaluate Harness when: Need headless/self-hosted/model-cost runtime, or Cursor loop/debugging becomes bottleneck. Do a one-day Mini probe first, then decide on adaptation – don't rewrite first.

If you do one thing: Open your workflow and ask: is the bottleneck the kernel or the gate? If gate, fix workflow; if kernel, then touch Harness.

DeepSeek Harness deserves attention – it opens "Agent = Model + Runtime" and makes plugin assembly and trajectory default capabilities. Good for agent infrastructure builders. But for those with a working workflow on existing tools, it's not a "move now" notice. The author's workflow stays on current hosts, hardening contracts and portability. Harness remains a spare-tire experiment, not a production base.