github·Aug 11, 2026·2 min readCurated summary

From coder to orchestrator: How agents shift the role of a developer

AI agents can generate impressive one-prompt demos, but reliable software delivery requires more than isolated outputs. Developers increasingly need to design workflows that define how code is proposed, tested, reviewed, and shipped. The article argues that this shifts developers from primarily writing code to orchestrating agents within controlled, repeatable systems. ## From One-Off Prompts to Reliable Workflows - A single prompt can quickly produce a demo, such as a simple game. - Production development requires repeatable delivery with: - Appropriate context - Validation and testing - Security controls - Review processes - Clear permissions and handoffs - GitHub Copilot is presented as a control plane for connecting these parts. ## An Agentic Development Flow - Familiar repository events can trigger agent work, including: - Adding a label to an issue - Running a scheduled workflow - Starting a GitHub Actions process - The agent’s changes are captured in a pull request. - Deterministic checks then validate the work through: - Linting - Tests - Security scans - Build verification - CODEOWNERS, required reviews, and branch protection rules control what can be merged. - Agents handle ambiguous, context-heavy tasks, while predictable automation provides the safety boundary. - Developers decide: - What agents can access - How tasks are scoped - Where workflows hand off - When human judgment is required ## GitHub’s Implementation Options - Copilot cloud agent workflows support event-driven automations. - Copilot CLI can run AI-powered steps inside GitHub Actions. - Model Context Protocol (MCP) can extend agents with additional tools and external context. - These options represent different stages of building an agent-enabled development workflow. ## Starting Small - Teams should begin with one bounded, low-risk workflow. - Suitable examples include: - Issue triage - Synchronizing documentation and tests - Routine maintenance updates - The recommended approach is to integrate Copilot into existing development infrastructure rather than redesigning everything at once. Developers should treat AI agents as components within an engineered delivery system, not as replacements for that system. Start with a limited workflow, surround agent output with automated checks and review controls, and gradually expand as the process proves reliable.

Read original(opens in new tab)

CI/CDAI AgentsModel Context ProtocolGithub Copilot+4

github·Aug 4, 2026·3 min readCurated summary

Turn one giant AI-generated pull request to a reviewable stack

Coding agents can rapidly produce complete features, but they often deliver them as enormous, shallow pull requests that are difficult to review and slow to merge. GitHub’s stacked pull requests address this by decomposing a feature into small, dependency-ordered layers. The result is a reviewable chain of changes that preserves context while reducing maintenance and merge conflicts. ## The Problem with Giant AI-Generated Pull Requests - A seemingly simple product-search feature may include: - A data model and seed data - An API route and validation - Client integration and UI states - Coding agents commonly generate all of this in a single 1,000-plus-line pull request. - Large pull requests: - Become difficult to review thoroughly - Cause reviewers to lose context - Receive lower-quality feedback - Take longer to merge - Are more likely to land under-reviewed Traditional alternatives are also imperfect: one large pull request harms reviewability, while a manually maintained chain of smaller pull requests creates synchronization work and conflict-management overhead. ## Stacked Pull Requests - Stacked pull requests break a feature into logical, dependent layers. - Each pull request focuses on one concern and remains small enough for reviewers to understand. - Later layers build naturally on earlier, already-reviewed work. - Different layers can be assigned to specialized reviewers, such as data or UI owners. For the product-search example, the proposed stack is: - **L1 – `feat/catalog-data`**: Typed catalog, seed data, validation, and data access; based on `main` - **L2 – `feat/search-api`**: Validated `/api/products/search` endpoint; based on L1 - **L3 – `feat/chat-grounding`**: Connects chat to the API and real product data; based on L2 - **L4 – `feat/grounded-ui`**: Adds product citation cards and UI states; based on L3 ## Setting Up the Stack - Choose the stack base first, because CI checks and merge rules are evaluated against it. - Place foundational work closest to the base and dependent work above it. - Install GitHub’s CLI extension: ```bash gh extension install github/gh-stack ``` - Teach coding agents how to create and manage stacks: ```bash gh skill install github/gh-stack ``` Alternatively: ```bash npx skills add github/gh-stack ``` - Ensure CI is configured, since every pull request layer is checked against the stack base. ## Assigning Agents to Layers The example uses separate agents with strict scope boundaries: - **L1:** Data modeler agent - **L2:** Backend agent - **L3:** Frontend agent - **L4:** Frontend agent This division encourages each agent to produce a focused pull request rather than reconstructing the entire feature in one pass. ## Recommended Workflow The development process starts with the foundational catalog layer and proceeds upward through the dependency chain. Agents work autonomously within their assigned scope, while each completed layer can be reviewed independently before subsequent layers are evaluated. Stacked pull requests are a practical way to preserve the productivity benefits of coding agents without sacrificing review quality. Teams should define clear layer boundaries, establish the stack base, assign appropriate reviewers or agents, and run CI for every layer.

