Every software engineer knows the Agile mantra: “Stop starting, start finishing.” For decades, it was gospel. The logic was simple: each work item you juggle increases time-to-delivery for all of them, plus you lose time switching between tasks.
Each day, the smiley gets one step closer to completion
When more customers come along who want their own smileys, this smiley-maker simply creates them in sequence:
Sequential: Orange done by day 3, Pink by day 6, Yellow by day 9
This is all well and good, but in the real world things aren’t always this easy. Each customer might want their smiley started ASAP, as it’s very critical. So another smiley creator might start on yellow’s first, then start purple’s, etc.
Interleaved: All three start early, but none finish until day 7-9
Hooray! The same 3 smileys get produced at the end, and now we can tell all three customers that their smiley’s have been started right away to placate them. Do you see the issue? The first method would’ve gotten yellow and purple their smilies much sooner than with the second. So while overall productivity stayed the same, the time to delivery for each customer was 2-3x worse!
Now lets take into account the cost of context switching. The first method allowed for the smiley-maker to only context switch once per project. However the second forced them to switch between every step.
Context switching (red gaps) adds wasted time between every task switch
Now, in this more realistic example, not only is the time to delivery for each customer worse as before, but the overall productivity is also worse. Now the saying “Stop Starting, Start Finishing” makes a lot more sense!
So far, this has been gospel. Sequential work, minimal context switches, clear WIP limits. Every productivity framework in software engineering traces back to this truth.
And then AI-assisted development arrived and broke the fundamental constraint.
In computing terms, we can think of it like multithreading vs multiprocessing. Where before you were limited to a single core (yourself) and could choose to either process sequentially or to interweave tasks, now you have access to multiple brains. It’s now possible to multiprocess.
Parallel: All three processed simultaneously - everyone gets their smiley by day 3
With parallelism, you can get the best of both worlds — Every customer gets their task started ASAP, and they all finish in the shortest possible time.
But what about context switching? Even though the AI can process a task end-to-end, there is still the work of kicking it off and wrapping it up that falls to the human. Well lets factor that into our example:
Human orchestration (init & delivery) becomes the bottleneck - AI does the building
The Bottleneck Moved
Notice what happened: the bottleneck shifted. While previously initialization and delivery were still part of the process, the actual building was the slowest part and therefore the bottleneck. But in this parallel world, building is no longer the constraint — orchestration is.
Starting tasks, reviewing output, providing context, making decisions: these are now the steps that limit your throughput. And all of these steps require context switching.
This creates a profound inversion: context switching went from productivity killer to productivity requirement. Every switch you make can spin up a new parallel workstream. Refusing to context-switch now means leaving AI agents idle while you finish reviewing one thing at a time.
The old equation was simple: more context switches = more overhead = less output.
The new equation: more context switches = more parallel work unlocked = more output.
This is why the old mantra needs updating. “Stop starting, start finishing” optimized for our constraint: human building capacity. Now the constraint is human orchestration capacity. And orchestration requires context switching.
So the new mantra? “Stop finishing one at a time. Start orchestrating many.”
Context switching isn’t the enemy anymore. It’s the job.