GitHub

88 posts

github.blog/engineering

Filter by tag

github3 min readCurated summary

How to scan for vulnerabilities with GitHub Security Lab’s open source AI-powered framework

GitHub Security Lab’s open-source Taskflow Agent uses AI-driven, multi-step auditing workflows to find high-impact vulnerabilities in web applications and open-source projects. The authors report more than 80 vulnerabilities, including authorization bypasses and private-data disclosures, with about 20 already disclosed. They argue that carefully designed taskflows and prompts can give LLMs enough freedom to discover vulnerabilities while reducing hallucinations and false positives. ## Running the Audits - The taskflows are available in the [`seclab-taskflows`](https://github.com/GitHubSecurityLab/seclab-taskflows) repository. - To run an audit: 1. Start a Codespace for the repository. 2. Wait for initialization. 3. Run `./scripts/audit/run_audit.sh myorg/myrepo`. - Audits may take one or two hours on a medium-sized repository. - Results are stored in SQLite and can be inspected in the `audit_results` table. - Rows marked with a check in `has_vulnerability` indicate potential findings. - A GitHub Copilot license and premium model requests are required. - The same repository should be audited multiple times because LLM results are nondeterministic; using different models may reveal different vulnerabilities. - Private repositories require changes to the Codespace configuration to grant access. ## How Taskflows Work - Taskflows are YAML files defining ordered tasks and dependencies for an LLM. - The `seclab-taskflow-agent` runs tasks sequentially and passes their results between stages. - Repository audits begin by dividing the codebase into functional components. - For each component, context is gathered, including: - Untrusted-input entry points - Intended privilege levels - Component purposes and behavior - This context is stored in a database for later auditing tasks. - Separate tasks can: - Suggest generic security issues - Carefully verify each suggested issue - Focus on specific vulnerability classes - Tasks can be reused across many components asynchronously through templated prompts and component-specific substitutions. ## Why Use Multiple Tasks - A single large prompt is less reliable because LLMs may omit steps in complex, multi-stage investigations. - Taskflows help control, debug, and structure the process even when models provide large context windows. - Breaking work into stages allows each result to be reviewed and reused as context for subsequent analysis. - Repeated task execution across components makes the approach scalable for large repositories. ## General Security Auditing - The team initially used the framework to triage CodeQL alerts, where strict instructions and predefined criteria helped limit false positives. - General auditing is more difficult because the LLM must search broadly for vulnerabilities rather than evaluate known alerts. - Greater freedom increases the risk of hallucinations and unexploitable findings. - The authors’ approach uses taskflow design and prompt engineering to preserve a high true-positive rate while allowing the model to investigate diverse security issues. ## Reported Vulnerabilities - The taskflows have found more than 80 vulnerabilities in open-source projects. - Many reported issues are high-impact, including: - Authorization bypasses - Information disclosure - Logging in as another user - Accessing private user data - Examples include exposing personally identifiable information in ecommerce shopping carts and authenticating to a chat application with arbitrary passwords. - The authors manually verify findings before reporting them and maintain an advisories page as disclosures become public. The practical recommendation is to run the open-source taskflows on your own projects, repeat audits with different models, and manually validate every result. The framework is intended to improve through shared taskflows, prompts, and findings across the security community.

Read original(opens in new tab)
github3 min readCurated summary

60 million Copilot code reviews and counting

