Copilot und Coding Agents wirksam nutzen

GitHub Copilot, Claude Code und andere Coding Agents können in kurzer Zeit viel Code, Tests und Dokumentation erzeugen. Unser Beitrag GenAI in der Softwareentwicklung ordnet ein, was generative KI (GenAI) dabei leisten kann und wo ihre Grenzen liegen. Um im Alltag belastbare Ergebnisse zu erzielen, braucht dein Team neben guten Prompts und Instructions vor allem eine belastbare Grundlage, die Anforderungen, Tests, Pipelines und Betrieb verbindet.

Ein Coding Agent beschleunigt die Arbeit an einer Änderung. Fehlende Informationen erkennt er aber nicht zuverlässig und schließt sie nicht mit Produktwissen. Bleiben Anforderungen offen, fehlt Architekturkontext oder gibt eine Pipeline kaum Rückmeldung, entsteht schneller ein großer Pull Request. Vollständig wird die Änderung dadurch noch nicht.

Produkt und Planung geben einer Änderung Richtung

Ein Agent kann eine gute Lösung nur gegen eine Erwartung entwickeln, die beschrieben ist. Ein Ticket wie Versende Rechnung nach Zahlung lässt offen, welche Daten zulässig sind, wie Berechtigungen geprüft werden und was nach einem Timeout passiert. Ohne diese Entscheidungen ergänzt der Agent Lücken nach Wahrscheinlichkeiten, nicht nach deinem Produktmodell.

Beschreibe Ziel, fachlichen Ablauf, Nicht-Ziele, Akzeptanzkriterien, Risiken und verantwortliche Rollen so, dass sie im Pull Request prüfbar bleiben. Bei einer externen Zustellung gehören etwa Idempotenz, Teilausfälle, Wiederholungsregeln und Nachvollziehbarkeit dazu. Ein API-Contract wie OpenAPI konkretisiert Endpunkte, Fehlerantworten und Sicherheitsmechanismen zusätzlich für Consumer und Provider. Wie wertvolle Anforderungen in User Stories greifbar werden, beschreibt unser Beitrag Valueable Userstories.

Das ist kein Plädoyer für lange Spezifikationen. Für eine kleine Änderung reichen oft wenige präzise Sätze und ein Beispiel für einen kritischen Fehlerfall. Wichtig ist, dass Produkt, Entwicklung und Review dieselbe Definition einer vollständigen Änderung verwenden.

Behavior-Driven Development (BDD) kann Anforderungen so konkret machen, dass sie zugleich als Testfälle dienen. Gherkin-Spezifikationen beschreiben dabei Ausgangslage, Aktion und erwartetes Ergebnis in einer für Fachseite und Entwicklung lesbaren Form. Sie lohnen sich besonders für geschäftskritische Abläufe, bei denen ein Agent sonst leicht einen plausiblen, aber fachlich falschen Happy Path ergänzt.

Szenario: Zahlung löst genau einen Rechnungsversand aus
Angenommen eine bezahlte Rechnung ohne Versand-ID
Wenn die Zahlung erneut verarbeitet wird
Dann wird eine Versand-ID gespeichert
Und ein weiterer Aufruf versendet keine zweite Rechnung

Die Spezifikation allein schützt noch nicht. Sie muss über einen passenden Akzeptanz- oder Integration Test ausführbar sein und mit echten Regeln für Testdaten, Berechtigungen und Fehlerfälle verbunden werden.

Architekturwissen macht Änderungen vollständig

Ein Repository liefert Dateinamen und Suchergebnisse, aber nicht automatisch die Gründe hinter einer Modulgrenze oder den Ablauf nach einem Produktionsfehler. Ein Agent benötigt deshalb dieselben Quellen wie ein neues Teammitglied. Dazu gehören Domänenbegriffe, Verantwortlichkeiten, Schnittstellen, Architekturentscheidungen, lokale Start- und Testbefehle sowie Betriebsinformationen.

Diese Informationen müssen weder in einer langen globalen Anleitung noch perfekt dokumentiert sein. Hilfreicher sind kurze, gepflegte Quellen mit einer klaren Aufgabe, etwa eine Entscheidung für die Authentifizierung, eine Schnittstellenbeschreibung oder eine Betriebsanweisung für einen wiederkehrenden Alarm. Eine Struktur für technische Dokumentation nah am Code beschreibt unser Beitrag Documentation as Code: Struktur. Für Copilot lassen sich laut der Dokumentation zu Repository Instructions repository-weite und pfadspezifische Hinweise kombinieren.

Instructions beschreiben dabei, wie ein Agent mit vorhandenem Wissen arbeiten soll. Sie ersetzen weder eine Architekturentscheidung noch eine Sicherheitskontrolle. Gib jeder relevanten Quelle ein zuständiges Team und prüfe sie bei größeren Änderungen, denn veralteter Kontext führt Menschen und Agents gleichermaßen in die falsche Richtung.

Entwicklung und Tests machen Ergebnisse überprüfbar

