In my Human + AI pair-development system, the human is the constraint.

By constraint, I mean the resource whose capacity limits the throughput of the whole system. In practice, the rest of the system repeatedly waits for this resource's work.

Two ways to help the constraint

  1. 01 / DELEGATE Delegate some of the constraint's work to other resources.
  2. 02 / KEEP ACTIVE Keep the constraint from sitting idle when useful work is available.

AI and the surrounding development harness can take on some of the human's work. The human can stay busy by switching to another task, though every switch requires a context reset.

Consider equally sized tasks with three rounds of 30 minutes of human work followed by 20 minutes of AI work. AI phases can run in parallel; the human can work on only one task at a time. The model assigns two minutes to each switch.

You can feel the cost with a simple experiment. First write the numbers 1 to 30 and then 30 to 1. Next alternate between the two sequences: 1 and 30, 2 and 29, and so on. The alternating version takes longer because each switch requires a small context reset.

With ten open tasks, assume that cost grows to four minutes: there are more terminal windows, more task states to reconstruct, and more opportunities to resume the wrong task. The exact numbers are not important. They represent two assumptions: switching has a cost, and that cost can increase as work in progress grows.

Case 1: favor Task 1

CASE 1 / SHARED CLOCK

Interrupt Task 2 when Task 1 is ready

First result
152 min
Batch complete
234 min
Switching
10 min
Task 1 stays close to serial latency and completes at minute 152. Fragmenting Task 2 creates two later idle periods, so the batch remains open until minute 234.

Case 2: minimize human delay with two tasks

CASE 2 / SHARED CLOCK

Finish each human block before switching

First result
178 min
Batch complete
210 min
Switching
10 min
The human stays continuously busy through minute 190 apart from explicit switches. Task 1 completes at minute 178 and the two-task batch at minute 210.

Case 3: minimize human delay with three tasks

CASE 3 / SHARED CLOCK

Keep three tasks active around the constraint

First result
242 min
Batch complete
306 min
Switching
16 min
All three tasks keep the human constraint supplied with work. The first result moves to minute 242; the other tasks complete at minutes 274 and 306.

Which result should be faster?

The first schedule optimizes Task 1's latency. It finishes at minute 152, close to the fully serial case. The interruptions fragment Task 2, so both tasks are not done until minute 234.

In the second schedule, the human finishes every 30-minute block before switching. Task 1 is delayed until minute 178, but both tasks are finished by minute 210.

Adding a third active task delays the first result further, to minute 242. The remaining tasks finish at minutes 274 and 306. In both the second and third schedules, the human constraint stays continuously busy, but the completion profiles are different.

With two active tasks, the first two results arrive sooner. With three active tasks, the first results arrive later, but the entire three-task batch finishes sooner than it would with a rolling two-task schedule. There is no single definition of faster.

If one result must arrive as quickly as possible, such as a critical hotfix, focus on that task and avoid switching. If the goal is completing a batch or maximizing long-term throughput, the answer becomes less obvious.

Next: To switch or not to switch? Part 2