How to Choose an AI Coding Agent in 2026: A Hands-On Comparison of 30+ Tools

Models, Agents, Harnesses, and Platforms Are Not the Same

The article opens by clarifying four frequently conflated layers: the model (understands tasks, generates code), the Coding Agent (searches repos, calls tools, edits files, reads execution results), the Agent Harness (organizes tools, permissions, context, session state, exception recovery), and the IDE/cloud platform (integrates everything into the developer's environment, handling Git, deployment, review, collaboration). A diagram shows the flow: task + constraints → Coding Agent (model + Harness + runtime) → code changes + build/test + evidence + human acceptance.

Crucially, open-weight model ≠ open Harness . Qwen or DeepSeek may power an agent, but that doesn't mean the execution framework is open source. Conversely, an MIT-licensed agent may call paid/closed model APIs. The author stresses evaluating which layer is actually open.

Decision Table: Match Your Task to an Entry Point

Maintain existing repo, developer reviews continuously → First compare: IDE Agent, Terminal Agent. First-round checks: Accurate localization, restrained diffs, reproducible tests.

Well-bounded long task, return to accept results → First compare: Cloud delegation, PR workflow. First-round checks: Isolation, stop conditions, failure reporting, audit trail.

Build runnable small tool from scratch → First compare: App workbench, AI IDE, general task workbench. First-round checks: Local rebuildability, portable deps/deployment.

Customize toolchain or research Harness → First compare: Open-source CLI, runtime, research frameworks. First-round checks: Extensibility, permission boundaries, session/tool traces.

Internal repo with strict data requirements → First compare: Enterprise or self-hosted entry. First-round checks: Actual data flow, identity/permissions, audit, model location.

Overseas Commercial Coding Agents (10)

1. Claude Code — Terminal-Centric Closed Loop

Form: Terminal Coding Agent with editor/toolchain integration. Strength: multi-step tasks (search PDF export chain → edit → run tests → re-fix) run in one session via file ops, shell commands, project context, tool feedback. Uses CLAUDE.md for project rules, Skills for repeat flows, Hooks for external checks, sub-agents for complex tasks. Author's example: constrained task to not delete existing export formats and require regression tests for missing pages. Caveat: continuous execution ≠ auto-approve everything; permissions, shell access, external repos need explicit config. Best for teams with mature terminal workflows.

2. Cursor — Agent Actions in the Editor

Form: AI-native IDE with Agent + terminal entries. Differentiator: puts code understanding, editor navigation, diff review, and agent ops in one place, reducing context-switching. Example: open export module, check if pagination state shared by two async tasks, review conditional branches after edit. Not about "which model is smarter"; one optimizes IDE human-AI collaboration, the other optimizes terminal execution orchestration.

3. GitHub Copilot — Agent Inside Existing PR/Collaboration Chain

Form: Editor assistant, Agent mode, GitHub workflow. Value: connects to repo, Issues, PRs, CI checks. For a team already on GitHub, "AI modifies code" is only half the battle; the time sink is submit → CI → review → merge. Author writes reproduction steps + acceptance criteria into an Issue, lets agent handle changes within authorized scope, reviews via PR. Advantage: plugs into existing collaboration infra . Must distinguish editor Copilot, repo-hosted Coding Agent, org policies — permissions, models, deployment differ.

4. Devin — Delegate Bounded Long-Running Tasks

Form: Cloud, long-task software engineering agent. Not line-by-line pairing; delegates "analyze repo → edit → verify → submit PR". Example: 30 legacy interfaces need unified type definitions — hand off scope, compat requirements, test commands, review resulting PR. For PDF bug: give reproducible sample, repo, CI, ask for minimal fix PR. Experience resembles handing work to remote colleague: upfront spec and final acceptance must be precise. Less watching ≠ less final acceptance. Must verify code/dep/log data flow; tasks needing local hardware, restricted networks, or human-judged UI details may not suit.

5. Windsurf — Editor Follows Developer Intent Continuously

Form: AI coding IDE, core interaction = Cascade. Focus: agent keeps up with "what I'm doing now" as developer moves through codebase. Integrates multi-file edits, chat, commands, editor env into continuous flow. Example: ask to explain PDF page-splitting logic → point to render entry "why reuse last export cache?" → adjust only that chain. Suits explore-then-converge development, not fully unattended complex tasks. Like Cursor, evaluate on code navigation, diff review, context continuity — not UI smoothness = fix quality. Migration cost: existing plugins, remote envs, review processes.

6. Google Antigravity — From Single Coding to Agent Workspace

Form: Agent dev environment + terminal workflow. Direction: complex task execution, tool env, multiple work units in unified experience. For cross-UI/backend/test faults, need separated investigation, fix, verification steps with clear execution traces. Distinguish from Gemini CLI : 2026 migration moved personal terminal experience to Antigravity CLI; Gemini CLI repo stays Apache-2.0, enterprise licenses + paid API keys still supported. Don't infer Antigravity from old Gemini CLI personal experience, nor assume open-source project disappeared. Evaluate actual sandbox, plugin interfaces, task persistence, enterprise permissions.

7. Factory (Droid) — Team-Deployed Specialized Agents

Form: Team-oriented software engineering agent platform. Individual: one general agent often suffices. Team doing code review, migration, incident response simultaneously needs per-task instructions, tools, workflows. Factory packages these as Droids. Example: split "PDF export missing page fix" into two team flows — one for locate+edit, another for regression test/check scope/compat. Goal: same task type → same execution rules , reducing ad-hoc prompt variance. Cost: org-level setup — repo auth, identity, logs, template maintenance, quality gates. For 1-2 dev projects, mature general agent is more direct.

8. Amazon Q Developer — AWS Engineering Home Turf

Form: Coding + cloud engineering assistant in AWS ecosystem. Difference shows in context: if PDF export runs on Lambda, missing pages may tie to timeout, memory spike, S3 upload. Q Developer sees app code, cloud config, execution logs together. Author uses it to check if app fix needs IAM/Lambda/deploy config changes, then lands infra-as-code changes. "Explains AWS services" ≠ "auto-gets current AWS account access" — permissions still controlled by identity/config. If project is pure local Python/frontend, ecosystem advantage fades; prefer general agents.

9. Replit Agent — From Prompt to Runnable Prototype

Form: Browser cloud IDE + app generation, run, deploy. Value when no repo exists: "upload image → generate PDF → online preview" — builds files, installs deps, runs app, gives viewable page. Execution + preview in same cloud env, low entry barrier. Prototype runs in hosted workspace ≠ code meets long-term maintenance, migration, security. Later must check project structure, version control, third-party deps, export artifacts, deploy cost.

10. Muse Code — Multi-Agent Terminal, Verify Real Scope

Form: Meta's multi-agent terminal coding product. Public materials show sub-agents in isolated workspaces processing tasks in parallel. Represents explicit product choice: decompose task into multiple work units, not single agent sequentially calling tools. Must verify supported platforms, execution permissions, workspace isolation, failure recovery; compare against same-terminal-entry candidates on identical tasks. Parallel units' correct integration still proven by final diff + test results.

Overseas Open-Source Projects (10 + 2)

Extra value: inspect Harness implementation and extension interfaces. Open code ≠ product quality, ≠ auto-solved sandbox/secret issues. Grouped into three categories: daily-dev-ready, customizable execution kernels, related-but-not-pure-coding-agent systems.

1. OpenCode — Complete Dev Experience on Open Framework

MIT. Form: Open-source Coding Agent, terminal + multiple entries. Contrast with Pi: OpenCode prioritizes delivering a usable Coding Agent product — multi-model, file ops, sessions, workspace. For PDF bug: use like mature commercial agent (search, edit, test) while able to inspect/replace internals. Author uses it for model-vs-Harness controlled experiments : fix repo, task, tool config; swap model service. Observed differences more attributable. Caveat: multi-model support ≠ every model equals on tool calling, long context, pricing. Upgrades need config/plugin compat checks. Natural candidate for devs wanting open-source agent for daily work.

2. Pi — Deliberately Tiny Harness

Form: Minimal terminal Agent Harness, supports SDK, RPC, extensions, tree-shaped sessions. While OpenCode solves "I need to edit code today", Pi asks "which parts of this execution system should I decide?" Small core provides tool calling, session mgmt, context, interaction, extension points. TypeScript Extensions define custom tools, intercept execution events, adjust context strategy; SDK/RPC embed agent into other apps. PDF scenario: not satisfied with generic npm test; need dedicated tool — generate two PDFs, read page counts/hashes, diff, only allow finish if rules pass. Pi lets project-specific validator into execution loop, not just remind model "remember to check". Trade-off: more engineering ownership; some multi-agent/planning/permission patterns need extra config/extensions. Suits Harness research, custom tooling, embedded agents — not necessarily lowest-config choice.

3. Codex CLI — Open-Source Terminal Agent, Separate from Commercial Service

Apache-2.0 core repo; separate productized service/UI. Value: read files, edit code, run commands in repo, with explicit permission/sandbox policies. Example: in separate Git worktree, locate PDF export bug, forbid edits outside repo, demand minimal patch. Boundaries: model choice, run permissions, Git isolation, final code review. Must evaluate separately: (1) local CLI open-source degree, (2) which cloud model, account quota, hosted service actually used. Former inspectable/modifiable; latter bound by service terms. Open-source CLI ≠ all execution/data stays local.

4. Gemini CLI — Open Repo Persists, Personal Entry Changed

Apache-2.0. Execution code still public; good for studying terminal agent tool/session/extension impl; usable under enterprise licenses or paid API keys. Separate from Antigravity CLI : 2026 migration changed personal terminal entry, but didn't revoke Gemini CLI open-source repo. If team has Gemini CLI scripts/extensions, confirm current auth, available models, maintenance scope. If personal user picking terminal product now, compare Antigravity CLI as distinct product — don't assume old tutorial's free login still works.

5. Aider — Every Edit Bound to Git History

MIT. Form: Terminal, Git-native code assistant. Long focused on existing code files, Git diffs, commits to organize AI edits — not building large autonomous agent workbench. For small-scope high-risk changes, this restraint is practical. Example: only allow edits to two pagination functions, want every step Git-checkable. Aider's Git-first approach shows which files changed, why, how to revert. Model may still write wrong code, but Git history gives clearer audit/rollback path. Not best for cloud deploy, browser automation, multi-agent parallel, long unattended runs. Suits incremental-edit, terminal-habit, review-transparency workflows.

6. Cline — Developer Keeps Explicit Approval on High-Risk Actions

Apache-2.0. Form: IDE Agent, also CLI/SDK entries. Design understood from "control sense": model proposes read/edit/execute actions; critical ops presented for developer review. Example: agent wants to delete old PDF cache dir — developer sees why, impact, then approves. For unfamiliar repos, explicit approval reduces mis-operation risk. Doesn't make model reasoning more accurate, but lowers probability of error actions hitting filesystem. Cost: long tasks may frequently pause for confirmation. Fits keep IDE + human review, want agent to actually call tools , not pursue highest unattended automation.

7. Roo Code — Fine-Grained Work Modes on Open IDE Agent

Form: Open-source IDE Agent, from Cline ecosystem. Research-worthy: makes different agent working styles configurable modes. Real dev: "explain structure", "debug bug", "edit code", "review results" need different tool permissions. Research phase read-only; execute phase write; final independent review step. Custom modes add flexibility + config maintenance cost. Read-only analysis → confirm impact → open write is worth verifying; mode names/prompts ≠ actual approval/isolation mechanisms provided by version.

8. Goose — Composable Extensions for External Capabilities

Apache-2.0. Form: Open-source, extension-driven local Agent. Like a workbench gradually assembling capabilities. Beyond read/write code, emphasizes connecting external tools/systems via extensions. PDF bug needs query task records, DB, build logs not in Git — extension approach shines: let different systems' data enter same process via controlled tools. Design separates "what model knows" from "what system allows it to access". Each extension expands tool boundary; convenient but widens permission surface. Evaluate not just extension count, but sources, credential scope, log retention, whether agent can write to external systems. For cross-service task handling, more relevant than pure code completion.

9. Zed Agent — Editor Performance + Native Agent Co-Designed

Form: Open-source editor with built-in Agent. Agent capability formed inside editor interaction, not stuffing independent CLI into window. For heavy navigation, symbol definitions, incremental diff checks, editor responsiveness, panel org, code views are real productivity factors. When heavily comparing entry functions, shared vars, callers, Zed's editor-Agent synergy worth observing; long-task suitability needs separate verification. If already on highly customized VS Code/JetBrains, calculate plugin/debug/collab/language ecosystem migration cost.

10. Continue — Cross-IDE Existing Impl, Confirm Maintenance Status

Apache-2.0. Form: Open-source CLI, VS Code ext, JetBrains plugin; official repo now read-only, 2.0.0 called final version . Teams with locked-in IDEs (by language/plugins/debuggers) don't want to rebuild env for Agent. Continue covered this with CLI + two IDE plugins, leaving inspectable/modifiable impl. Must separate this status from still-iterating projects. If half team on VS Code, half JetBrains, existing version still usable for studying cross-editor rules, model integration, context config; but adopting as new long-term team standard means owning compat, security fixes, future maintenance. Official repo suggests JetBrains users prefer Continue CLI over plugin. Illustrates: open-source list can't just check license + historical features; maintenance status directly changes adoption cost. Also mentions OpenHands (open software dev agent platform + execution env) and SWE-agent (auto-resolve repo issues, tool interaction, evaluation) for public reproduction experiments or fault-fix trajectory research — goals don't fully overlap daily IDE use.

Four Domestic Open-Source Projects

Qwen Code & Kimi Code CLI target terminal dev; DeepSeek Harness opens runtime composition; Trae Agent suits software engineering agent research/evaluation. Cross-compare with OpenCode, Pi, Codex CLI by responsibility — not just model origin.

1. Qwen Code — From Model Ecosystem to Configurable Dev Executor

Apache-2.0. Form: Open-source Coding Agent, terminal + programmatic access. Mainline: not just drop Qwen model into terminal chat, but let it read repo, call tools, edit code, run tests, incorporate developer project instructions into persistent session. Provides multi-model/service connections, gradually forming tool extensions, Skills, MCP, sub-agents. Docs show Plan, Approval, Auto-Edit permission modes for stepwise risk-based op range. Author's controlled experiment: fix repo, task, tool config; swap model endpoint to compare Qwen series vs another compatible model on PDF missing-page task — more explanatory than swapping model+IDE together. If sub-agents investigate pagination logic and test coverage separately, must verify actual effective permissions of parent vs child; "read-only" config ≠ child agent name/prompt. Note: configurable multi-model ≠ every model equals on tool-call stability, long context, price; permission modes ≠ true OS sandbox. For devs valuing domestic model adaptation, open-source auditability, CLI workflow — compare alongside OpenCode, Codex CLI, not siloed as "domestic alternative".

2. Kimi Code CLI — Continuous Dev Tasks in Terminal Session

MIT. Form: Open-source terminal Coding Agent. Reads/writes project files, runs shell, searches repo/web, decides next op from results — not just "model plugged into terminal" but full tool-call+feedback loop. Repo docs cover session continuation, interactive approval, config, IDE protocol access; suits Git/SSH/CLI-habitual devs. Example: PDF export fault debugged two hours, excluded cache, pinned async write-page issue — want to continue next day without new session re-learning whole repo. Session state + resumption > "one-shot generation speed". Also want to run project tests in terminal, collect errors, edit code — comparable to Pi, Claude Code. Clarify old vs new: early Kimi CLI archive vs later Kimi Code CLI development judged by respective repos/versions, not old tutorials. Still check auth, model compat interfaces, op approval, complex task stop conditions. Worth serious trial for terminal-first individual dev.

3. DeepSeek Harness — Execution System as Swappable Plugins

MIT. Form: Plugin-based Agent Harness Runtime, currently developer preview. Highlight: not "how much code for a given task" but Cordis + "Everything is a Plugin" design . Attempts to make model interface, tools, session, loop, persistence, UI all composable components. Unlike installing Skill on ready-made agent, this architecture lets devs directly adjust runtime organization. PDF scenario: product requires internal code search first → read-only diagnosis → custom PDF validator before finish — dev may need finer-grained changes to tool scheduling, session storage, execution nodes. Research value: foundation for building your own agent execution system , not primarily optimizing "open-and-use" IDE experience. Limits: officially marked developer preview, breaking updates; security notes state no security audit yet, not production isolation. Author would test on sanitized repos, containers, minimal perms — not hand production creds just because it's open-source or has approval features.

4. Trae Agent — Researchable, Evaluable Software Engineering Agent

MIT. Form: Open-source Agent + CLI for software engineering tasks. Name close to TRAE IDE but goals distinct. Open-source Trae Agent emphasizes transparent, modular, modifiable, analyzable implementation for SE task execution, tool calling, model configs; facilitates ablation studies + behavioral evaluation. Has independent repo + technical report — a researchable agent engineering project, ≠ open-sourcing entire TRAE commercial IDE. Example research question: when agent fixes PDF missing pages, does performance gain come from model itself or better tool selection/context management? Fix problem sample, adjust execution config on Trae Agent, retain per-round tool traces, compare test pass rate + invalid tool calls. Suits explainable research , not just product demo videos. For product dev, can base custom SE agent extensions but own dep upgrades, run config, test infra cost. If goal = ship web page now, TRAE IDE-type product entry more direct; if goal = modify execution strategy or standardized eval, Trae Agent worth studying.

Summary: Qwen Code, Kimi Code CLI ≈ daily terminal dev products; DeepSeek Harness ≈ low-level runtime design; Trae Agent ≈ SE agent research/experiment. Cross-maps with OpenCode, Pi, Codex CLI, OpenHands — not two separate tech lines.

Domestic Commercial Products (7)

Domestic vendors now cover requirement understanding, task decomposition, tool execution, test, review, delivery — not just code completion in editor. Besides repo-dev products, WorkBuddy, 豆包工作 (Doubao Work) as general workbenches handle some dev tasks, but don't conflate with pro Coding Agents. Providing model/Agent API/plugins ≠ product-level Harness fully open.

1. TRAE — "Requirement to Artifact" in Agent Workbench

Form: Agent-oriented AI IDE + task workbench (SOLO mode). Fits visible dev goal start: "build web tool: upload image, set paper size, export PDF" — agent drives page, code, build, preview. SOLO emphasizes task decomposition + end-to-end delivery, closer to dev workbench than pure completion. Author separates "from-zero tool" vs "fix large legacy". Former: page runs → good first impression. Latter: tests finding historical call chains, preserving behavior, leaving regression tests. For PDF bug given to TRAE, want investigation conclusion, proposed modules, existing-function protection list first — not full rewrite of export. Value: visual task progress + result preview. Limitation: preview success ≠ engineering quality proof . Check code sync, model calls, offline availability, enterprise data policy. TRAE IDE ≠ open-source Trae Agent.

2. Tencent CodeBuddy — Code Dev Extended to Design, Docs, Task Collaboration

Form: IDE, plugins, Agent workflows. Product thinking: not just model edits code, but unify requirements, docs, design artifacts, code dev in collaborative interface. Docs describe multi-task parallel, changed-file view, artifact view/preview, distinguish coding mode vs general work mode. Design-to-frontend: artifact view/preview useful. Legacy engineering: check if recognizes existing modules, continues fixing per test failures, multi-task parallel file conflicts. Model selection, API service, private deployment, permission policies may vary by version/enterprise plan — confirm item by item before purchase.

3. Qoder / Qoder CN — Emphasize Plan, Execution, Delegation Continuity

Form: AI IDE, CLI, task workbench. Focus: not just lines near cursor, but task from understanding → decomposition → delivery. Fits well-bounded dev work: "keep original export API, fix pagination mess, add three regression samples". Developer reviews task plan first, then agent implements, finally centralized delivery verification. vs TRAE: compare not UI prettiness but complex task continuity when plan changes, tests fail, execution interrupts. For multi-year legacy projects, locate relevant files first > generate shiny demo project. Qoder ≠ Qoder CN — different product systems, accounts/tasks/data not interoperable; features, service regions, versions need separate verification. Commercial service multiple entries ≠ all runtime source open, ≠ same model quotas/security policies across accounts.

4. Baidu Comate — Advance Agentization Inside Existing IDE + Enterprise Code

Form: IDE plugin, AI IDE, coding agents. Fits entry from existing dev env + enterprise codebase. Teams may not want to switch editors, nor hand code to fully independent cloud task system; need project understanding, smart edits, test, code review gradually fused into familiar IDE. Example: PDF issue touches frontend button, Java service, DB records, old interface doc. Evaluation not just "can complete a method" but how it retrieves project context, accurately cross-file locates, controls change scope, fixes confirmed by unit+integration tests. Enterprise real difficulty: legacy complexity — repo scale, dep versions, internal permissions, process integration often harder than code gen. Author puts Comate in legacy codebase maintenance bucket with Cursor, Copilot, CodeBuddy — not just zero-to-webpage demos.

5. Huawei Cloud CodeArts — Closer to Enterprise R&D Governance + Codebase Engineering

Form: AI IDE, plugins, CLI for individual + enterprise R&D. Large legacy repos: codebase indexing/retrieval is product focus. If project runs in strict-access team env, selection must ask: what code can agent see, what commands can it run, can it leave audit evidence — not judge by "enterprise-grade" label. Example: export service on internal network, source/build artifacts/test logs cannot enter public cloud. First clarify deployment form, index location, model call data path, permission isolation — then compare agent's pagination defect location ability. Only authorized + audit-record-retaining auto-edits enter formal R&D process. Not saying enterprise tools inherently strongest at fixing, but they address org requirements consumer agents don't default-solve. Whether CodeArts meets specific org's domestic/private/on-prem standards must be verified against corresponding version, deployment plan, security docs — not inferred from product name.

6. Tencent WorkBuddy — Office Tasks Extended to Code Dev

Form: General AI workbench covering office, code dev, design tasks. In Tencent matrix, CodeBuddy and WorkBuddy both touch code but entry focus differs. CodeBuddy: IDE-centric project understanding, file edits, change review. WorkBuddy: from natural language task, calls tools, processes authorized local files, provides frontend domain experts. For small page or stitching data-organizing/UI-making/code-gen into one task, WorkBuddy candidate. If task = maintain multi-year history repo, still separately verify call-chain location, diff control, regression test run — don't equate with CodeBuddy on codebase maintenance just because it generates pages.

7. Doubao — Separate Doubao Work from Doubao MarsCode

Doubao Work: multi-productivity-task Agent workbench. Doubao MarsCode: AI coding assistant + cloud IDE. Writing just "Doubao" misses two distinct entries. Doubao Open Platform supports skills/plugins into Doubao Work; plugins can wrap MCP/CLI; code/app delivery is one task Work may undertake. MarsCode originally faced devs directly with completion, explain, debug, cloud env. MarsCode plugin renamed to TRAE Plugin → product lineage with TRAE above, not mechanically two unrelated new products in 2026 selection table. If goal = stitch multi-source data/tools into app prototype, observe if Work's delivered code exportable, locally rebuildable, Git-integrable. If goal = continuous edits in existing repo, prioritize verifying TRAE or similar dev tools' project understanding, test feedback, change review. Doubao model, Doubao Work task entry, MarsCode/TRAE programming product line = three different layers — don't merge compare because all carry "Doubao" or use related models.

Systems Not to Mix into Coding Agent Rankings

General agent systems: OpenClaw (multi-channel personal assistant), AgentScope, Coze Studio, Dify (Agent app dev/orchestration). They have model routing, tool calling, continuous flows but don't center on code modification in Git repos . Example: "receive ticket → search KB → generate reply → escalate human" → Dify/Coze natural; study agent role collab/tool exec → AgentScope framework; controlled tasks via messaging channels → OpenClaw. If primary deliverable = locate PDF missing page → modify source → run tests → submit PR → pick Coding Agent first. Coding Agent proven by runnable code, tests, diffs, review records; Biz Agent platform evaluated by biz process results, API behavior, KB retrieval quality, human takeover mechanisms. Combinable but different acceptance objects.

Validate Candidates with Three Dev Tasks

Don't run all 30 products on same question. Filter by task type, then evaluate shortlist with identical constraints.

Scenario A: PDF Export Missing-Page Bug in Legacy Project

Traits: existing repo, must not break existing, needs cross-file debugging, result proven by regression tests. Pick 2-3 terminal agents (Claude Code, Codex CLI, OpenCode, Qwen Code, Kimi Code CLI) + 1-2 IDE agents (Cursor, Cline, TRAE, CodeBuddy, Qoder, Comate). Not that tools are identical, but answer two questions: does terminal continuous execution save repeated instruction time? Does IDE incremental review help avoid wrong edits? Task spec with clear boundaries (see article for full markdown): locate cause, reproduce, minimal fix; constraints: no delete existing formats/config, only edit src/export/ & tests/export/, report cause+planned files first, cover single/multi-page/continuous export test cases, run existing tests (report missing env, don't fake "passed"), submit file list, diff summary, test results, remaining risks. Stop conditions: cannot reproduce, two same blocking errors, need to breach dir/permission boundaries → pause and ask. Acceptance: author independently runs git status --short, git diff --check, npm run typecheck, npm test — these check change traces, whitespace/patch format, static types, existing tests. They don't prove PDF bug fixed. Must have real regression tests asserting output page count, content, continuous export consistency. If original lacks PDF regression test, implement it first, keep before/after failure evidence. That's "demo delivers promise": tool claims "fixed", acceptance must prove it.

Scenario B: Build Deployable Small Tool from Zero

Traits: clear-ish req, no existing repo; need quick UI, logic, preview env. First group: Replit Agent, TRAE SOLO, CodeBuddy, Qoder, Cursor — easier to observe product diffs from req to initial engineering. Pi, DeepSeek Harness, Trae Agent (customizable execution frameworks) not necessarily fastest start — still need to configure run tools/product UI. WorkBuddy, Doubao Work as supplemental, especially when req includes data processing, page gen, other office delivery. Compare by submitting same runnable project, not just workbench preview. Doubao MarsCode plugin lineage under TRAE product line, not double-counted. Acceptance card: files locally rebuildable? project installable from clean env? exported PDF correct? invalid input handling? hardcoded secrets? code independently migratable? Avoid conflating product demo with actual delivery.

Scenario C: Internal Repo + Strict Data Boundaries

Traits: fine-grained access, log retention, source may not leave intranet, involves cloud resources/internal APIs. First do environment + compliance screening , then compare agent coding ability. Investigate enterprise plan's actual data flow, available sandboxes, identity auth, audit records, model deployment location. Domestic: prioritize Huawei CodeArts, Comate, CodeBuddy, Qoder enterprise plans. Overseas: GitHub Copilot, Factory, Amazon Q Developer, plus self-deployable/modifiable OpenCode, Codex CLI, Qwen Code, DeepSeek Harness. No "open-source passes, closed-source fails" rule. Open-source CLI running locally may still send code to remote model; commercial tool with compliant enterprise deployment may satisfy specific org boundary. Real evidence from deployment arch + tested logs, not marketing headlines.

Open vs Closed: Eight Decision Dimensions

Execution Loop — What to actually verify: Can it search, edit, run tests, read failures, continue? Common misjudgment: Supports Agent mode ≠ reliable verification.

Task Interface — What to actually verify: IDE, CLI, cloud delegation — which fits team habit? Common misjudgment: Same model in different entries ≠ same experience.

Project Context — What to actually verify: Reliable understanding of existing repo, rules, history? Common misjudgment: Large context window ≠ always retrieves right files.

Permissions & Sandbox — What to actually verify: How are file write, shell, network, secrets controlled? Common misjudgment: Ask confirmation ≠ strong isolation; local run ≠ no data egress.

Change Review — What to actually verify: Diff, test logs, PR, rollback path? Common misjudgment: "Done" ≠ acceptance evidence.

Openness & Portability — What to actually verify: Core repo, extension interfaces, model routing, session migration? Common misjudgment: Multi-model support ≠ full equivalence across models.

Execution Cost — What to actually verify: API usage, subscription limits, machine + human review time? Common misjudgment: Free framework ≠ free run; paid sub ≠ unlimited use.

Ongoing Maintenance — What to actually verify: Community activity, version compat, enterprise support, upgrade path? Common misjudgment: GitHub Stars ≠ stability proof.

Author adds repeat experiments : same task multiple runs, record success rate, time, failure causes, human interventions. Single success may be lucky random path; single failure may be model quota, test env, permission config. To assess Harness quality, fix model, repo version, task description, tool permissions, time budget. Practitioners need not do academic benchmarks, but can't decide software procurement + data security from one promo video.

Closing

Product can search, edit, run commands — that's just entry ticket. Real trial: does it hold directory/permission boundaries? Keep failures in records? Do edits survive independent test + review? Pick entry by task first, then compare 2-3 candidates on same repo, same constraints, same acceptance method. Open/closed, product origin affect extension, procurement, deployment choices; final team fit depends on execution traces, code diffs, human review cost.

Article ends with categorized official links for all mentioned tools (overseas commercial, overseas open-source, domestic open-source, domestic commercial, general agent platforms).