Coding Guidelines, Formatierung und Linting sparen vor allem Wiederholungsarbeit. Sie geben dem Agenten wie dem Team feste Konventionen für Fehlerbehandlung, Logging, Abhängigkeitsgrenzen und Codeform vor. Wo eine Regel maschinell prüfbar ist, sollte ein Tool sie anwenden oder ablehnen, statt dass sie nur in einer Anleitung steht. Alles, was ein klassisches Tool ohne AI deterministisch lösen kann, sollte auch dort bleiben. Das ist meist verlässlicher, schneller und günstiger als ein zusätzlicher Agentenschritt.

Tests tragen die fachliche Last. Unit Tests sichern Verhalten in einer Komponente, Integration Tests prüfen die Zusammenarbeit an einer technischen Grenze und Smoke- bzw. UI-Tests decken wenige kritische Nutzerabläufe ab. Welche Ebene für eine Änderung nötig ist, hängt von Risiko und Wirkung ab. Ein neuer Rabatt kann mit Unit Tests beginnen, während eine Änderung im Zahlungsfluss mindestens einen durchgängigen Test gegen die betroffenen Schnittstellen braucht. Welche Testtypen zu welchem Zeitpunkt sinnvoll laufen, ordnet unsere Testing-Strategie ein.

Die Testdatenbasis entscheidet, ob diese Prüfungen nützlich bleiben. Verwende fest hinterlegte Testdaten oder eine deterministische Generierung mit festem Seed, damit Fehler nachstellbar sind und parallele Testläufe sich nicht gegenseitig beeinflussen. Dann kann ein Agent nicht nur Tests vorschlagen, sondern das Team kann Agent-Änderungen gegen dieselben belastbaren Szenarien prüfen wie jede andere Codeänderung.

Testabdeckung allein sagt nicht, ob ein Test eine fachliche Aussage wirklich absichert. Beim Mutation Testing wird die Implementierung gezielt verändert, etwa ein Vergleichsoperator umgedreht oder eine Bedingung entfernt. Bleibt der Testlauf grün, fehlt wahrscheinlich eine relevante Prüfung. Die Methode kostet Laufzeit und Pflegeaufwand, deshalb passt sie eher zu kritischen Regeln wie Preisen, Berechtigungen oder Abrechnungen als zu jeder Klasse im Projekt.

Auch die Architektur lässt sich prüfen. Architekturtests verhindern beispielsweise, dass eine UI-Komponente direkt auf Persistenz zugreift oder zwei Module zyklisch voneinander abhängen. Code-Metriken wie zyklomatische Komplexität, Duplikate oder Abhängigkeitsrichtungen zeigen zudem, ob eine Änderung unkontrolliert wächst. Unser Beitrag .NET: Architekturtests mit ArchUnitNet zeigt, wie sich solche Regeln konkret automatisieren lassen. Beide Arten von Checks ersetzen keine technische Entscheidung, machen vereinbarte Grenzen aber vor dem Merge sichtbar.

Pipeline, Release und Betrieb liefern schnelles Feedback

Eine Pull-Request-Pipeline übersetzt Erwartungen in wiederholbare Nachweise. Sie sollte früh und klar melden, ob Formatierung, Typen, Unit Tests und relevante Integration Tests, Verträge oder Build-Artefakte brechen. Schnelle, verlässliche Rückmeldungen sind eine Investition in Fokus und Flow. Lange, unzuverlässige Pipelines werden umgangen oder ihre Ergebnisse erst spät gelesen, auch wenn der Code von einem Menschen stammt. Wie Build- und Deployment-Schritte übersichtlich abgelegt, wiederverwendet und mit Governance versehen werden, beschreibt unser Artikel Azure Pipelines: Strukturierung und Templates.

Teile Checks nach Rückmeldezeit und Risiko auf. Ein schneller Pflichtlauf kann Formatierung, Typprüfung, Architekturtests und fokussierte Tests enthalten, während zeitintensivere Integration, Browser-, Mutation- oder Kompatibilitätstests parallel oder vor dem Release laufen. Entscheidend ist nicht die Menge der Jobs, sondern dass ein fehlender Pflicht-Check den Merge nicht stillschweigend passieren lässt und derselbe Befehl lokal ausführbar ist.

Grüne Checks erlauben dem Review, sich auf Risiken und Entscheidungen zu konzentrieren. Sie bedeuten nicht, dass niemand den Code lesen muss, genauso wie Teams bei einer vertrauenswürdigen Abhängigkeit nicht den Quellcode jedes verwendeten Pakets vollständig prüfen. Je besser Anforderungen, Tests, Architekturregeln und Sicherheitschecks die bekannten Risiken abdecken, desto weniger Zeit muss ein Review auf Formatierung, offensichtliche Fehler oder einfache Regelverstöße verwenden. Ob die Lösung fachlich sinnvoll ist, unerwünschte Nebenwirkungen hat oder Wartungskosten verschiebt, bleibt eine menschliche Entscheidung.

