Two coding-agent tasks start from commit A
. Task X edits authentication. Task Y edits logging. While both run, a human pushes commit B
.
If the patches do not identify their base, “apply both” is unsafe. Parallel agent sessions are a consistency problem, not only a speed feature.
Here is a black-box experiment for MonkeyCode SaaS, not a claim about its concurrency implementation.
A
.Build a disposable repository:
src/auth.py tests/test_auth.py
src/logging.py tests/test_logging.py
TASK_X_SENTINEL.txt TASK_Y_SENTINEL.txt
Make both tests fail independently at A
.
Task X may edit only auth files; Task Y only logging files. Both are forbidden from changing either sentinel. Record requirement hashes and the full base SHA.
Start both tasks as close together as the workflow permits. While active, push an unrelated documentation commit B
.
Capture:
task_id: "<id>"
requested_base: "<A>"
reported_or_inferred_base: "<SHA or unknown>"
changed_files: []
test_command: "<command>"
test_result: "pass|fail|unknown"
result_revision: "<SHA or artifact>"
drift_action: "none|reject|rebase|restart|unknown"
unknown
is honest observation, but may fail your adoption gate.
Apply X and Y separately to clean checkouts of A
. Check allowed files, focused test, unrelated fixture, and sentinels.
Then evaluate both orders:
A + X + Y
A + Y + X
Run both tests after each order. If only one order works, the tasks have a dependency that must be represented and reviewed.
Now test B + X + Y
. A clean application, explicit conflict, or request to rerun from B
can all be reasonable. Silent base substitution is not.
Finally, create two tasks that deliberately edit the same line. The required property is visible conflict and rerun evidence—not magical automatic merge.
| Observation | Decision |
|---|---|
| Bases clear; isolated patches; both orders pass | Candidate |
| Conflict explicit | Candidate with human merge gate |
| Base unknown | Insufficient evidence |
| Cross-task files appear | Reject run |
| Drift silently changes base | Reject run |
| Combined patch lacks rerun evidence | Block merge |
MonkeyCode's README documents online managed environments plus task and requirement management, making it a practical candidate for this experiment. It does not promise the envelope or semantics above.
Sources: MonkeyCode repository and SaaS.
Limitations: two tasks are not a load test and cannot prove process- or tenant-level isolation.
Disclosure: I'm a MonkeyCode user sharing my own experience, not affiliated with the project. This is one of several independently useful technical articles published by accounts managed by the same operator; it is not an independent endorsement.
Which event should force a restart from a new base: human commit B
, overlapping patches, or either one?