github·May 22, 2026·3 min readCurated summary

GitHub recognized as a Leader in the Gartner® Magic Quadrant™ for Enterprise AI Coding Agents for the third year in a row

GitHub argues that AI coding has made code generation easier, shifting the main bottleneck to reviewing, securing, governing, and deploying software. It presents GitHub Copilot as an agentic platform spanning the full software development lifecycle, enabling developers to assign issues to agents and focus on reviewing and approving results. Gartner named GitHub a Leader in the 2026 Magic Quadrant for Enterprise AI Coding Agents, placing it highest for ability to execute for the third consecutive year. ## The Shift from Code Generation to Software Delivery - AI coding agents are increasingly expected to handle more than writing functions. - The harder problems now involve: - Code review - Security - Governance - Testing - Deployment - GitHub describes the new workflow as “orchestrating outcomes”: developers assign work to agents, then return to steer, review, and approve it. - Gartner projects that asynchronous AI coding-agent workflows could improve engineering productivity by 30%–50% by 2028, compared with 0%–20% gains from code assistants in 2025. ## Enterprise Adoption of GitHub Copilot - Copilot is used by 140,000 organizations, nearly three times the number reported a year earlier. - Overall growth exceeded 100% year over year. - Most users work with multiple AI models. - GitHub Copilot CLI usage nearly doubled month over month. - GitHub says these figures indicate that enterprises are adopting increasingly sophisticated, agent-driven workflows. ## Gartner’s 2026 Evaluation - Gartner evaluated 12 enterprise AI coding-agent vendors according to: - Ability to execute - Completeness of vision - GitHub was positioned as a Leader and ranked highest in ability to execute. - Gartner describes Leaders as vendors combining strong execution, market-shaping vision, rapid innovation, broad software-engineering relevance, and enterprise-grade security and governance. - The report’s Leader quadrant also includes Anthropic, Cursor, and OpenAI. ## GitHub’s Claimed Differentiators - **Developer choice:** Copilot supports multiple models and providers. - **Broad availability:** It works across editors, IDEs, CLIs, and GitHub’s web, desktop, and mobile applications. - **Full-lifecycle integration:** Copilot operates across issues, pull requests, code reviews, and GitHub Actions—not only inside the editor. - **Enterprise governance:** Teams can observe, audit, and secure how AI is used in engineering workflows. ## What GitHub Plans to Build Next - GitHub says it will expand agentic workflows across more developer-facing surfaces. - Planned investments include: - Greater model choice and intelligent model routing - Deeper integrations throughout the software lifecycle - Performance improvements based on how software is actually built and maintained on GitHub GitHub’s central recommendation is to treat AI coding agents as part of an end-to-end engineering platform rather than isolated code-generation tools. The post also notes that Gartner’s recognition is not an endorsement and that its findings should be considered alongside the full research report.

Read original(opens in new tab)

Github CopilotCode ReviewGithub Copilot CliAgentic Workflows+4

github·May 15, 2026·3 min readCurated summary

Building a general-purpose accessibility agent—and what we learned in the process

