Colin’s ALM Corner

From Sprints to Swarms, Part 3: When Code Gets Cheaper, Judgment Gets More Valuable.

2026-04-14T09:00:00+00:00

Cheap Code Changes the Economics
Two Lanes, Different Purposes
The Developer Role Moves Up the Stack
Verification Becomes a Competitive Advantage
The Platform Matters
Better Judgment Beats More Output
Metrics That Actually Matter
DevOps Becomes More Strategic, Not Less
Conclusion

In Part 1 of this series, I argued that AI made code cheap, not delivery easy. In Part 2 I argued that context and policy form the control plane that keeps the speed gains from AI from turning into chaos.

That leaves the last question: when implementation gets dramatically cheaper, what becomes more valuable?

The answer is judgment.

Bad decisions, weak proofs, brittle architecture, and slow recovery are still expensive. Agents lower the cost of generating options, but they do not lower the cost of choosing badly or shipping something you cannot safely operate.

This is the shift many teams still underestimate. Cheap generation should not lower the quality bar. It should raise the proof bar. If an agent can produce three plausible implementations before lunch, the hard part is no longer typing one of them. The hard part is deciding which one belongs in your production system, and proving it.

Cheap Code Changes the Economics

Implementation cost shapes engineering behavior. Teams tolerate awkward abstractions, live with duplicated logic, and defer rewrites because changing the system is expensive. Even when everybody knows a design is wrong, replacement cost often keeps the wrong thing in place.

Agents change that calculation.

You can now run parallel solution probes against the same problem, compare trade-offs quickly, and discard the weaker paths without feeling like you wasted a sprint. Disposable prototypes become practical. Selective rewrites become easier to justify. Branch by abstraction becomes more attractive because trying two implementations behind a stable contract is less painful than it used to be.

That is the upside. The caution is just as important: the cost of experiments is falling, but the cost of incidents is not.

Production outages still hurt. Compliance failures still hurt. Data corruption still hurts. Reputational damage still hurts. So while implementation gets cheaper, operational mistakes do not. That means the winning move is not to generate more code. It is to generate more options, then apply better judgment.

This is why I think teams should carry ideas forward, not baggage. If a prototype taught you something useful, keep the learning. Do not preserve every rushed implementation just because code already exists. Code volume is not an asset by itself. Architecture and intent clarity is.

Two Lanes, Different Purposes

In the first post I talked about dual-lane execution: humans and agents should not own the same kinds of work in the same way. There is a related distinction inside the codebase itself. Teams increasingly need two lanes for software assets:

Innovation Lane	Production Lane
Fast exploration	Hardened delivery
Multiple competing implementations	One supported implementation
Loose edges are acceptable	Operational sharp edges are not
Local proof may be enough	System proof is required
Easy to discard	Expensive to keep

The innovation lane can be a little messy on purpose. Prototype the workflow. Try two prompts. Compare two parsers. Generate scaffolding. Spike the interface. Throw most of it away if the idea does not hold up.

The production lane is different. Once code graduates into the part of the system that other people depend on, the standards change. At that point, tests are not optional polish. Observability is not nice-to-have. Ownership cannot be fuzzy. Rollback cannot be an afterthought.

That handoff matters more in the agentic era because the front half of the system can now move much faster than the back half. If you do not define graduation criteria, prototype code can easily leak into production simply because it exists and mostly works.

A useful graduation gate asks a few plain questions:

does this code solve a real, validated problem
can someone explain the design and its trade-offs clearly
do tests describe the expected behavior at the right level
do we know what signals will tell us it is healthy in production
is there a safe rollback or containment path
is there a named human owner for the risk

If the answer to those questions is weak, the solution is not ready, no matter how quickly it was produced.

The Developer Role Moves Up the Stack

This is the part that tends to trigger anxiety, but I think the shift is more interesting than threatening. The developer role does not disappear; it shifts toward higher-leverage work.

When code generation is abundant, the highest-value engineering work moves toward direction, selection, and proof. Developers become more like workflow directors than pure implementers. They frame the problem, shape the context packet, set boundaries for the agent, compare candidate solutions, and decide which path deserves deeper investment.

That role has several facets:

workflow director - decomposes work, routes it well, and manages parallel execution
context architect - makes sure the right domain, design, and operational context are available at the start
quality governor - insists on evidence, not just plausible output
platform engineer - improves the paved road so safe agentic delivery is the default
reviewer as verifier - evaluates correctness, risk, and fitness, not just style

None of those are entirely new. But they move much closer to the center of the job.

This is also why I think AI enablement becomes a continuous discipline, not a one-time rollout. Mature teams will keep refining their instructions, task templates, skills, ownership metadata, tests, rulesets, and observability because those things compound. Instructions, examples, docs, and tests are not administrative residue anymore. They are capital that helps humans and agents make better decisions.

In other words, the developer of the next few years is not just writing code. They are designing the system that decides how code gets written, validated, and trusted.

Verification Becomes a Competitive Advantage

If there is one idea I want to land in this series, it is this: when generation gets cheap, verification becomes a differentiator.

That starts with tests, but it does not end there. A strong verification culture treats tests as contracts, observability as proof, rollout telemetry as feedback, and provenance as part of operational reality. It asks not only “did the code compile?” but also “what exactly did we change, why do we believe it is safe, and how quickly will we know if we were wrong?”

That leads to a different kind of handoff. Good handoffs carry evidence:

what the intended behavior is
what changed and why
what tests were run
what risks remain
what telemetry or dashboards should be watched
what the recovery path is if reality disagrees with the plan

This is not bureaucracy. It is how you keep review and operations from collapsing under higher change volume.

It also changes what good platforms optimize for. Faster pipelines matter, but fast wrong answers are not impressive. The real target is trustworthy speed: fast feedback, useful test signals, clean provenance, safe progressive rollout, and recovery paths that work under stress.

That is why cheap code should raise the bar for proof. If your system can generate more change, your verification system has to turn more ambiguity into confidence. Teams that do this well will feel dramatically faster. Teams that do it poorly will feel busy, noisy, and fragile.

The Platform Matters

This is also why I think an integrated platform matters more in the agentic era.

If agents work in one place, context lives in another, CI runs somewhere else, security signals arrive late, and audit trails have to be stitched together by hand, the system creates friction right where it needs clarity. Review slows down. Provenance gets fuzzy. Policy becomes easier to bypass by accident. The more autonomy you add, the more expensive that fragmentation becomes.

An integrated platform does not remove the need for judgment. It makes judgment easier to apply at the right moment. When code, issues, pull requests, code review, Actions, security controls, environments, and audit history live in the same system, context travels with the work and evidence is easier to inspect.

That is why I think GitHub’s Agentic Platform is strategically important here. It gives teams a shared surface for agent execution, human review, workflow automation, and governance rather than forcing them to bolt those capabilities together across disconnected tools. Agents can work where developers already work, and the surrounding controls can stay close to the activity instead of being bolted on later.

That matters because speed is not the hard part anymore. Coordinated, governable, evidence-bearing speed is.

Better Judgment Beats More Output

Once agents can produce large amounts of software, the hard decisions become more visible.

What is worth building at all? What should be tested as an experiment and then discarded? What should be hardened into a long-lived capability? What should never be automated because the downside of failure is too high? Where does human review add real value, and where is it just ritual?

Those are judgment questions. They live at the boundary between engineering, product, operations, and risk.

This is also where accountability stays stubbornly human. An agent can propose a migration plan, generate a feature, or suggest a test. But a person still owns the decision to ship, the acceptance of residual risk, and the responsibility for the outcome. That is not a limitation of the tools. It is a property of real systems and real organizations.

I also think teams need better trust calibration here. Blind trust is dangerous. Reflexive distrust is wasteful. The useful posture is conditional trust, backed by evidence. Low-risk, well-bounded work with strong automated checks should flow quickly. High-risk work should keep much tighter human loops.

Not every task deserves autonomous parallelization. Agent budget should be treated a bit like compute budget: spend it where speed, coverage, or toil reduction materially improve the business outcome, not where it just creates more artifacts to review.

Autonomy is earned by evidence.

Metrics That Actually Matter

If you want to know whether judgment and verification are improving, the metrics need to reflect more than raw activity.

A few measures I would watch are:

Predicted versus observed productivity - did the time you thought you saved turn into shipped value, or just more in-flight work?
Experiment hit rate - how often do prototypes or parallel probes produce something worth hardening?
Escaped defects - is faster change creation increasing failure downstream?
Rollback frequency and recovery speed - how often do you need to back out changes, and how quickly can you recover?
Review burden - are senior engineers spending more time triaging noise than evaluating important risk?
Time reinvested in architecture and platform - is AI-created time being spent on higher-leverage work, or just absorbed by more throughput?
Trust signals - do teams increasingly let low-risk work flow through automation because the evidence deserves trust?

Those metrics tell a more useful story than counting prompts, tokens, or lines of generated code. The goal is not to maximize output. The goal is to improve decision quality, delivery quality, and business outcomes.

DevOps Becomes More Strategic, Not Less

A lot of the market conversation still implies that AI compresses software delivery into a prompt-and-approve loop. I do not buy that. AI mostly exposes whether a team has real delivery discipline underneath the surface.

If your flow is weak, more generation creates more queues. If your context is weak, more autonomy creates more guesswork. If your verification is weak, more output creates more false confidence. If your operational discipline is weak, incidents erase the gains quickly.

That is why I do not think DevOps becomes less important in the agentic era. I think it becomes a strategic differentiator.

The teams that win will not be the teams with the most agents. They will be the teams with the clearest protocols, the best verification culture, the strongest platform leverage, and the most disciplined judgment about where autonomy belongs.

Swarms still need stewards.

Conclusion

Across this series, I have argued three things. In Part 1, AI shifted the bottleneck from coding effort to delivery flow. In Part 2, context and policy became the control plane for safe speed. Part 3 is the consequence of both: when code gets cheaper, judgment becomes the scarce capability.

Cheap code is useful. Cheap mistakes are not. The future belongs to teams that can generate options quickly, verify them rigorously, and make disciplined decisions about what deserves to survive. That is less a story about replacing developers than about raising the value of the best parts of engineering judgment.

Happy shipping!

From Sprints to Swarms, Part 2: Context Is Infrastructure, Policy Is the Runtime

2026-04-07T09:00:00+00:00

Series
The Happy Path Needs More Than a Prompt
Context Is Infrastructure
The Context Packet Matters
Clean Codebases Are Not Just a Nice-to-Have
Documentation Is Now an Execution Input
Policy Is the Runtime
Review by Risk, Not Ritual
The Control Plane in GitHub Terms
New Operating Rituals
Conclusion

Series

In Part 1 of this series, I argued that AI made code cheap, not delivery easy. Once the pull request becomes the unit of flow, the constraint shifts into review, testing, merge speed, and all the coordination work teams used to treat as background noise.

That raises the next question: what does the happy path look like when agents do a meaningful share of the implementation?

It looks something like this: an agent receives a bounded task, finds the right code and docs, makes a small change, runs the right tests, and passes automated checks. A human then reviews the change in proportion to its risk and ships it quickly.

That workflow sounds simple. It only works when two conditions are already in place: reliable context and policy that runs near the activity. Together, they form the control plane for agentic delivery. Without them, faster generation just creates faster review debt.

The Happy Path Needs More Than a Prompt

A lot of current AI adoption still treats prompting as the main control surface. That is too narrow. What matters more is everything upstream that shapes what the agent can see, infer, and safely do, and what happens downstream that shapes how the system responds to what the agent did.