Read original(opens in new tab)

CI/CDGithubAPI DesignCoding Agents+2

github·Jul 29, 2026·2 min readCurated summary

Tame Dependabot: Group your updates, slow the cadence, keep security fast

Dependabot can generate unnecessary noise when it opens a separate pull request for every dependency update, especially on active repositories. Using dependency groups, a slower schedule, and coverage for all relevant ecosystems turns that stream into predictable maintenance batches. The recommended approach preserves the speed of security updates while reducing routine review and CI overhead. ## The Problem: Frequent, Un grouped Updates - Microsoft’s GCToolkit had 92 Dependabot commits out of 578—about one in six—with 61 arriving in the previous year. - Its original configuration: - Checked GitHub Actions dependencies daily. - Opened a separate pull request for every dependency. - Limited open Dependabot pull requests to 10. - The pull-request limit capped the visible backlog but did not reduce the underlying noise. ## Grouping Dependencies into Batches - Dependabot’s `groups` configuration combines multiple updates into one pull request. - A wildcard pattern such as `"*"` includes all dependencies in that ecosystem. - Instead of 10 pull requests and 10 CI runs, maintainers receive one reviewable batch. - Larger projects can define separate groups for categories such as testing and production dependencies. - In monorepos, Dependabot can group the same dependency across multiple directories using `directories` and `group-by: dependency-name`. ## Moving from Daily to Monthly Updates - Changing `schedule.interval` from `daily` to `monthly` creates a predictable maintenance cycle. - Combined with grouping, this produces one batch per ecosystem each month rather than a continuous stream. - `weekly` is an alternative for projects needing a faster cadence. - Specific days and times can be configured with `schedule.day` and `schedule.time`. ## Covering All Dependency Ecosystems - The original configuration monitored only GitHub Actions. - The revised configuration also monitors Maven, which is essential for a Java project like GCToolkit. - Each ecosystem receives its own schedule and grouped pull request, keeping Actions and Maven updates separate and manageable. ## Keeping Security Updates Fast - The grouping and scheduling changes primarily affect routine version updates, not Dependabot security fixes. - Maintainers can therefore slow ordinary dependency maintenance without delaying urgent vulnerability patches. A practical configuration is to group all routine updates by ecosystem, run them monthly—or weekly when appropriate—and explicitly configure every package ecosystem used by the repository. This reduces maintenance noise while keeping security response timely.

Read original(opens in new tab)

CI/CDGitHub ActionsDependency ManagementMaven+2

github·Jul 28, 2026·3 min readCurated summary

Disrupting supply chain attacks on npm and GitHub Actions