Copilot code review has grown tenfold since launch, surpassing 60 million reviews and accounting for more than one in five GitHub code reviews. GitHub argues that effective AI review is not about maximum coverage or comment volume, but about accurate, actionable feedback delivered quickly enough to support development. Its newer agentic architecture, informed by user feedback and continuous evaluation, is designed to improve context, reduce noise, and help teams merge with greater confidence. ## Redefining a “Good” Code Review - GitHub’s focus has shifted from exhaustive review coverage to high-signal feedback that helps pull requests move forward. - The system evaluates reviews across three dimensions: - **Accuracy:** Identifying consequential logic and maintainability problems. - **Signal:** Prioritizing useful findings over a high number of comments. - **Speed:** Providing a timely first pass while accepting some latency for deeper analysis. ## Measuring Accuracy - Copilot combines internal tests against known code issues with production data from real pull requests. - Key production indicators include: - Developer thumbs-up and thumbs-down reactions. - Whether flagged issues are fixed before the pull request is merged. - GitHub says these measures help distinguish useful scrutiny from feedback that merely slows development. ## Prioritizing Signal Over Volume - Copilot produces actionable feedback in 71% of reviews and remains silent in the other 29% when it finds nothing worth reporting. - It now averages approximately 5.1 comments per review without increasing review churn or lowering quality standards. - Examples of high-signal findings include missing React hook dependencies and retry loops that could run indefinitely when an API returns HTTP 429 without a `Retry-After` header. ## Trading Some Speed for Better Reasoning - GitHub treats latency as a deliberate trade-off: deeper analysis is preferable to fast but noisy feedback. - A recent switch to a more advanced reasoning model increased positive feedback by 6% while increasing review latency by 16%. - The team continues to optimize speed, but not at the expense of findings developers can trust. ## Agentic Architecture and Repository Context - The redesigned system retrieves context, explores repositories, and reasons about architecture and invariants instead of examining changes in isolation. - This architectural shift produced an initial 8.1% increase in positive feedback. - Improvements include: - Identifying issues during analysis rather than waiting until the end, reducing forgotten findings. - Retaining memory across reviews to recognize recurring patterns. - Creating explicit plans for long or complex pull requests. - Reading linked issues and pull requests to compare code against project requirements. ## Making Reviews Easier to Navigate - Multi-line comments attach feedback to logical code ranges, making problems and suggested fixes easier to understand. - Related comments are clustered into a single unit instead of cluttering the pull request timeline. - Batch autofixes allow developers to resolve entire classes of bugs or style issues at once. - More than 12,000 organizations automatically run Copilot code review on every pull request. Copilot code review is most valuable when treated as a trusted first-pass reviewer rather than a replacement for human judgment. Teams should favor configurations and workflows that maximize actionable findings, preserve developer context, and accept modest delays when they produce materially better reviews.

Read original(opens in new tab)
github3 min readCurated summary

Scaling AI opportunity across the globe: Learnings from GitHub and Andela

GitHub and Andela argue that AI opportunity should not depend on geography or employer resources. Their AI Academy trained 3,000 engineers by embedding GitHub Copilot into real production work rather than isolated exercises. The approach improved developers’ ability to understand unfamiliar systems, work with legacy code, and focus more time on higher-value decisions—while preserving human review and accountability. ## Unequal Access to AI Skills - Developers across Africa, South America, and Southeast Asia have substantial technical talent but uneven access to: - Emerging AI tools - Mentorship and structured training - Reliable connectivity and high-performance computing - Affordable cloud services and data - Much existing training assumes constant internet access, well-resourced environments, and localized content. - Contract-based or informal work can leave developers with limited time and financial capacity for reskilling. - Without affordable access and regionally relevant learning communities, AI could deepen existing technology inequalities. ## Learning AI Within Production Work - Mid-career developers generally cannot leave live systems and deadlines to experiment with new tools. - Simply giving teams access to AI does not guarantee adoption; organizations also need: - Clear role and use-case definitions - Training tied to actual responsibilities - Updated review and quality standards - Andela selected developers whose work involved complex production systems and incorporated Copilot into: - IDE workflows - Pull request reviews - Refactoring and maintenance - This made training practical and exposed AI tools to legacy code, architectural complexity, and real production risks. ## Faster Orientation in Unfamiliar Systems - One of the first benefits was not raw code-generation speed but faster understanding of existing systems. - Developers used AI to: - Generate unit tests before changing legacy code - Reveal system behavior and architectural patterns - Draft refactors and clarify control flow - Sketch diagrams of system boundaries - Tests provided safer boundaries for modifying poorly covered legacy code. - AI suggestions still required cleanup and could introduce subtle errors, making disciplined review essential. ## Confidence and Productivity Gains - After several weeks, developers reported: - Faster onboarding - Greater confidence handling ambiguous work - Less time spent on setup and more on business and engineering decisions - Senior engineer Daniel Nascimento estimated that Copilot increased his productivity by about 50%. - The main value was not merely completing tasks faster, but freeing time to understand business needs and focus on meaningful impact. ## Practical Model for AI Adoption - AI training is most effective when it is: - Embedded in everyday development - Based on real systems and responsibilities - Supported by structured guidance - Evaluated through production-quality standards - Organizations should treat AI as a capability developed through practice, not as a standalone certification or experiment. The GitHub–Andela experience suggests that inclusive AI adoption requires more than tool access. Pairing affordable, structured training with real production work can help developers worldwide build confidence, improve productivity, and participate more fully in the AI-driven future.

Read original(opens in new tab)
github1 min readCurated summary

