# Will it work on my codebase? CodeHerder never reads your source. Here is exactly what it needs from your repository, your device, and your coding agent. Source: https://codeherder.com/will-it-work/ Fit CodeHerder never reads your code, so the question isn't really about your language. It's about your setup instead: your repository and your device, plus the coding agent you already run. [Request access →](https://codeherder.com/get-started/#request-access) [See the short answer →](https://codeherder.com/will-it-work/#short-answer) The short answer ## Three conditions, and you likely meet them 1. Your code sits in a git repository CodeHerder drives git. That is the one hard requirement on the code itself. 2. You have a device that can already build and test it A laptop or a small server works, as long as your normal build and test commands already run there. 3. Your coding agent can already work in that language See [/works-with](https://codeherder.com/works-with) for what each supported agent covers today. Meet all three, and CodeHerder can drive the work. The rest of this page explains why. The structural fact ## CodeHerder never reads your code CodeHerder stores task descriptions and costs. It also records events. It coordinates the work, and it does not open a single file in your repository. The agent that reads and writes your code runs somewhere else entirely: on a device you register, in its own isolated git worktree, with your own toolchain already installed. That device and that agent carry your language. CodeHerder does not. See [/security](https://codeherder.com/security) for the full trust boundary, and [/where-agents-run](https://codeherder.com/where-agents-run) for how a device connects. What CodeHerder needs ## From your repository: a clone URL and a branch You enter both once, the same way you'd add a repo to any tool: ``` ch repo create --name my-app --url git@github.com:you/my-app.git --branch main ``` The branch needs to be one the agent can push to. One real limit: the merge stage signs in with your own `gh` or `glab` on the device, so GitHub and GitLab are the hosts it automates today. CodeHerder is never a git host itself; it drives the one you already use. See the full add-a-repo steps at [/get-started](https://codeherder.com/get-started/#path-b). What CodeHerder needs ## From your device: a toolchain and one CLI - Your toolchain, already installed Whatever you already build and test with. CodeHerder installs nothing on your behalf. - The harness CLI The coding agent you'd run by hand anyway: Claude Code, Codex, or another tool from [/works-with](https://codeherder.com/works-with). Three ways to bring that device online, including one with no CLI install at all: see [/where-agents-run](https://codeherder.com/where-agents-run). Capabilities ## Your language is a tag, nothing more CodeHerder ships no per-language feature list, because it needs none. Capabilities are free-form strings you write yourself. Tag an agent `rails`. Tag a task `rails`. CodeHerder ranks the agents carrying that tag highest for that task. Add `mobile`, `cobol`, or whatever word your team already uses; CodeHerder never checks the string against a fixed list. See how capability matching decides placement at [/how-it-works#capabilities](https://codeherder.com/how-it-works#capabilities). What makes a task go well ## Three things any stack can give a task - A command that tells the agent it passed A test, lint, or typecheck run the build stage can run and read the result of, in any language. - A clear description of "done"Written acceptance criteria the plan stage can check its work against before a line of code exists. - A scope one person could hold in their head One control, one endpoint, one bug. See [/starter-briefs](https://codeherder.com/starter-briefs) for what that looks like written out. None of these are new claims. [/starter-briefs](https://codeherder.com/starter-briefs) and [/verification](https://codeherder.com/verification) already say them; this page just answers the fit question they leave open. Where it is not a fit yet ## The limits, said out loud - CodeHerder is not a git host Your code stays where it already lives. CodeHerder coordinates the work. It does not store the repository. - It needs a device you register No device, no agent. See [/where-agents-run](https://codeherder.com/where-agents-run) if that first step is the blocker. - The merge stage automates two hosts today GitHub and GitLab, through your own signed-in `gh` or `glab`. A different host needs its own path in first. - Nobody leaves the loop A human still approves the plan and the result. CodeHerder removes the busywork in between, not the person. FAQ ## Questions people ask before connecting their first repo Does CodeHerder support my language? CodeHerder never reads your code, so it has no language list of its own. The real question is whether your coding agent already works in that language. See /works-with for what each one covers. What if my code isn't on GitHub or GitLab? You can still register the repo and run every stage up to merge. The merge stage itself signs in with your own gh or glab on the device, so GitHub and GitLab are the hosts it automates today. Do I need to install anything special for an unusual stack? No. The agent uses whatever toolchain is already on the device you register. If your normal build and test commands run there today, CodeHerder can drive them. Can I route a Rails task toward the agent who knows Rails? Yes. Capabilities are free-form strings you choose. Tag an agent and a task with the same word, and CodeHerder ranks that agent highest for the task. Does CodeHerder read our source code to make any of this work? No. CodeHerder coordinates task descriptions and stage transitions, and it tracks cost data. The agent that reads and writes your code runs on your own device, in its own isolated git worktree. What if my repository is private, or behind a VPN? That's the point of running the agent on your own device: it reaches your repository the same way you do, over your own network, with your own credentials.