When a failed coding task cannot simply switch models
I designed Switchyard to assign development tasks to AI models and send changes to independent reviewers. Routing to another provider is useful when one becomes unavailable. An authoring failure needs more care: the first model may already have changed files.
Before another author starts
The next attempt needs a known starting point. In Switchyard, fallback stops when the first author changed files or the file state is uncertain. I can then inspect the work that exists before deciding how to continue.
That leaves room for useful partial work. A failed run does not tell me that its edits are worthless, and it does not establish that they are complete. The files and the task’s requirements determine what can be kept.
Review the change that exists
I give reviewers the requirements and relevant code, including what the author actually changed. Reviewers come from other model families. Different models can still share a mistaken assumption, so I want a finding to identify the condition that causes a defect and a way to reproduce it.
The author should not supply its own independent verdict. Nor should a summary replace inspection of the changed files. I keep review findings and test results with the work so the next decision has evidence behind it.
Completion needs another check
After review and any fixes, I compare the result with the intended change and check the important behavior through its real interface. A generated file can exist while the application still serves an older version. A command can exit successfully without producing the required output.
When the environment prevents a check, I record what remains untested. I make the decisions about the workflow and what evidence is enough to proceed.
Further reading: Google’s code review guide.