githubAug 11, 2026

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.

pull-requestsai-agentmodel-context-protocolgithub-copilot+4

githubJul 30, 2026

Stacked sessions and pull requests in the GitHub Copilot app (opens in new tab)

GitHub Copilot’s stacked sessions let developers split large, dependent changes into smaller pull requests while preserving their order. Cassidy Williams demonstrates this by modernizing a decade-old React application, recovering from an incorrect branch choice, and then starting a separate `react-bootstrap` replacement on top of the styling work. The approach made a difficult modernization more manageable and reduced the temptation to create an unwieldy “everything” pull request. ## Modernizing a Legacy Application - Williams’ personal dashboard had accumulated outdated dependencies and patterns: - React 15 - Less - An old version of `react-bootstrap` - Updating the application manually had previously seemed too time-consuming. - She used the GitHub Copilot app to plan a frontend modernization focused on: - Replacing Less with Tailwind or vanilla CSS - Improving accessibility and responsiveness - Modernizing dependencies - Cleaning up links, inputs, labels, wrapping, and container widths - Claude Opus 4.8 helped formulate the plan, while GPT-5.5 provided a review. - The initial attempt failed because the work began from the wrong branch. ## Recovering from the Wrong Branch - Williams discovered that an old `dev` branch already contained partial modernization work and was the version she actively used. - The new session had incorrectly branched from `main`, creating compatibility problems. - Rather than discard the work, she asked Copilot to: - Close the incorrect pull request - Start a fresh session from `dev` - Port the styling and accessibility changes onto that branch - Copilot handled the branch and pull request transition, preserving useful decisions from the failed attempt. ## Investigating Legacy Warnings - Testing exposed warnings involving: - `findDOMNode` - `componentWillReceiveProps` - The outdated code was largely coming from `react-bootstrap`, not Williams’ own application code. - She used Plan mode to compare upgrading or migrating existing components with removing the library. - Copilot recommended replacing `react-bootstrap` entirely. ## Stacking Dependent Sessions - Replacing `react-bootstrap` represented substantial scope beyond the current styling work. - Williams chose to submit the existing work first, then create a second session branched from it. - The new session would: - Build on the completed styling changes - Replace `react-bootstrap` - Produce a separate pull request - Eventually merge into `dev` after the first pull request - This structure keeps each change easier to review and test while maintaining the dependency between them. The practical recommendation is to use stacked sessions for large, related modernization efforts: isolate coherent tasks into separate pull requests, branch later work from earlier changes, and avoid allowing AI-assisted development to turn every improvement into one oversized change.

pull-requestsreactaccessibilitytypescript+4

githubJul 27, 2026

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.

pull-requestsai-agentgithubgithub-copilot+3

githubJul 15, 2026

GitHub for Beginners: Your roadmap to mastering the GitHub essentials (opens in new tab)

GitHub for Beginners presents a step-by-step roadmap from understanding version control to collaborating on projects through GitHub. It explains the essential Git concepts, account setup, repository creation, Markdown, and the GitHub flow. The central message is that beginners can master GitHub by learning a small set of practical tools and following a repeatable workflow. ## Understanding Version Control and Git - Version control tracks file changes over time, allowing developers to see what changed, when, and why. - Git replaces confusing file copies such as `final_v2` or `FINAL_actually` with a complete change history. - Git uses three main areas: - **Working directory:** where files are edited - **Staging area:** where changes are prepared for saving - **Local repository:** where committed history is stored - Core commands include: - `git status` to inspect changes - `git add` to stage changes - `git commit` to save a snapshot - “Pushing” code means uploading local commits to GitHub. ## Securing and Personalizing a GitHub Account - A GitHub account acts as a developer identity and should be protected with two-factor authentication. - 2FA can be enabled under **Settings → Password and authentication**. - Recovery codes should be downloaded and stored securely, such as in a password manager. - A profile README can serve as a public portfolio describing skills, projects, and interests. - The README appears on the profile when stored in a public repository named after the user’s GitHub username. ## Essential Git Commands - Beginners do not need to memorize all of Git; a small group of commands supports most daily workflows. - Important commands include: - `git config --global user.name "..."` to identify commits - `git init` to create a repository - `git clone <url>` to copy a remote repository locally - `git add .` to stage changes - `git commit -m "message"` to save changes - `git switch -c <branch>` to create and enter a branch - `git push` to upload commits - `git pull` to retrieve and merge remote changes - `git merge <branch>` to integrate another branch ## Creating a First Repository - A repository is a project’s home base: it stores files, tracks history, and supports collaboration. - To create one: - Select **New** from the GitHub dashboard - Choose a name - Set it as public or private - Optionally initialize it with a README - A `.gitignore` file excludes generated files, dependencies, system files, and temporary build output from version control. - A license communicates how others may use or share the project. ## Writing with Markdown - Markdown is a lightweight text-formatting language used throughout GitHub. - It powers READMEs, issues, pull requests, and comments. - Simple symbols and optional HTML tags can create readable documentation without complex tools. ## Following the GitHub Flow - GitHub flow provides a repeatable process for contributing safely: 1. Clone the repository 2. Create a branch 3. Make changes 4. Commit the work 5. Push the branch to GitHub 6. Open a pull request - Pull requests let colleagues review changes before they are merged. - The workflow applies to many shared projects, including repositories containing reusable AI prompts or other collaborative resources. Start with the basic Git commands, protect and document your GitHub profile, then practice the branch-and-pull-request workflow on a small repository. These fundamentals provide a practical foundation for contributing to larger team projects and open source.

