BLOG / / 2 MIN READ / THE ELISHA TEAM
Most coding assistants hand you a diff and stop. The diff looks finished — it is syntactically valid, it is on topic, it usually even compiles. But the work isn't done, because the part nobody wants to do is still yours: pull the branch, wire the change into the files that actually exist, run the suite, notice the two callers the snippet forgot, write the regression test, push it.
We kept watching that gap swallow the time the assistant was supposed to save. So we drew the line somewhere else: the run isn't over until there is a branch pushed and a pull request open against the default branch, with the test suite green on it.
What that forces
Choosing the pull request as the unit of work is not a packaging decision. It forces everything upstream of it to be real:
- The agent has to clone the actual repository, not reason about an idealised version of it.
- It has to run the project's own test command, and deal with what comes back.
- It has to reproduce the bug before claiming to have fixed it — otherwise there is nothing to prove the patch did anything.
- It has to name the files it touched, because the diff is right there.
A snippet can be plausible. A pull request with a red suite is just wrong, visibly, in front of everyone.
The review still belongs to a person
Nothing merges itself. The blast radius of a run is a sandbox that gets thrown away, a branch, and a pull request — which is exactly the surface your team already knows how to review. If the change is wrong, closing it costs one click and nothing is lost.
The worst thing a run can produce is a pull request nobody merges.
That property is what makes it reasonable to let an agent work unattended at all. Autonomy is only frightening when the failure mode is unbounded.