If you want agents to behave well, you need a codebase and documentation set that are easy to search, easy to trust, and hard to misread. You also need tasks that state intent, scope, constraints, and risk clearly. Otherwise you get the worst kind of acceleration: fast local output followed by slow, expensive review and cleanup.

The happy path still depends on a few things that should be familiar to any team that has done DevOps well:

clear task intent
reliable documentation and architecture context
small batch sizes
good tests
automated checks, scans, and release protections
clean ownership and review paths

None of that is new. What changes is the penalty for getting it wrong. Weak context used to slow people down. In an agentic system, it can create a larger volume of confident mistakes.

Context Is Infrastructure

Think about what infrastructure as code solved. Before IaC, admins clicked around consoles, produced inconsistent environments, and created brittle handoffs. Infrastructure as code made infrastructure versioned, testable, and reviewable. That was a major step forward for speed and reliability.

We need the same shift for context. In agentic engineering, context is infrastructure. If it is thin, stale, or hard to find, autonomy rests on guesswork.

When an engineer starts a task, they do not start from raw code alone. They pull in product intent, domain language, architecture decisions, service boundaries, conventions, and known sharp edges. If your agents are contributing real work, they need the same kind of grounding, delivered in a form they can actually use.

That context usually lives across several layers:

product intent and acceptance criteria
domain language and business rules
ADRs and architecture diagrams
service boundaries and ownership metadata
repository instructions and coding conventions
tests that show expected behavior

Teams can go overboard here. The point is not to dump the entire universe into every task. That just creates noise. The point is to make the right context easy to find and the critical context impossible to miss.

This is where many teams discover that their documentation problem is really a delivery problem. If architectural patterns are not discernible from the code, notes are stale, ownership is ambiguous, or operational constraints only exist in people’s heads, the agent does what a human would do under the same conditions: it guesses.

The Context Packet Matters

One practical pattern I like is the context packet. Before work starts, package the task as a small execution contract instead of a vague request.

A good packet answers questions like:

what outcome are we trying to achieve
what is explicitly in and out of scope
what proves the change is done
what dependencies or affected systems matter
what risks need special attention
what roll-forward path exists if this goes badly
what evidence should accompany the handoff

That sounds close to good issue writing, and it is. The difference is that the packet needs to be written for execution, not just prioritization. A backlog item can tolerate some ambiguity because a human will usually resolve it on the fly. Agents mostly turn that ambiguity into review work.

This is also where Copilot CLI /research and /plan mode help. /research helps gather the relevant code, docs, and constraints before implementation starts. /plan forces that context into an explicit approach, which is often the fastest way to expose fuzzy intent before it turns into bad code and noisy review. For more formal requirements and plans, frameworks like SpecKit can be used.

This is one of the quieter shifts in the agentic era. Product thinking, architecture thinking, and delivery thinking have to meet earlier. Handoff quality at the start now does a lot to determine how expensive the review and recovery path will be at the end.

Clean Codebases Are Not Just a Nice-to-Have

This is the unglamorous part, but it matters. If your codebase is hard to understand, your agents will make hard-to-review changes. If it has weak tests, the evidence attached to those changes will be weak too. If ownership is fuzzy, review routing will be fuzzy as well.

A lot of teams get a system to deployable shape, then spend years layering fixes and workarounds instead of improving the structure underneath. That is survivable in a system changing at human-speed. It gets much more expensive when you add agents that can produce changes faster than the system can absorb them.

For some teams, the first serious agentic investment should not be net-new feature work. It should be test expansion, modular refactoring, better ownership metadata, and clearer repository guidance. Those are not side quests. They are how you build the context infrastructure that makes autonomy safer.

Once that foundation improves, the payoff compounds. Agents can navigate the system more accurately, reviewers can reason about changes faster, and the codebase becomes a source of truth instead of a source of confusion.

Documentation Is Now an Execution Input

I think this is the point many teams still underestimate. Documentation gets treated as onboarding material or compliance residue. In an agentic system, it is also an execution input.

That includes obvious things like API contracts and architecture notes, but it also includes all the little details that experienced teams accumulate over time: naming conventions, test expectations, release rules, migration patterns, and operational caveats. If those things are not discoverable, agents will either miss them or infer them poorly.

DORA has written about documentation quality as a capability amplifier, and that framing fits here. Good documentation does not just help people ramp up. It improves change quality because the system becomes easier to understand and safer to modify.

The reverse is also true. Doc rot is not a cosmetic issue. It is a delivery failure mode. If the docs say one thing and the code or platform behavior says another, review slows down, false confidence rises, and both humans and agents learn not to trust the written system.

That is why I think mature teams will maintain docs the way they maintain tests: continuously, as part of the normal flow of change.

Note: Teams should leverage agents for this work! The Documentation Updater sample is a practical pattern for keeping docs aligned with code changes.

Policy Is the Runtime

Context alone is not enough. Even perfect documentation does not replace guardrails.

In a human-only workflow, policy often lives too far from the moment of execution. You see it in tribal review norms, security checklists, end-of-release approvals, or an outdated wiki page nobody opens until something goes wrong. That model does not scale when change volume rises.

Policy has to run where the work happens.

In practice, that means using repository rulesets, required checks, CODEOWNERS, secret scanning, code scanning, dependency review, environment protections, audit logs, and CI/CD automation that enforces the standards the team claims to care about.

This is not about distrusting developers or agents. It is about reducing variance. Good policy removes low-value decisions from the critical path and reserves human judgment for the places where judgment actually matters.

That distinction matters. If every PR gets the same human scrutiny regardless of risk, your reviewers become the bottleneck and the review signal gets diluted. If low-risk work can flow through strong automated controls, humans can spend their time where the blast radius is real.

Review by Risk, Not Ritual

The old habit is ritual: every change gets the same ceremony. Agentic engineering calls for a new habit: calibration: review in proportion to risk.

A low-risk documentation fix should not wait in the same queue or require the same depth of analysis as an auth change, a payment flow change, or infrastructure that can disrupt production. Agentic delivery makes that distinction more important because the system can generate a lot of small, safe changes alongside a smaller number of high-consequence ones.

Teams need an explicit risk model:

every PR gets Copilot Code Review plus baseline checks
low-risk work gets fast automated validation and lightweight review, or automatic approval where policy allows
medium-risk work gets normal peer review plus targeted integration tests
high-risk work gets deeper human review, stronger evidence, and tighter deployment controls

The point is not bureaucracy. It is calibration. You want the amount of human attention to match the potential downside of the change.

Note: Once again, Agentic Workflows can be used - create a workflow that categorizes PRs by risk level and labels or routes them accordingly. For example, a PR that changes infrastructure code might automatically get labeled as “high-risk” and require additional checks or approvals.

This is also where evidence-bearing handoffs matter. A good handoff does not just say, “I changed some files, please review.” It says: here is the intent I believe I implemented, here are the files I changed, here are the tests I ran, here are the risks I still see, and here is what I did not do from the acceptance criteria. That turns review from guesswork into decision-making.

The Control Plane in GitHub Terms

Teams should think of this as a layered control plane.

Copilot custom instructions, custom agents, and Skills shape how work gets interpreted and executed. /research, /plan and/or Issue/PR templates provide the context packet. Actions and required checks verify behavior continuously. CODEOWNERS and ownership metadata route the work to the right humans. Repository rulesets enforce the non-negotiables. Environment protections and deployment approvals contain higher-risk changes. Audit logs and PR history preserve the evidence trail.

These features add a bit of value in isolation. But real value comes from how they combine. The agent gets better context at the start, the system enforces better policy during execution, and the reviewer receives a smaller, clearer unit of work with better evidence attached.

The more autonomous execution becomes, the more deliberate the surrounding system has to be. Speed without a control plane is just faster risk accumulation.

New Operating Rituals

Once you accept that context and policy are part of the runtime, a few rituals start to change.

Standups matter less as status broadcasts and more as exception handling. Review queues need active triage because review latency becomes a first-order constraint. Retrospectives should look at flow, false positives, noisy checks, stale docs, and policy gaps, not just missed estimates. Teams also need a visible backlog for context maintenance, because docs and instructions decay unless someone owns that work.

Conclusion

In Part 1, I argued that AI changes where the bottlenecks live. Part 2 is the operational consequence of that shift. If agents are going to produce meaningful amounts of code, context stops being background material and policy stops being a late-stage gate. They become infrastructure and runtime.

Better context improves autonomy. Stronger policy makes speed safer. Teams that build this control plane will scale agentic delivery far more effectively than teams that simply add more agents to a messy system.

In Part 3, I’ll look at the next implication: when code gets cheaper, judgment becomes the scarce capability.

Happy shipping!

From Sprints to Swarms, Part 1: AI Made Code Cheap But Delivery Hard.

2026-04-03T09:00:00+00:00

Series
Part 1: AI Made Code Cheap But Delivery Hard
The Pull Request Is the Unit of Flow
Then vs Now
New Bottlenecks
Metrics That Matter
Dual-Lane Execution
Conclusion

Series

We all know that software engineering has been irrevocably changed by LLMs and agents. It is a mistake to think the main change is faster typing. It isn’t. The bigger change is economic: when code gets cheaper, the delivery system becomes the constraint.

This series is about what that means for software teams. Part 1 is about flow. Part 2 will cover context and policy. Part 3 will cover judgment and the changing role of the developer.

Part 1: AI Made Code Cheap But Delivery Hard

Copilot, Chat, and now agents have expanded the amount of software I can produce. They let me tackle work I would have avoided a few years ago because it was too laborious, too time consuming. But they have also exposed something uncomfortable: faster code generation does not automatically mean faster delivery.

Before joining GitHub in 2021, I spent more than a decade in DevOps consulting. From that angle, most “agentic engineering” problems look familiar: they are still about process and culture more than about the tools. The labels may have changed, but most of the constraints have not. If code is cheaper, then review quality, test quality, merge flow, context management and architecture discipline matter even more.

The Pull Request Is the Unit of Flow

Agile teams broke work into stories, estimated them with story points, and synchronized through sprints. That made sense when the system was shaped around human constraints: people are single-threaded, context is limited, and coordination is expensive.

Agents weaken those assumptions. Work can now be decomposed and executed in parallel, often asynchronously. That shifts the real unit of flow from the story to the pull request.

Teams should measure flow at the PR level: idea-to-PR (how fast can we code it), PR-to-merge (how fast can we validate it), and merge-to-production (how fast can we deliver it).

Then vs Now

Sprints, standups, and estimates are coordination tools. They help humans batch work, surface blockers, and synchronize periodically.

Agentic delivery looks different. You can have a continuous stream of PRs from multiple agents working in parallel. That changes the role of the human. The highest-value work shifts toward framing problems, resolving ambiguity, setting policy, reviewing risk, and deciding what is worth shipping.

It also breaks batch-oriented quality practices. QA cannot stay at the end of the sprint. Security cannot be a late gate. Governance cannot depend on tribal knowledge. Quality, policy, and context have to move earlier and run continuously.

This is where many teams get stuck. They add AI at the edge of the system, but leave the delivery model untouched. The result is predictable: more code entering the pipe, with the same review capacity and the same weak automation.

New Bottlenecks

The bottlenecks do not disappear. They move:

Review throughput - can review capacity keep pace with PR volume?
Test quality - do tests catch regressions without creating noise?
CI quality - is verification fast, trustworthy, and automated?
Merge latency - how long do approved changes sit before merge?
Context quality - do people and agents have the right information at the right time?
Ownership clarity - who decides, reviews, and accepts risk?

Metrics That Matter

Business outcomes matter more than agent benchmarks. If faster code does not produce better delivery, the optimization is irrelevant. Start with a few operational metrics that expose flow quality:

PR size - larger PRs increase review cost and defect risk
Review latency - how long it takes a PR to get meaningful attention
Median time-to-merge - the clearest signal of delivery friction
CI pass rate - whether your verification system is doing its job
Agent-authored PR ratio - how much work is entering the system through agents
Agent-authored PR outcomes - whether that work is actually getting accepted and shipped

Dual-Lane Execution

Not all work should go to agents. A useful model is dual-lane execution: one lane for human judgment, one for agent execution.

Humans are better at ambiguity, trade-offs, architecture, and accepting risk. Agents are better at bounded fixes, repetitive refactors, test generation, documentation updates, and parallel experiments.

The point is not rigid separation, but intentional routing. Agents simply cannot do everything, despite the hype. But we can probably give more work than we realize to agents. Good teams decide which lane owns which kind of work, then revisit that split as the agents evolve. Here is a rough sketch of how that might look:

Human Lane	Agent Lane
Ambiguity resolution	Bounded fixes
Vision	Research, planning
Architecture decisions	Test generation
Product trade-offs	Refactoring
Risk acceptance	Documentation updates
Escalation handling	Repetitive toil
Assessing business impact	Parallel experiments

Conclusion

AI did not remove the need for DevOps. If anything, it increased it. When code gets cheaper, flow discipline, verification, and judgment become more important, not less.

Treat the PR as the unit of flow. Design for continuous review and verification. Be explicit about which work belongs to humans and which belongs to agents. In Part 2, I’ll look at the next constraint: context and policy as operational infrastructure.

Happy shipping!

Transform Your SDLC with Agentic Workflows

2026-02-12T09:00:00+00:00

Intent-driven Development
What Are Agentic Workflows?
Benefits of Agentic Workflows
What can you do with Agentic Workflows?
Anatomy of an Agentic Workflow
Updating a project when a dependency changes: A real example
A New Way of Thinking: Intent Over Implementation
1. Failed Build Autofix
2. Patterns worth exploring
Security considerations
Tips and Gotchas
Conclusion

In this post, I’ll show you how GitHub Agentic Workflows fundamentally change the way you should think about automation, and why “Continuous AI” is the next frontier of agentic software delivery. I’ll cover what Agentic Workflow are and show a real example where a few sentences of intent replace hours of manual SDK tracking, issue creation, and implementation work.

Intent-driven Development

For years, teams have been scripting automation in declarative languages like YAML. If you needed a weekly automation, you had to learn the cron syntax, chain together actions, write scripts, wire up secrets, parse outputs, handle edge cases, and debug failures. The logic lives in rigid procedural steps, and every new workflow requires you to think like a build engineer.

Most automation teams rely on today is a rigid set of steps. We’re now at an inflection point where we need to start thinking in terms of outcomes instead. GitHub Actions is fantastic for repeatable processes that checkout, build and test the applications we work on day to day. But how can we add more intelligence into these workflows?

In a previous post about “self-healing DevOps”, I showed how to inference build failure analysis via GitHub models wrapped in Actions steps. The idea was solid: “Why should I debug failed builds - surely models are better at trawling build logs and diagnosing issues than I am?” - but the implementation was laborious and required writing procedural logic in YAML, even if there was some inferencing sandwiched in the middle.

But what if there was an easier way to perform regular, intelligent tasks on a codebase? What if you could describe a goal in natural language, and have that intent transpiled into a GitHub Actions workflow? That’s exactly what Agentic Workflows do. They abstract workflows into natural language.

When I first saw the demo of Agentic Workflows at Universe 2025 I was intrigued, but unconvinced. The barrier to entry was still fairly steep - there was a GitHub CLI extension that you had to install and you had to author markdown with special frontmatter before you got to a workflow. However, the amazing team at GitHub Next has done a fantastic job iterating on the experience and reducing a lot of friction. And the mind shift of “use agentic workflow to generate agentic workflows” is a game changer - and definetely carries tones of Inception!

Agentic Workflows is an open source repo in technical preview and you can use it today. The framework is the enabler of some of the ideas I’ve been writing about for a while now like Agentic Software Delivery, eight principles for ASD and teaching async thinking. This is the next chapter that makes all of these “Continuous AI” concepts practical.

What Are Agentic Workflows?

Agentic Workflows are not just another way to write GitHub Actions. They represent a fundamental shift in how we think about automation. They empower “intent driven development”. Here is the process:

Use a simple prompt to instruct Copilot Coding Agent (CCA) to bootstrap the agentic workflow prerequisites into your repo. This adds steps to install the gh CLI and the gh-aw extension, and creates a custom agent that help Copilot understand how to make new agentic workflows.
Use a simple prompt (and the custom agent from the boostrap) to describe a workflow you want - Copilot writes a markdown file for you.
You can edit the markdown file if you want to - but it’s better to use the custom agent to refine the workflow for you. You should never edit markdown or YAML directly - just talk to your agent in natural language and let it do the work of creating the markdown and YAML for you.

Benefits of Agentic Workflows

Natural language intent and iteration: Describe what you want to achieve, instead of how to make it happen. The agent figures out the implementation details. This lets you iterate in natural language rather than having to program scripts and workflows by hand.
Scale and familiar framework: Agentic Workflows are really just GitHub Actions workflows that invoke the Copilot CLI under the hood, so they run on the same infrastructure, with the same reliability, scale and performance you already have.
Built-in security: The framework includes structural guardrails like a sandboxed read-only environment to ensure that your agent can’t do anything you don’t explicitly allow. Safe outputs, network controls, and AI-powered threat detection make it safe to give agents more responsibility.
Enhanced fontmatter: The fontmatter that Agentic Workflows introduces is more expressive than Actions metadata, leading to richer specifications, triggers, permissions, and engine options. But you don’t need to know all the details, since you can just tell your agent what you want and it will generate the correct markdown and frontmatter for you. For example, telling the agent to execute a workflow “daily” will lead to a cron expression that randomizes the time of day so that you spread out your runs and avoid hitting rate limits.
Traceability: Each Actions run that contains an Agentic Workflow gets a unique ID - that ID is added to any issues or PRs that the workflow creates, so you can easily trace outputs back to the specific workflow run and its associated markdown instructions. This is extremely helpful for debugging, auditing and searching (the repo semantic search will find mardown, YML and issues created by the workflow, and you can correlate all of those together via the unique ID).

What can you do with Agentic Workflows?

The truth is that the possibilities are really endless - you’re truly only limited by your imagination. There are a couple of canonical scenarios that are a great fit for Agentic Workflows:

keeping documentation up to date
monitoring dependencies for updates and vulnerabilities
triaging issues and PRs
generating release notes
optimizing code and detection duplicate code
analyzing CI failures and creating remediation issues

But the sky is the limit. If you can describe it, you can probably build it. The best way to get a sense of the possibilities is to check out the Agentic Workflows gallery and see the examples that the GitHub team has built - and then start thinking about how you can build your own.

Anatomy of an Agentic Workflow

At this point, I would normally show you a snippet of a workflow markdown or YAML, but I won’t do that here. You shouldn’t ever have to see or edit these files, since you can just talk to your agent in natural language and let it do the work of creating and refining these files for you. Instead, I’ll show you the actual prompt I used to create a workflow, and then I’ll break down the resulting markdown file so you can understand how the intent maps to the implementation.

There are a couple of artifacts that the bootstrap process creates in your repo and then every repo consists of two files in the repo:

.github/agents/agentic-workflows.agent.md - this is the custom agent file that helps Copilot understand how to create and refine agentic workflows. You can tell your agent “Make me a new workflow that does X” and it will use the instructions in this file to generate the correct markdown and YAML for you.
.github/workflows/copilot-setup-steps.yml - if this does not exist, the agent will create it for you, otherwise the bootstrap will just add the gh-aw CLI setup steps to the existing file.

Then, for each workflow you create via a prompt, you get two files:

.github/workflows/agentic-workflow.md - this file has frontmatter that defines triggers, permissions, and other metadata for your workflow, and a markdown body that describes the intent in natural language.
.github/workflows/agentic-workflow.lock.yml - this is the file that gets transpiled by the gh-aw CLI and executed by GitHub Actions. It has all the security hardening, sandboxing, and threat detection baked in.

Once again: never ever edit the .lock.yml file. You can edit the markdown body if you want to refine the intent, but it’s better to talk to your agent and let it update the markdown for you.

Note: While the .lock.yml file is an committed to the repo, you should consider it a build artifact rather than source code. When a workflow executes, it will fetch the intent from the markdown of the workflow.md file. You only need to update the .lock.yml file when you change the frontmatter in the .md file - and if you use Copilot to perform your updates with the custom agent, this is done for you.

Updating a project when a dependency changes: A real example

I was recently playing with the Copilot SDK and wanted to create a simple TUI (text-based UI) to experiment with the SDK and show off some of its capabilities. I built Planeteer as an experiment in work breakdown and orchestration using Copilot. But even as I was building Planeteer, I realized that the SDK was changing rapidly - new features, API changes, and improvements were landing on a daily basis. I wanted to stay up to date with those changes and incorporate them into Planeteer, but it was a lot of manual effort to track the SDK repo for updates, read changelogs, analyze relevance, create issues and implement changes. This is a perfect scenario for an Agentic Workflow.

I headed to the Planeteer repo and clicked on the “Agents” tab. I bootstrapped Agentic Workflows by typing in this prompt (copied from the Agentic Workflows getting started docs):

Initialize this repository for GitHub Agentic Workflows using https://raw.githubusercontent.com/github/gh-aw/main/create.md

Copilot Coding Agent (CCA) got to work and created the necessary files to set up the framework in my repo and submitted a PR with the changes. I merged that PR, and then I was ready to create my first workflow.

I also added two secrets (tokens) to the repo since these are required for the workflows I had in mind: one for Copilot inference (GH_COPILOT_TOKEN) and one for assigning Copilot to issues and PRs GH_AW_AGENT_TOKEN. The auth page has detailed instructions on how to create these tokens and what permissions they need.

Now I was ready to create a workflow. I went back to the “Agents” tab, ensured that I was using the agentic-workflows custom agent and typed in this prompt:

Check the release notes and recent commits in `github/copilot-sdk`.
Identify new features or enhancements from the last 7 days.
Suggest 3 ways to use these updates to improve my app.
For each suggestion, create a GitHub Issue with implementation details and assign it to Copilot for implementation.
Run this workflow once a week on Wednesdays.

Selecting the agentic-workflows custom agent to create a new workflow.

CCA got to work and in a few minutes I had a PR with the new workflow. I checked through the markdown quickly, and it looked good - the frontmatter had the correct triggers and permissions, and the body had a clear description of the intent. I merged the PR, and now every Wednesday, this workflow runs, checks the SDK for updates, creates issues with enhancement suggestions, and assigns them to Copilot for implementation. I review the PRs that Copilot creates when I’m ready, provide feedback, and merge what makes sense.

Let’s take a quick look at the markdown file - but remember, you don’t need to mess around with the markdown or YAML - just talk to your agent in natural language and let it do the work for you!

---
description: Weekly analysis of Copilot SDK releases and commits to suggest project enhancements
on:
  schedule: weekly on wednesday
permissions:
  contents: read
  issues: read
  pull-requests: read
tools:
  github:
    toolsets: [default]
safe-outputs:
  create-issue:
    title-prefix: "[enhancement] "
    labels: [enhancement, ai-suggestion]
    assignees: [copilot]
    max: 3
  assign-to-agent:
    name: copilot
    max: 3
---

# Weekly Enhancement Suggestions

You are an AI agent that monitors the GitHub Copilot SDK (`github/copilot-sdk`) for new releases, features, and changes, then suggests how they can be leveraged in the Planeteer project.

## Context

