The Agentic Automation Revolution • Don Syme • Bug Bash EU 2026
Don Syme, designer of F# and GitHub Next engineer, explains how AI agents are moving from individual productivity tools toward continuous, collaborative automation inside repositories. He introduces continuous AI and agentic ops, GitHub Agentic Workflows with their guardrails, and the factory and farm metaphors for managing software production.
Don Syme begins by reflecting on his own path into computer science, which started through formal verification, and on a moment in the software industry that feels disorienting. He notes that someone in the room could now build a language better than F# over a weekend by asking agents, and he has spent the years since 2022 at GitHub Next, the group that produced the original Copilot completions, trying to work out what comes next.
Chat as a collaborative form factor
Syme admits he underestimated chat when ChatGPT appeared. He had assumed it could not be the future of how people work and explore problems, but he now sees the sequential, text-based output of an LLM as a surprisingly good match for how humans reason back and forth. He contrasts this with hardware interfaces such as silicon chips, raster displays, and the mouse, where there is a large conceptual gap between the underlying technology and the experience it delivers. This is one of the lessons he takes from the last few years.
Wizards, collaboration, and the limits of individual productivity
His central metaphor is that everyone is now a wizard. A team meeting that once produced one plan can now produce six working prototypes in fifteen minutes, one from each person in the room, which means the team has six competing prototypes and no shared direction. Wizards are also known to blow things up, especially in training mode. Syme argues that most AI investment from OpenAI, Anthropic, Microsoft, and others is aimed at making individuals more productive, which is valuable, but that open-source communities and enterprise teams need collaboration and clear authorization boundaries. A wizard walking into a shared project and acting outside its agreed boundaries is a different problem.
He also describes a personal wish: he wants autonomy rather than sitting and steering an assistant all day. He wants AI collaborators that look after parts of a project, review pull requests, answer questions, and move work forward while he is on holiday. He is not asking for full, unsupervised maintenance, but for steady forward progress.
Continuous AI as a new category
Syme frames continuous AI as a natural extension of continuous integration and continuous deployment. In CI/CD, change happens in a bounded context and the integration or deployment process reacts to it. He wants to bring subjective activities such as documentation, triage, and code improvement into that family as a third bucket, which he calls agentic ops. He is explicit that CI/CD itself should not become agentic. Its determinism is where trust is established, and code must pass through it before it ships.
He gives an example of rolling out CVE fixes across 20,000 repositories in a large investment bank. This is slow, subjective, and costly work that humans or AI can perform inside a bounded process. Rather than building point tools for code migration or documentation, as GitHub did in 2022 through 2024, he argues for one generic primitive, the way GitHub Actions answered the CI/CD question. Actions gives developers bounded permission to use compute, networking, and storage, with auditing, and Syme believes AI can ride on that same structure.
He describes continuous fault analysis as an example. An Actions workflow connected to telemetry could notice fifteen failures from a service, download the data, identify the fault, and propose a fix within five to ten minutes. The on-call engineer returning to the computer would then find a proposed remedy waiting. He summarizes the maintainer’s ideal as ‘start your day with code that’s better.’ He stresses that maintainers should define what their automation does, rather than having the platform prescribe how triage or code improvement must be done. Organizations pay for these runs, so they decide where the value lies.
He also points to the self-improving nature of automation. Agents can review their own definitions and recent run histories, identify failures, and turn reasoning into scripts that harden the process over time. He also mentions an idea not yet implemented: exam-style testing, where several models run the same task in isolation and their results are compared, providing a disciplined way to choose the right model for a job.
The ledger for this work is GitHub itself, meaning issues and pull requests. Syme acknowledges the drawbacks of GitHub’s information model, including comment threads, review threads, and bot noise. The advantage is that the ledger is already familiar to humans and agents, and it makes continuous processes multiplayer by default.
GitHub Agentic Workflows
The concrete implementation is GitHub Agentic Workflows. A developer checks a markdown file into .github/workflows, where a YAML file would normally go. A compilation and checking step turns it into a standard Actions workflow that runs a coding agent on a trigger or schedule. The markdown is natural-language programming, and Syme deliberately calls the ambiguity ‘genuinely useful.’ Agents are good at writing and revising these files, and running on GitHub means that instructions such as ‘create a new GitHub issue’ work naturally. Setup is simple, with an integrated billing option or a token from Anthropic or OpenAI.
Safety is central to his argument. The agent receives no direct access to secrets. Web access must be explicitly enabled. The agent runs in a container behind a firewall. Its outputs are restricted through declared safe outputs, so a workflow may be allowed to create one issue and nothing else, which sharply limits the blast radius. Safe outputs are also checked by AI for safety. Pull requests are not merged automatically, so a human stays in the loop at that point, although the AI may write issue comments. On public repositories, issues from non-collaborators are invisible unless the maintainer opts in, which guards against prompt injection. Syme advises against giving these agents access to private data on public repos, since they might write that data into logs.
He shows examples such as issue triage, documentation, and CI failure analysis, and he walks through a workflow that triggers on issue creation, gathers context, assesses completeness, and applies labels, with the maintainer in charge.
Results from the agent zoo and Repo Assist
Peli de Halleux, a colleague at GitHub, runs what Syme calls an agent zoo, with many small agents each handling a recurring need. One example analyzes Go module usage in a codebase to find better ways of using existing dependencies rather than removing them. This workflow produced 58 merged pull requests out of 74, a 78 percent merge rate. Its design is notable: agents first write reports, and a second step turns approved reports into pull requests. That intermediate human checkpoint preserves judgment and creates a traceable causal chain on the ledger.
Syme also describes continuous test improvement, where agents measure coverage, identify gaps, and add tests with some judgment about what should be tested. He especially cares about continuous performance engineering. He argues that performance work has historically depended on heroic efforts that decay: benchmarks break, scripts stop running, and old experiments rot in repositories. Automation can make this sustainable without pulling attention from mainline developers.
He reports on Repo Assist, which he used on dormant F# repositories with 100 to 400 open bugs. It examined every issue one by one, closed stale ones such as a 2016 issue, implemented fixes where appropriate, and contributed to three new releases of a project that had been dormant. He acknowledges that results depend on the backlog size and on whether the maintainer engages, since a repository with 5,000 bugs will not clear quickly.
He makes a point about guardrails. With individual productivity tools, developers tend to switch guardrails off or approve everything. With automation, the opposite holds: ’the faster the better the train tracks you have,’ because strong guardrails let people walk away and trust the work.
Lean Squad and formal verification
Syme describes an experiment inspired by formal verification. A manager with no expertise in the field might want a squad that does it anyway, so he built a GitHub agentic workflow that runs hourly, called Lean Squad. It selects targets in the codebase, extracts informal specifications, writes formal specs, implements them, checks that the formal model matches the code, and critiques its own work. The question is less whether the output is valuable, since that is highly context-dependent, and more whether this form factor can deliver meaningful verification depth. He suggests there may be relevance for a company like Antithesis, which the transcript renders as ‘Entasis.’
Factories, farms, and process engineering
Syme sees repositories becoming human-agent knowledge factories. Once automation is added, a repository becomes a production system that can be analyzed with process engineering. Is the factory blocked, flowing, or idle? He argues that making individuals more productive while the wider process is jammed is like ‘chopping down more trees’ upstream from a log jam. The goal is end-to-end flow for teams and companies, not just faster individuals. Internally, GitHub runs four such factories: one for backlogs of query problems, one for CI performance, one for a list backlog, and one that studies production profiling data from Go services to find small performance wins on the hottest routes.
He is moving from factory metaphors to farm metaphors, partly because he grew up in an Australian farming town. Factories imply determinism, repeatability, and homogeneous assembly lines, while farms involve crop cycles, growing seasons, inspection points, and human environments that move more slowly. The questions he asks of software factories are useful: where is it run, what are the production lines and ledger, what are the quality gates, can humans override it, who designs and runs it, what are the escalation and authorization paths, is it protected from outside influence, what are the cost limits, and what does the audit trail look like?
He closes by predicting a new role he calls the agentic maestro. A central, controlled repository has bounded permissions across many repositories, and it hosts a factory runner that can be removed when the work is done. Many people in large enterprises may spend their working lives improving a thousand repositories this way.