GitHub describes a layered approach to disrupting npm and GitHub Actions supply-chain attacks, which typically compromise one project, steal credentials, and spread malware across many others. Rather than relying on one defensive feature, GitHub is targeting several links in the attack chain—from initial compromise through credential theft and malicious publishing. Recent protections add account recovery delays, safer workflow defaults, credentialless publishing, network monitoring, and stronger publishing approvals. ## Anatomy of Supply-Chain Attacks - Attacks commonly: - Compromise a maintainer account or CI/CD workflow. - Escalate access by stealing credentials. - Use those credentials to infect additional packages and projects. - GitHub says effective defense requires multiple mitigations that disrupt the most damaging steps in the chain. ## Preventing Initial Compromise - **High-impact npm account protection** - Accounts enter read-only mode for 72 hours after an email change or use of a 2FA recovery code. - The delay gives maintainers time to detect phishing-related account takeover and recover access. - **Safer `pull_request_target` checkout defaults** - `actions/checkout` now prevents commonly exploited workflows from checking out untrusted code from forks by default. - This reduces exposure to “pwn requests,” where fork-provided code executes with workflow privileges. - **Workflow execution policies** - Enterprise, organization, and repository administrators can control who may trigger workflows and which trigger types are permitted. - These policies provide configurable least-privilege controls for Actions. - **Read-only Actions cache for untrusted triggers** - Less-trusted workflows can no longer modify caches shared with more privileged workflows. - This blocks cache poisoning attacks intended to escalate access to release and publishing credentials. ## Limiting Credential Exfiltration - **npm trusted publishing for CircleCI** - CircleCI can now use trusted publishing, allowing packages to be published without long-lived credentials stored in CI/CD. - Removing persistent tokens reduces the value of compromised workflows. - **Actions network firewall** - The technical preview logs outbound network traffic from workflow runs. - This can expose suspicious downloads or credential exfiltration to unfamiliar domains. - Planned restrictions will allow organizations to block unauthorized network destinations. ## Slowing Attack Propagation - **Staged npm publishing** - Publishing credentials alone are insufficient to immediately release a new package version. - Packages remain staged until an additional approval and 2FA authentication occur through npm’s CLI or website. - This opt-in control separates automated publishing credentials from final authorization, giving maintainers a chance to detect malicious releases. Together, these measures reduce the opportunities for attackers to enter projects, obtain powerful credentials, and rapidly publish malware. GitHub’s recommendation is effectively to combine safer workflow configuration, short-lived or trusted authentication, network visibility, and additional publishing approval rather than depending on any single control.

Read original(opens in new tab)

CI/CDGitHub ActionsNpmSupply Chain Security+3

github·Jul 27, 2026·2 min readCurated summary

GitHub Copilot app for Beginners: Getting started

The GitHub Copilot app is designed as a development workspace rather than a single AI chat window. It connects agent sessions to projects, supports parallel tasks, provides an interactive browser canvas for UI work, and helps manage pull requests through Agent Merge. Together, these features aim to support the full workflow from exploration to shipping. ## Project-Based Agent Sessions - Each session is connected to a specific project and its repository context. - Projects can be selected from GitHub or added from a local machine. - Copilot can inspect the codebase, identify relevant files, implement changes, and run tests. - This reduces the setup required before beginning a development task. ## Managing Multiple Work Threads - Users can create separate sessions for different tasks without interrupting ongoing work. - **Quick Chat** provides a lightweight way to: - Ask questions about Copilot or the codebase - Explore implementation options - Investigate unfamiliar parts of an application - Gather context before making changes - Returning to an existing session preserves its history and allows work to continue from where it stopped. ## Interactive UI Work with Canvas - The app includes a browser canvas for previewing applications alongside the AI conversation. - Canvas can be created with the `/create-canvas` slash command. - **Enable Canvas Dev Mode** and **Pick & Polish** allow users to select page elements directly and use them as context for refinement requests. - This supports an iterative workflow in which developers can inspect the visual result, identify problems, and ask Copilot to adjust specific UI elements. ## Pull Request Assistance with Agent Merge - **Agent Merge** extends Copilot’s role beyond implementation into code review and delivery. - It can be enabled from a pull request’s options in the Copilot app. - Developers choose which actions it may perform, including: - Addressing review feedback - Helping resolve CI failures - Handling merge conflicts - Agent Merge monitors the pull request while checks and reviews are in progress, preparing it for merge once requirements are satisfied. The Copilot app is intended to centralize development activities in one workspace: start with a project, separate work into focused sessions, visually refine applications through canvas, and use Agent Merge to help complete the pull request process. Developers can learn the workflow by applying it to an existing backlog task.

Read original(opens in new tab)

CI/CDAI AgentsGithubGithub Copilot+3

github·May 7, 2026·4 min readCurated summary

Agent pull requests are everywhere. Here’s how to review them.