How we rebuilt the search architecture for high availability in GitHub Enterprise Server

The provided content is a brief author biography, not a technology blog post. It describes David, a GitHub software engineer specializing in search engineering and information retrieval. His expertise spans both search infrastructure and relevance engineering. ## Author Background - Works as a software engineer at GitHub. - Specializes in search engineering. - Covers the full information-retrieval stack, including: - Search infrastructure - Relevance engineering No blog post content or technical argument was included to summarize.

Read original(opens in new tab)
github2 min readCurated summary

Join or host a GitHub Copilot Dev Days event near you

GitHub Copilot Dev Days is a global, community-led event series designed to help developers adopt AI-assisted coding in practical ways. Through live demonstrations, workshops, and hands-on exercises, the events support everyone from beginners to experienced Copilot users. GitHub encourages developers to attend local events or organize one for their own user group. ## Purpose and Audience - Events address how AI is changing software planning, coding, reviewing, and delivery. - They are open to professional developers, students, and anyone interested in improving their workflow. - Beginners learn foundational tools and best practices. - Advanced users can explore updated Copilot techniques and features. ## Event Content and Format - Sessions include live demos, practical training, and interactive workshops. - Topics may cover: - GitHub Copilot CLI - Copilot Cloud Agent - Copilot in VS Code - Visual Studio - Other supported editors - Hosts include GitHub Stars, Microsoft MVPs, GitHub Campus Experts, student ambassadors, and GitHub and Microsoft employees. - A sample agenda includes: - 30–45-minute introductory Copilot session - 30–45-minute presentation from a local developer or community leader - One-hour hands-on coding workshop - Organizers can adapt event topics and formats to their local communities. ## Event Availability - Events begin in March in cities around the world. - Dates, topics, and formats vary by location, so attendees should review individual registration pages. - Attendance also offers opportunities to meet local developers and receive food, swag, and community support. - User groups interested in hosting an event can submit an organizer request form. Developers interested in practical AI-assisted development should find a nearby GitHub Copilot Dev Day and register soon, as places are limited.

Read original(opens in new tab)
github2 min readCurated summary

GitHub for Beginners: Getting started with GitHub Issues and Projects

GitHub Issues and Projects work together to organize tasks, bugs, ideas, and broader project goals. Issues capture individual pieces of work, while Projects provide visual planning and tracking through boards, views, workflows, and charts. The post introduces beginners to creating an issue, building a Kanban project, and managing progress collaboratively. ## Why Issues and Projects Matter - Issues provide a shared space for tracking bugs, tasks, and ideas. - Projects organize issues into a larger workflow for planning and prioritization. - Using both tools helps teams coordinate work, communicate progress, and avoid missed tasks. ## Creating a GitHub Issue - Open a repository and select the **Issues** tab, then click **New issue**. - Add: - A clear title. - A detailed description explaining the expected behavior or required change. - An assignee. - Labels for classification. - An issue type, such as a bug or task. - A related project or milestone. - After creation, team members can comment and collaborate. - Typing `#` followed by an issue number creates a clickable link to another issue. - Completed work can be marked by closing the issue. ## Creating a GitHub Project - Open the repository’s **Projects** tab and click **New project**. - Choose the **Kanban** template, name the project, disable bulk import, and create it. - GitHub automatically provides columns, which can be customized. - Multiple project tabs offer different ways to view and manage the same work. ## Managing and Customizing Projects Project settings allow users to: - Control access permissions. - Create or modify custom fields. - Rename the project and edit its description. - Add a README. - Copy the project board. - Change project visibility. ### Insights and Charts - The **Insights** section provides charts for analyzing project data. - Charts can be customized through the **Configure** menu, including their layout and displayed information. ### Automated Workflows - Built-in workflows can update item statuses automatically. - Examples include: - Setting new items to `todo`. - Closing issues when their project status changes. - Marking items as `Done` when an issue is closed. ### Project Status Updates - The **Add status update** feature lets teams report project health and progress directly from the project view. GitHub beginners can start with well-written issues and then connect them to a Kanban Project board. Custom fields, automated workflows, charts, and status updates make it easier to turn individual tasks into a transparent, trackable team workflow.

Read original(opens in new tab)
github3 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)
github2 min readCurated summary

What’s new with GitHub Copilot coding agent