GitHub is piloting a general-purpose accessibility agent that answers accessibility questions and automatically fixes straightforward issues in front-end code. The agent has reviewed 3,535 pull requests and resolved 68% of identified issues, especially problems involving structure, control names, status messages, text alternatives, and keyboard focus. GitHub’s experience shows that an accessibility agent is most effective as an augmentation of human expertise, supported by a strong foundation of manually documented accessibility work. ## Goals and Results - The agent serves two purposes: - Provide just-in-time accessibility guidance through GitHub Copilot CLI and VS Code. - Detect and automatically remediate simple, objective accessibility issues before production. - It evaluates pull requests that modify front-end code. - Its five most common issue categories are: - Making structure and relationships understandable to assistive technologies. - Giving interactive controls clear, concise names. - Ensuring users receive important status announcements. - Providing text alternatives for non-text content. - Maintaining a logical keyboard focus order. - Example fixes can identify mismatches between visual order and screen-reader reading order, then suggest code changes that developers can commit directly. ## An Augmenting, Not Universal, Tool - GitHub frames accessibility through the social model of disability: barriers are often created by how digital environments are designed and built. - The agent is intended to help engineers remove those barriers, not “solve” accessibility independently. - It is not a silver bullet capable of handling every accessibility scenario. - Clearly limiting its responsibility helped GitHub launch the experiment more quickly and gain broader internal support. ## Why Manual Accessibility Work Matters - New and upcoming regulations, including the European Accessibility Act and the Americans with Disabilities Act’s planned WCAG 2.1 AA requirements, increase the importance of accessibility investment. - Organizations without established processes for manually identifying and fixing accessibility problems will be at a disadvantage. - GitHub already had a mature issue-management process containing: - Structured problem reports. - Reproduction steps. - Severity, service-area, and WCAG metadata. - Links to fixing pull requests. - Acceptance criteria. - Centralizing these issues in one repository made the collection a valuable reference corpus for the agent. ## Using Historical Issues as Training Material - The agent examines past accessibility issues and related pull requests to find applicable code and language patterns. - LLMs’ fuzzy matching can be useful here because it helps connect new problems with similar historical examples. - Generic instructions such as “follow accessibility best practices” are insufficient. - LLMs often reproduce accessibility antipatterns because their training data contains decades of inaccessible code. - Manually cataloged issues and organization-specific fixes provide contextual examples that are more useful than short, generic accessibility checklists. GitHub’s experience suggests that teams should first build reliable human processes for reporting and remediating accessibility issues. Once that structured knowledge exists, an agent can help apply it consistently and efficiently—while remaining a complement to, rather than a replacement for, accessibility expertise.

Read original(opens in new tab)

Github CopilotLarge Language ModelsAccessibilityGitHub Actions+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)

Github CopilotLarge Language ModelsCI/CDCode 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)

Github CopilotAI AgentsCI/CDGitHub Actions+3

line·Apr 24, 2026·4 min readCurated summary

ODW #4: From Copilot to Pilot, Automating from Implementation to PR with Agentic Coding

LY Corporation’s Orchestration Development Workshop promotes a shift from using AI as a code suggestion tool to using it as an autonomous development “pilot.” The team combined specification-driven development with Jira/Confluence access through MCP so AI agents could investigate requirements, plan implementations, write code, run checks, create pull requests, and respond to reviews. The approach improved development speed and planning, but still requires humans to review AI-generated code and retain responsibility for product quality. ## From Copilot to Agentic Coding - The team initially used GitHub Copilot for small code-generation tasks but saw limited productivity gains. - Two developments enabled a broader shift: - Existing requirements and design documents supported specification-driven development. - Jira and Confluence became accessible to AI coding tools through the Model Context Protocol (MCP). - Agentic coding gives an AI agent a high-level goal, which it decomposes into tasks and executes iteratively. - Unlike autocomplete tools, an agent can analyze the broader codebase, run commands and tests, fix lint errors, and continue until the requested feature is complete. ## Workshop Goals and Human–AI Responsibilities - The workshop focused on automating the process from implementation through pull-request creation. - Humans remained responsible for: - Defining requirements and writing specifications - Final testing, review, and release decisions - AI was assigned: - Implementation planning - Code implementation - Pull-request creation - Initial review and review-response work - This division preserved the existing development process while giving participants practical experience with agentic workflows. ## Stage 1: Research and Implementation Planning - Participants supplied a Jira ticket URL to a custom slash command. - The AI agent: - Retrieved Jira data through the Jira MCP tool - Followed Epic links and collected related tickets - Retrieved Confluence documentation through the Confluence MCP tool - Explored the codebase, using an Explore Agent where available - Wrote a detailed implementation plan to `specs/{ticket-or-topic}/plan.md` - The plan included requirements, affected components, technical analysis, implementation tasks, risks, testing considerations, and a checklist. - Saving the plan to a file made it available for human review, future sessions, and later PR generation. - The team emphasized planning early because vague instructions can lead to incorrect implementations and costly rework. ## Stage 2: Implementation and Pull-Request Creation - The reviewed plan was passed to an implementation command. - The AI was instructed to: - Understand the plan and implementation scope - Modify the code - Add or update tests - Run the test suite - Run linting and build commands - Fix any resulting problems - Explicitly listing these steps encouraged the coding agent to maintain a task checklist and complete the full development cycle. - A separate PR command generated the pull request using the team’s template. - Information gathered during the planning stage could be reused in the PR description, reducing administrative work. ## Stage 3: AI Review and Issue Resolution - An AI screening-review command analyzed the generated PR. - It also read existing comments, including: - The AI’s own prior review comments - Comments from other team members - The agent identified issues requiring changes and explained its assessment of existing comments. - After a human reviewed those conclusions, the AI could implement the necessary fixes, reducing the cost of responding to review feedback. ## Benefits and Risks - **Higher code-generation speed** - Agents can work with less frequent human intervention. - Developers can perform other tasks while agents work. - Multiple agents can potentially run in parallel. - **Earlier risk discovery** - Detailed implementation plans clarify the work before coding begins. - Planning can reveal overlooked tasks, dependencies, and risks. - **Greater review burden** - AI can generate large volumes of code that humans must still inspect. - The unfamiliar workflow may create stress for developers. - **Human accountability remains essential** - Developers are responsible for the quality of AI-generated code. - Poor-quality output increases reviewer workload and can add technical debt. ## Workshop Results - The workshop was delivered twice: - A hands-on practical session requiring prior preparation - An introductory session with more detailed support - Approximately 2,500 people participated. - More than 40% of respondents had already applied, or intended to apply, some aspect of the workshop. - The sessions provided concrete guidance on MCP server usage and effective ways to delegate coding tasks to AI agents. The recommended approach is to introduce agentic coding incrementally: keep human ownership of requirements and final quality decisions, while allowing AI to handle structured planning, implementation, testing, PR creation, and initial review.

