GitHub puts the quality gates before the pull request, not after it

Syme, who designed F#, now leads GitHub's work on what he calls continuous AI: judgment-heavy work such as triage, documentation and performance research, run on the same scheduled, event-driven footing as CI/CD but kept deliberately separate from it. GitHub Agentic Workflows, the product built on this and now in public preview, runs coding agents inside GitHub Actions with a firewall around each run, a fixed set of inputs, and a bounded set of outcomes. His case for constraint is a case for speed: "the better the guardrails are the faster you can run with automation. It's like train tracks, you know, the stronger the train tracks, the faster you can run." One concrete default: issues from untrusted contributors are ignored unless a workflow explicitly opts in.

Where human attention goes is the sharper argument. Syme does not dispute that review is a bottleneck, but he refuses to solve it by removing the reviewer. "There's just no point creating a pull request for the human to review" when the work is low quality, he argues; the job is to build enough automated quality gates upstream that the reviewer only ever sees candidates worth their time. The word he returns to is equipped. "My job is to equip the reviewer with all the information they need" to understand why a change was made, what the risks are, and what the trade-offs were. In GitHub's own CI performance work, that means shipping the pull request alongside a before-and-after run: the reviewer is handed a measurement rather than asked to trust the agent.

Two smaller practices are worth copying. He evaluates non-deterministic workflows by running several models on identical work at exactly the same moment, taking the first result, and comparing: "A room full of models is doing exactly the same work at exactly the same time, setting them in exam." Simultaneity is the point, because these workflows share a ledger, so a model that runs later can find a closed issue that hints at the answer. He also names an absence: "I think harnesses should have cost controls and kind of budgeting." And he declines the metaphor his own product page uses, preferring to describe a repository as "a site of production, a site where things happen, a site where value is kind of produced," on the grounds that the factory analogy only earns its keep when tasks repeat identically. This is a conversation rather than a study and it reports no dataset. The one throughput figure Syme mentions in passing carries no denominator or time window, so it is not repeated here.

Why it matters: GitHub's stated position is that "the human is always in the loop" and "no pull request gets merged without the human actually approving that," which sits against the autonomy-maximalist line elsewhere in this field. Read as a design commitment rather than a limitation, it relocates the engineering: if the merge gate stays human, the work moves into the gates upstream of it and into the evidence attached to whatever arrives. That is a different roadmap from the one that ends in auto-merge.