MonkeyCode Under Parallel Tasks: 패치는 여전히 기본 커밋을 알고 있습니까?

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.

Define four invariants

1. Every result is associated with immutable base A.
2. X cannot observe Y’s uncommitted/generated files.
3. Each task changes only its allowed scope.
4. Branch drift never changes a base silently.

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

Enter fullscreen mode Exit fullscreen mode

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"

Enter fullscreen mode Exit fullscreen mode

unknown is honest observation, but may fail your adoption gate.

Test isolation before composition

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

Enter fullscreen mode Exit fullscreen mode

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?