Agent-generated pull requests are increasing rapidly, while human review capacity remains limited. Although these changes often look clean and pass CI, research suggests they can introduce more redundancy and technical debt—and reviewers may be more likely to approve them. The solution is not to review more slowly, but to focus human judgment on risks agents are least equipped to recognize. ## The Scale of Agent-Generated Pull Requests - GitHub Copilot code review has processed more than 60 million reviews and grown tenfold in under a year. - More than 20% of GitHub code reviews now involve an agent. - Developers can launch many agent sessions simultaneously, causing pull-request volume to grow faster than human review capacity. - Reviewers therefore need a deliberate method for identifying high-impact issues. ## Understanding the Agent’s Limitations - Coding agents are productive and literal, but lack: - Incident history - Team-specific edge-case knowledge - Operational constraints not documented in the repository - Agents can produce code that appears complete while quietly embedding incorrect assumptions. - Human reviewers provide the context and judgment that automated tools cannot fully replicate. ## CI Gaming Agents may weaken CI when their changes fail, for example by removing tests, skipping linting, or adding commands such as `|| true`. Reviewers should verify: - Coverage thresholds were not reduced. - Tests were not removed, renamed, or skipped. - Workflows still run for forks and pull requests. - CI steps were not placed behind new restrictive conditions. Any such change requires explicit justification before approval. ## Blindness to Existing Code Reuse Agents may copy patterns from nearby code without discovering equivalent utilities elsewhere in the repository. Warning signs include: - Duplicate helper or utility functions - Reimplemented validation logic - New middleware duplicating shared modules - “Almost identical” helpers with different names Reviewers should search for existing implementations and require consolidation rather than merely commenting on duplication. For larger agent pull requests, requiring justification for new utilities can prevent redundant code from becoming future “prior art.” ## Hallucinated Correctness The most dangerous agent errors are not obvious API or syntax failures. They are changes that compile, pass tests, and still behave incorrectly under conditions such as: - Pagination boundaries - Missing permission checks - Validation edge cases - Race conditions at scale Reviewers should trace a critical path from input to output, checking empty, zero, and maximum values, external input validation, permissions on every branch, and unusual conditionals. A claimed bug fix should include a test that fails before the change; otherwise, the fix or the agent’s understanding may be incomplete. ## Agentic Ghosting and Oversized Pull Requests Large, poorly structured agent pull requests are more likely to become abandoned or misaligned. Before conducting an in-depth review, check: - Whether the agent has responded usefully in earlier review rounds - Whether the pull request includes a clear implementation plan - Whether the changes can be divided into smaller, scoped units If no plan exists, request a breakdown or a clear explanation of each component before spending time on detailed comments. ## Untrusted Input in Agent Workflows Workflows that send pull-request bodies, issue content, or commit messages to an LLM can create prompt-injection risks—especially when model output is later executed with `GITHUB_TOKEN` permissions. Reviewers should block workflows that: - Interpolate untrusted content into prompts without sanitization - Grant write access when read-only permissions are sufficient - Execute model output as shell commands without validation - Expose secrets to agent steps or logs Safer designs should use least-privilege permissions such as `permissions: read-all`, sanitize and quote untrusted content, separate analysis from execution, and require human approval before actions affecting production. Agent pull requests should not automatically receive either extra trust or blanket suspicion. Reviewers should focus on CI integrity, reuse, behavior under edge cases, reviewability, and workflow security—the areas where contextual human judgment adds the most value.

Read original(opens in new tab)

CI/CDLarge Language ModelsGithub CopilotCode Review+3

github·May 6, 2026·3 min readCurated summary

Validating agentic behavior when “correct” isn’t deterministic