GitHub Copilot coding agent is becoming more capable at handling delegated development work from issue to pull request. Recent updates let users choose models, receive self-reviewed and security-checked changes, apply team-specific workflows through custom agents, and move tasks between the cloud and local CLI without losing context. Together, these features aim to reduce cleanup and make background coding tasks more reliable. ## Model selection for different tasks - The Agents panel now includes a model picker. - Users can choose faster models for routine work, stronger models for complex refactoring or integration tests, or let GitHub select automatically. - Model selection is currently available to Copilot Pro and Pro+ users; Business and Enterprise support is planned. ## Self-review before pull requests - Copilot coding agent now runs Copilot code review on its own changes before opening a pull request. - It incorporates feedback and improves the patch, such as simplifying overly complex code. - Users can inspect the review and iteration steps in the task logs before reviewing the resulting pull request. ## Integrated security checks - The agent performs code scanning, secret scanning, and dependency vulnerability checks during its workflow. - Vulnerable dependencies, exposed API keys, and other risky patterns can be identified before a pull request is created. - These code-scanning capabilities are provided without requiring a separate GitHub Advanced Security subscription for this workflow. ## Custom agents for team processes - Teams can define specialized agents in `.github/agents/`. - Custom agents can enforce repeatable procedures, such as benchmarking code before and after a performance change. - Agents can be shared across an organization or enterprise to standardize development practices. - The article describes a custom performance agent that achieved a 99% improvement on a targeted lookup function. ## Cloud and local CLI handoff - Cloud coding-agent sessions can be continued locally with their branch, logs, and context intact. - Users can select “Continue in Copilot CLI” and run the provided command in a terminal. - Pressing `&` in the CLI delegates work back to the cloud without restarting the task. GitHub recommends using these features to match models and workflows to each task, while reviewing the agent’s logs and pull requests. Planned capabilities include private mode, planning before coding, and tasks that produce summaries or reports instead of pull requests.

Read original(opens in new tab)
github2 min readCurated summary

Multi-agent workflows often fail. Here’s how to engineer ones that don’t.

Multi-agent workflows often fail because agents make implicit assumptions about state, ordering, and intended actions. The post argues that these systems should be engineered like distributed software rather than treated as chat interfaces. Typed schemas, explicit action definitions, and MCP-enforced interfaces make agent behavior more predictable and failures easier to contain. ## Typed Schemas Prevent Data Drift - Natural-language exchanges and inconsistent JSON lead to changing field names, mismatched types, and ambiguous payloads. - Typed interfaces define machine-checkable contracts, such as a `UserProfile` with fixed fields and allowed plan values. - Schema violations can fail fast, triggering retries, repairs, or escalation before invalid state spreads. - Debugging becomes contract-based instead of dependent on inspecting logs and guessing. ## Action Schemas Clarify Intent - Agents cannot reliably infer what “take action” means; they may assign, close, escalate, or do nothing. - Action schemas restrict outcomes to explicit, valid choices such as: - Requesting more information - Assigning an issue - Closing an issue as a duplicate - Taking no action - A discriminated union or similar structure ensures every agent returns one recognized action. - Invalid or ambiguous actions can be rejected, retried, or escalated. ## MCP Enforces Agent Interfaces - Schemas and action definitions are only conventions unless consistently enforced. - Model Context Protocol (MCP) provides explicit input and output schemas for tools and resources. - Calls are validated before execution, preventing agents from inventing fields, omitting required inputs, or drifting between interfaces. - MCP therefore acts as the enforcement layer for both data structure and intended behavior. Reliable multi-agent systems require explicit contracts at every boundary. Engineers should treat agents like code components: define their data and actions precisely, enforce interfaces with mechanisms such as MCP, and prevent invalid state from propagating.

Read original(opens in new tab)
github3 min readCurated summary

How AI is reshaping developer choice (and Octoverse data proves it)

