Is it worth splitting work between two AI sessions once setup, integration, and repairs are included? A small list app was prepared to investigate that question, but no measured run with AI implementation workers took place (NOT RUN). The comparison stopped before it began because access restrictions, usage and stopping controls, and real-browser verification had not been established for the way the AI sessions would actually be run. This article explains what would need checking to answer the question, and what limitations the offline preparation exposed. It offers no answer about speed.
In this article
Define completion for both features
The prepared task was to add search and category filters, plus CSV export, to a six-row list. CSV is a format for storing table data in a text file. The two features shared this requirement: export only the rows visible on screen, in the same order. If a search finds nothing, the CSV should retain its header and contain no data rows. Clearing the filters should restore the full list.
This is only a summary of the acceptance requirements. Search had to trim spaces around the query and match it anywhere in an entry's label without distinguishing case; category matching had to be exact, and both conditions had to hold. The requirements also covered preservation of zero values, Korean text, quotes and embedded newlines; CSV line endings (CRLF) and text encoding (UTF-8 without a BOM); preservation of input and test files; and real downloads and checks for console errors.
There was also a requirement about code structure: the display and export had to use the same function to select visible rows. Keeping two separately copied rule sheets with the same content is different from both features consulting one shared sheet. Matching outputs on a few examples do not prove that the same function was used. Checking behavior and inspecting code structure are separate tasks.
This shared requirement matters because separate working folders still leave points where the work must come together. In this design, both roles could edit the same app.js file, and the display and export had to use the same row-selection function. Git worktrees let one repository have multiple working directories while sharing some repository information. Git documentation For this design, separate folders were therefore not treated as proof that access to other working copies was blocked.
Even when files merge without a conflict, their combined behavior can be wrong. One study distinguished textual conflicts from build and test failures after integration. It studied human software collaboration, however; it cannot be used to infer error rates or timings for AI work. Brun et al., 2011
The planned comparison: time until the same checks pass
The design called for comparing one session implementing filtering and then export with two sessions implementing the features separately in their own copies. Two datasets were prepared: an equipment list and a reading list. The planned order was sequential then parallel for the first list, and parallel then sequential for the second. All four planned conditions—each approach on each of the two lists—remained unrun.
Completion meant passing the same full set of checks, not receiving a worker's “done” message. The checks covered search and reset, agreement between the screen and the file, an actual download, and preservation of existing behavior. If a limit was reached before a pass, the plan was to record time to stopping and unresolved checks, not a completion time, and retain failures and unrun outcomes across all four conditions. Each condition had a maximum of 30 minutes, with at most two correction cycles of three minutes each including rechecking. There would be no replacement run to obtain a better result.
Total elapsed time would include setup for each condition, waiting, integration, checks, repairs, and rechecks. Time spent building the shared data and the checking tools would be reported separately. Total elapsed time, the elapsed span of the worker phase, and the sum of individual worker durations would be recorded separately. The total includes preparation, integration, and checks outside the worker phase. Summed parallel worker durations count overlapping time twice, so that sum alone cannot establish actual overlap. Work by the coordinator—Codex, the AI tool assigned to combine the two results in this design—would also be distinguished from a person's manual intervention.
The design allowed for the possibility that shorter elapsed time could still consume more usage. Exposed usage would therefore be recorded separately, with its units and coverage; hidden usage would remain “not exposed / unknown.” This is not a measured increase or multiplier.
Two open windows would not qualify as parallel work. The design required overlapping work intervals and records of substantive progress from both sessions within that overlap. Even that would not prove simultaneous computation inside the provider's servers. If delayed records or queueing made useful overlap unverifiable, the parallel comparison would remain not-run, while already-started work would be preserved with its time to stopping and consumed usage. No artificial waits would be used to manufacture overlap.
The sequential session would retain the earlier task's context; the parallel sessions would start separately without seeing each other's history or results. Both would still receive the full behavioral requirements. Reversing condition order would leave filtering before export fixed within sequential work and integration. It would not remove context differences, what the coordinator would learn from earlier runs, server load, caching, or dataset effects. The coordinator's integration skill would also limit how readily a novice could reuse the procedure.
What offline preparation revealed about the checking tools
What was actually built was two synthetic datasets, expected outputs and reference implementations, task instructions, and tools for checking and recording work. On October 13, 2026, the initial tools passed 19 self-tests. During a separate review, eight kinds of faulty code were then planted in separate reference copies for each dataset, one fault per copy. The checks caught only four kinds on each dataset. These deliberately selected probes do not estimate general error-detection or AI failure rates.
For example, a search that matched text anywhere in an entry's label was changed to match only at the start of it, yet still passed. The prepared search examples could not distinguish the two behaviors. Code that used six fixed rows instead of the rows supplied to it also slipped through. The four escapes were prefix-only search, use of fixed global rows, rows embedded literally in code, and reset without clearing the controls. Incorrect export selection, a changed function input format, reversed row ordering, and losing zero values were rejected. Passing the checking tools' own tests was not enough to establish that they could adequately reject incorrect apps.
In an independent review on October 18, the revised checks rejected all 16 retained faulty cases: the eight kinds on each of the two datasets. That does not prove that every duplicate implementation was excluded. A separate offline test rejected a copied filter that matched the sample outputs, but complete source inspection and real-browser verification were still required. The reference implementations and a prepared submission for dataset A, exported during offline preparation, also passed the relevant offline checks. That submission was not an AI implementation worker's result, and its pass was not full real-browser acceptance.
The independent review also checked logic for maintaining a stop state using synthetic inputs, within a limited scope. Later, the implementer reran checks for submission integrity, record preservation, and synthetic monitoring; independent review of that additional work was still pending. These checks do not establish that provider-side work ended or that helper programs started by the run were fully cleaned up. They concern prepared code and synthetic inputs, not success rates for AI-built apps or observations of two AI sessions working concurrently. Even if offline checks that imitate a browser pass, they do not verify real input interactions and downloads.
Why the comparison stopped despite further preparation
The October 18 record put known preparation at about 64 minutes: roughly 16 minutes from the original preparation, plus 47.99 minutes charged to a later 60-minute preparation allowance. The final task's 284 seconds were already included in that total. About 12.01 minutes of the later allowance remained before deducting unrecorded coordination and work on the host computer. That unrecorded time and service usage during preparation remained unknown. The roughly 64 minutes is not a completion time for either condition, nor an estimate of how much preparation everyone would need.
The remaining problems went beyond adding a few more test cases. The planned way of running the AI sessions lacked sufficient verification of the following:
- Could the AI be prevented from reading other working copies and private answer materials?
- Could usage be observed during a run so work could stop before a limit, and could provider-side work be confirmed to have ended after a stop request?
- Could each progress record be linked to its session to verify actual overlap?
- Could real-browser downloads, errors, and unexpected network requests be checked, and helper programs started by the run (child processes) be cleaned up?
The preparation record judged that there was no supported plan to close these gaps and complete measurement within the remaining preparation-time allowance. This was not proof of a minimum implementation time. On October 25, the decision was made to write an article about the method. This reflects the preparation limits of this particular comparison design. It does not establish that a particular product cannot support parallel work, or that splitting work is a losing proposition. The measurements are absent, not “zero minutes.”
Questions to adapt for your own work
These questions came from an unrun design using sessions of the same model and two datasets with the same app structure. They are neither a procedure with demonstrated benefits or transferability to other tasks nor a table of experiment results.
| What to write down before a run | Question to check |
|---|---|
The two features' shared requirement |
Which rows, ordering, and empty-result behavior must the screen and saved file share? If a shared function is required, how will you inspect that structure separately from matching outputs? |
Completion checks |
After combining the features, do you check the actual screen and downloaded file? Do the checks also reject deliberately faulty code? |
Time and intervention |
Where will you record setup, waiting, integration, repairs, and rechecks? Do you distinguish model work from human intervention? Do you record elapsed time and exposed usage separately, marking hidden usage as not exposed / unknown? |
Evidence of execution and stopping |
Can you verify access boundaries, actual overlap, usage, and stopping? Will you stop if you cannot verify them? |
Whether splitting the work was worthwhile remains unanswered. A starting point suggested by this case is to define completion and check whether the actual way of running the sessions can provide evidence of access restrictions, usage, stopping, and browser behavior. Closing those gaps would enable only this small design. Even completed runs would need to be read alongside usage and failures, and would not establish the value of splitting other work.
AI assisted with research and drafting. The author reviewed the final manuscript and directed the revisions.
