Most of the discussion about AI in software development still assumes one developer, one chat window, one task. That framing is starting to look like a blind spot. The harder and more interesting question is what happens when agents run continuously inside a team's repository, on a schedule, producing work while nobody is watching. At that point coding agent reliability stops being a model quality problem and starts being a systems design problem.

Don Syme, Principal Researcher at GitHub and the designer of F#, joined The AI Native Dev to make the case for what he and his colleagues call continuous AI. The conversation is a useful corrective, because it comes from someone who has been building this machinery in production rather than theorising about it.

What continuous AI actually is

Continuous AI is the practice of running subjective, AI-driven work on the same continuous, event-driven footing as CI/CD. Where continuous integration re-establishes deterministic invariants such as "the build passes", continuous AI handles judgment-heavy activities like issue triage, documentation, performance research and bug fixing, repeatedly and in context rather than as one-off experiments.

Syme is deliberate about keeping the two apart. "It's one reason that we don't say we're putting AI into your CI," he noted. "No, no, no, we don't do that at all." CI/CD is where an organisation establishes that its software works, and he argues it should stay exactly as deterministic as it is. Continuous AI is a separate bucket that teams can dial up or down.

I find it helpful to plot the shift across two axes. One runs from single player to multiplayer, from an individual's chat session to work that happens in a shared context. The other runs from ad hoc to operational, from a clever one-off script to something on a permanent, running basis. Continuous AI is what sits in the far corner of both. As Syme put it, it is easy to find the duplicate bugs in your repo once. "But you got to make that continuous."

Bounding the context is the first reliability control

The most practical idea in the conversation is also the least glamorous. Agents go off the rails, Syme observed, largely when they are not situated inside a bounded context. GitHub Agentic Workflows, now in public preview, is his team's answer: coding agents running inside GitHub Actions with strong guardrails, a firewall around each run, a fixed set of inputs, and a bounded set of outcomes such as a single pull request or a single issue.

His framing of guardrails is worth borrowing. "The better the guardrails are, the faster you can run with automation. It's like train tracks. The stronger the train tracks, the faster you can run." The test he applies is whether you can sleep at night with the automation running, which turns an abstract safety conversation into an operational one.

There is a security dimension too. Private repositories should not be reachable by agents running in public ones, and issues arriving from untrusted contributors are ignored by default unless a workflow explicitly opts in. This is information flow integrity applied to agent workflows, and it appears to be the layer most teams building their own automation are skipping.

Quality gates come before pull requests

The strongest argument in the episode concerns where human attention goes. Review is a bottleneck, and Syme does not pretend otherwise. His conclusion is not to remove the human but to stop wasting them.

"There's just no point creating a pull request for the human to review when that thing is low quality," he argued. "You've just got to create as many quality gates as possible and automate those, to reduce the amount of attention you're sucking from the humans involved."

The word he keeps returning to is equipped. His job as a factory creator, he explained, is to deliver pull requests where the reviewer already has what they need: why the change was made, what the risks are, what the trade-offs were, and ideally the evidence. In GitHub's own CI performance factory, that evidence is a before-and-after run showing a test that took 120 seconds now taking 15. The reviewer is not being asked to trust the agent. They are being handed a measurement.

The contrast he draws is with the individual productivity world, where a developer fixes a thousand accessibility bugs and drops a thousand pull requests on their team. That is throughput without a system around it, and it is disruptive rather than productive.

Evaluating agents as exams, not vibes

On the question of how you know a non-deterministic workflow is still working, Syme described a feature that reframes AI agent evaluation in a way many teams could copy. Multiple models run exactly the same work at exactly the same time, and the first result is taken. The point of the simultaneity is subtle: because these workflows share a ledger, a model that runs later can find a closed issue or merged pull request that hints at the answer. "Now you've got to test those models at exactly the same time." He calls it exam testing, and turning it on for a day gives real evidence about which models suit which repetitive job.

He also flagged something the harness conversation has largely ignored: cost controls. "I think harnesses should have cost controls and kind of budgeting." In an automated modality where a scheduled workflow runs nightly across many repositories, unit economics per run is a first-class design concern rather than an afterthought.

Where the factory metaphor stops being useful

The most quotable moment is Syme declining the metaphor his own product page uses. He prefers to think of a repo as a site of production, a place where value is produced. "A film studio is not a factory, but it's also a place where value is hopefully produced as well." The factory analogy earns its keep when tasks repeat identically down a pipeline. Given how broad AI's range of use is, he suggests reaching for studios, productions and workbenches too.

The tension he acknowledged without resolving is the repo itself. Models are trained to work within a single repository, which pushes teams toward consolidation, while a modern monorepo is far too large to serve cleanly as a unit of access, security and permission. That, he conceded, is work GitHub still has to do.

Worth a listen if you are further along than prompting and starting to design the system around the agents. What does your bottleneck look like once the agents are the fast part?