AI is reshaping software development not only by increasing coding speed, but also by changing which languages and tools developers choose. Octoverse 2025 shows this shift clearly: TypeScript became GitHub’s most-used language in August 2025, overtaking Python and JavaScript. The article argues that AI reduces the friction of complex technologies, while teams must establish strong architectural and testing practices to prevent faster development from producing faster degradation. ## The Convenience Loop Changes Developer Behavior - Developers form associations between convenience and particular technologies, much like sensory cues can trigger strong memories. - Eighty percent of new GitHub developers use Copilot within their first week, establishing AI-assisted development as their baseline experience. - When AI handles boilerplate and difficult syntax, developers become more willing to use powerful but traditionally costly tools. - Recent adoption figures reflect this change: - TypeScript grew 66% year over year. - JavaScript grew 24%. - Shell scripting in AI-generated projects increased 206%. - The rise in shell usage suggests developers are choosing tools based on suitability rather than avoiding them because of friction. ## Why Strong Typing Helps AI-Generated Code - Strongly typed languages provide clearer constraints for AI models. - A TypeScript declaration such as `x: string` rules out invalid operations that would remain possible in JavaScript. - These constraints help AI produce more reliable and contextually appropriate code. - More than 1.1 million public repositories now use LLM SDKs, showing that AI integration has become mainstream. - Adoption is concentrating around languages and frameworks that work effectively with AI-assisted workflows. ## Moving Faster Without Damaging Architecture ### Guidance for Developers and Teams - Establish coding patterns before generating large amounts of code; AI follows clear existing structures better than it invents them. - Use type systems as guardrails, not as proof that business logic is correct. - Test AI-generated code rigorously, even when it appears correct or passes initial checks. ### Guidance for Engineering Leaders - AI-assisted development can increase throughput by roughly 20–30%, but architectural drift can accumulate just as quickly. - Standardize practices before scaling AI adoption through documentation, template repositories, and explicit architectural decisions. - Monitor the nature and quality of generated code, not only productivity or acceptance rates. - GitHub’s Copilot usage metrics dashboard tracks active users, agent adoption, lines added and deleted, language and model usage, and other organizational patterns. - Teams can use these metrics to identify defect-prone languages, models, or workflows and target training or stricter review processes. - Greater developer productivity increases the importance of senior engineering capacity for architectural review. AI makes more technologies accessible and is actively influencing the future popularity of languages and frameworks. Organizations should embrace the productivity gains while pairing them with standardized patterns, strong type systems, rigorous testing, and continuous architectural oversight.

Read original(opens in new tab)
github3 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)
github3 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)
github3 min readCurated summary

How to maximize GitHub Copilot’s agentic capabilities

GitHub’s guide presents Copilot’s agent mode as a partner for architecture, refactoring, and coordinated multi-file changes—not a replacement for engineering judgment. It argues that Copilot is most useful when developers first define system boundaries, assess cross-cutting effects, and then use the agent to implement and document changes. The examples build toward extending a modular Notes Service with tagging, validation refactoring, migrations, and test modernization. ## Preparing for Agentic Work - The guide assumes: - Copilot agent mode is enabled. - Familiarity with service-layer architectures. - Access to a GitHub Skills exercise template. - Willingness to review and challenge Copilot’s proposals. - Earlier-career engineers can use the exercises to learn how senior engineers evaluate architecture and risk. ## Using Copilot for System Design - Developers should begin by identifying boundaries between: - Domain logic - Data access - Interfaces - Module interactions - Copilot can analyze a service for: - Poor module boundaries and tight coupling - Async and transaction risks - Duplicated responsibilities - Testability and observability problems - It can also compare architectural approaches, such as hexagonal and layered architecture, and explain tradeoffs based on the codebase’s constraints. ## Building Modular Services - Once the architecture is understood, Copilot can coordinate implementation across: - Domain modules - Controllers - Repository abstractions - Suggested practices include dependency inversion and documenting module contracts and assumptions. - Copilot may generate interfaces, repository abstractions, controller logic, and Markdown documentation, reducing boilerplate while exposing developers to established design patterns. ## Adding a Tagging Subsystem - A seemingly simple tagging feature requires decisions about: - Embedded tags versus normalized or many-to-many data models - Search indexing, filtering, and relevance - Whether tags are API resources or internal details - Validation and invariant boundaries - Additive migrations, compatibility, and rollback - Copilot can first map the feature’s architectural impact, including migration requirements, caching, indexing, regressions, tests, and external consumers. - Implementation may span the domain model, database schema, repositories, controllers, tests, and documentation. - The example uses a `tags` column with a default empty array and adds `Tag[]` to the note model, illustrating how agent mode maintains consistency across files. ## Safe Schema Changes - The guide emphasizes that migration design involves more than writing SQL. - A production-ready change should be: - Backward compatible - Reversible - Safe under load - Transparent to dependent systems - Copilot can assist with reasoning about rollout strategies, but engineers must inspect its recommendations and validate them against operational constraints. The practical recommendation is to use Copilot agent mode as an architecture-aware collaborator: ask it to analyze and compare options first, then implement changes across the system while requiring explicit assumptions, diffs, tests, and documentation.

Read original(opens in new tab)