Read original(opens in new tab)

Github CopilotAIModel Context ProtocolAgentic Coding+4

gitlab·Apr 20, 2026·3 min readCurated summary

GitHub Copilot's policy for AI training: A governance wake-up call

GitHub’s April 2026 policy change will make Copilot Free, Pro, and Pro+ interaction data—including code, prompts, outputs, and context—available for AI training by default unless users opt out. The change highlights governance risks for regulated organizations, especially when protections vary by subscription tier or can be altered through policy updates. The post presents GitLab’s no-training commitment, contractual safeguards, and transparency documentation as a stronger model for enterprise AI governance. ## What the GitHub Policy Change Means - Beginning April 24, 2026, GitHub may use Copilot Free, Pro, and Pro+ data for model training by default. - Covered data includes: - User inputs and outputs - Code snippets - Associated context - Interaction data - Users must actively opt out. - Copilot Business and Enterprise customers remain exempt under existing contracts. - Data may also be shared with GitHub affiliates, including Microsoft, for AI development. - Organizations must review license tiers, settings, contracts, and internal AI governance controls. ## Why This Matters in Regulated Industries - Source code can expose: - Proprietary business logic - Internal system architecture - Sensitive data flows - Financial algorithms and risk models - Financial institutions may face intellectual-property and model-risk concerns involving trading strategies, underwriting rules, fraud detection, and credit models. - Frameworks such as Federal Reserve SR 11-7 and DORA require documented oversight of third-party technology and material changes in vendor practices. - Public-sector environments governed by NIST 800-53 and FISMA may require sensitive code to remain within controlled boundaries. - Healthcare organizations must consider HIPAA obligations when development tools interact with clinical or patient-adjacent systems. - Default opt-in training, individual opt-out requirements, and tier-dependent protections create compliance risks. ## Requirements for Enterprise AI Vendors - **Contractual certainty:** Vendors should clearly and unconditionally define how customer data is handled. - **Auditability:** Organizations need documentation about models, training data, subprocessors, retention, and compliance status. - **Independence from vendor incentives:** Customer code should not become training data for systems that may benefit competitors. - **Operational flexibility:** Regulated customers may require self-hosting, controlled processing boundaries, or clear procedures for vendor changes. ## GitLab’s AI Governance Position - GitLab states that it does not train AI models on customer code at any pricing tier. - Its AI vendors are contractually prohibited from using GitLab customer inputs or outputs for their own purposes. - The GitLab AI Transparency Center documents: - Models powering its features - Data handling practices - Subprocessors - Retention periods - Feature compliance status - GitLab emphasizes cloud and model neutrality, supports self-hosted deployments, and addresses vendor changes through its AI Continuity Plan. - The post argues that these policies reduce vendor-concentration, compliance, and intellectual-property risks. ## Closing the Governance Gap Organizations should ask every AI vendor: - Is customer data used for model training? - Who are the model subprocessors? - What happens if data practices change? - Can AI processing remain inside the organization’s infrastructure? - What indemnification applies to AI-generated output? The post’s recommendation is to favor vendors that provide durable, contractual, and auditable answers rather than relying on defaults, temporary opt-outs, or policies that can change with short notice.