This repository contains **Planeteer**, an AI-powered work breakdown and parallel execution TUI built with Ink (React for terminals) and TypeScript. Planeteer depends on **`@github/copilot-sdk`** for AI-powered project planning and execution. All Copilot SDK interactions are isolated in `src/services/copilot.ts`.

## Your Task

1. **Gather recent activity** from the last 7 days in the **`github/copilot-sdk`** repository (https://github.com/github/copilot-sdk):
   - List recent releases and release notes
   - List recent commits to the `main` branch from the past week
   - Review any notable changes, new features, bug fixes, API updates, or deprecations

2. **Review this project** (`${{ github.repository }}`) to understand how the Copilot SDK is currently used:
   - Read `src/services/copilot.ts` to understand the current SDK integration points
   - Check `package.json` for the current SDK version
   - Understand the project architecture to identify where SDK updates could have impact

3. **Analyze the Copilot SDK changes** and identify opportunities for this project:
   - Determine which new SDK features or API changes could benefit Planeteer
   - Consider new capabilities that could improve the clarification, breakdown, refinement, or execution flows
   - Identify any deprecations or breaking changes that require attention
   - Think about how new SDK features could unlock better UX, performance, or reliability

4. **Create exactly 3 enhancement suggestions** as GitHub issues in this repo. Each issue should:
   - Have a clear, descriptive title summarizing the enhancement
   - Include a detailed body with:
     - **Background**: What recent Copilot SDK commit(s) or release(s) inspired this suggestion, with links to the relevant changes in `github/copilot-sdk`
     - **Proposal**: A clear description of how to leverage this SDK update in Planeteer
     - **Benefit**: Why this enhancement would improve the project
     - **Acceptance Criteria**: Specific, measurable criteria for completion
   - Be actionable and scoped appropriately for a single task

5. **Assign each issue to Copilot** for implementation using the `assign-to-agent` safe output.

## Guidelines

- Focus on practical, high-value enhancements that take advantage of new Copilot SDK capabilities.
- Each suggestion should be independent and self-contained.
- Ensure suggestions are diverse — cover different aspects of the project (e.g., one for new SDK features, one for performance or reliability improvements, one for UX enhancements enabled by SDK updates).
- If there are no releases or commits in the Copilot SDK repo in the last week, base your suggestions on the current SDK capabilities that Planeteer is not yet using.
- When referencing recent activity, attribute changes to the humans who authored them, not to bots or automation tools.
- Use GitHub-flavored markdown for issue bodies.

## Safe Outputs

- Use `create-issue` to create each of the 3 enhancement issues.
- Use `assign-to-agent` to assign Copilot to each created issue.
- If for any reason you cannot identify meaningful enhancements, use the `noop` safe output with a message explaining why.

You can see how the frontmatter defines the triggers, permissions, tools and safe outputs, while the body describes the intent in natural language.

Here’s an example of one of the issues that gets created by the workflow. And since the workflow assigns the issue to Copilot, you can see the PR that Copilot creates to implement the issue as well: example PR.

If I click “Edit” on the Issue body, I also see the following hidden HTML metadata:

<!-- gh-aw-agentic-workflow: Weekly Enhancement Suggestions, engine: copilot, run: https://github.com/colindembovsky/planeteer/actions/runs/21970499900 -->

<!-- gh-aw-workflow-id: weekly-enhancement-suggestions -->

Searching weekly-enhancement-suggestions in the repo yields code references (to the workflow files) as well as any issues created by the workflow, and you can easily correlate these together to trace outputs back to the specific workflow run and its associated markdown instructions.

A New Way of Thinking: Intent Over Implementation

This is the mindset shift that matters most. For over a decade, “automation” has meant “write the steps.” Need to check an API? Write a curl command, parse the JSON, handle errors, format the output. Need to create an issue? Construct the body string, call gh issue create, capture the URL.

Agentic Workflows ask a different question: what do you want to happen?

You don’t script the API call. You don’t build the JSON parser. You don’t format the issue body. You describe the outcome, and the agent handles the implementation. The framework provides the guardrails that make this safe: read-only execution by default, writes only through scoped “safe output” jobs, network egress controls via a firewall, and AI-powered threat detection that scans all outputs before they’re externalized.

This isn’t “vibe coding your CI.” The structure is there. The security is there. The deterministic parts of your pipeline stay deterministic. But the intelligent, context-dependent tasks that you’ve been putting off (or doing manually) can now be expressed as intent.

Think of it this way: you wouldn’t write YAML to tell a teammate how to review a PR. You’d say “check if the tests pass, flag any security concerns, and make sure the docs are updated.” Agentic Workflows let you talk to your automation the same way.

Failed Build Autofix

In a past post I outlined the “manual way” to create “self-healing DevOps”. This can now be replaced by a prompt like this to CCA using the agentic-workflow custom agent:

Create a workflow that runs on every failed build. The workflow should analyze the build logs, identify the root cause of the failure, and if it's a common issue with a known fix, automatically create a PR with the fix and assign it to Copilot for implementation.

Much easier!

Patterns worth exploring

The planeteer SDK monitor is just one pattern. The Agentic Workflows gallery showcases several others:

DailyOps: Generate a daily repo status report - open PRs, stale issues, CI health, contributor activity
IssueOps: Auto-triage incoming issues, add labels, request clarification, and route to the right team
ChatOps: Respond to PR comments with agent-driven code analysis, suggestions, or documentation
Continuous Documentation: Keep READMEs, API docs, and architecture diagrams in sync with code changes
Failure Analysis: Analyze CI failures and create remediation issues (the structured evolution of my self-healing DevOps approach)
Multi-Repo Orchestration: Coordinate changes across multiple repositories when a shared dependency updates

The common thread is that these are all tasks where you know what you want but the how requires judgment and context. That’s exactly the sweet spot for Agentic Workflows.

Security considerations

Giving an AI agent write access to a repo sounds terrifying. But Agentic Workflows are designed with security in mind. Here’s why the security model matters:

Read-only by default: The agent runs in a sandboxed container with read-only access. It can browse code, read issues, and fetch data, but it can’t write anything during execution.
Safe Outputs: Writes happen in separate jobs with explicitly scoped permissions. If your workflow only declares issues as a safe output, the agent can’t push code or merge PRs, even if you accidentally instruct it to.
Agent Workflow Firewall: The agent container uses iptables-based network egress controls via a Squid proxy. You can allowlist specific domains and block everything else.
Threat Detection: Before any safe output is externalized, an AI-powered pipeline scans for secret leaks, malicious patches, injection attempts, and policy violations.
Content Sanitization: Inputs are scrubbed of @mentions, bot triggers, HTML/XML tags, and untrusted URIs to prevent injection attacks.

When creating or updating workflows, the compilation step (gh aw compile) bakes all of this into the .lock.yml file. You can audit it, review it, and version-control it just like any other Actions workflow.

Tips and Gotchas

Start small: Try one workflow in one repo. A daily status report or issue triage is a great first candidate. Get comfortable with the model before scaling up.
Iterate on the body, not the frontmatter: Edits to the markdown instructions take effect on the next run without recompilation. Frontmatter changes (triggers, permissions, engine) require gh aw compile. Even better - don’t edit the markdown at all. Just instruct CCA (using the agentic workflow custom agent) to update the workflow for you.
Cost awareness: The Copilot engine uses 1-2 premium requests per run. Track usage with gh aw logs. If you’re running daily across many repos, the costs add up.
Use workflow_dispatch for testing: By default, agentic workflows include a workflow_dispatch trigger so that you can manually trigger workflows without waiting for the schedule.
Be specific in your instructions: Agents perform better with clear, structured prompts. List steps, define priorities, and handle edge cases explicitly. Think of the markdown body as a detailed brief for a capable but literal colleague. There’s no limit to the number of workflows, so you can even break complex processes into multiple smaller workflows that call each other via issue creation or repository dispatch.

Note: Agentic Workflows are actively evolving. Expect changes to the CLI, engine options, and security features. Pin to specific versions and monitor the documentation for updates.

Conclusion

Agentic Workflows represent a fundamental shift in how we think about automation. Instead of scripting steps in YAML, you declare intent. Instead of building one-off integrations, you describe outcomes and let AI agents handle execution. The combination of Agentic Workflows, GitHub Actions, and Copilot creates a natural language continuous AI loop where your codebase improves itself - with you in the decision seat, not the execution treadmill.

The Planeteer example shows what this looks like in practice: a few sentences of intent replace hours of manual SDK tracking, issue creation, and implementation work. Every Wednesday, the loop runs. Issues appear. Copilot submits PRs. I review and merge. The app evolves.

This is one example of why the GitHub platform is so powerful. We provide the building blocks - Actions for automation, Copilot for intelligence, and now Agentic Workflows for intent-driven development. The possibilities are endless, and we’re just scratching the surface of what’s possible when you combine these capabilities.

Happy automating!

Extract and visualize PR counts using the Copilot Enterprise Metrics API

2026-02-02T09:00:00+00:00

Prerequisites
Step 1 — Create the GitHub App and capture IDs
Step 2 — Clone the repo and install dependencies
Step 3 — Run the script
Step 4 — Review the outputs
Alternatives and tips
Conclusion

In this post, I’ll show you how to download and visualize Copilot PR counts (for Coding Agent and Code Review Agent) using metrics from your GitHub Enterprise using a python script. You’ll end with the JSON usage report plus a PR summary chart that visualized PRs created by humans and Copilot Coding Agent (CCA), and number of Code Reviews from humans and Copilot Code Review (CCR). This will help you keep tabs on how much usage you’re getting from CCR and CCA.

Note: This visualization isn’t very sophisticated given the limits of the PR metrics available. It would be great to see and compare lead times for PR merges (time from open to merge) and compare those PRs with to those without CCR reviews - or even to split out by org or team! But this visualization at least gives you an idea at a coarse Enterprise level how many PRs are created by CCA and how many PRs are reviewed by CCR.

The code for this post is in this repo.

Prerequisites

You’ll need:

Enterprise owner access in GitHub.
A GitHub App installed in your enterprise (instructions in the sample repo).
Python 3 and pip.

Assumptions: You have permission to create and install GitHub Apps in your GitHub enterprise. If you do not, ask your enterprise admin to help. The “app” is more like a service account - there’s no code at all!

Step 1 — Create the GitHub App and capture IDs

Create a GitHub App at the enterprise level, capture the IDs and download the private key pem file. The full instructions are detailed in the README file.

Step 2 — Clone the repo and install dependencies

Use the following commands to clone the repo, activate a python virtual environment and install the dependencies.

git clone https://github.com/colindembovsky/copilot-pr-metrics.git
cd copilot-pr-metrics
python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt

Step 3 — Run the script

Run the script with your app details to fetch the latest 28-day enterprise usage report and generate PR metrics. You can enter the values as args or create a test.env file in the repo root like this:

APP_ID=123456
INSTALLATION_ID=987654321
PRIVATE_KEY=path/to/app-key.pem
ENTERPRISE=your-enterprise-slug
API_BASE=https://api.github.com
OUTPUT=metrics-YYYY-MM-DD.json

Run the python command to download all the usage data as well as generate the chart of PR counts.

python copilot_metrics.py \
  --app-id <GITHUB_APP_ID> \
  --private-key <PATH_TO_PRIVATE_KEY_PEM> \
  --installation-id <APP_INSTALLATION_ID> \
  --enterprise <ENTERPRISE_SLUG>

Step 4 — Review the outputs

The script downloads the enterprise Copilot usage report (last 28 days) and produces a PR summary chart showing human PRs and Copilot PR activity for Copilot Coding Agent and Copilot Code Review. For an example chart, see the repository’s sample-chart.png.

Alternatives and tips

For automation, schedule the script in a CI workflow or a cron job and version the JSON output in a metrics repository or create an Issue with the chart image.
Use the --output flag or the OUTPUT variable to keep a dated archive of metrics files.

Conclusion

You now have a repeatable way to download Copilot usage data and visualize PR activity using a GitHub App. From here, you can automate collection and build trend reporting.

Happy measuring!

The Agentic Future of Software Delivery: My AWS re:Invent 2025 Session

2025-12-09T10:00:00+00:00

Watch the Session
Session Overview
What’s Next?
Conclusion

I recently had the privilege of presenting at AWS re:Invent 2025 in Las Vegas. In this session, I traced the history of developer productivity tools from punch cards through IDEs and into the era of AI pair programming and autonomous agents. If you missed it, you can watch the full recording below.

Watch the Session

The Agentic Future of Software Delivery - AWS re:Invent 2024

Session Overview

The session covers the evolution of tools designed to decrease the time it takes to get from idea to deployment (also sometimes called “developer productivity”):

The Early Days: From punch cards and batch processing to interactive terminals
The IDE Revolution: How integrated development environments transformed coding
AI Pair Programming: GitHub Copilot’s code completions started a revolution in 2021
The Agentic Future: Where autonomous agents are taking software delivery
Industry Themes: What trends are we seeing in the industry - and how is GitHub building for those?
GitHub Universe Ships: What announcements and ships GitHub made at Universe (in Oct 2025)

What’s Next?

The agentic future isn’t coming - it’s here. Even if you are faster at “coding” you can dilute those gains if you spend more time planning and validating! GitHub’s visions is to bring agentic capabilities to all parts of the SDLC so that you can scale your acceleration beyond the IDE.

Agentic workflows are not just about new shiny tools - they are about a new way of thinking and working. For more on these topics, see my posts about principles of agentic software delivery and teaching async thinking.

Conclusion

Thanks to everyone who attended the session at re:Invent. The energy in Las Vegas was incredible, and the questions from the audience showed just how much interest there is in this space. We’re at an inflection point in software development, and I’m excited to see how teams embrace these new capabilities.

Happy building!

Teaching Your Team to Think Async-First with GitHub Copilot

2025-11-25T09:00:00+00:00

The Fundamental Question: “Should Copilot Do This?”
Practical Async Patterns: Examples That Work
Redesigning Workflows for Parallel Experimentation
1. What Breaks in Async Workflows
2. New Coordination Patterns
Teaching the Mindset: What to Delegate, What to Keep
1. Copilot Excels At
2. Humans Excel At
Overcoming Resistance: “This Feels Like Cheating”
Conclusion

The Fundamental Question: “Should Copilot Do This?”

Once you’ve built an enablement program (see my companion post on Building a GitHub Copilot Enablement Program That Actually Works), the next challenge is teaching your team a new way of thinking.

The fundamental shift is asking a new question before starting any task: “Should Copilot do this instead of me?”

This isn’t about laziness - rather, it’s about leverage. When Copilot handles routine tasks, developers have more cognitive bandwidth for architecture, business logic, and creative problem-solving. But most developers have years of muscle memory telling them “I must do this myself.”

The core shift your team needs to make is recognizing which work should be delegated to Copilot versus done manually. In this post, I’ll show you practical patterns for async, multi-threaded development where AI handles routine work in parallel while humans orchestrate and make decisions.

Practical Async Patterns: Examples That Work

Let’s look at specific tasks where async thinking delivers massive wins.

Test Generation

Traditional approach: Developers write feature code then spend hours crafting test cases, debugging failures, and iterating until coverage is acceptable.

Async approach with Copilot: You describe behavior in comments as you write features, then ask Copilot to generate comprehensive tests including edge cases. Review the generated tests to ensure assertions meaningfully verify the contract (not just pass), adjust as needed, and move to your next task while Copilot handles integration tests in the background.

This delivers huge time savings while often improving coverage, since AI identifies edge cases humans miss.

Key technique: Create custom agents for testing to encapsulate your team’s patterns and ensure consistent output.

Documentation

Traditional approach: Docs fall out of date because writing them is tedious. Developers ship features, promise to “update docs later,” and never do.

Async approach with Copilot: Copilot generates README sections, API documentation, and code comments alongside your implementation, making it fast enough that developers actually keep docs current.

Key technique: Use Copilot Chat to generate documentation as you go. Prompt: “Generate API documentation for this function including parameters, return values, and usage examples.”

Prototyping Multiple Solutions

Traditional approach: Teams debate approaches theoretically in design meetings. They pick one design, discover limitations during implementation, then either live with them or go back to design. This cycle wastes days.

Async approach with Copilot: Create multiple GitHub issues describing different approaches and assign them all to Copilot coding agent. Within hours, you’re reviewing three actual implementations side by side, making decisions based on real code rather than speculation.

This saves days compared to sequential implementation and dramatically improves decision quality.

Key technique: Write clear, detailed issue descriptions. Copilot coding agent works best when you specify requirements, constraints, and success criteria upfront.

Build Failure Analysis

Traditional approach: Developers scroll through hundreds of lines of logs guessing at root causes. They ping team members for help. They search Stack Overflow. It takes hours to diagnose complex failures.

Async approach with Copilot: GitHub Actions can automatically invoke Copilot to analyze failures, categorize them (code, config, test, infrastructure, transient), and generate remediation plans with the appropriate team member tagged.

You can implement this today with the actions/ai-inference action and GitHub Models (see my post on self-healing devops for details).

Key technique: Set up automated workflows that capture build/test output and feed it to Copilot with context about your repo structure and conventions.

Code Optimization

Traditional approach: Developers manually review code for dead imports, unused variables, inefficient algorithms, and memory leaks. They profile the application, identify hotspots, then spend hours refactoring. Code reviews often catch optimization opportunities too late, after the feature ships.

Async approach with Copilot: Ask Copilot to analyze your codebase for optimization opportunities while you work on new features. Copilot can identify dead code, suggest more efficient algorithms, highlight memory-intensive operations, and recommend performance improvements.

For example, prompt Copilot Chat: “Analyze this module for optimization opportunities including dead code, inefficient loops, and memory usage.”

This is particularly powerful for refactoring legacy code. Create GitHub issues describing different optimization strategies (memory reduction, CPU optimization, code simplification) and assign them to Copilot coding agent. Compare the results to choose the best approach.

Key technique: Combine Copilot analysis with profiling data. Share performance metrics in your prompt: “This function takes 500ms on average with 10k records. Optimize for speed while maintaining correctness.” Copilot can suggest targeted optimizations based on actual bottlenecks rather than premature optimization.

These patterns represent the essence of async, multi-threaded development: AI agents work in parallel while humans orchestrate and make decisions.

Redesigning Workflows for Parallel Experimentation

Async development requires rethinking how your team coordinates work. Traditional rituals assume synchronous, sequential workflows. They break down when developers work on multiple features simultaneously while AI handles background tasks.

What Breaks in Async Workflows

Daily standups: “What did you do yesterday?” becomes less meaningful when you’re orchestrating multiple parallel Coding agent tasks rather than completing one task yourself.

Code review queues: Reviewers expect PRs to arrive sequentially. In async workflows, developers might open multiple PRs for the same feature (testing different approaches) simultaneously.

Deployment schedules: Batch deployments assume teams synchronize to a release train. Async teams ship when features are ready, not on a schedule.

Design reviews: Traditional design reviews debate approaches theoretically. Async teams prototype multiple approaches with AI and compare actual implementations and working prototypes.

New Coordination Patterns

Here’s what works better for async teams:

Repurpose daily standups: Rather than “what I did yesterday, what I’m doing today and what’s blocking me”, change the format to cover what Copilot is working on, what needs review and what prompts are yielding the best results.

Move to continuous code review: Create a policy that requires Copilot Code Review on all PRs, and continuously iterate on Copilot instructions that help guide the review to your standards and conventions.

Enable on-demand deployments: Shift from “we deploy every Friday” to “we deploy when features pass quality gates.” Use GitHub Actions to automate deployments on merge to main. Requires strong automated testing, but eliminates batching delays.

Invest in good quality gates and policies: including Code Quality and GitHub Advanced Security scans, linting and test coverage. You’re aiming to have high confidence that when all automated gates pass, the PR can be shipped as soon as human review is completed. No waiting for Friday.

Shift design reviews to “build and compare”: Instead of debating approaches in a meeting, create multiple issues describing each approach. Assign to Copilot coding agent or have developers prototype with Copilot assistance. Review actual code, not theoretical designs.

Teaching the Mindset: What to Delegate, What to Keep

The hardest part of async thinking isn’t the mechanics - it’s the judgment. Developers need to learn what work Copilot handles well versus what requires human expertise.

Copilot Excels At

Repetitive code (CRUD operations, boilerplate, type conversions)
Test generation (unit tests, integration tests, edge cases)
Documentation (README, API docs, code comments)
Code transformations (refactoring, format changes, migrations)
Pattern matching (finding similar code, applying conventions)
Performance optimization (is this efficient enough?)
First-draft implementations of well-specified features

Humans Excel At

Architecture decisions (system design, tech stack choices)
Business logic validation (does this match requirements?)
Context synthesis (how does this fit the broader system?)
Ambiguity resolution (what did the stakeholder really mean?)

Key principle: Use Copilot to accelerate execution, but keep humans in the decision loop for validation and high-level thinking.

Overcoming Resistance: “This Feels Like Cheating”

Some developers resist async thinking because it feels like they’re not “really” coding. They worry about skill atrophy or whether they deserve credit for AI-assisted work.

Reframe the conversation:

“Using Copilot isn’t cheating. It’s like using a compiler, debugger, or IDE - it’s a tool that makes you more effective.”
“Your skills shift from typing code to refining specs and reviewing code, which is actually more valuable. Senior engineers spend more time reviewing than typing.”
“You’re orchestrating complexity. That’s higher-level thinking than implementing details manually.”

Address skill atrophy concerns:

“You’re still coding. You’re just moving faster on routine work and spending more time on hard problems.”
“Review every suggestion critically. You’ll learn from seeing multiple approaches to problems.”
“Experiment with Copilot turning off periodically to ensure you retain fundamentals.”

Celebrate the shift:

“Think about what you can build now that you couldn’t before. More features? Better quality? Time to learn new skills?”

Most resistance fades once developers experience the productivity boost firsthand.

Conclusion

Teaching async-first thinking is the key to unlocking GitHub Copilot’s full potential. It’s not just about using AI tools - it’s about fundamentally rethinking how work gets done.

Start by teaching your team to ask “Should Copilot do this?” before starting tasks. Show them practical patterns for test generation, documentation, prototyping, and build analysis. Redesign coordination patterns (standups, code review, deployments) to support parallel work. And help them develop judgment about what to delegate versus what requires human expertise.

The shift from sequential, single-threaded development to async, multi-threaded workflows takes practice. But once your team internalizes the mindset, they’ll wonder how they ever worked any other way.

For the leadership and enablement foundation that makes this possible, see my companion post on Building a GitHub Copilot Enablement Program That Actually Works.

Happy orchestrating!

Building a GitHub Copilot Enablement Program That Actually Works

2025-11-25T08:00:00+00:00

License Distribution Isn’t Enough
The Innovation Curve: Understanding Adoption Patterns
What Leaders Must Build
Building a Continuous Enablement Program
Creating the Right Culture: Celebrate, Measure, Share
The “Sharpen the Saw” Principle: Continuous Learning
1. Building Learning Into the Cadence
Common Pitfalls and How to Avoid Them
Conclusion

License Distribution Isn’t Enough

Many teams are struggling with “AI-hype”: they’ve purchased GitHub Copilot licenses for their teams, but are not immediately seeing massive productivity boosts across the board. Is Agentic software delivery just a marketing term, or can real gains be realized?

Within weeks of provisioning licenses, most teams will notice a pattern: a handful of high performers start achieving remarkable results, slashing time spent on routine tasks, experimenting with new approaches, shipping features faster. Meanwhile, the majority of teams continue working exactly as before, with Copilot sitting idle or producing mediocre suggestions they ignore.

This isn’t a tool problem. It’s a leadership problem.

GitHub Copilot boosts task productivity - most developers instinctively know this. But systemic gains don’t materialize automatically. They require intentional investment in training, cultural change, and workflow redesign. In this post, I’ll share what leaders must build to drive real Copilot adoption, and why productivity improvement is a change management issue rather than a technology issue.

In my companion post, Teaching Your Team to Think Async-First with GitHub Copilot, I cover the specific mindset shifts and workflow changes teams need to make. This post focuses on the leadership and enablement foundation that makes those changes possible.

The Innovation Curve: Understanding Adoption Patterns

When you roll out GitHub Copilot, you’ll encounter a classic innovation adoption curve:

10% Innovators: High performers who immediately “get it”, experiment aggressively, and achieve noticeable productivity gains within weeks
70% Early/Late Majority: Developers who need structured guidance, coaching, and proof points before they change their workflows
20% Laggards: Skeptics who resist AI, worry about job security, or simply prefer their existing muscle memory

The innovators succeed because they have four traits:

they understand prompt context engineering (even if they don’t call it that)
they have an experimentation mindset
they’re comfortable with ambiguity
they continually learn

Many developers don’t start with these skills.

McKinsey research confirms this pattern. Junior developers (less than 1 year experience) were actually 7-10% slower with AI tools when left to figure things out on their own. But organizations that implement coaching programs, use case frameworks, and skills development see consistent gains across all experience levels.

The risk of uneven adoption is real: team friction emerges when some developers are much faster than others. Code quality concerns arise when inexperienced developers trust AI output without verification, and knowledge gaps widen as innovators pull ahead while others stagnate.

What Leaders Must Build

Leaders must build a structured enablement program, not just a rollout announcement. Here’s what that looks like:

Training curriculum with three levels:

Beginner: Copilot basics, prompt patterns, acceptance vs rejection criteria
Intermediate: Context refinement, code review with AI, debugging techniques
Advanced: Custom instructions and agents, agentic workflows, custom MCP servers

Ongoing support beyond one-time workshops:

Weekly “Copilot office hours” where developers bring real problems
Monthly team showcase of wins and techniques
Quarterly skills assessments and refresher training
Peer coaching network with internal champions

Metrics to track effectiveness:

Copilot suggestion acceptance rate
Time saved on routine tasks (measure before/after on sample tasks)
Developer satisfaction scores (survey quarterly)
Feature velocity and cycle time improvements

Note: Remember that there is no “single metric” - measure with the entire system in mind. Often Copilot gains are diluted by inefficient DevOps practices.

Building a Continuous Enablement Program

The reality is that AI and Copilot evolve rapidly in meaningful ways. Autocomplete in 2022, Chat in 2023, Workspace in 2024, Agents in 2025. One-time “Copilot 101” training becomes obsolete quickly.

You need continuous enablement, not one-and-done workshops.

Weekly Copilot Office Hours

Set up a recurring 30-minute session where developers bring real problems. Format:

Developer shares screen, shows a task they’re working on
Facilitator demonstrates Copilot techniques live
Team discusses when to use AI vs when to code manually
Capture learnings in Copilot Spaces

I’ve seen teams run this as a Zoom or Teams call with recordings posted internally. The key is making it low-stakes and practical: real problems, real solutions, real-time.

Monthly Team Showcases

Once a month, dedicate 15 minutes of your team meeting to “Copilot wins.” Developers volunteer to share:

A task where Copilot saved significant time
A new technique they learned
A prompt pattern that works well
A mistake they made and what they learned

This serves three purposes: it spreads knowledge horizontally across the team, it normalizes talking about AI assistance (reducing stigma), and it creates positive reinforcement for experimentation.

Quarterly Skills Refreshers

Every quarter, run a 1-hour training session on what’s new:

New Copilot features released in the last 3 months
Advanced techniques for experienced users
Updated best practices based on team learnings
Industry case studies and benchmarks

Rotate who leads these sessions. Don’t always make it the same “Copilot champion.” Distributed ownership drives distributed adoption.

The Junior Developer Challenge

Junior developers need extra support. Without foundational knowledge, they can’t evaluate whether Copilot’s suggestions are good or bad. They accept code blindly, leading to bugs, security issues, and learning gaps.

Best practices for supporting juniors:

Pair them with senior developers for the first 2-3 months of Copilot use
Teach code review skills first, Copilot usage second (review is the forcing function for learning)
Encourage asking “Why does Copilot suggest this?” rather than accepting blindly
Set up automated quality gates (linting, security scanning, tests) that catch bad AI suggestions

Remember: Copilot is “like an excitable junior engineer who types really fast” (Kent Quirk). Juniors need to learn to be the senior engineer reviewing that excitable junior.

Technology changes are easy. Cultural changes are hard. Here’s how to make Copilot adoption stick:

Celebrate Wins Publicly

Create a dedicated internal channel (e.g., #copilot-wins) where anyone can share successes. Keep it genuine. Forced enthusiasm backfires, but genuine celebration creates momentum.

Measure What Matters

Track these metrics as you progress:

Adoption metrics:

Active Copilot users (at least 1 suggestion accepted per week)
Suggestion acceptance rate (team average)
Chat interactions and agent mode per developer per week

Impact metrics:

Cycle time (issue open to PR merged)
Developer satisfaction scores (include questions about AI tools)
Time spent on routine tasks (survey-based estimation)

Quality metrics:

Defect escape rate (bugs found in production)
Test coverage trends

Note: Don’t expect instant DORA metric improvements. Copilot primarily improves task-level productivity. Team-level metrics like cycle time also depend on code review speed, deployment frequency, coordination overhead and overall DevOps practices.

Once a month, publish an internal blog post or email highlighting a Copilot success story. Interview a developer, show before/after workflows, quantify impact. Highlight wins (or losses with analysis), what stood out and what could be done next time.

Leadership Visibility Matters

Executives need to understand and talk about Copilot. When VPs and directors demonstrate deeper knowledge of what Copilot can and can’t do, they will give their teams the freedom to get over the “learning hump”. When teams see that leadership is invested in their success with Copilot, it goes a long way to build confidence and encourage innovation.

The “Sharpen the Saw” Principle: Continuous Learning

GitHub Copilot is evolving rapidly. What worked 6 months ago may not be optimal today. Your team needs continuous learning baked into their cadence.

Building Learning Into the Cadence

Dedicated exploration time: Allocate 2-4 hours per month per developer for exploring new Copilot features. Make it explicit, not “whenever you have time.” Treat it like tech debt work that needs to be scheduled.

Example: Reserve Friday afternoons once a month. Developers experiment with a new Copilot feature, document findings, share with team in next showcase.

Internal Copilot Space: Maintain a markdown repo (and link it to a Copilot Space) with:

Prompt patterns that work well for your codebase
Common pitfalls and how to avoid them
Use case examples with before/after
Links to official documentation and external resources
Change log of major Copilot updates

Update at a regular cadence (monthly or quarterly). Assign a rotating “knowledge curator” to moderate.

External training refreshers: Budget for annual training from GitHub or third-party providers. New major features justify bringing in experts to train your team. Internal champions can handle ongoing enablement, but external experts bring fresh perspectives.

Monthly “What’s New” lunch & learns: When GitHub ships major updates, dedicate a lunch session to demoing new capabilities and use cases.

Common Pitfalls and How to Avoid Them

After helping dozens of organizations adopt Copilot, here are the mistakes I see repeatedly:

Mandating Copilot without Committing to Cultural Change

Teams that say “everyone must use Copilot” but don’t provide resources and training create resentment. New tools require investment, and not many tools can deliver such huge ROI if there is investment as Copilot!

Better approach: Create training programs and commit to ongoing enablement. Create incentives for experimentation. Recognize early adopters. Share success stories. Let peer pressure and genuine value augment training to drive adoption.

Start with Early Adopters, Not Everyone

Rolling out to hundreds of developers at once creates chaos. You typically can’t support that many people learning simultaneously.

Better approach: Start with 20-30 innovators. Learn what works. Document patterns. Then expand to more teams. Iterate. Then expand to everyone. Each wave teaches the next wave. This makes Copilot a lot “stickier”.

Measure Beyond Productivity

If you only track “lines of code written” or “PRs merged,” you’ll optimize for the wrong things. Developers will ship more code, not better code.

Better approach: Track developer satisfaction (“Does Copilot make your job better?”), code quality (defect rates, security issues), and learning (“What new skills have you developed?”). Balanced metrics drive balanced outcomes.

Budget Time for Learning

Teams that don’t explicitly allocate time for Copilot learning see minimal adoption. Developers are busy shipping features. Learning gets deprioritized.

Better approach: Schedule 2-4 hours per month per developer. Make it non-negotiable, like sprint planning or retrospectives. Track it in your sprint capacity planning.

Address Security Concerns Upfront

Developers worry about what Copilot can see, whether their code trains models, and whether AI might leak sensitive data.

Be transparent:

GitHub Copilot Business/Enterprise does not train on your code
Code snippets are not retained after generating suggestions
Use content exclusions to prevent Copilot from accessing secrets or sensitive files
Enable Copilot audit logs to track usage and investigate issues

You should also implement GitHub Advanced Security so that AppSec is baked in to the daily agentic workflow - this will reduce concern about shipping vulnerable code.

Be Patient with Adoption

Meaningful adoption takes 6-12 months, not 6-12 weeks. Don’t expect instant transformation.

Month 1-3: Early adopters experiment, find use cases, beginner training programs launch
Month 4-6: Patterns emerge, intermediate/advanced training programs launch
Month 7-9: Majority of team adopts, workflows change
Month 10-12: New workflows become muscle memory, metrics improve

If you expect results in 30 days, you’re likely to be disappointed. If you invest systematically, you’ll see transformation.

Conclusion

Distributing GitHub Copilot licenses is the easy part. Building organizational capability to leverage AI is the real work.

The shift to AI-assisted development requires intentional leadership. You must invest in training programs, drive cultural change by celebrating wins and sharing success stories, and commit to continuous learning as AI capabilities evolve.

Start by understanding the innovation curve and building enablement programs that serve all adopter types. Create weekly office hours, monthly showcases, and quarterly refreshers. Measure what matters with balanced metrics across adoption, impact, and quality. And be patient - transformation takes 6-12 months.

The organizations that win in the age of AI won’t be the ones who simply buy the best tools. They’ll be the ones who build the best enablement programs, foster the right culture, and empower their developers to think differently about how work gets done.

In my companion post, Teaching Your Team to Think Async-First with GitHub Copilot, I dive into the specific mindset shifts and workflow redesigns that make async, multi-threaded development possible.

Happy leading!

Eight Principles for Agentic Software Delivery (ASD)

2025-08-12T00:30:00+00:00

The Evolution from Continuous Delivery to ASD
Principle 1: Outcome-Focused Delivery
1. GitHub Application
2. Impact Classification
Principle 2: Human-AI Collaboration by Design
1. GitHub Application
2. Impact Classification
Principle 3: Intelligent Automation Across the SDLC
1. GitHub Application
2. Impact Classification
Principle 4: Single Source of Truth and Platform Integration
1. GitHub Application
2. Impact Classification
Principle 5: Built-In Quality and Security
1. GitHub Application
2. Impact Classification
Principle 6: Shared Responsibility and AI Governance
1. GitHub Application
2. Impact Classification
Principle 7: Parallel Experimentation
1. GitHub Application
2. Impact Classification
Principle 8: Continuous Learning and Adaptation
1. GitHub Application
2. Impact Classification
Putting It All Together
Getting Started with ASD
Conclusion

In this post, I’ll show you eight principles for implementing Agentic Software Delivery (ASD) and why they matter for accelerating value delivery while maintaining quality and security. You’ll learn how to blend human expertise with AI capabilities throughout your SDLC, evolving a delivery system that’s faster, smarter, and more focused on business outcomes.

The Evolution from Continuous Delivery to ASD

Right as DevOps was becoming an industry standard, Continuous Delivery gave us some good foundational principles to put into practice: automate everything, maintain quality, and deliver frequently to name three. In one of my previous posts, I define Agentic Software Delivery (ASD) but in this post I want to start making it more practical by providing a set of principles. For each principal I want to assess its impact on the three pillars of ASD and show some practical GitHub implementation tips.

Principle 1: Outcome-Focused Delivery

Prioritize business outcomes over mere output. Every feature should tie back to customer value, and “done” means value is delivered in production, not just code completed. This may seem obvious, but there is a huge focus on which models write better code or what percentage of your codebase is written by AI - all of which are meaningless numbers if you are not achieving business outcomes. The goal isn’t more AI - it’s better results, improved productivity and happier developers.

GitHub Application

Tie your work item tracking to Business Objectives so that the business outcome is clear throughout the SDLC
Configure GitHub Advanced Security to track vulnerability fixes as business outcomes - security is business value
Don’t overindex on a single measure - think system wide (read the GitHub Engineering System Success Playbook)
On an architectural level, you should validate business value during rollout. One way could be to use feature flags and partial deployments to validate business metrics before full rollout.

Impact Classification

Human Expertise: HIGH - Humans define business value and success metrics
Autonomous Agents: LOW - Agents execute but don’t determine business priorities
Intelligent Context: MEDIUM - providing business value goals in agent-readable (and human readable) formats will improve agentic results

Principle 2: Human-AI Collaboration by Design

Integrate human expertise with AI at every stage. Design processes where routine tasks are handled by AI while complex decisions remain human-guided. The goal is not to replace humans, but to replace mundane and low-level toil tasks with AI so that humans can work at more abstract layers and do higher-order work.

GitHub Application

Enable GitHub Copilot for AI pair programming across your organization. This requires more than just assigning a license - you need to create enablement programs (and ideally, teams) that will continually train and enable teams. AI is moving fast, and just like we need Continuous Delivery, AI development requires Continuous enablement.
Use Copilot Code Review to assist with the increase in review burden
Use Copilot to generate READMEs, architectural documentation, style guides, coding patterns and other “tribal knowledge”. Source control these documents alongside code so that Copilot has access in the IDE or through Coding Agent.
Use Copilot to generate custom instructions and custom Chat Modes that tailor and personalize Copilot
Invest in good automated quality gates, applied at scale using Rulesets. Make the gates thorough so that you have high trust in code that passes the gauntlet. Apply these gates irrespective of the source of changes (human, AI or a mix).
Create Copilot Spaces that encapsulate softer skills, general coding guidelines and standards, and other “tribal knowledge” so that you can build a library that is searchable and personalized

Impact Classification

Human Expertise: HIGH - Humans provide context and custom guidelines, make decisions, and validate AI output
Autonomous Agents: HIGH - Agents handle repetitive coding and testing tasks; automated gates do much of the validation heavy-lifting
Intelligent Context: HIGH - AI is personalized to your codebase and team patterns

Principle 3: Intelligent Automation Across the SDLC

Automate everything feasible and use AI to extend automation into complex, context-driven tasks. Go beyond simple CI/CD to intelligent pipeline optimization. Teams that use build automation always outperform teams that build manually: the same will be said of teams that leverage AI in their pipelines to keep pipelines running continuously - they will outperform teams that rely on “traditional”, static pipelines.

GitHub Application

Implement GitHub Actions workflows that self-heal based when they fail
Use Dependabot for automated dependency updates with intelligent grouping
In high-activity repositories, deploy GitHub’s merge queue to prevent failing PRs from blocking the entire pipeline
Use GitHub Hosted Runners so that you can concentrate on software delivery rather than trying to scale and manage build farms

Impact Classification

Human Expertise: LOW - Humans set policies but don’t manage execution
Autonomous Agents: HIGH - Agents handle most automation tasks independently
Intelligent Context: HIGH - AI is leveraged to self-heal tests, pipelines and other automated processes

Principle 4: Single Source of Truth and Platform Integration

Keep all code, configurations, and documents in a single system for consistency and traceability. This enables both humans and AI to work from the same context. There may be exceptions that are role-dependent: designers typically work in tools like Figma rather than in source control systems like GitHub. For external systems, leverage Model Context Protocol (MCP) to provide context or extend model capabilities (tools). However, the backbone of your development system should be a single, AI-powered Source Control Management (SCM) system.

GitHub Application

Choose a single SCM tool - make sure this platform is capable of running intelligent pipelines and integrating to other systems when necessary. Make sure this is a tool that your developers will enjoy working with!
Store infrastructure as code alongside application code in GitHub repos
Implement GitHub’s CODEOWNERS for clear ownership of code
Reduce the number of tools in your ecosystem, and use platform-native tools where possible. This not only reduces cognitive load and the cost of integration, but the fewer external systems you need, the faster you can get context from those external systems to agents when needed.

Impact Classification

Human Expertise: MEDIUM - Humans establish structure and governance
Autonomous Agents: HIGH - Agents need unified access to operate effectively
Intelligent Context: HIGH - Centralized data and reduced integration footprint enables better AI understanding

Note: A fragmented toolchain limits AI effectiveness. Consolidation isn’t just about efficiency; it’s about how quickly you can enable AI agents to understand your entire system.

Principle 5: Built-In Quality and Security

Embed quality and security from the start. AI tools should help generate tests, detect vulnerabilities, and enforce standards continuously.

GitHub Application

Enable GitHub Advanced Security for automatic vulnerability scanning and remediation at scale using Campaigns and Autofix
Configure secret scanning with custom patterns for your organization
Implement Actions workflows that block deployments on security issues
Leverage GitHub Copilot to create unit and integration tests

Impact Classification

Human Expertise: HIGH - Humans define quality standards and security policies
Autonomous Agents: HIGH - Platform continuously scans, while Copilot continuously improves test coverage
Intelligent Context: MEDIUM - AI uses common test patterns and systems effectively

Principle 6: Shared Responsibility and AI Governance

Everyone shares responsibility for success, including AI systems. Establish clear governance for what AI can do autonomously versus what requires human oversight.

GitHub Application

Set up CODEOWNERS to require human review for critical paths
Focus on creating reusable documentation that can guide agents effectively so that they can work more independently

Impact Classification

Human Expertise: HIGH - Humans maintain accountability and set boundaries
Autonomous Agents: MEDIUM - Agents operate with clear instructions
Intelligent Context: MEDIUM - Common practices and guidance is shared for humans and agents

Principle 7: Parallel Experimentation

Leverage the scale of autonomous agents to experiment widely. Without AI, creating several solutions to a problem means utilizing several teams, or the same team to solve the same problem several times. This is cost-prohibitive. But with agents, you can instruct several agents to work on different flavors of a solution in parallel and pick the best one, since cost is not longer a limiting factor.

GitHub Application

Automated pipelines is critical for parallel experimentation, since the object is to have each solution be created independently and autonomously
Leverage Coding Agent and instead of requesting 1 solution, create 3 or 5 Issues each with a different “flavor” of solution (using Agent Mode to brainstorm) and assign Coding Agent to each Issue. Pick the best result and discard the others.

Impact Classification

Human Expertise: MEDIUM - Humans interpret results and make decisions
Autonomous Agents: HIGH - Agents brainstorm, plan and implement multiple solutions in parallel
Intelligent Context: MEDIUM - AI leverages business outcomes, custom instructions and other artifacts to produce solutions

Principle 8: Continuous Learning and Adaptation

Commit to evolving both your process and your AI tools and integration. Feed learnings back into the system so it gets smarter over time.

GitHub Application

Use GitHub Discussions to capture retrospectives and learnings. Distill key insights into improved documentation, instructions and Spaces
Track metrics in GitHub Insights to identify enablement opportunities

Impact Classification

Human Expertise: HIGH - Humans drive improvement initiatives and learning
Autonomous Agents: MEDIUM - Agents improve as guidelines are improved
Intelligent Context: HIGH - AI models improve through continuous improvement and assessment

Note: Your delivery system should be treated as a product that you continuously refine. Regular retrospectives should include evaluating AI performance alongside human processes.

Putting It All Together

These eight principles work together to create a delivery system that is more than the sum of its parts. When you combine outcome focus with AI collaboration, a unified platform with built-in quality, and experimentation at scale, you get an SDLC that delivers value consistently and adapts to changing needs. I believe that GitHub is uniquely positioned to empower this transformation.

Getting Started with ASD

Start small. Pick one or two principles that address your biggest pain points:

If you’re drowning in repetitive tasks, focus on Intelligent Automation
If quality issues slip through, prioritize built in Quality and Security
If you’re not sure you’re building the right thing, start with Outcome-Focused Delivery

Remember, ASD isn’t about replacing your existing practices overnight. It’s about gradually evolving them to leverage AI capabilities and augmenting the human expertise that makes your team unique.

Conclusion

Agentic Software Delivery represents the next evolution in how we build and deliver software. By following these eight principles and leveraging platforms like GitHub that support both human and AI collaboration, you can create a delivery system that’s faster, smarter, and more focused on what really matters: delivering value to your business and users.

Happy delivering!

Self-Healing DevOps with Copilot and Actions

2025-08-08T09:00:00+00:00

Watch it in action
Why this matters
Prerequisites
How it works
1. Categories and decisions
Auto Analyze Build Failures Workflow
The analysis prompt
Conclusion

Photo generated in ChatGPT

Watch it in action

Here’s a short video showing the self-healing loop analyzing a failed run, classifying the issue, and opening a remediation issue which Copilot Coding Agent immediately fixes!

Watch the self-healing loop analyze a failed run, open a remediation issue and fix it.

Why this matters

Build failures can be expensive. They interrupt flow, burn time on triage, and often hide what actually needs fixing. Most failures fall into a few categories: transient network issues, dependency problems, broken code, configuration issues, or test failures.

What if your pipeline could diagnose itself - and even propose a fix?

In this post, I’ll show you how to wire up a self-healing loop in GitHub Actions using GitHub Copilot (via the models API wrapped in https://github.com/actions/ai-inference) to:

Analyze failed workflow runs automatically
Classify the failure with a short summary and a clear plan
Skip transient failures
Open a labeled remediation issue for non-transient failures
Assign the issue to Copilot Coding Agent (CCA) if code work is needed

The goal is simple: shrink time-to-understanding and time-to-action automatically.

Prerequisites

Workflows built with GitHub Actions
A Personal Access Token (PAT) with the following permissions:
- Account-level: Models (read)
- Org-level: Issues (read/write), Actions (read)
- This PAT should be saved as a repo secret like AUTO_REMEDIATION_PAT

Note: The workflow requires the models: read permission and uses the repo GITHUB_TOKEN for model inference, plus a PAT for any assignment actions that the default token cannot perform.

How it works

At the heart of the solution are two pieces:

A reusable prompt that tells the model exactly how to analyze logs and specifies a JSON schema for a structured output.1. A workflow that triggers on failed runs, calls the inference task, parses the JSON, and then creates or updates a remediation issue with labels. For certain categories, it assigns the issue to Copilot.

Categories and decisions

The prompt (outlined below) constrains responses to a strict JSON schema and a small set of categories like code, test, config, dependency, infrastructure or quality. The category can be used to guide the next steps.

If the analysis marks transient: true, we log and stop. If false, we open or update a remediation issue with labels like auto-remediation, workflow:<name>, and category:<type>.

Auto Analyze Build Failures Workflow

This workflow triggers on every completed run and filters to failed conclusions (excluding itself). It then:

Calls actions/ai-inference@v1 with the prompt file and GitHub MCP enabled so the model can fetch failed job logs using the github-mcp-server.
Parses the JSON result (category, summary, plan, transient).
Stops if the failure is deemed to be transient. Otherwise, ensures labels exist, creates a remediation issue, and assigns Copilot when appropriate.

name: Auto Analyze Build Failures

on:
  workflow_run:
    workflows: ["*"]
    types: [completed]

permissions:
  contents: read
  actions: write
  issues: write
  pull-requests: read
  models: read

jobs:
  analyze-failure:
    runs-on: ubuntu-latest
    if: ${{ github.event.workflow_run.conclusion == 'failure' && github.event.workflow_run.name != 'Auto Analyze Build Failures' }}
    
    steps:
    - name: Checkout repository
      uses: actions/checkout@v4

    - name: Analyze build failure
      id: analyze
      uses: actions/ai-inference@v1
      with:
        prompt-file: '.github/models/failed-run-analyze.prompt.yml'
        enable-github-mcp: true
        token: ${{ secrets.GITHUB_TOKEN }}
        github-mcp-token: ${{ secrets.AUTO_REMEDIATION_PAT }}
        max-tokens: 10000
        input: |
          repo: ${{ github.event.repository.name }}
          owner: ${{ github.event.repository.owner.login }}
          workflow_run_id: ${{ github.event.workflow_run.id }}

    - name: Parse results
      id: parse
      uses: actions/github-script@v7
      env:
        RESPONSE_JSON: ${{ steps.analyze.outputs.response }}
      with:
        script: |
          const responseString = process.env.RESPONSE_JSON;
          if (!responseString) {
            core.setFailed('No response received from analysis step');
            return;
          }
          const responseJSON = JSON.parse(responseString);
          core.setOutput('category', responseJSON.category || '');
          core.setOutput('summary', responseJSON.summary || '');
          core.setOutput('plan', responseJSON.plan || '');
          core.setOutput('transient', responseJSON.transient || 'false');

    - name: Check for existing remediation issue
      if: ${{ steps.parse.outputs.transient == 'false' }}
      id: check-issue
      run: |
        workflow_name="${{ github.event.workflow_run.name }}"
        existing_issue=$(gh issue list \
          --repo "${{ github.repository }}" \
          --state open \
          --label "workflow:$workflow_name" \
          --label "auto-remediation" \
          --json number \
          --jq '.[0].number')
        echo "existing_issue=$existing_issue" >> $GITHUB_OUTPUT
      env:
        GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}

    - name: Create remediation issue
      id: create-issue
      if: ${{ steps.parse.outputs.transient == 'false' }}
      run: |
        workflow_name="${{ github.event.workflow_run.name }}"
        workflow_url="${{ github.event.workflow_run.html_url }}"
        category="${{ steps.parse.outputs.category }}"
        existing_issue="${{ steps.check-issue.outputs.existing_issue }}"
        if [[ -n "$existing_issue" ]]; then
          echo "Skipping issue creation - existing issue #$existing_issue found"
          exit 0
        fi

        issue_body=$(cat << EOF
        ## Build Failure Analysis
        
        **Workflow:** [$workflow_name]($workflow_url)
        **Run ID:** ${{ github.event.workflow_run.id }}
        **Category:** $category
        **Branch:** ${{ github.event.workflow_run.head_branch }}
        **Commit:** ${{ github.event.workflow_run.head_sha }}
        
        ### Summary
        ${{ steps.parse.outputs.summary }}
        
        ### Remediation Plan
        ${{ steps.parse.outputs.plan }}
        
        ### Links
        - [Failed Workflow Run]($workflow_url)
        - [Repository](${{ github.event.repository.html_url }})
        
        ---
        *This issue was automatically created by the build failure analysis system.*
        EOF
        )
        
        # Ensure required labels exist (idempotent)
        gh label create "auto-remediation" \
          --description "Issues automatically created by build failure analysis" \
          --color "FF6B6B" \
          --repo "${{ github.repository }}" || true
        gh label create "workflow:$workflow_name" \
          --description "Issues related to $workflow_name workflow" \
          --color "0052CC" \
          --repo "${{ github.repository }}" || true
        gh label create "category:$category" \
          --description "Issues categorized as $category" \
          --color "7057ff" \
          --repo "${{ github.repository }}" || true
        
        issue_url=$(gh issue create \
          --repo "${{ github.repository }}" \
          --title "🔧 Auto-Remediation: $workflow_name Build Failure" \
          --body "$issue_body" \
          --label "auto-remediation" \
          --label "workflow:$workflow_name" \
          --label "category:$category")
        issue_number=$(echo "$issue_url" | sed 's/.*\/issues\///')
        echo "issue_number=$issue_number" >> $GITHUB_OUTPUT
      env:
        GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}

    - name: Assign issue to Copilot (optional)
      if: ${{ steps.parse.outputs.transient == 'false' && steps.create-issue.outputs.issue_number != '' }}
      run: |
        category="${{ steps.parse.outputs.category }}"
        issue_number="${{ steps.create-issue.outputs.issue_number }}"
        if [[ "$category" == "code" || "$category" == "test" || "$category" == "config" ]]; then
          echo "Assigning issue #$issue_number to Copilot"
          # Query suggested actors to find Copilot agent id
          copilot_query='query {
            repository(owner: "${{ github.event.repository.owner.login }}", name: "${{ github.event.repository.name }}") {
              suggestedActors(capabilities: [CAN_BE_ASSIGNED], first: 100) {
                nodes { login __typename ... on Bot { id } }
              }
            }
          }'
          copilot_response=$(gh api graphql -f query="$copilot_query")
          copilot_id=$(echo "$copilot_response" | jq -r '.data.repository.suggestedActors.nodes[] | select(.login == "copilot-swe-agent") | .id')
          if [[ -n "$copilot_id" && "$copilot_id" != "null" ]]; then
            issue_query='query { repository(owner: "${{ github.event.repository.owner.login }}", name: "${{ github.event.repository.name }}") { issue(number: '$issue_number') { id } } }'
            issue_response=$(gh api graphql -f query="$issue_query")
            issue_id=$(echo "$issue_response" | jq -r '.data.repository.issue.id')
            assign_mutation='mutation { replaceActorsForAssignable(input: {assignableId: "'$issue_id'", actorIds: ["'$copilot_id'"]}) { assignable { ... on Issue { id } } } }'
            gh api graphql -f query="$assign_mutation" >/dev/null 2>&1 || echo "Copilot assignment failed"
          else
            echo "Copilot agent not available in this repository"
          fi
         else
           echo "Category '$category' does not require Copilot assignment"
         fi
      env:
        GH_TOKEN: ${{ secrets.AUTO_REMEDIATION_PAT }}