pull-requestsopen-sourcegithubgit+3

githubJul 10, 2026

Better tools made Copilot code review worse. Here&#8217;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.

pull-requestsgithub-copilotagentic-aicode-review+2

lineJun 25, 2026

What If AI Agents Debated Each Other? Redesigning the Development Process Through Multi-Agent Collaboration (opens in new tab)

AI coding’s main bottleneck is no longer code generation but the human coordination surrounding it: clarifying intent, validating assumptions, testing implementations, and preparing trustworthy pull requests. LY Corporation proposes an AI-native pipeline in which specialized “proposer” and “challenger” agents debate across three stages—specification, build, and delivery—while an orchestrator decides whether to revise, escalate, or proceed. The goal is for AI to substantiate its own work before human engineers review and approve it. ## Human Coordination as the Bottleneck - Traditional AI-assisted development speeds up individual tasks but leaves handoffs between requirements, implementation, verification, and review to humans. - Engineers still need to: - Write or refine specifications - Review AI-generated drafts - Transfer failed tests and feedback between steps - Inspect diffs - Prepare PR descriptions - Decide whether the result is trustworthy - The proposed solution is not to remove human judgment, but to automate repetitive coordination while preserving human ownership and final approval. ## Proposer–Challenger Collaboration - AI responsibilities are divided between two opposing groups: - **Proposers** develop specifications, implementations, and delivery materials. - **Challengers** validate them from specialized perspectives. - The separation prevents one general-purpose assistant from combining design, implementation, testing, and review into a single unchallenged response. - Specialized roles may include: - `requirements-synthesizer` - `security-analyst` - `test-coverage-reviewer` - `technical-writer` - `evidence-verifier` - An **orchestrator** mediates disagreements, redirects discussions, resolves deadlocks, and determines whether to revise, escalate, or advance. ## The Spec–Build–Deliver Pipeline ### Specification - The specification acts as a contract for all later stages. - It records: - Goals and constraints - Interpreted requirements - Explicit assumptions - Open questions - Proposed approach - Definition of done - Agents use evidence from the workspace and external sources such as Jira, Confluence, design documents, APIs, tests, dependencies, and existing conventions. - Ambiguous but low-risk and reversible issues can be documented as assumptions. - Unsafe, destructive, externally constrained, or hard-to-reverse uncertainties are escalated instead of guessed. ### Build - The approved specification is converted into a test-first verification plan before production code is changed. - The proposer identifies expected behavior, edge cases, required tests, and execution commands. - Challengers can dispute the verification design before or during implementation. - Proposers must support rejected objections with concrete evidence such as: - Execution paths - Compiler or linter output - Failing tests - Other workspace evidence - This prevents a simple green CI result from hiding missing or inadequate validation. ### Delivery - The final output is a review-ready PR package rather than merely a diff summary. - It explains: - What changed - Where reviewers should look first - Which checks passed - Remaining risks - Which challenges were already investigated - At this stage, the orchestrator acts more like a jury, judging whether sufficient evidence exists for release. ## Structured Debate Protocol - Each agent receives stage-specific context and returns structured JSON rather than a free-form essay. - Agents do not share one live context window. Shared state consists of: - Workspace files - Generated artifacts - The orchestrator’s accumulated transcript - Each round includes a proposer response, challenger response, and orchestrator decision. - The protocol distinguishes manageable uncertainty from blocking risk. - Consistent schemas make agent outputs easy to parse, compare, and feed into subsequent rounds. - For example, a challenger can identify an unclear scope boundary, explain why it matters, assign severity and confidence, and indicate whether user input is required. ## Overall Impact - Issues move through a continuous chain: debated specification, branch, tested implementation, and review-ready PR. - Humans intervene mainly to define intent, approve the final result, or resolve explicitly escalated decisions. - The central leverage comes not from generating code faster, but from requiring AI to explore, challenge, verify, and package its work before asking engineers to pay attention. The practical recommendation is to redesign AI development around explicit artifacts, specialized adversarial roles, evidence-based decisions, and automated handoffs. Human engineers should remain the final decision-makers, while AI handles the intermediate coordination and proof-building work.

