Mastering Code Reviews with GitHub Copilot: The Definitive Guide

Mastering Code Reviews with GitHub Copilot: The Definitive Guide

Pull requests keep piling up. Your team reviews dozens a week, and each one needs careful attention to security, performance, style, and correctness. Human reviewers catch domain-specific issues that machines miss, but they also miss the mechanical things that machines are brilliant at, such as spotting unhandled edge cases, flagging deprecated API calls, or enforcing naming conventions across hundreds of files.

What if you could get an AI-powered first pass on every pull request before a human even looks at it? Better still, what if that AI reviewer lived in your editor, your terminal, your GitHub.com workflow, and your custom automation, all at once?

GitHub Copilot offers not one but eight distinct surfaces for AI-assisted code review. This guide maps every one of them, shows you how to configure each for maximum value, and walks through a real end-to-end review workflow that combines several surfaces together.

If you have been following the GitHub Copilot series, you have already seen individual pieces of this puzzle across previous posts on custom instructions, MCP, the coding agent, and the customisation guide. This post brings everything together through the lens of code review.

---

The 8 Surfaces of AI-Assisted Code Review

Before we dive into each method, here is the landscape at a glance. Every surface serves a different context in your workflow.

#	Method	Where It Runs	Best For	Setup Required	Automation Level
1	GitHub.com Native Review	Browser (github.com)	PR reviews at scale	Org/repo settings	High
2	VS Code Review Selection	Editor (VS Code)	In-flight code review	Settings toggle	Low
3	Custom Instructions	VS Code + GitHub.com	Team review standards	.github/ config files	Medium
4	Prompt Files	VS Code	Repeatable review workflows	.prompt.md files	Medium
5	Custom Agents	VS Code	Specialised review roles	.agent.md files	Medium
6	MCP-Powered PR Review	VS Code	Deep PR analysis with live context	MCP server config	Medium
7	Coding Agent	GitHub Actions	Fully automated review tasks	Coding agent enabled	High
8	Copilot CLI	Terminal	Pre-commit local checks	Copilot CLI installed	Low

The rest of this guide walks through each surface in detail, then ties them together in a worked example.

---

1. GitHub.com Native Copilot Code Review

This is the highest-leverage surface for teams. Copilot acts as an automated reviewer directly on your pull requests in the browser, no editor or CLI needed.

How It Works

1. Navigate to any pull request on github.com.
2. Click Reviewers in the sidebar and select Copilot from the reviewer list.
3. Copilot analyses the diff and posts inline review comments, just like a human reviewer would.

You can also configure Copilot to automatically review every PR when it is opened or updated, so you never have to remember to request it.

What Feedback Looks Like

Copilot's review comments appear inline on the PR diff. Each comment includes:

• A description of the issue found.
• A suggested fix (where applicable) that you can accept with one click.
• Severity context so you can prioritise critical issues over style nits.

Comments cover categories such as:

• Bugs and logic errors (off-by-one, null dereferences, race conditions).
• Security concerns (injection risks, hardcoded secrets, missing input validation).
• Performance issues (unnecessary allocations, N+1 queries, blocking calls in async code).
• Best practice violations (deprecated APIs, missing error handling, inconsistent patterns).

Custom Coding Guidelines

By default, Copilot reviews against general best practices. To tailor feedback to your team's standards, create a coding guidelines file:

.github/copilot-code-review-instructions.md

This file contains natural language descriptions of your team's review standards. For example:

## Security

- All database queries must use parameterised queries, never string concatenation.
- Secrets must be loaded from environment variables or a vault, never hardcoded.
- All public endpoints must validate and sanitise input.

## Naming

- Use PascalCase for public methods, camelCase for private methods.
- Infrastructure resources must follow the pattern: {env}-{region}-{service}-{resource}.

## Testing

- Every public method must have at least one unit test.
- Integration tests must clean up after themselves.

## Error Handling

- Never swallow exceptions silently. Log at minimum.
- Use typed errors rather than generic Error objects.

When Copilot reviews a PR in your repository, it reads these guidelines and incorporates them into its analysis. This is how you move from generic AI feedback to feedback that matches your team's actual standards.

Enabling at Organisation and Repository Level

Repository administrators can configure Copilot code review under Settings > Copilot > Code review:

• Enable/disable Copilot as an available reviewer.
• Auto-review: Automatically request Copilot review on every new or updated PR.
• Custom coding guidelines: Point to your .github/copilot-code-review-instructions.md file.