Read original(opens in new tab)

Github CopilotMachine LearningGitlabData Privacy+3

figma·Apr 8, 2026·3 min readCurated summary

How Figmates Used Figma AI to Take Delight to the Next Level | Figma Blog

Figma’s 2026 April Fun Day project, “FigCade,” used Figma Make, Figma Weave, and the Figma MCP server to create six playable mini-games in only a few days. The tools helped the team rapidly prototype ideas, explore visual styles, produce media, and translate designs into code. The project demonstrated how AI can make design and development more collaborative and iterative. ## Building a playful canvas experience - April Fun Day is Figma’s annual tradition of adding playful surprises and Easter eggs for its community. - This year, the team brought six mini-games directly into the Figma canvas for one week. - The project also gave employees an opportunity to experiment beyond their usual roles and push Figma’s tools in new ways. - The resulting FigCade included games such as: - **2Fast2Figma**, a timed quiz about Figma facts. - **FigPalette** and **Diabolical Magic Square**, featured in the game menu. ## Rapid prototyping with Figma Make - Figma Make helped the team turn ideas into working prototypes quickly. - An early concept for 2Fast2Figma was created on a Sunday morning and became functional that afternoon. - The team generated multiple prototypes, tested them with others, and iterated based on feedback. - This established a fast workflow: build something quickly, review it, align with the team, and refine it. ## Exploring visuals with Figma Weave - Figma Weave helped designers generate and explore visual assets more efficiently. - Designer Lesley Moon used it to create felt-style textures and assets, including the project’s textured cursor. - Generating many variations quickly expanded the range of visual themes the team could consider. - Weave was also used to develop the April Fun Day trailer: - Product Manager Tara Nadella explored the initial concept. - Motion Designer Fifi Law used those explorations and Lesley’s visuals to produce the final trailer in one day. ## Connecting design and code with MCP - The Figma MCP server helped developers turn design explorations into implementation. - Engineer Steven Noto used Claude and GitHub Copilot with MCP authentication. - By sharing links to specific Figma components, the coding agents could access design context and generate code matching the intended specifications. - The team moved back and forth between design and development, using AI to reduce the distance between visual concepts and working software. ## Practical takeaway FigCade illustrates how combining rapid prototyping, generative visual tools, and design-aware coding assistance can help small teams create polished interactive experiences quickly. The strongest results came from treating AI as part of an iterative design-and-development process rather than as a replacement for human direction.

Read original(opens in new tab)

Github CopilotPrototypingGenerative AIFigma Make+2

github·Mar 31, 2026·3 min readCurated summary

Agent-driven development in Copilot Applied Science

