Copilot Code Review als Agent: So baust du deinen eigenen Reviewer in VS Code

Reviews sind Pflicht, aber sie sind auch zeitaufwändig. Nicht wegen der fünf Minuten, die jemand auf einen Diff schaut, sondern wegen Kontextwechseln, Review-Schleifen und der Tatsache, dass gute Reviewer:innen in jedem Team knapp sind. Gleichzeitig willst du die Sicherheit haben, dass Änderungen korrekt sind, keine Non-Functional Requirements (NFRs) vernachlässigt werden und es langfristig wartbar bleibt.

Genau hier lohnt sich ein GenAI Pre-Review vor dem Push oder Pull Request: Jede:r Entwickler:in kann lokal einen strukturierten Review laufen lassen, bevor der Human Review startet. Der PR bekommt dadurch weniger Überraschungen, weniger Review-Schleifen und das Team gewinnt Zeit für die wirklich wichtigen Dinge. In diesem Artikel bauen wir Schritt für Schritt einen eigenen Review-Agent in VS Code, inklusive Guidelines und NFR-Checks als Input und einem pragmatischen Weg, Findings in Azure DevOps PRs zu schreiben.

Warum Code Reviews unverzichtbar sind und was Menschen dabei oft übersehen

Code Reviews sind mehr als eine Formalität. Sie sind ein Mechanismus, der Qualität und Teamfähigkeit gleichzeitig verbessert: Risiken werden früher sichtbar, Wissen verteilt sich, und es entsteht ein gemeinsames Verständnis für Standards.

In der Praxis landet der Fokus im Review aber oft zu stark auf Style oder offensichtlichen Bugs. Die wirklich teuren Dinge sind subtiler und liegen meist in den nicht-funktionalen Anforderungen. Eine typische Code Review umfasst deshalb mehrere Aspekte:

• Korrektheit und Edge Cases: Fehlersituationen, Null-/Empty-Handling, Ausnahmen.
• Fehlerbehandlung und Observability: Sinnvolles Logging, Telemetrie, sinnvolle Metriken.
• Security und Privacy: Input Validation, Secrets Handling, AuthN/AuthZ, Datenminimierung.
• Performance und Skalierung: Hot Paths, Allokationen, Query-Patterns, Backpressure.
• Architektur und Konsistenz: Patterns, Naming, Dependency-Richtung, Schichtentrennung.
• Testbarkeit und Testabdeckung: Sind die kritischen Pfade abgedeckt und sind Tests stabil?

Warum gibt es trotzdem Lücken? Zeitdruck, fehlender Kontext, und Change Blindness, also die Unfähigkeit, Veränderungen im Code richtig wahrzunehmen, sind echte Faktoren. Dazu kommen unterschiedliche Reviewer-Standards: Was bei Person A ein Blocker ist, rutscht bei Person B durch. Genau hier kann GenAI helfen, nicht als Ersatz, sondern als konsistente zweite Perspektive.

Was du heute schon bekommst: Copilot Code Review in GitHub & VS Code

Wenn du GitHub nutzt, bekommst du inzwischen sehr viel out of the box: Copilot kann Pull Requests direkt auf GitHub.com reviewen, du kannst Reviews erneut anfordern und du kannst das Ganze in deinen Prozess integrieren. Auch lässt sich der Review-Output über Repository- und Path-spezifische Instructions anpassen.

In VS Code selbst kannst du Copilot Code Review auch lokal nutzen. Der offizielle Workflow ist simpel: Markierten Code reviewen oder alle uncommitted changes reviewen. Die Schritte sind in der Doku gut beschrieben, inklusive des Buttons in der Source-Control-Ansicht: Using GitHub Copilot code review (VS Code).

Eine interessante Alternative zur nativen VS Code Integration ist die Community-Extension GitHub Copilot Code Reviewer im VS Code Marketplace. Im Unterschied zur Standardintegration, die meist nur auf uncommitted changes oder markierten Code schaut, kannst du mit der Extension gezielt Git Diffs reviewen, zum Beispiel zwischen zwei Branches oder bestimmten Commits. Das macht sie besonders nützlich, wenn du einen kompletten Feature-Branch oder einen spezifischen PR-Diff analysieren möchtest, statt nur lokale Änderungen zu prüfen.

Warum ein eigener Review-Agent sinnvoll ist

Ein eigener GitHub Copilot Review-Agent lohnt sich immer dann, wenn du mindestens eine dieser Situationen hast:

• Du bist nicht auf GitHub (z.B. Azure DevOps).
• Du willst, dass der Agent nicht nur den aktuellen Diff betrachtet, sondern eine definierte Sicht auf alle relevanten Änderungen bekommt.
• Du brauchst deutlich mehr Customization: Was genau reviewt wird, welche Guidelines gelten, wie Findings priorisiert werden.

Das Kernprinzip dahinter ist Single Source of Truth. Du willst keine Copilot-only Regeln pflegen, die sonst niemand liest. Stattdessen nutzt du dieselben Guidelines, die auch dein Team ohnehin leben sollte. Der Agent liest sie nur mit.

Das lässt sich mit GitHub Copilot einfach über Copilot Instructions lösen. Diese können im .github/copilot-instructions Ordner deines Repositories liegen und werden automatisch vom Agent geladen. Du kannst dort zum Beispiel deine Coding Guidelines, Security-Standards und Architektur-Prinzipien verlinken, so dass Copilot sie auch berücksichtigt.

Wer einen eigenen Agent in VS Code erstellen will, kann dies sehr einfach tun. Dazu muss nur ein neuer Agent Mode definiert werden, der die gewünschten Tools nutzt und ein entsprechendes Prompt-Template hat. Im nächsten Abschnitt zeigen wir dir, wie du das Schritt für Schritt machst.

Bausteine eines guten Review-Agent-Modes in VS Code

Um einen guten Review-Agent-Mode zu erstellen, definiere klar, was der Agent tun soll, was nicht, wie der Ablauf aussieht und wie der Output strukturiert ist. Du legst damit fest, wer der Agent ist, was er tut und was er ausdrücklich nicht tut.

---
name: Review Agent
description: Reviewt lokale Änderungen gegen Team-Guidelines und NFRs. Gibt Findings strukturiert aus, implementiert nichts.
tools: ['changes', 'fetch', 'search', 'runCommands', 'usages']
model: GPT-5.2
---

Im Agent Mode kannst du auch das Modell definieren, was von dem Agenten genutzt werden soll. Für Code Reviews empfiehlt sich ein leistungsfähiges Modell wie GPT-5.2 oder Claude Sonnet 4.5, um komplexe Analysen und Kontextverständnis zu gewährleisten. Aber auch die Tools, die dem Agent zur Verfügung stehen, sind entscheidend. Tools sind Plugins, die dem Agenten helfen, bestimmte Aufgaben zu erledigen, wie z.B. das Lesen von Dateien, das Durchführen von Suchanfragen oder das Ausführen von Befehlen auf der Kommandozeile.

You are an experienced .NET and web architect with a strong focus on thorough, critical code reviews.

Your task: Conduct in-depth, opinionated reviews that go far beyond a simple “Looks good.” Be specific, constructively critical, and always prioritize findings based on their impact.

You are not a cheerleader, but a seasoned architect who helps the team deliver robust, secure, and maintainable software for the long term. Your assessments are based on real code, diagnostics, and context—not assumptions.

In review mode, you are expected to:

- Identify errors, code smells, security vulnerabilities, performance issues, architectural weaknesses, and gaps in non-functional requirements.
- Provide concrete, actionable improvement suggestions—not just observations.
- Explicitly work through checklists and answer them based on the actual code and context, rather than simply repeating them.

Within the instructions, you will find links to specific coding guidelines for each language. If you detect a language in the code, read the relevant guidelines and incorporate their definitions into your evaluation.

Wenn du Inspiration für den Aufbau deines eigenen Agent Modes suchst, lohnt sich ein Blick in die kuratierte Liste von Agenten bei GitHub/Microsoft: awesome-copilot – Agents. Dort findest du viele Beispiele, wie Agenten für verschiedene Aufgaben strukturiert sind.

Auch der Plan Mode in VS Code, der euch einen strukturierten Plan für komplexe Aufgaben erstellt, ist hinter den Kulissen nichts anderes als ein Custom Agent Mode. Du kannst diesen dir direkt in VS Code anschauen, um zu sehen, wie ein gut strukturierter Agent aufgebaut ist. Besonders hilfreich sind dabei z.B. die Nutzung von XML-Tags zur Strukturierung einzelner Abschnitte, das Definieren von Stopping Rules, wann der Agent aufhören soll, und ein klar beschriebener Workflow für den Ablauf des Agents. Solche Bausteine helfen, den Agent nachvollziehbar, wiederverwendbar und robust zu gestalten. Aber auch damit der Agent seine Leitplanken kennt, in denen er agieren kann und wie er auch agieren soll.