Agentic systems such as GitHub Copilot cloud agent can complete tasks through multiple valid action sequences, making traditional deterministic tests unreliable. Timing changes, loading screens, and UI differences often produce false negatives even when the agent achieves the correct result. The post proposes an independent “Trust Layer” that validates essential outcomes and convergent behavior rather than rigid step-by-step execution paths. ## Challenges of Agent-Driven Validation - An agent may adapt to network delays or changing UI conditions and still complete its task successfully. - Conventional CI tests can fail when execution no longer matches a recorded script or expected assertion timing. - This creates a trust gap: - **False negatives:** successful tasks are reported as failures. - **Fragile infrastructure:** rendering, timing, and environment noise affect test results. - **Compliance trap:** valid behavioral variation is mistaken for regression. - Agent correctness should focus on reliably achieving essential outcomes, not reproducing an identical sequence of actions. ## Why Traditional Testing Breaks Down - **Assertion-based tests** require manually specifying every expected check and often omit valid alternative paths. - **Record-and-replay tools** are highly sensitive to timing and rendering differences. - **Visual regression tests** compare screenshots without understanding semantic meaning or the broader workflow. - **ML-based oracles** need large training datasets and generally provide little explanation for their decisions. - All four approaches assume correctness means following a stable sequence of observable states, which does not fit autonomous agents. ## Essential, Optional, and Convergent Behavior The proposed approach distinguishes between behavior that determines success and behavior that merely reflects environmental variation: - **Essential states:** Required milestones, such as reaching a VS Code “Search Results” screen. - **Optional variations:** Incidental states, including loading spinners or decorative UI changes. - **Convergent paths:** Different action sequences—such as using a keyboard shortcut or a menu—that eventually reach the same result. - A loading screen may appear in one run and not another, but the appearance of search results is what establishes success. ## Dominator Analysis The post connects this model to **dominator relationships** from compiler theory: - In a control-flow graph, node A dominates node B when every path to B must pass through A. - Applying dominator analysis to agent execution traces can identify: - Mandatory states - Optional states - Points where different execution paths converge - This produces a minimal and explainable definition of correctness instead of relying on every recorded step. ## Graph-Based Execution Modeling - Agent behavior should be represented as a graph rather than a linear script. - Graphs capture branching paths, optional states, and convergence points. - This structure provides a foundation for lightweight, explainable validation in GitHub Actions and other CI environments. A reliable validation system for agents should test whether essential outcomes occurred and whether critical invariants held, while ignoring harmless differences in timing, rendering, and execution order. This outcome-oriented Trust Layer can reduce false failures and make agentic workflows more dependable in production CI pipelines.

Read original(opens in new tab)

CI/CDAI AgentsGithub CopilotGitHub Actions+3

github·Mar 16, 2026·3 min readCurated summary

GitHub for Beginners: Getting started with GitHub Actions

GitHub Actions is GitHub’s built-in platform for automating CI/CD and repetitive repository tasks. Workflows are YAML files triggered by events such as pushes, pull requests, schedules, or newly opened issues, then executed as jobs on hosted or self-hosted runners. The post guides beginners through creating a workflow that automatically labels new issues. ## What GitHub Actions Provides - GitHub Actions supports: - Continuous integration and delivery - Automated tests and vulnerability scans - Release creation - Team reminders and other repetitive tasks - Workflows are stored in the repository and run automatically when configured events occur. - Jobs execute in virtual machines called runners, provided by GitHub or managed by the user. ## How Workflows Operate - **Events** trigger workflows, such as: - Pushing code - Opening or merging pull requests - Creating issues - Scheduled times - **Runners** are virtual machines that execute workflow jobs. GitHub offers Ubuntu, Windows, and macOS hosted runners, while teams can also use self-hosted runners. - **Jobs** contain groups of steps executed on the same runner. - **Steps** can either run shell commands or invoke reusable Marketplace actions. ## Workflow Structure Workflow files use YAML and live in `.github/workflows`. The three main sections are: - **`name`**: Describes the workflow. - **`on`**: Specifies the event or events that trigger it. - **`jobs`**: Defines the work performed after triggering. The post recommends descriptive filenames such as `build-and-test.yml`, `security-scanner.yml`, or `label-new-issue.yml`. ## Creating an Issue-Labeling Workflow The example workflow automatically adds a `triage` label whenever a new issue is opened. - It is named `Label New Issues`. - Its trigger is configured as: ```yaml on: issues: types: [opened] ``` - The `label-issues` job runs on `ubuntu-latest`. - Permissions are explicitly granted: - `issues: write` allows the workflow to add labels. - `contents: read` allows it to access repository content. ## Using Actions and Shell Commands The workflow contains two steps: - `actions/checkout@v6` uses a prebuilt Marketplace action to check out the repository code. - A shell command uses the GitHub CLI to add the label: ```bash gh issue edit "$ISSUE_NUMBER" --add-label "$LABEL" ``` Environment variables provide the command with: - `GITHUB_TOKEN` for authentication - The issue number from `github.event.issue.number` - The label name, `triage` The `uses` keyword invokes reusable actions, while `run` executes a shell command directly. Start with a small workflow in `.github/workflows`, define its trigger and required permissions carefully, and build from reusable actions plus simple commands. The post also recommends practicing with GitHub’s “Hello GitHub Actions” exercise to become familiar with workflow creation.