The post describes how Tyler McGoffin used GitHub Copilot to automate the intellectual work of analyzing coding-agent evaluation trajectories. This led to `eval-agents`, a tool designed to let researchers create, share, and run specialized agents. By making coding agents the primary contributors, the team rapidly added 11 agents, four skills, and workflow support while learning new approaches to prompting, architecture, and collaboration. ## The Motivation: Automating Evaluation Analysis - McGoffin analyzes coding-agent performance using benchmarks such as TerminalBench2 and SWEBench-Pro. - Each benchmark task produces a trajectory: a large JSON record of the agent’s thoughts and actions. - Reviewing hundreds or thousands of trajectories can involve hundreds of thousands of lines of data. - Copilot initially helped identify patterns, reducing the amount of material requiring manual inspection from hundreds of thousands of lines to a few hundred. - The repetitive nature of this process inspired `eval-agents`, which automates parts of the analysis itself. ## Project Goals The project was designed around three objectives: - Make agents easy for others to share and use. - Make authoring new agents straightforward. - Make coding agents the primary mechanism for contributing to the project. The third goal had the greatest architectural impact. Using Copilot to build the tool also made the repository easier for teammates to understand, extend, and collaborate on. ## An Agent-First Development Setup McGoffin’s development environment consisted of: - Copilot CLI as the coding agent. - Claude Opus 4.6 as the model. - VS Code as the IDE. - The Copilot SDK for creating agents, registering tools and skills, and accessing existing MCP servers. This setup allowed the project to reuse Copilot’s existing agent infrastructure instead of implementing those capabilities from scratch. ## Prompting Strategies - Agents perform best when treated like capable engineers rather than simple code generators. - Effective prompts are conversational, detailed, and explicit about assumptions. - Planning mode should be used before implementation mode, especially for complex tasks. - McGoffin used stream-of-consciousness descriptions to explain problems and collaborate with Copilot on possible solutions. - For example, a discussion about preventing agents from weakening regression tests led to protected test areas and human-controlled contract-test-like guardrails. - The broader lesson is that agents benefit from many of the same practices as human engineers: context, dialogue, planning, and clear constraints. ## Architectural Strategies An agent-first codebase makes maintainability work especially valuable: - Refactoring names and file structures improves the repository’s understandability. - Documentation gives agents the context needed to implement features consistently. - Additional tests expose and prevent recurring mistakes. - Removing dead code helps keep agents from copying outdated or irrelevant patterns. - Work that was traditionally postponed—cleanup, documentation, and test improvements—becomes foundational when agents are responsible for much of the implementation. ## Rapid Team Collaboration Applying these principles enabled substantial development in a short period: - Five people contributed to the project for the first time. - The team created 11 agents and four skills. - They introduced eval-agent workflows for structured streams of scientific reasoning. - In under three days, the changes amounted to approximately 28,858 added and 2,884 removed lines across 345 files. ## Practical Recommendation Teams adopting agent-driven development should invest first in clear architecture, documentation, tests, and conversational planning practices. Agents become substantially more effective when the repository provides strong context and guardrails, allowing developers to focus less on repetitive implementation and more on directing, reviewing, and improving the overall system.

Read original(opens in new tab)

Github CopilotAI AgentsModel Context ProtocolCopilot Cli+2

github·Mar 19, 2026·3 min readCurated summary

How Squad runs coordinated AI agents inside your repository

Squad is an open-source GitHub Copilot project that places a preconfigured team of AI agents directly inside a repository. Rather than relying on a single chatbot or complex orchestration infrastructure, it coordinates specialized agents for design, implementation, testing, documentation, and review. Its core argument is that repository-native, versioned context makes multi-agent development more accessible, inspectable, and resilient. ## Coordinating Specialized Agents - Install Squad with `npm install -g @bradygaster/squad-cli`, then run `squad init` in a repository. - The setup creates roles such as lead, frontend developer, backend developer, tester, and documentation specialist. - A coordinator interprets natural-language requests, loads repository context, and assigns work to specialists. - Agents can work in parallel, create files and branches, write tests, and open pull requests. - They use shared decisions and project history rather than requiring every detail to be repeated in prompts. - Testing and review happen within the workflow: - Testers evaluate implementations and reject failing code. - A rejected author is prevented from revising its own work. - Another agent must address the problems, providing a more independent review. - Developers still answer questions, correct assumptions, and review and merge pull requests; Squad is collaborative orchestration rather than full autonomy. ## Repository-Based Shared Memory - Squad uses a “drop-box” model instead of depending on live chat synchronization or complex vector databases. - Architectural decisions, library choices, and conventions are appended to a versioned `decisions.md` file. - This creates: - Persistent shared knowledge - An understandable audit trail - Recovery after disconnects or restarts - Memory that can be reviewed and changed like code ## Replicating Context Across Agents - The coordinator remains a thin router instead of attempting to manage all implementation work. - Each specialist runs in its own inference call with an independent context window. - This replicates relevant repository context across agents rather than splitting one limited context among multiple roles. - Parallel, independent contexts reduce the risk that project-management instructions and other agents’ reasoning crowd out the actual coding task. - Supported models may provide context windows of up to 200,000 tokens. ## Versioned Agent Identities and History - Each agent’s behavior is primarily defined by repository files: - A charter describing its role and responsibilities - A history recording previous work - Shared team decisions - These files live in `.squad/` alongside the application code. - Cloning a repository also restores the team’s accumulated knowledge, making the agents effectively pre-onboarded. - Keeping memory in plain text makes it inspectable, versioned, and independent of hidden model state. ## Lowering the Barrier to Multi-Agent Development Squad’s main goal is to make agentic workflows practical without requiring users to build orchestration layers, configure databases, or master advanced prompt engineering. Its repository-native design favors simple setup, transparent memory, independent review, and recoverable project context. Developers interested in this approach can install Squad and experiment with it directly in the project repository.

