For bugs with a finish line
An AI coding agent for bugs, patches and test evidence
Start with a reproducible bug and a clear contract. A useful coding-agent handoff includes the change, the commands that actually ran, their results and the risks that remain, so you can inspect all of it before your normal merge process.
Handoff template
Illustrative, not a recorded run- Brief
- Bug, contract, files in scope
- Command 1
- The test command you named
- Command 2
- Another check you named
- Patch
- Unified diff to read before merging
- Notes
- Root cause, what changed, what was not checked
Every command ends in one of three states. Only the first is a pass.
- Ran and passed
- Ran and failed
- Did not run, with the reason
What comes back is evidence, not just code
A coding task is not finished when code appears. The reviewer needs the change, its boundaries and the checks that ran. The headline promise is a patch you can inspect, not a guaranteed fix: dependencies, runtime limits and weak tests can all stop a clean result, and the report should say when they do.
A unified patch
A focused diff, so you read exactly which lines moved before anything reaches your branch.
Raw command results
Each command you named, with its output and whether it passed, failed or did not run.
Release notes
The visible defect, the root cause, what changed, what was validated and what was not.
Corrected code and tests
The implementation and test files, keeping the public interface you said must stay stable.
What code and environment can the agent access?
Two things can be stated here with confidence: who gets the code agent, and what this page has not verified. Everything else about the coding environment belongs in the product and its docs.
Who has the code agent
Plan access comes from the pricing catalog. Paid plans list the code agent; the Free plan does not. This is a plan-backed Work task, so there is no free coding run to promise.
Free
$0/mo
No code agent. 100 free credits to start.
Plus
$14.99/mo
Lists access to the code agent.
Pro
$29.99/mo
Lists access to ZeroCode, the code agent.
The Code Agent product details page describes the code agent as part of the ZeroTwo desktop app. See pricing for coding task usage for the full plan comparison.
Not published here
These details need engineering confirmation before anyone should rely on them. Check docs.zerotwo.ai or ask in the product.
- Supported language runtimes and versions
- Package-install and network rules
- How code reaches the agent: upload, repository connection or local folder
- Task-size limits
Prepare a task the agent can verify
The clearest tasks state the current behavior, the intended contract and an executable way to tell whether the change worked. This template is a starting point for that brief.
Bug: what happens now vs. what should happen
Contract: the public interface that must not change
Reproduce: one command or a short list of steps
Checks: the exact test commands, in the order to run them
In scope: files or directories that may change
Out of scope: new dependencies, refactors, other modules
Runtime: language and version you actually use
Report back: a result for every command (including failures and
anything not run), the diff, the root cause, remaining risksLeave out
- Secrets, production credentials and customer data. Use a fixture or redacted data.
- Unrelated proprietary code. Share the smallest workspace that reproduces the bug.
- Open-ended goals such as “clean this module up”. Bound the task to one defect.
A bounded task also gives you a cleaner review: one defect, one diff, one set of results.
Which coding workflow fits the job
An agent that executes is not better than autocomplete or a snippet generator at everything. It earns its place when the task has a reproduction and a check, because that is what lets it return evidence instead of a suggestion.
| What differs | Autocomplete in your editor | Answer-only chat or snippet generator | Coding agent with execution |
|---|---|---|---|
| Best for | Finishing the line or function you are already writing | A new function, a regex, an explanation or a one-off script | A bounded bug with a reproduction and a check you can name |
| You provide | Your open file and cursor position | A prompt, plus whatever code you paste in | A brief, the code context, and the commands that define “fixed” |
| You get back | Suggested text inline | Code in a reply | A change set, command results and release notes |
| Who runs the checks | You | You | The agent runs what its environment allows and reports what it could not run. You re-run before merging |
| Main risk | Plausible code accepted without a test | Code written without seeing your repository | A green run on a narrow test that misses the real behavior |
These are general workflow categories, not a review of any product. Individual tools often blend modes; check each vendor's current documentation.
- AI code generator for output-only tasks such as a snippet or a function.
- AI code editor for the editing surface itself.
- AI coding assistant for broader assisted development.
- Compare AI coding workflows when you are choosing between tools.
From failing behavior to reviewable evidence
The order matters. Reproducing first means the baseline is observed, and explaining the cause before editing keeps the fix scoped.
Reproduce the defect
Run the supplied reproduction or test first, so the baseline failure is observed rather than assumed.
Find the root cause
Inspect the relevant code path and explain the cause before touching the implementation.
Make the scoped fix
Change only what the brief allows, keep the public interface, and add no dependencies unless you asked.
Run and package the evidence
Execute the named checks and return the corrected files, the patch, the raw results and the release notes.
What the tests do not prove
Passing a bounded check is evidence for that check. It is not proof that a change is production-safe everywhere, and the agent should say where it stopped.
A green run can show
- The named tests passed in the environment where they ran.
- The behavior you encoded in those tests holds after the change.
- The diff stayed inside the files you allowed, if you read the diff.
A green run cannot show
- That the change is correct for inputs your tests never exercise.
- Integration, security, performance or concurrency behavior you did not test.
- That the change is safe to release in your production environment.
Where the agent should stop
- The failure cannot be reproduced from the brief.
- The fix needs a new dependency, a schema change or a public interface change.
- A check cannot run, so the claim cannot be verified.
Work with your existing engineering process
Review like any other change
Read the diff, the notes and the command output in your usual code review. Reviewer judgment stays with you.
Ask for a revision
If the result is off, tighten the brief or the scope and run another round. Usage varies with repository size, tools, commands and revision rounds.
Ship through your own pipeline
CI, security review and release controls apply as always. This page makes no merge, pull request or deployment claim.
Have a bug you can reproduce and a command that checks it? That is the right size for a first task.
Start a scoped coding taskWhat people ask
Can the agent run my tests?
That is what the workflow is built around: you name the commands, and the agent runs the ones its environment can execute and reports the output. If a command cannot run, for example because of a missing dependency or a service it cannot reach, the report should say so. A check that was not run is not a pass, so look for a result next to every command you listed.
Which runtimes and repository connections are supported?
This page does not publish a supported-runtime or repository-connection list, so it does not guess one. The Code Agent page describes the product as a desktop app, and docs.zerotwo.ai is the place to confirm current runtimes, how code is made available to the agent, and any package-install or network rules. Until you have confirmed them for your stack, start with a small, dependency-light task.
What if a dependency or test cannot run?
Expect a partial result, not a pass. The returned notes should name the command that failed or was skipped and why, and the patch should be treated as unverified for that part. Re-run the check in your own environment, or narrow the task until the agent can run it.
Can I restrict which files change?
You can write the scope into the brief: the files that may change, the ones that must not, and no new dependencies. The diff is how you check it. This page does not claim the restriction is technically enforced, so reject any change that leaves the stated scope.
Does the returned patch merge or deploy automatically?
This page does not promise merging, pull request creation or deployment. Treat the output as a proposed change that goes through your own review, CI and release process.
Explore related workflows
The product page for the coding agent itself.
Where ZeroTwo helps with the rest of an engineering day.
How to choose among coding tools for your task.
Plan allowances and what each plan includes.