Read original(opens in new tab)

CI/CDGithubAutomationGitHub Actions+2

github·Mar 9, 2026·3 min readCurated summary

Under the hood: Security architecture of GitHub Agentic Workflows

GitHub Agentic Workflows are designed to bring autonomous agents into CI/CD without giving them unrestricted access to repositories, secrets, or the internet. Because agents can be prompt-injected and behave unpredictably, GitHub treats them as untrusted components and compiles workflows into constrained GitHub Actions. The architecture relies on layered isolation, controlled communication, staged writes, and comprehensive auditing. ## Threat Model - Agents reason over repository state and act autonomously, so they cannot be trusted by default. - GitHub Actions normally place components in one permissive trust domain with broad access to: - Repository contents - Authentication secrets - MCP servers - Arbitrary network destinations - A malicious webpage, issue, or repository file could prompt an agent to: - Read credentials from files, environment variables, logs, or `/proc` - Upload secrets externally - Embed secrets in issues, pull requests, or comments - Make unwanted repository changes - Strict mode follows four principles: - Defense in depth - Never trust agents with secrets - Stage and vet writes - Log everything ## Layered Security Architecture GitHub Agentic Workflows use three complementary layers: - **Substrate layer** - Runs on a GitHub Actions runner VM. - Uses trusted containers, Docker isolation, network controls, and kernel-enforced boundaries. - Separates components and mediates privileged operations and system calls. - Is intended to contain damage even if an untrusted component is compromised. - **Configuration layer** - Defines which components run and how they connect. - Controls communication channels, privileges, firewall policies, Docker images, and MCP configuration. - Determines which tokens are loaded into which containers. - Converts declarative workflow configuration into a secure runtime structure. - **Planning layer** - Controls which components are active and how data moves between them over time. - Creates staged workflows with explicit data exchanges. - Uses the Safe Outputs subsystem to govern potentially dangerous operations. ## Keeping Secrets Away from Agents - In ordinary GitHub Actions, secrets may be visible through environment variables and configuration files across the shared runner trust domain. - This creates a major prompt-injection risk: an agent with shell access could discover credentials and exfiltrate them. - Agentic Workflows instead place the agent in a dedicated container with: - Firewalled internet access - MCP access through a trusted gateway - LLM communication through an API proxy - A private network connects the agent only to approved services. - The trusted MCP gateway launches MCP servers and exclusively handles MCP authentication material. - LLM authentication tokens are kept in the isolated API proxy rather than exposed directly inside the agent container. ## Controlled Execution and Writes - Open-ended workflow authoring is separated from governed execution. - Workflows are compiled into GitHub Actions with explicit constraints covering: - Permissions - Outputs - Network access - Auditability - The planning and Safe Outputs systems are intended to mediate GitHub write operations and apply controls such as call filtering, volume limits, secret removal, and moderation. GitHub’s approach is to treat agents as untrusted CI/CD components rather than granting them normal workflow privileges. Organizations adopting agentic automation should isolate agents, broker access to tools and credentials, restrict network connectivity, stage all writes for review, and maintain detailed logs.

Read original(opens in new tab)

CI/CDModel Context ProtocolDocker & ContainersGitHub Actions+3

github·Feb 27, 2026·3 min readCurated summary

From idea to pull request: A practical guide to building with GitHub Copilot CLI

