01
The trap: a parallel job stuck in single file
You hand your AI five things to do — research five competitors, draft five replies, test five ideas — and it works through them one after another, even though not one of them depends on the others. That is wasted time you are paying for in latency and, often, in tokens. The fix is not a faster model. It is asking one question before you press send: do these steps actually depend on each other? If they don't, fan them out. If they do, keep them in order. This page is the cheat-sheet for telling the two apart in five seconds.
02
The one dependency-check question
For any two steps A and B, ask: does B need the OUTPUT of A to even start?
- No → they are independent. Run them in parallel. Nothing is lost by starting both at once.
- Yes → there is a real data dependency. B must wait for A. Keep them sequential.
- Not sure → assume a dependency only if B literally reads what A produced. "They're about the same topic" is not a dependency. "B summarises A's result" is.
Most things people run single-file are actually independent. Sequential is usually a habit, not a requirement.
03
5 worked builder examples
Run the question against the work you actually do. Here is how the five most common builder tasks break down:
| Task | Independent or dependent? | How to run it |
|---|---|---|
| Research 5 competitors | Independent — each lookup stands alone | Parallel: fire all 5 at once, collect the 5 answers |
| Draft 5 reply variants | Independent — none reads another | Parallel: one prompt per variant, sent together |
| Test 5 ideas / prompts | Independent — each test is self-contained | Parallel: batch them, compare results after |
| Summarise after enriching data | Dependent — the summary needs the enriched data | Sequential: enrich first, then summarise |
| Enrich → score → rank a list | Dependent chain — each step feeds the next | Sequential: enrich, then score, then rank |
Pattern you'll notice: 'do the same thing to N different inputs' is almost always parallel. 'Transform the result of the last step' is sequential.
04
The send-them-at-once pattern
You don't need any special tool to apply this. The everyday version is simple:
- List your jobs and run each one through the dependency question above.
- Group the independent ones together — these are your parallel batch.
- Send the independent jobs as separate messages at the same time (separate chat tabs, separate agent calls, or a batch request) instead of waiting for each answer before sending the next.
- Let the dependent chain stay sequential: only start a step once the step it depends on has returned.
- Collect the parallel results, then feed them into any sequential step that needs them.
The mental model: a fan, not a line. Independent work fans out wide and finishes together; dependent work runs as a single line because it has to.
05
Why this is suddenly easier (the proof point)
This isn't just a prompting trick — the platforms builders rely on are baking it in. On 2026-06-25, GitHub Actions (the most widely-used automation/CI platform) shipped its first native parallel-step primitive in the product's history. In about three lines you can now mark steps to run side by side instead of single-file:
background: true— runs a step asynchronously and immediately moves on.wait/wait-all— pauses until the named background steps have finished.parallel:— converts a group of steps into background steps with a wait after them.
Before this, parallelism meant spinning up a whole separate runner per job (matrix fan-out) or hacking it with bash backgrounding. The fact that a core automation platform made this a first-class feature tells you the principle is the durable lesson — the syntax is just catching up to how work should flow.
06
When NOT to parallelise
Parallel isn't a religion. Keep it sequential when:
- A later step genuinely reads an earlier step's output (real data dependency).
- You're rate-limited and firing everything at once just gets you throttled — batch in waves instead.
- Order matters for correctness (e.g. migrations, or anything that mutates shared state).
- The cost of a wrong-but-fast answer is high and you need step N to validate step N-1 first.
The rule isn't 'always parallel'. It's 'parallel by default for independent work, sequential only where a dependency forces it'.
Get the next drop
One AI speed habit a week, plus the occasional bonus template. No spam, unsubscribe anytime.
By submitting you agree to our Privacy Policy & Terms. Unsubscribe anytime.
You're in — check your inbox to confirm.
Frequently asked questions
How do I tell if two AI tasks can run in parallel?
Ask one question: does the second task need the OUTPUT of the first task to even start? If no, they are independent and safe to run in parallel. If yes, there is a real data dependency and they must stay sequential. 'About the same topic' is not a dependency — only 'reads the other's result' is.
What's a fast rule of thumb?
Doing the SAME thing to N different inputs (research 5 competitors, draft 5 replies, test 5 ideas) is almost always parallel. TRANSFORMING the result of the previous step (enrich → score → rank, or summarise after enriching) is sequential.
Do I need a special tool to run AI tasks in parallel?
No. The everyday version is to send your independent jobs as separate messages at the same time — separate chat tabs, separate agent calls, or a batch request — instead of waiting for each answer before sending the next. Tools just make it tidier.
Is this an AI-specific idea?
No, and that's the point. Independent work running in parallel is a general principle. The reason it's timely is that core platforms are now making it first-class: on 2026-06-25 GitHub Actions shipped its first native parallel-step primitive (background: / wait / parallel:). The video applies the same principle to multi-step AI work.
When should I keep tasks sequential instead?
When a later step genuinely reads an earlier step's output; when firing everything at once just gets you rate-limited (batch in waves instead); when order matters for correctness (migrations, shared state); or when you need one step to validate the previous one. Parallel by default for independent work, sequential only where a dependency forces it.