Comparison
How Shipwright compares.
The AI coding-agent field has matured into recognizable tiers. We are not going to pretend the landscape is simple — or that Shipwright occupies a category no one else does. Here is the honest version: where each tool sits, what they are great at, and where Shipwright is genuinely different.
Market structure
The AI coding agent space has settled into three poles. Where you sit on this spectrum should drive which tool you reach for.
Individual Copilots
Cursor, GitHub Copilot
Autocomplete, inline suggestions, single-dev productivity. Excellent at what they do — not designed to coordinate a team's delivery pipeline.
Team AI Workflow Gap← Shipwright
Shipwright Harness
Structured, multi-step delivery with a human review gate, shared task queue, policy controls, and audit trail. The gap between copilot UX and autonomous agents.
Autonomous Agents
Devin, OpenHands, Augment Code
Fire-and-forget agents that operate with minimal human involvement. Best when you trust the agent fully and want maximum autonomy.
Shipwright sits in the middle — team AI workflow — not because individual copilots are weak (they are excellent at developer productivity) and not because autonomous agents are wrong (they are right for the right teams), but because most engineering teams are somewhere in between: they want automation, but with visibility, controls, and a human in the loop on the decisions that matter.
The landscape
Commercial-tier agents in mid-2026 — the tools teams actually evaluate when choosing an AI delivery layer. MIT / own-it / self-hosted is table-stakes on the open-source side — every serious open-source tool runs on your infra, so it earns parity, not separation. The delivery-pipeline layer is already contested: OpenHands runs it today, Augment Code's Remote Agents pull from a background task queue and land review-ready PRs, and the commercial tier is moving fast.
Facts verified as of September 5, 2026, from each vendor's own primary sources (linked in the table below). Re-checked immediately before this page ships — vendor terms change.
| Tool | License | Models | Task Queue | Team Visibility | Policy Controls | Human Review Gate | Cron / Scheduling | Slack-Native Workflow | Tests-First Enforcement |
|---|---|---|---|---|---|---|---|---|---|
| Devin [source] | Commercial | Proprietary | Yes | Dashboard | Security profiles, network policy, audit logs | Optional | Yes | Yes — Slack Code | No |
| Cursor [Slack] [automations] [policy controls] | Commercial | Agnostic (multi) | No shared backlog | Team dashboard | Model/MCP/repo allowlists | PR review, no plan gate | Yes — cron and event automations | Yes — @cursor launches cloud agents | No |
| GitHub Copilot Agent [coding agent] [model selection] | Commercial | Agnostic (Claude / GPT / Gemini / Grok) | Issues-based | PR-level | Repo policies | PR review | Yes — scheduled and event automations | Yes — Slack and Teams | No |
| OpenHands [enterprise vs OSS] [automations] | MIT | Agnostic (100+) | Yes | Dashboard (Agent Canvas) | RBAC (commercial) | Optional | Yes | Yes | No |
| Augment Code [source] | Commercial | Agnostic (Claude/GPT/Gemini) | Yes — Remote Agent queue | Slack + PR | SOC 2 Type II, ISO 42001 | PR review | Yes — cron, webhook, event triggers | Yes — Slack as tool and trigger | No |
| Factory [source] | Commercial | Agnostic (Claude/GPT/Gemini, BYOK) | Yes — Missions | Mission Control | SOC 2, ISO 27001, ISO 42001 | Missions (plan-approval) | Yes | Yes — @-mention task delegation | No |
| Shipwright Harness | MIT | Claude Code | Yes — shared, assignable | Slack + PR trail | Per-repo, per-skill | Yes — plan approval required | Yes — cron-native | Yes — first-class | Yes — enforced |
The field is converging on the middle. Factory's Missions now approves a plan before its droids execute, and Augment's Remote Agents land review-ready PRs. So the honest question is no longer who has a review gate, it is whose gate is the default and what it enforces. Shipwright approves a plan on every task, not just as an optional add-on, and it is the only tool here that writes tests first and blocks merge until they pass. That combination, not the gate alone, is the whole point.
What actually makes Shipwright different
Three things hold up under a direct comparison. We have retired the ones that did not.
Tests are enforced, not offered
Everyone in this table can generate tests. Nobody else makes passing them the default gate. OpenHands is explicit that running the suite is CI's job, not the agent's. Factory's Missions do run QA against your app as they work and self-correct, but nothing holds the merge on a red suite. Augment generates tests when you ask for them, and Cursor's missing-test PR checks are rules you opt into. Shipwright writes the failing test before the implementation and will not merge without green CI. It is the pipeline's rule, not the agent's discretion.
[OpenHands: QA is CI's job] [Factory Missions] [Augment: Agent use cases] [Cursor: test generation]
An opinionated loop you can take apart
OpenHands gives you primitives and no opinion: you assemble the pipeline yourself. Factory gives you an opinion you cannot open. Shipwright ships the loop already opinionated, then lets you disable phases, override the review principles per repo, and bolt on your own commands and scheduled jobs. Start on rails, then change the rails.
[OpenHands: primitives, not prescriptions] [Factory Missions]
Open throughout, not open core
MIT is table stakes in open source now, so the question is what the license actually covers. In OpenHands, authentication, role-based access control, multi-user organisations and isolated sandboxes sit in the commercial product. In Shipwright, SSO and scoped per-agent access are in the repo you fork. Their open source converts to a paid product exactly when a team needs it. Ours does not.
On "own-it": running on your own infra is necessary, not sufficient — a local agent can still read secrets and act on your behalf. Shipwright's answer is permission scoping, approval gates, and an auditable review trail, not "your code never leaves your machine" alone.
Run it yourself
Self-host it on your own infrastructure
Shipwright is MIT-licensed, with no managed service in the loop. The plugin runs inside Claude Code; the cloud agent — admin, metrics, and runner — deploys to Docker or to your own Kubernetes cluster with the bundled Helm chart. Your code and the agent that writes it both stay on infrastructure you control.
helm repo add shipwright https://app-vitals.github.io/shipwright
helm install shipwright shipwright/shipwrightOne chart packages the admin, metrics, and agent services (plus an optional PostgreSQL). Runs on Minikube, GKE, and EKS.
- MIT-licensed — fork it, audit every line, run it in your own cluster.
- No managed service between your repository and the agent.
- Bring your own Claude Code credentials — nothing routes through an App Vitals service.
Head to head
Shipwright vs Devin
Devin is the highest-profile autonomous coding agent — a managed commercial service with a strong benchmark track record. Choose Shipwright when you want the full pipeline, deploy stage included, on infrastructure you own and operate; choose Devin when a fully managed service with no infrastructure to run yourself is what you want.
Head to head
Shipwright vs OpenHands
OpenHands is the category leader in open-source autonomous agents — MIT, model-agnostic, deployable on your infra, ~86.3k GitHub stars, and it already runs a delivery pipeline (scheduled tasks, triggers, PR review, opening reviewable PRs). It is the closest project to Shipwright on this page: both are MIT, both open real PRs against your repository, and both occupy the same architectural layer — the team delivery pipeline, not the editor. Its Agent Canvas gives that pipeline a dashboard for creating and managing automations, and its ACP support can launch and drive Claude Code, Codex, or Gemini CLI directly as a subprocess agent — so OpenHands can run the very runtime Shipwright is built on. If you want maximum model flexibility and a mature ecosystem today, it is an excellent choice. Here is where the two genuinely differ:
Choose Shipwright when
- You have already chosen Claude Code and want a pipeline tuned for it, not averaged across providers.
- You want tests written first and landed with every change, gated by CI, by default.
- You want a plan a human approves before the agent builds — structured autonomy with a checkpoint.
Choose OpenHands (or the field) when
- You need BYOK / model-agnostic across many providers, including local models.
- You want the largest community and the most mature ecosystem available right now.
- You are not committed to a single runtime and want to keep that optionality — OpenHands' ACP support can even drive Claude Code, Codex, or Gemini CLI as a subprocess agent.
- You want this same delivery-pipeline layer — OpenHands occupies it too, with Agent Canvas as its dashboard — and prefer its breadth to Shipwright's Claude Code focus.
Head to head
Shipwright vs Augment Code
Augment Code pairs a context engine built for very large codebases with "Remote Agents" — cloud workers that pull tasks from a queue, run in the background, and land review-ready PRs — plus a Slack app for codebase-aware Q&A. It is well-funded and enterprise-focused, with real autonomous-agent chops. Here is where the two differ:
Choose Shipwright when
- You want MIT / self-hosted on your own infra, not a managed SaaS with enterprise contracts.
- You want a human to approve the plan before code is written — not review after the fact on a PR the agent already opened.
- Tests-first and CI-green are enforced by the pipeline, not left to the agent's judgment.
- You have committed to Claude Code and want a pipeline tuned for it, not a router averaging across providers.
Choose Augment Code when
- Your codebase is very large and you want a purpose-built context engine across hundreds of thousands of files.
- You want a managed service with enterprise security certifications and no self-hosting overhead.
- Your team already lives in the IDE and Slack, and wants agent access woven into both.
- Model flexibility across providers matters more than depth on a single runtime.
Head to head
Shipwright vs Factory
Factory is the closest thing to Shipwright by architecture: its Missions flow decomposes an outcome, approves a plan, then runs specialized droids in a Mission Control view. It is a managed, enterprise-hardened platform with compliance certifications and airgapped deployment. Choose Shipwright when you are on Claude Code and want tests-first enforced, plan-approval on every task by default, and an MIT harness you can fork and run yourself.
Customizability — opinionated by default, malleable by design
Shipwright ships with an opinionated pipeline: plan, build, review, ship, with tests-first enforcement and a human approval gate. That pipeline is not locked in — every stage is customizable.
Swap skills
Each pipeline stage is a skill. You can replace the default planning skill with your own, add a pre-deploy gate, or swap the review skill for a custom policy check. Skills are plain markdown files — no special build step.
Disable default crons
The built-in review and patch loops ship disabled on new agents. Enable what you want; skip what you do not. Some teams run only the task queue and plan gate, and manage review manually. That is a valid configuration.
Add custom gates
Pre-check scripts can block a cron from firing based on any condition you define — CI status, PR state, time of day, external API call. The gate runs before the agent, so you control when automation is appropriate.
Every tool in the landscape above has converged on some form of this — Devin has Playbooks and CLI-beta Skills, Cursor has rules and hooks, Copilot Agent has custom .agent.md agents, Augment Code has Rules and CLI-only Subagents, and OpenHands has Skills and hooks in the open. The difference is where it lives: for the commercial tools, the deeper extensibility (subagents, hooks, plugins) sits in a separate CLI product, often beta, sometimes pulled without notice (Cursor removed Custom Modes in v2.1). Shipwright's skills, gates, and cron controls are first-class in the one product you actually run.
Honest note: Shipwright is not as easy to customize as rolling your own pipeline from scratch — if you want total control from day one, a bespoke setup is simpler. What Shipwright offers instead is a battle-tested pipeline you can start with immediately, and customize over time as you learn what your team actually needs. Some teams have disabled all the defaults and built their own workflow on top. You own the infrastructure either way.
The honest trade-off
Shipwright runs on Claude Code only. That is a deliberate bet, not an oversight: we think a pipeline built for one excellent runtime beats one hedged across a dozen. If model-agnosticism is a hard requirement, the field above is strong — use it. If you are building on Claude Code and want structure, tests, and a review gate around it, that is exactly what Shipwright is for.
We hold ourselves to the same honesty here: Claude Code is not a closed, locked-in dead end, and we do not pitch it that way. The case for Shipwright is Claude Code quality, not Claude Code exclusivity.
Try it
Install the plugin into Claude Code and run a task end to end. Free, MIT, runs on your own infra.
/plugin install shipwright@app-vitals/shipwright