Resolving one GitHub issue as a DAG of parallel AI agents

One AI coding agent is still fundamentally sequential.

It reads something, changes something, runs a test, reacts to the result, and moves to the next piece of work.

Giving it more tokens doesn't change that execution model.

With vincent 0.8.0, I wanted to explore a different approach: split an issue into a dependency graph of work units and let independent agents execute those units concurrently.

The model is simple:

• nodes are implementation units
• needs edges describe real dependencies
• independent nodes can run in parallel
• each unit gets its own branch and worktree
• dependent units start from a branch that already contains their dependencies
• an integration step validates the combined result

I’ve now been running this workflow against vincent itself.

A real run

Issue #324 was decomposed into three units across two waves.

Wave 1 produced a dependency required by the remaining work.

Wave 2 then ran two independent implementation lanes concurrently.

Their individual coding times were roughly:

• 4m18s
• 10m22s

Sequentially: ~14m40s.

As one parallel wave: ~10m22s.

So this particular run saved around four minutes.

That number isn't spectacular, and I don't want to pretend it is.

What's more interesting is the scaling property:

the floor becomes the longest dependency chain through the graph rather than the sum of all independent work.

There are costs, of course.

More parallel lanes mean more agent sessions, more worktrees, more merges, and more opportunities for integration problems. The article goes into those trade-offs as well as how vincent constrains lanes to avoid agents modifying overlapping files.

I also found something counterintuitive while testing the scheduler.

vincent supports both barrier and eager DAG scheduling.

eager sounds obviously better because dependent work can start as soon as its own dependencies finish.

But across the real workflows I've run so far, it saved zero additional time compared with barrier.

What it did sacrifice was reproducibility: an eagerly scheduled lane can start from a different branch state depending on timing.

For agent-generated code, that's a meaningful debugging cost.

My takeaway so far:

Get the graph right first. The scheduler is the last thing to optimize.

I wrote up the implementation, actual workflow, real timings, costs, failure modes, and the lessons from running it on vincent itself:

https://blog.lezli01.is-a.dev/blog/vincent-dag-workflows/#two-waves-on-a-real-issue