Die Softwareentwicklung endet nicht beim grünen Build. Beim Deployment prüfen Smoke- bzw. UI-Tests, Gesundheitsprüfungen und ausgewählte Signale aus Monitoring und Logging, ob die Anwendung in ihrer Zielumgebung funktioniert. Konfiguration, Infrastruktur und Datenbankänderungen müssen versioniert sein, damit ein fehlerhaftes Release zurückgenommen werden kann, soweit Datenmigrationen das zulassen. Ein Agent kann einen Rollback vorbereiten, die Entscheidung dafür braucht aber weiterhin fachlichen und betrieblichen Kontext.

Security und Governance begrenzen die Reichweite

Sicherheitsprüfungen gehören ebenso wie Tests in den alltäglichen Entwicklungsprozess, nicht in eine spätere Aufräumphase. Static Application Security Testing (SAST) prüft den erzeugten oder geänderten Quellcode auf bekannte Schwachstellenmuster. Dynamic Application Security Testing (DAST) untersucht dagegen die laufende Anwendung. Für Web-APIs kann ein DAST-Tool wie OWASP ZAP eine OpenAPI-Spezifikation nutzen, um Endpunkte und ihre Sicherheitsmechanismen automatisiert zu prüfen. Ein Secret-Scan verhindert zusätzlich, dass ein Agent versehentlich Schlüssel oder Zugangsdaten in einen Commit aufnimmt. Für Abhängigkeiten sollte die Pipeline nicht nur bekannte Schwachstellen und Lizenzen prüfen, sondern auch eine Software Bill of Materials (SBOM) erzeugen. Sie macht nachvollziehbar, welche Komponenten ein Agent eingebunden hat. Mit Dependency-Track lassen sich diese Komponenten, neue Informationen zu Schwachstellen und Lizenz-Policies auch nach dem Release fortlaufend bewerten. Für Infrastruktur stellt die automatisierte Prüfung von Richtlinien sicher, dass Konfigurationen und Plattformvorgaben eingehalten werden. Sie ersetzen keine Sicherheitsprüfung für sensible Änderungen, helfen aber dabei, dass offensichtliche Fehler nicht erst im Review oder Betrieb auffallen. Wie sich Sicherheitsmaßnahmen über den gesamten Entwicklungsprozess hinweg bewerten lassen, zeigt unser Beitrag zum Secure Development Lifecycle.

Für APIs bleiben Objektberechtigungen, Authentifizierung und sichere Fehlerbehandlung Teil der fachlichen Definition. Das OWASP API Security Project beschreibt typische Risiken, die bei neuen Endpunkten oder Integrationen geprüft werden sollten. Bei Zugriffen auf Tickets, Repositories, Cloud-Ressourcen oder Produktionsdaten gilt Least Privilege, also nur die Berechtigungen, die für eine klar abgegrenzte Aufgabe nötig sind.

Ein Agent darf nicht pauschal mehr als ein Teammitglied können. Schreibzugriffe, Produktionswirkungen und Änderungen an Berechtigungen brauchen nachvollziehbare Identitäten, Audit-Protokolle und einen menschlichen Freigabepunkt. Diese Regeln schützen nicht nur vor Fehlbedienung, sondern machen die Arbeit des Teams später erklärbar.

Copilot im Softwareentwicklungsprozess einsetzen

Erst auf einer soliden Basis werden Instructions, Skills und spezialisierte Agents wirklich nützlich. Sie können wiederkehrende Arbeit strukturieren, etwa einen Endpunkt mit Logik, Tests und Dokumentation ergänzen oder einen Fehler gegen vorhandene Betriebsanweisungen untersuchen. Diese Agents sollen bestehende Arbeitsregeln zugänglich machen und nicht an ihnen vorbeiarbeiten.

Für den Einstieg lohnt sich eine wiederkehrende Änderungsart. Verfolge ihren Weg von der Anforderung bis in den Betrieb. Wo wird Kontext gesucht, welche Tests fehlen, welcher Pipeline-Schritt ist langsam und wer entscheidet bei einem Risiko? Verbessere zuerst den Engpass mit der größten Wirkung und miss anschließend etwa Durchlaufzeit, Review-Nacharbeit oder den Anteil isoliert testbarer Pull Requests.

Für eine strukturierte Bestandsaufnahme beschreibt unser Angebot zum AI-Ready Software Development Lifecycle, wie Produkt, Architektur, Qualitätssicherung, Security und Betrieb eine reale Softwareentwicklung gemeinsam bewerten können. Der Maßstab bleibt dabei die tägliche Arbeit am Produkt. Ein Coding Agent ist dann kein Ersatz für gute Softwareentwicklung, sondern kann auf einem System arbeiten, das seine Vorschläge schnell und nachvollziehbar in gute Software überführt.

Wie ist dein Softwareentwicklungsprozess für Coding Agents vorbereitet? Schau gerne bei uns auf LinkedIn vorbei und diskutiere mit.