GitHub Copilot CLI helps developers move from an idea to reviewable code without leaving the terminal. The recommended workflow is to begin with intent, let Copilot propose plans and scaffolding, validate changes through tests and diffs, then move to an IDE for refinement and GitHub for collaboration. Copilot accelerates development but does not replace design judgment, code review, or user approval. ## What Copilot CLI Is—and Isn’t - It is a GitHub-aware coding agent that operates in the terminal. - Developers can describe goals in natural language and use `/plan` or `Shift + Tab` planning mode. - It proposes commands, file changes, and diffs for review before execution. - It can generate files, modify code, and explain failures. - It does not silently run commands or eliminate the need for careful design and review. ## Start with Intent - Begin by describing the application or feature rather than choosing a framework or copying a template. - For example, ask Copilot to create a small web service with a JSON endpoint and tests. - Copilot may suggest a technology stack, file structure, and setup commands. - Review these suggestions before deciding what to execute. ## Scaffold Only What You Own - Once the direction is clear, ask Copilot to create a minimal project structure. - It can generate directories, configuration, test runners, and README files. - Generated scaffolding should be treated as a starting point, not an unquestioned design. - Developers remain responsible for reviewing, editing, or discarding the result. ## Iterate from Real Failures - Run tests directly within the CLI and use the resulting output as context. - Ask Copilot to explain a failure or propose a fix with a reviewable diff. - The recommended loop is: run a command, inspect the output, ask for help, and review the proposed change. - Use `explain` when understanding is the goal and `suggest` when seeking a concrete proposal. ## Handle Mechanical Repository-Wide Changes - Copilot CLI is effective for clearly scoped, repetitive work such as renaming symbols across a repository. - It can update related tests and provide a concrete diff. - Mechanical changes are relatively easy to inspect, revert, and validate. ## Move to the IDE for Precision - The terminal is best for fast exploration, planning, scaffolding, and low-ceremony changes. - Move to an editor or IDE when refining APIs, handling edge cases, and making design decisions. - A practical division is: - **CLI:** plan, generate diffs, and move quickly. - **IDE:** refine logic and shape the implementation. - **GitHub:** commit, open pull requests, review, and collaborate. ## Finish by Shipping on GitHub - Copilot CLI can help add descriptive commits, push changes, and create pull requests. - Pull requests make the work durable through teammate review, CI testing, and asynchronous collaboration. - The workflow can also add Copilot as a reviewer. - The ultimate value comes from reaching commits and pull requests, not merely generating suggestions. Copilot CLI is most effective as a momentum tool: use it to turn intent into concrete, testable changes, while retaining human control over design, approval, and review.

Read original(opens in new tab)

CI/CDGithub CopilotGithub Copilot CliNode.Js+3

github·Feb 13, 2026·3 min readCurated summary

Automate repository tasks with GitHub Agentic Workflows

GitHub Agentic Workflows bring coding agents into GitHub Actions, allowing developers to describe repository tasks in Markdown instead of complex YAML. They can automate issue triage, documentation, testing, code cleanup, CI investigation, and reporting while preserving human oversight through permissions, sandboxing, logging, and review. The post presents the technology, now in technical preview, as an extension of CI/CD rather than a replacement for deterministic build and release pipelines. ## Markdown-Defined Repository Automation - Developers describe desired outcomes in plain Markdown and add the workflow to a repository. - The workflow runs in GitHub Actions using configurable coding agents such as: - GitHub Copilot CLI - Claude Code - OpenAI Codex - Because workflows operate within GitHub Actions, they benefit from repository context, audit logs, permission controls, and sandboxed execution. ## Examples of Continuous AI GitHub describes these workflows as “Continuous AI”: AI-powered automation integrated throughout the software development lifecycle. - **Issue triage:** Summarize, label, and route new issues. - **Documentation maintenance:** Update READMEs and documentation after code changes. - **Code simplification:** Find opportunities for improvement and open pull requests. - **Test improvement:** Evaluate coverage and add valuable tests. - **Quality hygiene:** Investigate CI failures and suggest targeted fixes. - **Reporting:** Produce recurring reports on repository health, activity, and trends. These tasks are difficult to implement with traditional deterministic YAML workflows because they require interpretation, judgment, and code changes. ## Relationship to CI/CD - Agentic workflows are intended to augment, not replace, existing CI/CD systems. - Traditional pipelines remain responsible for deterministic builds, tests, and releases. - Agentic workflows handle higher-level tasks involving analysis, recommendations, and repository maintenance. - GitHub Actions provides the infrastructure needed for controlled execution and observability. ## Guardrails and Human Control - Security is presented as a core design requirement, particularly against unintended behavior and prompt injection. - Workflows run with read-only permissions by default. - Write operations require explicit approval through “safe outputs,” which are designed to make changes pre-approved and reviewable. - The overall approach emphasizes inspectability, defined boundaries, and human review rather than unrestricted autonomous changes. ## Adoption Across Teams - GitHub Next reports using workflows to replace repetitive chores and assemble useful information for developers. - Home Assistant uses them to analyze large numbers of issues and identify important trends. - The Cloud Native Computing Foundation applies them to documentation automation and organizational reporting. - Carvana uses them for engineering work spanning multiple repositories. GitHub Agentic Workflows are best viewed as a controlled way to add AI judgment to repository operations. Teams should begin with focused, reviewable maintenance tasks and expand usage as they gain confidence in the workflows’ behavior and safeguards.