Read original(opens in new tab)

Github CopilotAI AgentsPrompt EngineeringMulti Agent Systems+4

github·Mar 17, 2026·3 min readCurated summary

Investing in the people shaping open source and securing the future together

Open source security depends on supporting the maintainers who sustain critical software, not merely hosting their code. GitHub argues that funding, education, practical security tools, and AI assistance can reduce maintainer burnout while improving the broader software supply chain. Its new commitments focus on making security work more manageable as AI accelerates both vulnerability discovery and attacks. ## A $12.5 Million Open Source Security Commitment - GitHub is joining Anthropic, AWS, Google, and OpenAI in committing $12.5 million to the Linux Foundation’s Alpha-Omega initiative. - The funding will help integrate emerging AI security capabilities into existing open source workflows. - The effort builds on GitHub’s broader role as a provider of security tools, education, and long-term maintainer support. ## Expanding Maintainer Resources - More than 280,000 GitHub maintainers are eligible for free access to: - Core GitHub services - GitHub Copilot Pro - GitHub Actions - Code scanning and Autofix - Secret scanning and push protection - Dependency alerts - GitHub’s Secure Open Source Fund is adding $5.5 million in Azure credits and funding for training, expertise, community support, and new partners such as Datadog, Open WebUI, the Atlantic Council, and OWASP. - GitHub Security Lab is improving security advisories and Private Vulnerability Reporting to reduce low-quality reports and ease the burden on maintainers. ## Results from Security-Focused Funding - Previous Secure Open Source Fund programs supported 138 projects and more than 200 maintainers across 38 countries. - Participating projects produced: - 191 new CVEs - More than 250 prevented secret leaks - More than 600 detected and resolved leaked secrets - These projects collectively affect billions of monthly software downloads. - GitHub concludes that security improves when maintainers receive dedicated time, funding, education, and tools that fit naturally into their workflows. ## Using AI to Reduce Maintainer Burden - AI has increased the speed and scale of vulnerability discovery for both attackers and defenders. - Maintainers are facing more automated pull requests and security reports, often with poor signal-to-noise ratios, contributing to burnout. - GitHub’s goal is to use AI for triage, pull request review, vulnerability identification, and remediation—not simply to generate more findings. - GitHub has open sourced an AI-powered security research framework so maintainers, rather than only specialized security teams, can benefit from it. - Copilot Pro provides eligible maintainers with AI-assisted code review, agentic security remediation workflows, and access to multiple leading models. GitHub’s overall recommendation is to treat AI as a force multiplier and pair it with sustained funding, education, and workflow-integrated security tools. Supporting maintainers directly is presented as the most effective way to protect the wider software ecosystem.

Read original(opens in new tab)

Github CopilotAIGithubSoftware Supply Chain Security+3

github·Mar 12, 2026·3 min readCurated summary

Continuous AI for accessibility: How GitHub transforms feedback into inclusion

