GitHub/code-review

8 posts

github

From coder to orchestrator: How agents shift the role of a developer (opens in new tab)

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

github

GitHub Copilot app for Beginners: Getting started (opens in new tab)

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

github

Better tools made Copilot code review worse. Here’s how we actually improved it. (opens in new tab)

Copilot code review became more expensive and less effective after GitHub replaced its specialized exploration tools with shared `grep`, `glob`, and `view` tools. The tools themselves worked correctly, but their general-purpose instructions encouraged broad repository browsing rather than focused pull request investigation. After rewriting the instructions around diff-first review workflows, GitHub achieved roughly 20% lower average review cost without reducing review quality. ## Why the Tool Migration Regressed - Copilot code review previously used specialized tools for: - Listing directories - Searching files and directories - Reading code - These tools often returned matching lines along with surrounding context, which suited earlier models that made fewer tool calls and needed more context per request. - GitHub migrated to the shared Unix-inspired tools used by Copilot CLI and other products: - `glob` replaced `list_dir` - `grep` replaced `search_file` and `search_dir` - `view` replaced `read_code` - The migration aimed to reduce duplicated implementations and let improvements benefit multiple Copilot products. - Offline benchmarks showed higher review costs and fewer useful comments after the migration. ## Repository Browsing Instead of Pull Request Review - Execution traces showed the agent: - Searching broadly - Guessing file paths - Reading large sections of code - Finding more things to search - Carrying unnecessary context into later reasoning - This workflow is reasonable for a coding assistant asked to understand an unfamiliar repository. - It is inefficient for code review, where the agent should begin with the pull request diff and investigate a specific potential problem. - Excessive tool output increases token usage because returned file contents remain in the agent’s context window. - Broad exploration can also make the review less focused by mixing relevant evidence with unrelated code. ## The Difference Between Coding and Reviewing - A coding assistant may need to map a large area of a repository before editing code safely. - A reviewer typically asks targeted questions based on the diff, such as: - Where is the changed function called? - Is a modified configuration key used elsewhere? - Does a similar test or helper already exist? - What is the smallest code range needed to understand the behavior? - Copilot code review has a narrower objective: - Start from the pull request diff - Determine whether the change introduced a real issue - Gather only the evidence needed to confirm or dismiss that issue - The shared tools were designed for broader interactive workflows, so their instructions unintentionally encouraged the wrong behavior in the review agent. ## Instructions Were the Real Fix - GitHub concluded that changing tools was not enough; the agent’s workflow instructions also had to change. - The revised instructions emphasized: - Diff-first investigation - Targeted searches - Minimal surrounding context - Narrow evidence gathering - Avoiding unnecessary repository-wide exploration - With these workflow changes, the shared tools became more effective for review rather than merely reproducing their coding-assistant behavior. - The result was approximately 20% lower average review cost while preserving review quality. The practical lesson is that tool quality cannot be evaluated separately from the instructions and workflow guiding an agent. Shared tools can work well across products, but each use case needs instructions that match its task—in this case, focused, evidence-driven pull request review rather than broad repository exploration.

github

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

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.

github

Agent pull requests are everywhere. Here’s how to review them. (opens in new tab)

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.

github

GitHub Copilot CLI combines model families for a second opinion (opens in new tab)

GitHub Copilot CLI’s experimental Rubber Duck feature adds an independent reviewer from a different AI model family to catch mistakes before they compound. When Claude models orchestrate a task, GPT-5.4 reviews plans, implementations, and tests at key checkpoints. On SWE-Bench Pro, Claude Sonnet 4.6 with Rubber Duck closed 74.7% of the performance gap with Claude Opus 4.6 alone, particularly on complex, multi-file tasks. ## The Problem with Self-Review - Coding agents typically assess a task, plan, implement, test, and iterate. - Early assumptions can create downstream dependencies and make small mistakes expensive to fix. - Self-reflection helps, but a model reviewing its own work may retain the same training biases and blind spots. ## Cross-Family Review with Rubber Duck - Rubber Duck is a focused review agent powered by a complementary model family. - Claude orchestrators currently use GPT-5.4 as the reviewer. - It produces a short list of high-value concerns, including: - Missed details - Questionable assumptions - Architectural risks - Relevant edge cases ## Evaluation Results - On SWE-Bench Pro, Sonnet 4.6 plus Rubber Duck approached the resolution rate of Opus 4.6 running alone. - Benefits were strongest for problems involving at least three files and 70 or more steps. - Sonnet plus Rubber Duck scored: - 3.8% above the Sonnet baseline on difficult tasks - 4.8% higher on the hardest tasks across three trials - Examples included detecting: - A scheduler that would start and immediately exit - A loop overwriting one dictionary key and dropping Solr facet categories - Cross-file Redis references that would silently break email confirmation flows ## When Reviews Happen Rubber Duck can be invoked automatically, reactively, or on request: - After a plan is drafted, to prevent flawed decisions from spreading. - After complex implementation work, to identify edge cases. - After tests are written but before they run, to expose coverage gaps or weak assertions. - When the primary agent is stuck or repeating an unproductive loop. - Any time the user asks Copilot to critique its work. Copilot incorporates the feedback and explains what changed. Reviews are intentionally infrequent and targeted at checkpoints where they provide the most value. ## Availability and Use Cases - Rubber Duck is available in Copilot CLI’s experimental mode through `/experimental`. - It works with Claude Opus, Sonnet, and Haiku as orchestrator models, provided the user has GPT-5.4 access. - It is especially suited to: - Complex refactors and architectural changes - High-stakes coding tasks - Test coverage review - Getting a second opinion before committing to a plan Rubber Duck is a practical way to reduce model-specific blind spots by combining different AI families. Developers can enable it experimentally in Copilot CLI and use automatic or on-demand critiques for difficult work.

github

60 million Copilot code reviews and counting (opens in new tab)

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.

github

Continuous AI in practice: What developers can automate today with agentic CI (opens in new tab)

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.