Two AI workers finish at the same time. One changes the purchase-order approval rule; the other writes tests against the old rule. Both report success. The project owner now has two plausible results and a new reconciliation job. Parallel work only helps if someone has decided which decisions are shared and which outputs can be produced independently.
The hypothetical P1 policy uses the final total in Thai baht after discounts and tax: a manager approves up to and including THB 50,000; a director approves above THB 50,000. An amount edit invalidates prior approval. This is an example policy, not an Odoo default.
This is episode 5 of a series about organizing AI-assisted engineering. We continue with a hypothetical purchase-order approval system. The team, records, work orders, and outcomes described here are teaching examples, not a customer deployment or the author's experience. The question is practical: when should someone work alongside AI, and when can they assign a bounded job and review it later?
Resolve the business decision before dividing the work
P1 already establishes that changing an amount invalidates approval. The business owner has not yet settled whether changing an internal note should preserve approval. This additional question changes system behavior. Splitting it among several workers would distribute the uncertainty rather than resolve it. A person responsible for the approval policy needs to decide, with AI helping list cases and expose conflicting assumptions.
Working alongside AI is useful here because each answer may change the next question. The developer can inspect the existing behavior, discuss an example with the business owner, and ask AI to trace the affected code. Close supervision still needs evidence. Watching a confident explanation appear on screen does not establish that it matches the application.
For this hypothetical exercise, the owner extends P1 to P1.1: changing the amount still invalidates approval, while changing an internal note does not. That is an example policy for this case, not a general purchasing rule. Record the decision and its examples before anyone implements it. If the owner has not made that decision, the correct output is a question and its consequences, not a guessed rule.
Assign an output that can be inspected
A bounded assignment says what the worker must deliver and where its authority ends. “Improve approvals” leaves almost everything open. “Add tests for the agreed amount-change rule using synthetic records, without changing the rule implementation” creates a result that another person can assess. A worker can still discover that the assignment is wrong. The handoff needs a way to stop and report that discovery.
| Field | Assignment |
|---|---|
| Deliverable | Tests showing that an amount change invalidates approval and an internal-note change preserves it. |
| Allowed work | Synthetic fixtures and the assigned test file in an isolated working copy. |
| Excluded work | Approval policy, application permissions, live records, deployment, and unrelated cleanup. |
| Evidence | Change list, test command and result, inspected cases, unresolved assumptions. |
| Stop condition | Existing behavior contradicts the agreed rule, or a required change falls outside the assigned files. |
| Review owner | The integration developer checks the result; the business owner resolves policy questions. |
The assignment is a communication artifact. It is not an access-control system. A prompt saying “do not touch live data” cannot revoke a credential. Use a working environment and tool permissions that match the permitted work. If a worker can access a live database, the boundary is already wider than the assignment suggests.
Separate files only after separating dependencies
The team can give one worker the approved test cases and another the wording for an approval-status message. Each gets a distinct file area and an explicit output. The message worker must use the same agreed meaning of “approval invalidated.” If the wording requires a new status or changes when a button is available, that is a dependency to return to the integration owner, not a harmless copy edit.
Keep the rule implementation under one owner for this change. Tests and explanatory text may proceed alongside it once their shared assumptions are stable. A small task with many hidden dependencies can be harder to delegate than a larger task with a clear boundary. The number of files is a clue, not a reliable measure of independence.
One person must own integration. That person checks the combined changes against the agreed policy, resolves conflicts, and reruns the relevant checks on the combined result. Tests that passed in separate working copies may fail together. Two workers may also repeat the same mistaken interpretation. Independent output is useful evidence, but agreement alone does not make it correct.
One implementation owner; parallel supporting work
Concepts informed by The New SDLC With Vibe Coding, Addy Osmani, Shubham Saboo and Sokratis Kartakis (May 2026). Author’s article · Full public paper
Review the boundary as well as the result
Ask the reviewer to inspect what changed, why it changed, and what the evidence leaves open. A convincing screenshot shows a visible state. It does not demonstrate that another user lacks access or that approval is invalidated after a later edit. A test result should identify the cases it covers. An evaluation pass supports behavior within its tested scope, not every possible situation.
Review effort should follow the risk of the change. Correcting a label and changing an authorization rule do not deserve the same treatment simply because both arrived from an AI worker. For the rule, the reviewer needs enough application knowledge to challenge the assumptions and examine failure paths. Assigning all review to the cheapest available model would ignore that responsibility.
The source paper describes close direction and asynchronous delegation as different working modes. Its discussion of unfinished edge cases is useful, but its “80% problem” should not become a planning ratio. A feature that looks almost complete can still be blocked by one permission error or an integration assumption. Do not budget the remaining work from how finished the screen looks.
Start with one handoff you can evaluate
For the next approval-system change, write the work order before choosing how many workers to run. Mark unresolved business decisions, shared files, and the person who can answer a blocking question. If two tasks depend on the same unresolved decision, keep them together until it is settled. If the reviewer cannot tell what a satisfactory result looks like, narrow the assignment.
A useful first experiment is one implementation owner and one bounded supporting assignment. Record the time spent preparing, checking, and combining the work, as well as the time the workers spend generating it. Expand delegation only when the completed handoff makes the next decision easier. More simultaneous activity is not itself evidence that the team has less work.
Conceptual reading: The New SDLC With Vibe Coding by Addy Osmani, Shubham Saboo, and Sokratis Kartakis, May 2026. The purchase-order examples, work orders, and pilot design are original proposals, not reported research results from the paper.
Further reading from the source author on planning, review, and responsibility: Addy Osmani, Agentic Engineering.