Should you evaluate Kandev?
Kandev supports configurable workflows, agent profiles, runtimes, and review gates. Evaluate it when coordinating parallel coding-agent tasks and reviewing their changes has become work of its own. Its documented workspace brings conversations, files, a terminal, browser preview, and Git changes together.
If one agent and your existing Git tools cover the job, another application adds configuration to maintain. The adoption question is whether Kandev's task and review model solves a coordination problem you already have.
What our sandbox recorded
Our run on September 29, 2026, at commit e99ac10 recorded installation success after 73 seconds. The stored harness records a 14-second build failure with exit code 1. The full measured SHA is e99ac10dbcde5a8febc947d4024ca3ce5fa3e593.
The selected project was the apps pnpm workspace. The recursive build reached the Tauri desktop package, where cargo metadata could not execute because the command was unavailable. The log identifies that package as @kandev/desktop@0.96.0. This establishes a desktop-build prerequisite gap in our sandbox; it does not establish whether the backend, web application, or packaged distribution works with the documented toolchain.
Tests were skipped because the harness detected no test script in that workspace. This is neither a test failure nor evidence that the repository has no tests. The README documents make test for backend and web tests, but our run did not execute that path. There is no passing-test total to report.
The stored dependency summary records 924 packages and 943 MB on disk. The raw install tail separately reports Packages: +923 and completion in 34.4 seconds. We retain the harness's 73-second installation duration and dependency summary rather than substituting those package-manager figures. The supplied records do not reconcile their counting and timing boundaries.
Our harness records command outcomes, exit codes, elapsed times, and log tails. Installation success does not demonstrate a working CLI deployment or agent workload. We did not validate live sessions, credentials, remote executors, task handoffs, pull requests, backup restoration, or deployment. No audit result or scanned-package count is attached, so advisory status and scan coverage are unknown.
The MrKeyoor testing methodology explains the site's measurement approach and limits. Its supplied October 31 extract provides provenance context; it does not establish that September's run used the current procedure unchanged. This correction uses the existing stored run and includes no new execution.
Which installation route fits an evaluation?
Kandev's native Go binary embeds the compiled frontend and serves the UI and API without Node.js at runtime. The README at the measured commit says Homebrew, Scoop, release archives, and the desktop app use that binary directly. The npm/npx distribution requires Node.js for its launcher.
A documented packaged route is a reasonable starting point for evaluating the workflow. Source contributors instead need the pinned Go 1.26.0, Node.js 24, and pnpm 9.15.9 toolchain, alongside the desktop build's requirements. Neither route received application-level validation in our run.
The v0.91.0 release warns that its macOS and Windows desktop installers are unsigned development builds. That warning belongs to the artifacts in the v0.91.0 release notes. It does not establish the signing status of other releases or identify the measured checkout as v0.91.0.
What do review gates and worktrees provide?
Kandev documents isolated Git worktrees for concurrent tasks and configurable workflow steps for agent handoffs. The feature guide also describes agent permission settings, reusable secrets, and executor profiles containing scripts, environment variables, and credentials.
Worktrees separate task edits; they do not establish isolation for credentials or agent permissions. Repository setup can copy selected ignored files, including .env files, into a new worktree. Before expanding a trial, inspect those settings and verify that your chosen review step stops the workflow where you expect. These are evaluation steps, not controls our sandbox verified.
Office mode remains experimental according to the current README, which says it is disabled by default in production and is not yet a stable production contract. Keep that autonomy layer separate from a decision about the documented task workflow.
Which alternatives address the same decision?
T3 Code provides mobile, web, and desktop control of agents on your machine. Consider it when access to existing local agents from several devices is your main requirement. Its README says the project is very early and users should expect bugs; the supplied evidence does not establish greater simplicity or reliability than Kandev.
OpenHands Agent Canvas supports multiple coding agents across local, remote, and cloud backends. Its repository also documents scheduled and webhook-triggered automations. Evaluate it as a replacement candidate when backend selection and automation triggers drive your choice. The current source does not support describing it as limited to its own agent.
Vibe Kanban's README says the project is sunsetting. It still describes Kanban planning, agent workspaces, diff review, and pull requests, but resolve its maintenance path before selecting it for a new installation. The supplied extract gives no shutdown timetable or migration destination.
Coding agents that Kandev runs are complements to the orchestration interface. Choosing an agent provider and choosing the application that coordinates its tasks are separate decisions.
What do the ratings mean?
Setup ease is 3/5, documentation is 5/5, and maturity is 3/5 under the rubric below; community remains unassessed. These are editorial assessments of the supplied evidence, not runtime measurements.
The scale is 1 for substantial documented obstacles, 2 for major gaps, 3 for a usable evaluation path with material caveats, 4 for strong evidence with limited gaps, and 5 for comprehensive evidence within the stated dimension. An unsupported dimension receives no numerical rating.
Setup has a documented packaged route, but our source build failed and agent configuration remains necessary. Documentation receives 5 for the breadth of installation, workflow, executor, MCP, and system-management coverage in the supplied extracts; we did not verify every instruction. Maturity receives 3 because the documentation describes operational features while Office remains experimental and our run provides no application-level validation. Release contributors and contribution invitations do not establish sustained participation or support responsiveness.