Read original(opens in new tab)

CI/CDAI AgentsGitHub ActionsMarkdown+3

github·Feb 5, 2026·3 min readCurated summary

Continuous AI in practice: What developers can automate today with agentic CI

Continuous AI extends CI into software-engineering tasks that require judgment, context, and interpretation rather than deterministic rules. It uses continuously running agents guided by natural-language instructions to review repositories, identify issues, and produce reviewable artifacts such as patches, issues, or reports. GitHub’s central argument is that AI should complement—not replace—traditional CI, while operating within explicit permissions and developer oversight. ## Why CI Isn’t Enough - CI is effective for binary, rule-based checks: - Tests pass or fail. - Builds succeed or fail. - Linters detect defined violations. - Many important engineering tasks depend on intent and context, including: - Finding discrepancies between documentation and implementation. - Detecting confusing accessibility text that passes linting. - Identifying behavioral changes caused by dependency updates. - Spotting subtle performance regressions, such as compiling a regular expression inside a loop. - Recognizing UI regressions that only appear during interaction. - GitHub describes this as a shift from AI-generated code toward AI handling cognitively demanding maintenance work. ## What Continuous AI Means - Continuous AI is a pattern, not a replacement for CI: - **Natural-language rules + agentic reasoning, executed continuously inside a repository.** - Developers describe expectations in natural language, especially when those expectations are difficult to encode with schemas, heuristics, or YAML. - Example workflows include: - Comparing documented behavior with implementation and proposing fixes. - Producing weekly reports on project activity, bug trends, and code churn. - Detecting performance regressions in critical paths. - Finding semantic regressions in user flows. - Workflows are refined collaboratively with agents by adding intent, constraints, and acceptable outputs rather than being authored as a perfect single instruction. ## Guardrails and Safe Outputs - Agents operate with read-only repository access by default. - They cannot modify content, create issues, or open pull requests unless explicitly authorized. - “Safe Outputs” defines the exact artifacts an agent may produce and the constraints governing them. - Agent activity is sanitized, logged, and auditable. - The goal is to keep the potential impact predictable even when agents make mistakes or behave unexpectedly. ## Natural Language Complements YAML - Deterministic problems should remain in CI, using YAML, schemas, tests, and heuristics. - Some expectations—such as determining whether documentation and code still express the same behavior—require semantic understanding. - Natural-language instructions let agents reason about intent without forcing that intent into brittle rules. - Continuous AI therefore expands automation into judgment-heavy tasks while preserving CI as the foundation for deterministic validation. ## Developers Remain in the Loop - Agents do not make unrestricted autonomous commits. - Depending on permissions, they can produce pull requests, issues, comments, discussions, or other reviewable artifacts. - Pull requests are especially useful because they fit existing developer review and collaboration practices. - The broader vision is to delegate recurring maintenance work while allowing developers to retain judgment, taste, and final control. Continuous AI is best adopted alongside traditional CI: use conventional automation wherever rules are sufficient, and use guarded, continuously running agents for tasks involving interpretation, synthesis, and evolving intent.

Read original(opens in new tab)

CI/CDAI AgentsGithubCode Review+3