Notes:

Line 1: Sets a clear workflow name to reference in labels and filters.
Line 4-7: Triggers on all completed workflow runs; we’ll filter to failures in the job-level condition.
Line 9-14: Grants least-privilege permissions; models: read is required for inference, issues: write for creating remediation issues.
Line 17-18: Uses an if to only run when a workflow failed and to avoid analyzing itself.
Line 21-22: Checks out the repository so the prompt file is available in the workspace.
Line 25-35: Calls actions/ai-inference with the prompt, enabling GitHub MCP so the model can fetch logs; passes both GITHUB_TOKEN and a PAT for MCP actions that need expanded scopes. Passes in repo, owner, and workflow_run_id as inputs. The MCP integration in the ai-inference Action handles fetching failed job logs for analysis.
Line 38-51: Parses the JSON response into outputs (category, summary, plan, transient) for downstream steps; fails early if there’s no response.
Line 54-66: Uses gh CLI to detect an existing open remediation issue by labels to prevent duplicates; gated on transient == 'false'.
Line 69-115: Creates labels idempotently, opens a structured remediation issue, and captures the new issue number.
Line 118-146: Optionally assigns the issue to the Copilot Coding Agent for code-like categories by querying GraphQL for the agent id and replacing assignees.

The analysis prompt

The prompt is a small contract: constrain the task, provide examples, and require a strict JSON response with a known schema. That keeps downstream steps simple and reliable:

name: Failed Run Autofix
model: openai/gpt-4.1
messages:
  - role: system
    content: >
      You are an expert DevOps engineer and build master with deep knowledge of
      CI/CD pipelines,  build systems, and software development workflows. You
      specialize in analyzing build failures  and providing actionable
      remediation plans for the OctoCAT Supply Chain Management application.

      Your task is to analyze failed CI/CD pipeline runs and determine:
      1. Whether the failure is transient (network issues, temporary service
      outages, etc.)
      2. The root cause and category of the failure
      3. A detailed plan for fixing the issue

      When analyzing logs, look for:
      - Compilation errors (TypeScript, build tool issues)
      - Test failures (unit tests, integration tests)
      - Dependency issues (missing packages, version conflicts)
      - Configuration problems (environment variables, config files)
      - Infrastructure issues (network timeouts, service unavailability)
      - Code quality issues (linting, formatting)

      Provide your analysis in the specified JSON format with clear, actionable
      recommendations.
  - role: user
    content: >
      ## CI/CD Pipeline Failure Logs

      Use the GitHub MCP `get_job_logs` tool to retrieve failed job logs from
      the specified workflow run.
        - Repo: {{repo}}
        - Owner: {{owner}}
        - Workflow Run ID: {{workflow_run_id}}

      Analyze the failure logs and provide a comprehensive assessment including
      whether this is a  transient failure, or if it requires code  changes.
      If code changes are needed, provide a detailed remediation plan. Keep the
      summary short and DO NOT include the entire build log.