At the organisation level, administrators can enable or enforce code review settings across all repositories, ensuring consistent review coverage.

Limitations

• Language support: Copilot code review works best with widely-used languages (JavaScript, TypeScript, Python, Go, Java, C#, Ruby, etc.). Less common languages may receive less detailed feedback.
• Context window: Very large PRs may exceed the context window. Copilot reviews what it can and notes when it could not review all files.
• Not a replacement for human review: Copilot catches mechanical issues brilliantly but does not understand your business domain. It is a first pass, not the final word.

Tip: You can work around the language support limitation by pairing Copilot with an advanced reasoning model (such as Claude Opus or Gemini 3 Pro in extended thinking mode) or a custom agent that has access to online sources via MCP web tooling or Playwright. For example, create a .agent.md reviewer that uses a web search tool to look up the latest best practices, idioms, or security advisories for a less common language. The agent can research real time strategies, verify its findings against up to date documentation, and cite the references it used so you can check them yourself. This is especially useful for newer frameworks or niche languages where the model's training data may be limited. See Section 5: Custom Agents and Section 6: MCP-Powered PR Review later in this guide for setup details.

Official docs: GitHub Copilot code review

---

2. VS Code Review Selection

If GitHub.com native review is the "PR-level" surface, VS Code review selection is the "code-level" surface. It lets you review any block of code in the editor, at any time, not just when a PR is open.

How to Trigger It

1. Select code in the editor (a function, a class, a block, whatever you want reviewed).
2. Right-click and choose Copilot > Review and Comment.
3. Alternatively, open the Command Palette (Ctrl+Shift+P) and run GitHub Copilot: Review and Comment.

Copilot analyses the selected code and posts its findings directly as editor comments, inline in your code.

You can also trigger a review of all uncommitted changes directly from the Source Control panel.

Copilot posts its findings as inline comments with suggested changes that you can apply or discard with a single click.

Configuring Review Instructions

You can customise what Copilot looks for during VS Code reviews using two settings. These live in your VS Code settings.json file. To open it:

1. Press Ctrl+Shift+P (or Cmd+Shift+P on macOS) and run Preferences: Open Settings (JSON).
2. For workspace-level settings shared with your team, create .vscode/settings.json in your repository root.

Add or update the following:

{
  // Enable the review selection feature
  "github.copilot.chat.reviewSelection.enabled": true,

  // Define what Copilot should focus on during reviews
  "github.copilot.chat.reviewSelection.instructions": [
    {
      "text": "Check for security vulnerabilities including injection attacks, hardcoded secrets, and missing input validation.",
    },
    {
      "text": "Flag any functions longer than 50 lines and suggest decomposition.",
    },
    {
      "text": "Verify error handling covers all failure paths.",
    },
  ],
}

You can also point to an external file for review instructions:

{
  "github.copilot.chat.reviewSelection.instructions": [
    {
      "file": ".github/review-instructions.md",
    },
  ],
}

This keeps your review criteria version-controlled and consistent across the team.

When to Use This Surface

• During development: Review your own code before you even commit.
• Pair programming: Get an instant second opinion on a tricky function.
• Learning: Understand unfamiliar code by asking Copilot to review and explain it.
• Pre-PR polish: Catch issues before they reach the formal review stage.

For a deeper dive into VS Code Copilot settings, see my earlier post: Tune GitHub Copilot Settings in VS Code

---

3. Custom Instructions for Code Reviews

Custom instructions shape how Copilot behaves across your workspace. For code review, they let you embed your team's review standards so that every interaction, whether in chat, inline completion, or review, reflects your agreed-upon practices.

Where to Define Review Instructions

You have three options, each with a different scope:

File	Scope	Use When
.github/copilot-instructions.md	Every Copilot interaction	You want review standards applied everywhere
.github/instructions/code-review.instructions.md	Pattern-matched files	You want review rules for specific file types
AGENTS.md	Multi-agent workflows	You use multiple AI tools, not just Copilot

Example: A Code Review Instructions File

Create .github/instructions/code-review.instructions.md:

---
applyTo: '**/*.{ts,js,py,go,cs}'
---

# Code Review Standards

When reviewing code, always check:

## Security

- No hardcoded secrets, tokens, or connection strings.
- All user input is validated and sanitised before use.
- SQL queries use parameterised statements.
- No sensitive data logged at INFO level or above.

## Reliability

- All async operations have proper error handling.
- Network calls include timeouts and retry logic.
- Resource cleanup is handled in finally blocks or using statements.

## Maintainability

- Functions do one thing and are under 40 lines where practical.
- Variable names are descriptive and follow project conventions.
- No commented-out code left in place. Use version control instead.

## Performance

- No unnecessary allocations in hot paths.
- Database queries are indexed and avoid N+1 patterns.
- Large collections use streaming or pagination rather than loading everything into memory.

The applyTo glob ensures these instructions activate whenever Copilot works with source code files, without cluttering interactions with documentation or configuration files.

How Instructions Shape Review Output

When you use Copilot to review code, either via VS Code review selection, chat, or GitHub.com, it reads these instructions and adjusts its analysis accordingly. The instructions act as a persistent checklist that Copilot applies without you having to repeat it every time.

This is the foundation layer. The other surfaces (prompt files, agents, MCP) build on top of it.

For a full walkthrough, see: Instructions and Prompt Files to supercharge VS Code with GitHub Copilot

---

4. Prompt Files for Structured Reviews

While instructions define standards, prompt files create repeatable review workflows that you invoke on demand. Think of them as named review commands.

Creating a Review Prompt File

Create .github/prompts/security-review.prompt.md:

---
description: 'Run a security-focused code review on the selected code'
mode: 'ask'
tools: ['githubRepo', 'codebase']
---

Perform a thorough security review of the current code. For each issue found, provide:

1. **Severity**: Critical / High / Medium / Low
2. **Location**: File and line reference
3. **Issue**: What the problem is
4. **Risk**: What could go wrong if left unfixed
5. **Fix**: Specific code change to resolve it

Check for:

- Injection vulnerabilities (SQL, XSS, command injection)
- Authentication and authorisation gaps
- Hardcoded secrets or credentials
- Missing input validation
- Insecure cryptographic usage
- Sensitive data exposure in logs or error messages
- Missing rate limiting on public endpoints

Format output as a table sorted by severity.

Using It

In VS Code chat, type /security-review and Copilot runs the review following your exact template. The output is structured, consistent, and actionable every time.

More Review Prompt Ideas

Here are additional prompt files you might create:

Prompt File	Purpose
performance-review.prompt.md	Analyse code for performance bottlenecks, memory leaks, and scaling concerns
test-coverage-review.prompt.md	Identify untested code paths and suggest test cases
accessibility-review.prompt.md	Check UI code for accessibility compliance (WCAG)
iac-review.prompt.md	Review Terraform/Bicep for security, cost, and best practices
api-review.prompt.md	Review API endpoints for consistency, versioning, and documentation

Each prompt file becomes a slash command in VS Code chat. Your team builds a library of review plays that anyone can run.

For more on prompt files, see: GitHub Copilot Instructions vs Prompts vs Custom Agents vs Skills vs X vs WHY?

---

5. Custom Agents for Code Reviews

Custom agents take things further by creating a dedicated reviewer persona with specific tool access and boundaries. Instead of a general-purpose assistant that also reviews code, you build a specialist.

Why Use a Custom Agent for Reviews?

• Role clarity: The agent only reviews. It does not generate new code, refactor, or make changes.
• Tool restrictions: You can limit the agent to read-only tools so it cannot accidentally modify files during review.
• Consistent voice: The agent's system prompt defines its review personality, checklist, and output format.
• Team alignment: Everyone uses the same reviewer agent, so feedback is consistent regardless of who runs it.

Example: Security Review Agent

Create .github/agents/security-reviewer.agent.md:

---
description: 'A security-focused code reviewer that analyses code for vulnerabilities and compliance issues'
tools: ['codebase', 'fetch', 'githubRepo']
---

You are a senior security engineer performing code review. Your role is strictly read-only. You analyse code but never modify it.

## Review Process

1. Examine the code provided or referenced in the conversation.
2. Check against the OWASP Top 10, CWE Top 25, and project-specific security policies.
3. For each finding, provide severity, location, description, risk, and remediation guidance.

## Output Format

Present findings in a structured report:

### Summary

- Total issues found: X
- Critical: X | High: X | Medium: X | Low: X

### Findings

For each finding:

- **ID**: SEC-001
- **Severity**: Critical/High/Medium/Low
- **Category**: (e.g., Injection, Auth, Crypto)
- **Location**: File and line
- **Description**: What the issue is
- **Risk**: Impact if exploited
- **Remediation**: How to fix it

## Rules

- Never suggest "it looks fine" without evidence of thorough checking.
- Always check for hardcoded secrets, even in test files.
- Flag any use of deprecated cryptographic algorithms.
- If you cannot determine security posture from the available context, say so explicitly.

Using It

Switch to the security-reviewer agent in VS Code chat. Everything you ask is filtered through the security reviewer's lens. Ask it to review a file, a diff, or a PR, and you get structured security feedback every time.

You can create different review agents for different concerns: architecture-reviewer.agent.md, performance-reviewer.agent.md, accessibility-reviewer.agent.md, each with its own checklist and tool set.

For a deeper look at custom agents: GitHub Copilot Instructions vs Prompts vs Custom Agents vs Skills vs X vs WHY?

---

6. MCP-Powered PR Reviews

The Model Context Protocol (MCP) lets Copilot connect to external tools and data sources. For code review, the GitHub MCP server is the key enabler. It gives Copilot live access to pull request data: diffs, comments, linked issues, CI status, and more.

Setting Up the GitHub MCP Server

If you followed my earlier post on MCP setup, you already have this configured. The GitHub MCP server provides tools such as:

• get_pull_request to fetch PR metadata and description.
• get_pull_request_diff to retrieve the actual code changes.
• list_pull_request_comments to see existing review feedback.
• get_issue to pull in linked issue context.
• list_pull_request_files to see which files changed.
• create_pull_request_review_comment to post review comments back.

Review Workflow with MCP

Here is how you can run a PR review entirely from VS Code chat using MCP:

Step 1: Fetch the PR context

Look at PR #42 in my repository. Fetch the diff, the PR description, and any linked issues.

Copilot uses the MCP tools to pull all the context it needs.

Step 2: Analyse the changes

Review the changes in PR #42 for security issues, bug risks, and adherence to our coding standards.
Cross-reference with the linked issue to ensure all requirements are addressed.

Step 3: Post feedback

Post your review findings as inline comments on PR #42, grouped by severity.

Copilot can post review comments directly on the PR via MCP, so the feedback appears on github.com where the rest of the team can see it.

Why MCP Changes the Game

Without MCP, Copilot in VS Code only sees the files open in your editor. With MCP, it can:

• Pull in the full PR diff, even files you have not opened.
• Read existing review comments so it does not duplicate feedback.
• Check CI status to correlate test failures with code changes.
• Follow linked issues to understand the intent behind the changes.
• Post comments back to the PR so everything stays in one place.

This turns VS Code chat into a full PR review workstation.

For MCP setup details, see: Supercharge VSCode GitHub Copilot using MCP

---

7. Coding Agent for Automated Reviews

The GitHub Copilot coding agent is an autonomous AI that runs in a GitHub Actions environment. While it is primarily designed for coding tasks, you can use it for review-adjacent automation.

How It Applies to Code Review

The coding agent works through GitHub Issues. You describe a task, assign it to Copilot, and it opens a PR with the result. For review workflows, consider these patterns:

Pattern 1: Fix issues found in review

Title: Address review feedback on PR #42

Review the comments on PR #42 and implement the requested changes:
- Fix the SQL injection vulnerability in UserService.cs
- Add input validation to the CreateUser endpoint
- Add unit tests for the new validation logic

Assign this issue to Copilot, and it will create a new PR addressing the review feedback.

Pattern 2: Review-driven refactoring

Title: Refactor authentication module per review guidelines

The authentication module in src/auth/ has accumulated technical debt.
Apply our coding standards from .github/copilot-code-review-instructions.md:
- Extract duplicated validation logic into shared utilities
- Add proper error handling to all OAuth flows
- Ensure all endpoints validate JWT tokens consistently

Pattern 3: Pre-review preparation

Title: Add missing tests before review

Before PR #42 is reviewed, ensure:
- All new public methods have unit tests
- Integration tests cover the new API endpoints
- Test coverage for the changed files is above 80%

The coding agent handles the mechanical work so that human reviewers can focus on design decisions and domain logic.

Key Considerations

• The coding agent cannot approve or merge PRs. It always produces a PR for human review.
• Every PR it creates is scanned by CodeQL and secret scanning.
• It runs in an isolated container, so it cannot affect your production environment.
• One task, one PR. Complex reviews may need to be broken into separate issues.

For full setup and use cases, see: Using GitHub Copilot Coding Agent for DevOps Automation

---

8. Copilot CLI for Local Reviews

GitHub Copilot CLI is a standalone terminal agent that replaces the retired gh copilot extension. You invoke it with the copilot command. It can read files, run shell commands, and interact with GitHub, making it ideal for reviewing changes before you commit or push.

Quick Local Review

Start an interactive session and ask Copilot to review your staged changes:

copilot

Then type your review prompt:

Review my staged changes for bugs, security issues, and style problems

Or use the programmatic interface for a one-shot review:

copilot -p "Review my staged changes for bugs, security issues, and style problems" --allow-tool='shell(git)'

Targeted Reviews

Review a specific file:

copilot -p "Review src/auth/login.ts for security vulnerabilities" --allow-tool='shell(cat)'

Review changes between branches:

copilot -p "Review the changes between main and feature/auth-refactor, focusing on authentication security" --allow-tool='shell(git)'

Check the changes in a pull request directly from the terminal:

copilot -p "Check the changes made in PR #42. Report any serious errors you find" --allow-tool='shell(gh)'

When to Use CLI Reviews

• Pre-commit check: Catch issues before they enter version control.
• Quick sanity check: Get a fast opinion on a small change without opening an editor.
• CI integration: Add a review step to your pipeline that flags issues early.
• Remote work: Review code on a server where you only have terminal access.

The CLI is a full agentic experience. It can read your codebase, run shell commands, and even create pull requests. For review purposes, use --allow-tool='shell(git)' to give it read access to your Git history without granting broader permissions.

For CLI setup and more examples, see: GitHub Copilot CLI: A DevOps Engineer's Practical Guide

---

The Comparison Cheat Sheet

Use this table to pick the right review surface for your situation:

Method	Where	Best For	Setup Effort	Automation	Team Visibility
GitHub.com Native	Browser	PR reviews at scale	Low (org setting)	High (auto-review)	High (comments on PR)
VS Code Selection	Editor	In-flight code	Minimal (built-in)	Manual trigger	Low (local only)
Custom Instructions	Both	Team standards	Low (one file)	Passive (always-on)	Medium (shared via repo)
Prompt Files	VS Code	Repeatable plays	Low (per prompt)	On-demand	Medium (shared via repo)
Custom Agents	VS Code	Specialised roles	Medium (agent config)	On-demand	Medium (shared via repo)
MCP PR Review	VS Code	Deep PR analysis	Medium (server setup)	On-demand	High (can post to PR)
Coding Agent	GitHub	Automated fixes	Low (already enabled)	High (issue-driven)	High (creates PRs)
Copilot CLI	Terminal	Pre-commit checks	Low (install copilot)	Manual/scriptable	Low (local only)

Choosing Your Starting Point

• Team just getting started? Enable GitHub.com native review. It requires no editor changes and covers every PR automatically.
• Individual developer wanting better habits? Start with VS Code review selection. It is built in and instant.
• Team with established coding standards? Add custom instructions. Your standards become Copilot's standards.
• Mature team wanting structured workflows? Build prompt files and agents. Create a library of review plays.
• Dealing with complex PRs and cross-references? Set up MCP. Live context makes reviews dramatically better.

---

Worked Example: End-to-End PR Review

Let us walk through a realistic review workflow that combines multiple surfaces. Imagine you have a teammate's PR that adds a new user registration endpoint with database access and email notifications.

Step 1: Pre-Push Local Check (CLI)

Before the PR even exists, the developer reviews their own changes locally:

copilot -p "Review my staged changes for security issues, particularly around user input handling and database access" --allow-tool='shell(git)'

Copilot flags that the email field is not validated and the SQL query uses string interpolation. The developer fixes both before pushing.

Step 2: PR Created, Copilot Auto-Reviews (GitHub.com)

The developer pushes and creates a PR. Copilot automatically reviews it (auto-review is enabled) and posts inline comments:

• High: Missing rate limiting on the registration endpoint.
• Medium: The error response leaks internal database column names.
• Low: Variable usr should be user per naming conventions.

The team's .github/copilot-code-review-instructions.md includes rate limiting and error handling standards, so Copilot catches these against the team's own rules.

Step 3: Deep Dive in VS Code (Review Selection + MCP)

You open the PR branch in VS Code. You select the registration handler function and use Copilot > Review and Comment for a focused analysis.

Then you use MCP to pull in broader context:

Fetch PR #87, including the diff, linked issue #156, and any existing review comments.
Review the entire PR for security compliance. Consider the requirements in issue #156
and check that all acceptance criteria are met.

Copilot correlates the PR changes with the issue requirements and identifies that one acceptance criterion (email verification flow) is missing from the implementation.

Step 4: Structured Security Review (Prompt File)

You run /security-review in VS Code chat. The prompt file produces a structured table:

Severity	Location	Issue	Fix
Critical	register.ts:45	No rate limiting	Add express-rate-limit middleware
High	register.ts:62	SQL string interpolation	Use parameterised query
Medium	register.ts:78	Error leaks DB schema	Return generic error message
Low	email.ts:12	SMTP credentials in env check	Add startup validation

Step 5: Automated Fix (Coding Agent)

For the mechanical fixes, you create a GitHub Issue:

Title: Address security review findings on PR #87

Fix the following issues found during code review:
1. Add rate limiting middleware to POST /api/register (max 5 requests per minute per IP)
2. Convert SQL query on line 62 to use parameterised statements
3. Replace detailed error responses with generic messages
4. Add SMTP credential validation at startup

The coding agent picks up the issue, implements the fixes, and opens a follow-up PR.

Step 6: Human Review

With the mechanical issues resolved, the human reviewer focuses on what matters most:

• Does the registration flow make business sense?
• Is the email notification content appropriate?
• Does the database schema support future requirements?
• Are the architectural decisions sound?

AI handled the mechanical first pass. The human focuses on design, domain, and judgement.

---

Tips and Best Practices

1. Layer your review surfaces. No single surface catches everything. Use GitHub.com auto-review as your always-on baseline, prompt files for structured deep dives, and MCP for complex PRs.

2. Write clear review instructions. Whether in .github/copilot-code-review-instructions.md, VS Code settings, or agent definitions, specific instructions produce specific feedback. "Check for security issues" is vague. "Ensure all user input is sanitised, all queries are parameterised, and no secrets are hardcoded" is actionable.

3. Treat AI review as a first pass, not the final word. Copilot is exceptional at catching mechanical issues (bugs, security patterns, style violations) but does not understand your business domain. Human reviewers should always have the last say on design, architecture, and domain logic.

4. Keep review instructions version-controlled. Store them in .github/ so they evolve with your codebase and are reviewed like any other code change.

5. Start small, expand gradually. Enable GitHub.com auto-review today. Add custom instructions next week. Build your first prompt file next month. You do not need all eight surfaces on day one.

6. Use different agents for different review concerns. A security review agent should not worry about variable naming. A style review agent should not flag architectural choices. Specialised agents give focused, high-quality feedback.

7. Combine MCP with prompt files for maximum context. A prompt file defines the review structure. MCP provides the live data (PR diff, comments, issues). Together, they produce the most thorough reviews.

8. Review the reviewer. Periodically check Copilot's review output against your team's actual standards. If it is flagging too many false positives or missing real issues, update your instructions.

---

Conclusion

Code review is one of the highest-value activities in software engineering, and also one of the most time-consuming. GitHub Copilot provides eight distinct surfaces for AI-assisted review, each suited to a different moment in your workflow:

• GitHub.com catches issues at the PR level, automatically.
• VS Code catches issues at the code level, on demand.
• Custom instructions make your team's standards automatic.
• Prompt files turn review workflows into repeatable commands.
• Custom agents create dedicated reviewer personas.
• MCP connects reviews to live PR data and project context.
• The coding agent automates fixes for review findings.
• The CLI enables fast local checks before code leaves your machine.

The real power comes from combining them. Start with GitHub.com auto-review as your baseline, layer on custom instructions for your team's standards, and add prompt files and agents as your review workflows mature.

Your reviewers will thank you. Your codebase will thank you. And the bugs that never make it to production? They will never know what hit them.

Author

Marcel.LFollow

Microsoft MVP in DevTech - DevOps | DevOps Architect | Technical speaker focused on Microsoft technologies, Agentic AI, IaC & automation in Azure. Find me on GitHub: https://github.com/Pwd9000-ML

Like, share, follow me on: 🐙 GitHub | 🐧 X | 👾 LinkedIn

Date: 13-03-2026