A pull request is a useful review surface. It is not a model of dependency.
GitHub Flow makes a branch and pull request a clear unit for independent work. It also permits dependent branches. But when Change B needs Change A before A reaches main, the relationship is represented indirectly through branch bases, pull request targets, and rebases.
Agents make that coordination cost visible. They can explore, implement, test, and revise several parts of a system at once. Faster authoring does not create faster software when every later decision still has to reconstruct what it depends on.
A pull request is a review surface. A Change is a fact in the graph.
Interactive 01 / Follow the work
Both workflows begin with the same small change.
One bounded change is ready for review. The difference appears only when the author wants to continue.
1 / 4
GitHub Flow
Dependent branches work. Their bases and PR targets need maintenance.
VEX Chaining
Dependency relation and review identity stay explicit.
A direct comparison
GitHub Flow and Git-based workflows → VEX chaining
GitHub Flow is clear for independent work. VEX makes dependent work first-class.
GitHub Flow can model dependent branches too. When Change B continues from Change A before A reaches main, the work is coordinated through Git branch bases, pull request targets, and rebases. VEX makes that relation explicit without redefining review around a branch.
GitHub Flow for independent work
This is a good, legible flow when nothing else needs to build on the work before it lands. VEX does not replace it; it extends the model when later changes need the unmerged work.
When a dependency chain must stay in motion
- 01
Branch as the review container
GitHub Flow can branch B from A, but then the branch and pull request become the container for the sequence. Either A, B, and C are bundled into one expanding review, or each pull request inherits context the reviewer must reconstruct.
VEX chaining makes each Change the durable review unit and records the dependency relation explicitly.
- 02
Revision scope
Feedback on A can force B and C to rebase. The code movement and the review boundary move together, so reviewers must work out what changed, what was already understood, and what proof still applies.
VEX chaining creates new patchsets without erasing the review, decisions, or evidence attached to the Change.
- 03
Two clocks
Authors can wait for A to land before starting from main, or use dependent branches while reviewers reconstruct ancestry from branch bases, diffs, and rebases.
VEX chaining lets authoring continue from an explicit parent while reviewers judge one bounded Change at a time.
- 04
Landing scope
A merge queue does valuable last-mile work: it validates an already-ready pull request against the latest main and pull requests already in the queue. It does not make dependency scope a first-class review unit.
VEX chaining computes the contiguous ancestor-first ready scope, validates it against current main, and lands it in order.
Chaining breaks the false dependency between “finished writing” and “merged to main.”
Create a small Change A and send it for review. Then start Change B from A immediately. Start C from B. A reviewer can inspect A while B is being written, then inspect B without rereading A, because the relationship between them is explicit.
If A changes after feedback, B and C receive new patchsets. The snapshots move. The purpose of each change does not. Comments, approvals, agent evidence, and human decisions remain attached to the same durable identities.
Nothing pretends the changes are independent. Nothing forces the author to be idle. The dependency chain preserves causality while the two clocks overlap.
Why chaining
A dependency chain is the causal context for a change.
A dependency chain is the ordered work around a change: it tells a reviewer what came before, what can follow, and what must be ready to land.
“Chaining” names the act of continuing from a stable boundary before the earlier work has landed. The dependency chain is the context that makes that work reviewable.
In VEX, the dependency chain is context. The durable change is the product.
Change
The durable unit of intent, authorship, review, evidence, approval, landing, and rollback.
Patchset
One concrete snapshot of a change. A new patchset can move the code without erasing the review.
Dependency chain
The explicit ordered context around a change: what it follows, what can build on it, and the ancestor-first scope that must be ready to land. It is context, not the review unit.
In Flight
The moment a proven-ready scope is running its final checks and advancing main.
Interactive 02 / A real review in motion
Keep a deploy safeguard moving without turning it into one giant review.
One Change enforces the rule. A parent supplies the policy. A follow-up is already being built. Walk through what happens when a reviewer finds one missing case.
1 / 4
What is happening now
Nina reviews the guardrail, not the whole feature.
#142 already stores the approval policy. An agent has started #87, the UI explanation, but Nina only needs to decide whether #311 blocks the right deploys.
parent Change
Store the approval policy
Patchset 3 · 91ad2c1
already approved
review this Change
Block unapproved deploys
Patchset 2 · b4e810f
Nina is reviewing this
agent follow-up
Explain blocked deploys in the UI
Patchset 1 · 6c22a90
already building ahead
What changed
Nothing moves yet.
What did not change
#311’s intent, comment thread, review identity, and proof remain attached.
Agents make exploration cheap. That makes discarding work a core capability.
Give an agent a question, not just a task, and it can prototype alternatives, trace a migration, probe a performance assumption, or find the counterexample that changes the plan. A team can afford to explore many paths where it once explored one.
Most of that output should not be merged. “Throwaway” code is valuable when it buys a decision: it rules out an approach, turns uncertainty into a constraint, or reveals the smallest change worth reviewing. The code can disappear. The learning should not.
Without new foundations, cheap generation becomes a mainline bottleneck. Every sketch looks like a pull request candidate. Reviewers face unbounded noise, and production policy has to sort through experiments that were never intended to carry authority.
The VEX model separates exploration from promotion. Agents get cheap, isolated workspaces and durable provenance. A human or policy promotes only the selected result into a bounded Change with intent, evidence, tests, and a review decision. The rest can remain discoverable or be discarded without asking main to absorb it.
An experiment does not need production confidence. A result proposed for main or production does.
Cheap experiments
Explore approaches, produce prototypes, and test assumptions without giving every result a claim on main.
Isolated workspaces
Discovery starts from known source state, so an experiment cannot quietly contaminate another change or main.
Promotion boundary
Intent, ownership, evidence, tests, policy, and review appear when a result becomes a production candidate.
Learning survives discard
Keep the question, outcome, and useful proof. Delete the code when it no longer earns its place in the graph.
- 01
The pull request is not the natural unit of work.
It is a packaging convention from branch-centric source control. The durable change is smaller, clearer, and better aligned with the decision a reviewer is actually making.
- 02
A change should outlive its commit hash.
Amend, rebase, and target movement should create new snapshots without destroying intent, discussion, evidence, or review identity.
- 03
Dependency is information, not inconvenience.
Hiding dependent work inside one giant pull request destroys useful structure. Pretending the work is independent creates unsafe integration. The dependency chain should remain explicit.
- 04
Review latency should not create authoring latency.
A person or agent should be able to build the next link while an earlier link is reviewed. The work can advance without weakening the review boundary.
- 05
Exploration should be cheap; promotion should be deliberate.
Agents should be free to compare approaches in isolated workspaces. The chosen result returns as a bounded Change with a clear reason to exist.
- 06
Main should carry decisions, not every attempt.
Unselected experiments can remain local or be discarded without blocking unrelated ready work. The selected path stays explicit as a coherent dependency chain.
- 07
Proof should scale with consequence.
Starting an experiment can be inexpensive. Moving a result through main and into production still requires the review, policy, validation, and release controls appropriate to its risk.
- 08
Agent output is not proof.
A change becomes trustworthy when it connects intent, actor, decisions, tests, policy, human judgment, and outcome. A transcript dump or a green check alone is not enough.
- 09
Landing is a graph operation.
The system should compute the ready dependency closure, validate it against current main, run its gates, and land ancestor first. A merge button should not guess.
- 10
Humans govern the loop.
People define authority, protected paths, reviewers, policies, budgets, and acceptable risk. Agents execute within those boundaries and leave an inspectable record.
- 11
Source control should remember what happened next.
The record should connect a change to its release, runtime result, rollback, and follow-up. Source is the beginning of the software loop, not its boundary.
Source control becomes the coordination layer for software production.
VEX is Jujutsu-native because change identity, cheap workspaces, operation history, and explicit conflict are better foundations for concurrent actors than branch choreography.
Review is the first wedge. The larger goal is one connected record from request, through source and proof, to release, runtime outcome, and the next change.
One main branch. Many changes in motion. Every worthwhile result returns to shared truth.
This is not a case for agents pushing to main without review. It is not a case for removing tests, ownership, or human authority. It is not a promise that every group of related work can land atomically across every repository.
Chaining does not hide complexity. It exposes it in a form that can be reasoned about. A dependency is visible. A failed check blocks its descendants. A topic or label can group related work without pretending it creates ancestry. A later change can remain open after a ready prefix lands.
Review one change. Understand the dependency chain. Land only what is proven ready.
The future is not larger pull requests written faster.
It is smaller changes moving continuously.
Stop packaging work. Preserve its causality. Let people and agents build ahead without asking reviewers to surrender understanding.
Continue exploring
See how chaining fits the wider VEX source-control vision.