pull-requestsai-agentcode-reviewcontinuous-integration+3

awsJun 17, 2026

Proactively reduce tech debt autonomously with AWS Transform – continuous modernization (preview) | Amazon Web Services (opens in new tab)

AWS is previewing AWS Transform – continuous modernization, a capability designed to continuously detect, prioritize, and remediate technical debt across thousands of repositories. It replaces fragmented, manual tooling with configurable analysis, automated pull requests, and current compliance visibility. The goal is to help engineering and platform teams keep codebases modern as dependencies, frameworks, runtimes, and security requirements evolve. ## Continuous Technical Debt Analysis - Scans connected repositories against configurable organizational baselines. - Produces findings within hours, including: - End-of-life dependencies - Deprecated frameworks - Security and code-quality issues - Organization-specific technical debt patterns - Teams can define custom policies for approved libraries, internal standards, deprecated components, or preferred coding patterns. - Findings provide a current view of which repositories are behind baseline, by how much, and which files or components are affected. - This reduces reliance on manual status reports and periodic compliance checks. ## Autonomous Remediation - AWS Transform can automatically generate pull requests for affected repositories. - Built-in transformations support common tasks such as: - Java version upgrades - SDK migrations - Library updates - Custom transformations can be created for organization-specific modernization needs. - Teams retain control by reviewing and merging the generated pull requests or applying their own fixes. - Continuous analysis verifies when repositories return to compliance without requiring manual confirmation. ## Integrated Security Remediation - Integration with AWS Security Agent brings source-code security vulnerabilities into the same workflow. - Security findings appear alongside other technical debt in a prioritized list. - Remediation is delivered through pull requests rather than separate, disconnected security processes. ## Dashboard and Remediation Campaigns - The AWS Transform web application provides portfolio-level visibility across repositories. - Users can view finding severity, affected files, categories, repositories, and available remediation options. - Remediation campaigns track: - Pull requests created - Pull requests merged - Repositories restored to compliance - AWS Transform supports repositories connected from GitHub and local environments. ## Continuous Mode and Campaign Mode - **Continuous mode** handles recurring maintenance: - Dependency upgrades - Security patches - Runtime updates - Coding-standard enforcement - **Campaign mode** is intended for larger, project-based changes, such as migrating frameworks or upgrading a major runtime across hundreds of applications. - AWS Transform custom remains the flexible option for substantial modernization projects, while continuous modernization focuses on high-volume, ongoing maintenance. AWS Transform – continuous modernization is available in preview through the AWS Transform web application, AWS Transform Kiro Power, MCP, and skills for coding-agent integration. It is most useful for organizations that need automated, organization-wide visibility and pull-request-based remediation for continuously accumulating technical debt.

pull-requestsmcpjavaaws-lambda+4

githubMar 5, 2026

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.

pull-requestsreactgithub-copilotagentic-ai+4

githubFeb 27, 2026

From idea to pull request: A practical guide to building with GitHub Copilot CLI (opens in new tab)

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.

pull-requestsgithub-copilotcontinuous-integrationgithub-copilot-cli+3

githubFeb 26, 2026

What&#8217;s new with GitHub Copilot coding agent (opens in new tab)

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.

pull-requestsgithub-copilotgithub-actionssecret-scanning+4

microsoftJul 14, 2025

Enhancing Code Quality at Scale with AI-Powered Code Reviews (opens in new tab)

