CI should be a buffet that your data engineering agent orders from

In a recent engineering scrum, we set the direction for the CI gate in Vibedata in one sentence: "So we have to convert CI from a one-way door problem to a two-way door problem."

That sentence is why we are moving away from diff-only CI. A suite that maps a fixed action set to changed paths is a one-way door: the action set and the routing are decided together, and changing either means rebuilding the gate.

What we are building instead is a buffet of actions that your data engineering agent selects into an execution plan for each pull request. That is a two-way door. The menu stays fixed. The order changes.

A diff-only plan is decided before the context arrives

The diff tells CI what changed. It does not tell CI what the change means.

A column rename looks the same whether it touches a table with one consumer or twenty. A backfill looks the same whether it runs against a snapshot nobody reads or the table behind the morning revenue report. A freshness threshold change looks the same whether it loosens a warning or silences the check that caught last month's incident.

That meaning lives in brownfield context. Which table is the source of truth for an entity, and which one merely looks like it. Which pipeline is fragile, and why. The downstream consumer that will break when a column moves, and the one that has been dead for a year.

Your data engineering agent can read that context before it acts. A mapping keyed only to changed files has no place to read it.

The mapping is still a plan. It is a list of checks chosen in advance for a class of diffs, hidden inside paths, filters and conditions. Calling it automatic does not make it contextual, and it does not make the choice visible to the person reviewing the pull request.

The menu is deterministic; the order changes per pull request

A buffet works only if the kitchen decides what is on it. The menu is a versioned set of actions with fixed definitions: lint, type check, unit tests, schema diff, data quality checks, policy scan, build, deploy preview.

The agent does not invent a dish. It chooses from the menu and writes an execution plan that names the actions for this pull request. CI runs that plan and nothing else.

That split is the architecture. The action set is deterministic and versioned. The invocation is chosen per run. GitHub's reusable workflows already show the shape: a caller passes inputs to a fixed, versioned workflow, so the action set stays stable while each run chooses what to invoke (GitHub Actions documentation).

The determinism is what makes the freedom safe. If the agent could write a new check on the fly, the gate would be as variable as the model's last guess. Because the action set is fixed and versioned, the agent's only freedom is selection, and every selection is a line in a file.

A plan can be a small file in the pull request. It names each action the agent selected, the reason it selected it, and each action it considered and skipped with the reason for skipping it. The reviewer reads that file beside the diff, and CI reads the same file when it runs.

The plan also gives the team a place to put the checks that must never be optional. A baseline group can sit outside the agent's choice: secret scan, license check, the one regression suite that has caught every bad release. The agent orders from the rest of the menu, and the baseline runs regardless.

A stated plan is easier to audit than a hidden mapping

The strongest objection deserves its full weight. A fixed, diff-keyed suite is easier to audit, and it cannot let the agent under-select checks. Take the two halves separately.

The first half is true only while the mapping stays legible. To show a reviewer why a given diff ran the checks it ran, someone has to trace paths, changed-file filters and conditional steps back to a rule. That record is spread across workflow files, and the person who wrote it may have left.

The second half is right that a fixed menu does not stop under-selection. The menu limits which actions exist. It does not limit which ones the agent selects.

The plan records every omission and the reason, and the must-run baseline sits outside the agent's choice, so the reviewer can see the gap and the must-run checks still execute. Under-selection becomes a visible decision the reviewer can reject; it does not become impossible.

The plan also gives the reviewer a second artifact to read beside the diff: the reason this pull request ran these checks. That is a stronger audit than a mapping nobody wrote down for this change.

An audit becomes a comparison. For each action on the menu, the reviewer sees whether the plan selected it or skipped it, and the stated reason. A skipped check becomes a question with an answer attached.

The plan moves the reasoning into the pull request, where the person with the most context is already looking.

Separating the menu from the order makes each change reversible

A one-way door is a decision you cannot cheaply reverse. A suite that couples its action set to its diff routing is one, because the action set and the routing live in the same configuration, and the mapping is the only record of why a check exists.

Separate the menu from the order and each becomes reversible on its own. Add an action to the menu and every plan can use it. Change a plan and the menu is untouched. Retire an action and the version tells you which plans used it.

This is also how the gate improves without a re-architecture. A missed check becomes a new dish, and a plan that should have selected it becomes a correction for that class of change. The system learns in two separate places, which is why neither change has to reopen the whole design.

The choice is stated and versioned, and a reviewer can read it; that is what makes the door two-way. Automation without a stated plan just moves the hidden decision somewhere else.

This is why we are building the gate this way. Vibedata runs deploy as one of its lifecycle functions, and the CI gate decides whether a change reaches production. A gate that cannot explain its own choices is a gate the team learns to route around.

A stated plan makes a wrong choice reviewable before it ships

The agent is still fallible. It can read the repository and still choose the wrong set, and a stated plan does not make a bad choice correct. What the plan does is make the choice available to review before it costs a release.

The menu can be wrong too. A versioned set of actions is only as good as the checks on it, and a missing dish cannot be selected by any plan. The menu needs an owner and a review of its own.

Human review does not disappear. The reviewer now has two things to read, the diff and the plan, and the plan is short by design. The work shifts from reconstructing why CI ran what it ran to judging whether the reason holds.

A data engineering menu needs actions a diff cannot order

A menu that mirrors a generic software pipeline misses the work. Data engineering needs actions that read schemas, compare data, check contracts, validate freshness and exercise the transformation graph. Those are the dishes a diff cannot order on its own.

The test for a dish is whether it can fail for a reason the reviewer would care about. A check that cannot fail on this repository is decoration, and decoration makes the menu longer without making the gate stronger.

The test for a plan is whether a reviewer can read it and say what was skipped and why. If the plan cannot answer that, it records what happened without stating the argument for it.

Start smaller than you think. The first menu can be the checks you already run, named and versioned in one place, with the mapping reduced to a suggestion.

Start with the plan you would write today

The move to this architecture does not need a new CI vendor. It needs one repository, one menu, and one plan written by hand for a pull request you already merged.

1. List the actions that ran on that pull request.
2. List the actions that should have run and did not.
3. For each missing action, write why the diff could not have known it was needed.
4. Name the actions that must run on every pull request and keep them outside the agent's choice.
5. Put the rest on the menu, with a version and a definition for each one.

Then ask your data engineering agent to write the same plan before CI runs, and compare the two. The gap is the argument.

The productivity claim is that the same team ships more with Vibedata: less time to PR and less time per PR, once the team changes what it focuses on and how it builds, and review compounds as each accepted change shrinks the next review.

What did your last pull request run, and who decided?