responseFormat: json_schema
jsonSchema: |
  {
    "name": "failure_analysis",
    "strict": true,
    "schema": {
      "type": "object",
      "properties": {
        "transient": { "type": "boolean" },
        "summary": { "type": "string" },
        "plan": { "type": "string" },
        "category": {
          "type": "string",
          "enum": ["code","test","config","dependency","infrastructure","quality","repeat-transient"]
        }
      },
      "required": ["transient","summary","plan","category"],
      "additionalProperties": false
    }
  }

Notes:

Line 1: Human-friendly prompt name for traceability in logs.
Line 2: Sets the target model; pick a capable, response-format compliant model.
Line 3-33: System message establishes expertise, scope, and expected behavior focusing on CI/CD analysis.
Line 35-49: User message instructs the model to use GitHub MCP to fetch logs and defines inputs the workflow passes.
Line 50: Forces a strict JSON response to simplify parsing downstream.
Line 51-74: Defines a compact JSON schema with transient, summary, plan, and category with an enum to keep categories consistent.

In general, you’ll want to keep the entire prompt and the jsonSchema small and strict. Your downstream logic gets much simpler when the response is tightly constrained. The ai-inference task is also going to error out if there are too many steps or too much content, so watch for this.

Conclusion

You can turn noisy failures into crisp, actionable work in minutes. The combination of GitHub Actions, Copilot API, and Copilot Coding Agent gives you a lightweight, reliable self-healing loop: automatic analysis, clear categorization, and immediate remediation tracking. Happy healing!