Microsoft developed an AI-powered pull request reviewer to reduce routine review work, catch defects earlier, and help developers merge code faster. What began as an internal experiment now supports more than 90% of Microsoft’s PRs—over 600,000 per month—and has influenced GitHub’s Copilot for Pull Request Reviews. The central lesson is that AI works best as a human-in-the-loop assistant embedded directly into existing workflows. ## Addressing PR Review Bottlenecks - Human reviewers often spend time on style issues and minor bugs while overlooking architectural or security concerns. - Large, multi-file PRs can lack sufficient context and may wait days or weeks for review. - The AI reviewer automatically joins new PRs and handles repetitive or easily missed checks, allowing humans to focus on higher-level decisions. ## AI-Powered Review Features - **Automated comments:** Flags issues such as missing null checks, error-handling problems, sensitive-data risks, inefficient algorithms, and style inconsistencies. - **Suggested fixes:** Provides corrected snippets or alternative implementations, but authors must explicitly review and apply changes. AI does not commit changes automatically. - **PR summaries:** Generates descriptions of the change and highlights key modifications across the diff. - **Interactive Q&A:** Reviewers can ask questions about parameters, code behavior, or the impact on other modules directly in the PR discussion. - **Workflow integration:** The assistant behaves like a normal reviewer, requiring no separate tools or interfaces and optionally engaging as soon as a PR is opened. ## Effects on Quality and Development Speed - AI-assisted reviews reduced median PR completion times by 10–20% in early studies across 5,000 repositories. - Early feedback reduces waiting time, back-and-forth cycles, and the chance that minor issues delay approval. - The system has identified bugs such as missing null checks and incorrectly ordered API calls before they reached production. - Developers, particularly new hires, can use the explanations as continuous guidance on coding standards and best practices. ## Team-Specific Customization - Teams can configure repository-specific review guidelines. - Custom prompts support specialized checks, including regression detection based on historical crash patterns and validation of deployment or change gates. - This extensibility allows the reviewer to address concerns beyond generic code quality rules. ## Feedback Between Internal and External Products - Microsoft’s internal deployment provided early feedback on review quality, usability, and developer trust. - Internal experiments helped shape features such as inline suggestions and human-controlled change application. - These lessons contributed to GitHub Copilot for Pull Request Reviews, which reached general availability in April 2025. - Microsoft also uses learnings from GitHub’s broader external adoption to improve its internal development practices, creating an ongoing feedback loop between first-party and third-party products. Overall, the post recommends treating AI review as an always-available first pass—not a replacement for human judgment. Its greatest value comes from seamless integration, strong customization, and keeping authors and reviewers accountable for final decisions.

pull-requestsgen-aigithubgithub-copilot+3

figmaSep 25, 2018

Microsoft automates design handoff with Figma’s API [Video] | Figma Blog (opens in new tab)

Microsoft Dynamics 365 for Talent’s design team used Figma’s API to automate the slow handoff between designers and engineers. By connecting Figma webhooks to their development workflow, saving a new design version automatically generates a pull request for review and approval. The team reported reducing the handoff process by about 70%, allowing designers and engineers to focus on their primary work. ## The Design Handoff Problem - After adopting Microsoft’s Fluent Design System, the team focused heavily on scaling visual design elements. - Even minor design updates required negotiation and prioritization between designers and engineers. - With a large enterprise workload, engineers could take a week or more to move a single design element into production. - The team needed a workflow that could support a high designer-to-engineer ratio while reducing manual coordination. ## Automating the Workflow with Figma’s API - During Microsoft’s OneWeek hackathon, the Dynamics 365 for Talent team built an automation around Figma’s web-based API. - A Figma webhook detects when a designer saves a new version of a file. - That event automatically creates a pull request containing the design change. - Designers and engineers can review, approve, and commit the update through the existing development process. ## Reported Benefits - The automated workflow reduced the overall handoff process by approximately 70%. - Designers gained more time to create and refine designs. - Engineers spent less time processing design requests and more time developing features. - The approach made design-system updates faster and easier to scale. The example demonstrates how integrating design tools directly with engineering workflows can eliminate repetitive coordination and accelerate production changes. Teams facing similar handoff bottlenecks can consider webhook- and API-driven automation to connect design revisions with code review and deployment.

pull-requestsdesign-systemsfigma-apiwebhooks+2