<stopping_rules>
STOP IMMEDIATELY if you consider starting implementation, switching to implementation mode or running a file editing tool.
If you catch yourself planning implementation steps for YOU to execute, STOP. Plans describe steps for the USER or another agent to execute later.
</stopping_rules>

Ein Workflow für eine Code Review, der sich bewährt hat:

1. Target bestimmen (unstaged, staged, commit, branch diff, PR diff)
2. Kontext holen (Guidelines, Architektur, NFRs, relevante Einstiegspunkte)
3. Review durchführen
4. Output ausgeben (Klarer Next-Step pro Finding)

<workflow>
## 1. Determine the target for review:
Decide whether to review unstaged changes, staged changes, a specific commit, branch diff, or PR diff.
[...]

## 2. Gather context:
Collect relevant guidelines, architectural principles, non-functional requirements, and key entry points related to the target code.
[...]

## 3. Conduct the review:
Perform a thorough review of the target code, identifying issues and areas for improvement.
[...]

## 4. Output findings:
For each finding, provide a clear next step, including what the issue is, why it matters
[...]
</workflow>

Code Review Output der hilft

Der Unterschied zwischen nett und hilfreich ist Struktur. Ein Human Reviewer will erstmal die relevanten Inhalte sehen. Deshalb brauchst du Kennzeichnung, welche Anmerkung welche Priorität hat.

Ein einfaches Modell für die Priorisierung ist:

• [CRITICAL] Security/Data Loss/Compliance, oder Produktion ist wahrscheinlich betroffen
• [HIGH] Correctness-Probleme, die zu Bugs führen, oder NFRs werden klar verletzt
• [MEDIUM] Maintainability/Architektur/Tests, mittelfristig teuer
• [LOW] Style/Lesbarkeit, die sich leicht beheben lässt

Dadurch kann der Mensch im Review schnell priorisieren, was sofort angegangen werden muss und was später. Gleichzeitig zwingt es den Agenten, sich auf das Wesentliche zu konzentrieren. Für jedes Finding sollte der Agent liefern:

• Was ist das Problem?
• Warum ist es ein Problem (Impact)?
• Wie kannst du es fixen (konkrete Idee, kleines Snippet oder Pseudocode)?
• Wo steht die Regel (Guideline-Link oder Doc-Pfad)?
• Wenn möglich: file + line oder mindestens Symbol/Datei, damit man die Stelle auch wiederfindet.

Das führt dazu, dass der Output des Review-Agenten wirklich als To-Do-Liste genutzt werden kann. Ein Beispiel-Output könnte so aussehen:

[CRITICAL] AuthZ-Bypass möglich: Endpoint "UpdateUser" prüft nur AuthN, nicht Rolle.
Fix: Autorisierung über Policy/Role-Check ergänzen; negative Tests hinzufügen.
Ref: /docs/security/authz.md
Location: src/api/users/UsersController.cs:118

[HIGH] Fehlerhandling inkonsistent: Repository wirft Exceptions ohne Kontext.
Fix: Domain-Exception mit Ursache + strukturierte Logs; Correlation-ID übernehmen.
Ref: /docs/observability/logging.md
Location: src/data/UserRepository.ts:74

[MEDIUM] Hot Path: LINQ in Schleife verursacht unnötige Allokationen.
Fix: Vorberechnete Lookup-Map oder `ToDictionary` vor der Schleife.
Ref: /docs/performance/dotnet.md
Location: src/services/PricingService.cs:55

Neben möglichen Problemstellen sollte der Agent auch positive Aspekte hervorheben, also was gut gemacht wurde. Das motiviert das Team und zeigt, dass der Agent nicht nur kritisiert, sondern auch anerkennt.

[INFO] Gute Testabdeckung: Kritische Pfade in PaymentService sind umfassend getestet.
Ref: /docs/testing/best-practices.md
Location: src/tests/PaymentServiceTests.cs

Context ist wichtig: Guidelines & NFR-Doku als Agent-Input

Wenn dein Agent keine Regeln kennt, gibt er dir Standard-Ratschläge. Die sind manchmal hilfreich, aber sie sind selten exakt das, was bei dir als richtig gilt.

Der bessere Ansatz: Der Agent liest dieselbe Doku, die auch dein Team nutzt. Idealerweise enthält sie:

• Coding Guidelines pro Sprache (C#, TypeScript, YAML, Markdown)
• Security-, Performance- und Observability-Standards (NFRs)
• Architektur-Prinzipien und typische Patterns im Projekt
• Build-/Validation-Steps, damit Findings realistisch bewertet werden können

Wichtig ist die Art der Einbindung: Lieber referenzieren als Copy/Paste. Du willst vermeiden, dass dein Prompt riesig wird oder veraltet.

Der Agent bekommt dann die Aufgabe, diese Dateien zu lesen und seine Findings explizit dagegen zu referenzieren. Das ist der Hebel, der aus einem generischen Reviewer einen Team Reviewer macht.

Vom lokalen Review zum automatisierten Code-Check: Git Diffs, Branch- und Commit-Analysen mit Azure DevOps

Ein lokales Review auf uncommitted changes ist ein guter Start, aber es reicht oft nicht aus. In der Praxis passieren Reviews im Pull Request: Mit PR-Beschreibung, Commit-Historie, referenzierten Work Items, bereits laufenden Diskussionen und manchmal auch CI-/Policy-Kontext. Wenn dein Agent nur lokale Änderungen sieht, fehlen ihm genau diese Informationen.

Natürlich kannst du dir lokal Diffs ziehen:

# Welche Files ändern sich überhaupt?
git diff --name-only

# Branch Diff: alles, was in deinem Branch ist, aber nicht in main
git diff origin/main...HEAD

Spätestens wenn du PR-Kontext automatisiert einbeziehen oder Findings direkt im PR hinterlassen willst, lohnt es sich auf deine DevOps-Umgebung zuzugreifen. Hier kommt MCP (Model Context Protocol) ins Spiel.

MCP (Model Context Protocol) ist ein offener Standard, um Tools/APIs strukturiert für Agents zugänglich zu machen. Du kannst es dir wie eine standardisierte Schnittstelle zwischen Agent (Client) und Tool-System (Server) vorstellen.

Der Azure DevOps MCP Server bringt dir Azure-DevOps-Kontext direkt in den Agent. Dabei wird der Server lokal in deiner Umgebung ausgeführt und läuft mit deinen eigenen Credentials, handelt somit in deinem Namen und hat auch nur Zugriff auf das, was du auch sehen kannst. Typische Use Cases in unserem Code Review Fall sind dabei:

• PR-Details holen (Titel, Beschreibung, Files, Status)
• Commits und Changed Files einer PR abfragen
• Referenzierte Work Items / Links / Relations abrufen
• Bestehende Threads/Kommentare lesen, damit der Agent nicht doppelt kommentiert
• Neue Review-Kommentare/Threads als Output des Agenten direkt an die PR hängen

Der große Vorteil: Deine Findings bleiben nicht lokal im Chat, sondern landen dort, wo der Prozess stattfindet: Im Pull Request. Damit wird der Review-Agent vom netten Pre-Check zum echten Prozess-Baustein.

Dein Review-Prozess als Multiplikator: Lessons Learned & Team-Rollout

Wenn du einen Review-Agent einführst, ist der technische Teil oft der schnellste. Oftmals ist das Finetuning des Prompts, was geprüft werden soll, worauf der Agent achten muss, und wie Findings priorisiert werden, der größere Hebel.

Lessons Learned aus Projekten, in denen wir diesen Ansatz gesehen haben:

• Guideline-Zentralisierung erhöht Akzeptanz, weil niemand doppelt pflegt.
• GenAI fängt frühe Fehler ab, sodass Human Reviews mehr Zeit für Architektur und Risiko haben.
• NFR-Abdeckung wird systematischer, weil der Agent immer die Checkliste abarbeitet.
• Die Gefahr etwas zu übersehen sinkt, weil der Agent konsistenter arbeitet.

Am Ende geht es nicht darum, Menschen aus dem Prozess zu nehmen. Es geht darum, Menschen ihre Zeit zurückzugeben, damit sie auf die Dinge schauen können, die wirklich Erfahrung brauchen.

In unserem Fall nutzen wir den Review Agent lokal, wenn ein PR bereit zum Review ist, bevor wir den Human Reviewer hinzuziehen. Das erfordert natürlich, dass jeder auch eine Copilot-Lizenz hat. Eine Ausbaustufe ist, den Agenten in die CI-Pipeline zu integrieren, sodass jeder PR automatisch einen GenAI-Review bekommt, bevor er gemerged werden kann. Hier kann durchaus auch in Verbindung mit Azure OpenAI oder Azure Foundry gearbeitet werden, um die Agent-Logik in der Cloud laufen zu lassen.

Wie würdest du einen Review-Agent bei euch in den Prozess einbauen, eher als Pflicht-Gate oder als freiwilligen Pre-Check? Schau gerne bei uns auf LinkedIn vorbei und diskutiere mit.