GitHub built a continuous, AI-assisted accessibility feedback system to replace scattered reports, unclear ownership, and unresolved “phase two” promises. The workflow combines GitHub Actions, Copilot, and GitHub Models to turn user feedback into tracked, prioritized issues while preserving human judgment. Its goal is continuous follow-through: every accessibility barrier is captured, routed, reviewed, and acted upon. ## Accessibility as a Living System - GitHub treats accessibility as an ongoing methodology rather than a one-time audit or standalone product. - The approach combines: - Automation - Artificial intelligence - Human expertise - Real user feedback is considered more valuable than automated code scans because it reveals barriers experienced in real workflows. - The system supports GitHub’s 2025 Global Accessibility Awareness Day pledge to improve accessibility across the open source ecosystem. - Technology helps process feedback at scale, turning unstructured reports into clearer, implementation-ready work. ## Designing for Different Users The workflow was designed around three primary groups: - **Issue submitters** - Community managers, support agents, and sales representatives submit reports for users and customers. - Since they may not be accessibility specialists, the system guides them and teaches accessibility concepts during submission. - **Accessibility and service teams** - Engineers and designers need actionable reports containing reproducible steps, WCAG references, severity ratings, and ownership information. - **Program and product managers** - Leaders need trend data, issue categories, and progress visibility to prioritize investments. The design treats feedback as data moving through a pipeline and allows the process to evolve over time. ## Event-Driven Feedback Workflow - Each workflow stage triggers a GitHub Action that determines what happens next. - Key events include: - New issues launching Copilot analysis through the GitHub Models API - Status changes initiating hand-offs between teams - Resolutions triggering follow-up with the original submitter - Actions can be started manually or rerun, allowing humans to intervene whenever necessary. - GitHub initially built the system largely by hand in mid-2024; newer tools such as Agentic Workflows could now create similar Actions from natural-language instructions. - The workflow contains seven stages: - Intake - Copilot analysis - Submitter review - Accessibility team review - Link audits - Closing the loop - Improvement - Feedback loops allow submitters to rerun analysis, resolved issues to return for further review, and improvements to update Copilot prompts. ## Actioning Intake - Accessibility feedback can arrive through support tickets, social media, email, direct outreach, or GitHub’s accessibility discussion board. - Approximately 90% of feedback currently comes through the public discussion board. - Public discussions let other users: - Confirm reported problems - Add context - Share workarounds - Reports from the community often contain more detail than conventional support tickets. - GitHub acknowledges every report within five business days, including reports it cannot directly address. - When internal action is needed, a team member creates a tracking issue using a custom accessibility feedback template. - The template records: - The user’s original report - The feedback source - Relevant product components - This preserves important context as feedback moves from intake into triage.

Read original(opens in new tab)

Github CopilotGitHub ActionsAgentic WorkflowsWcag+3

github·Mar 10, 2026·2 min readCurated summary

The era of “AI as text” is over. Execution is the new interface.

The post argues that AI is moving beyond text-based question-and-answer interactions toward embedded execution. The GitHub Copilot SDK lets applications use Copilot’s planning, tool use, file modification, command execution, and error recovery capabilities directly. This enables teams to build adaptable AI workflows without creating their own orchestration infrastructure. ## Delegating Multi-Step Work to Agents - Applications can express intent and constraints instead of hard-coding every workflow step. - For a task such as “Prepare this repository for release,” an agent can: - Explore the repository - Plan the necessary work - Modify files - Run commands - Recover and adapt when failures occur - This approach is more flexible than scripts, which become brittle when workflows depend on changing context or unexpected errors. - Teams can use agentic execution while maintaining defined boundaries and observability. ## Using Structured Runtime Context - Relying on prompts to contain system logic makes workflows difficult to test, maintain, and evolve. - The Copilot SDK supports structured, composable context through: - Domain-specific tools and agent skills - Model Context Protocol (MCP) - Runtime retrieval of relevant data - Agents can directly access systems such as: - Service ownership records - Historical decisions - Dependency graphs - Internal APIs - Permissioned tools and real-time data provide more reliable grounding than embedding organizational knowledge in prompts. ## Embedding Agents Beyond the IDE - Agentic capabilities can be integrated into: - Desktop applications - Internal operational tools - Background services - SaaS products - Event-driven systems - Applications can invoke Copilot in response to events such as file changes, deployments, or user actions. - Execution happens within the product itself rather than in a separate IDE or terminal interface. - This turns AI from an auxiliary developer tool into application infrastructure available wherever the software operates. ## Execution as a New Interface - Agentic workflows are programmable planning-and-execution loops that: - Integrate with real systems - Operate under constraints - Adapt during runtime - Use tools to complete tasks - The Copilot SDK provides this execution layer so teams can focus on defining outcomes instead of rebuilding orchestration systems. The practical recommendation is to treat AI as an executable application capability rather than merely a text interface. Teams can start by identifying multi-step workflows or event-driven tasks where structured tools, runtime context, and adaptive execution would provide more value than fixed scripts.

Read original(opens in new tab)

Github CopilotAI AgentsModel Context ProtocolAgentic Workflows+2

github·Mar 6, 2026·3 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)

Github CopilotLarge Language ModelsOpen SourcePrompt Engineering+4

github·Mar 5, 2026·3 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)

Github CopilotAI AgentsReactCode Review+4

github·Mar 5, 2026·3 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)

Github CopilotAIReactRefactoring+3