Ein Assistent schlägt vor, eine Berechnung für Rabatte zu vereinfachen. Die Beispielrechnung stimmt. Doch für genau 100 Euro greift danach ein anderer Grenzfall als zuvor. Solche Änderungen sind im normalen Programmablauf leicht zu übersehen, wenn der Test nur einen günstigen Eingabewert enthält.
Die Aufgabe vor dem Vorschlag beschreiben
Notieren Sie das erwartete Verhalten unabhängig vom erzeugten Code: „Rabatt ab 100 Euro einschließlich; Beträge mit zwei Nachkommastellen; fehlende Eingaben werden abgewiesen“. So lässt sich ein kompakter Vorschlag leichter prüfen. Begrenzen Sie den Auftrag auf die Dateien und Funktionen, die tatsächlich geändert werden müssen.
Öffnen Sie danach den Diff, also den direkten Vergleich der alten und neuen Zeilen. Verfolgen Sie die Eingabe bis zum Ergebnis. Bei Größer-als-Vergleichen, Rundung, Berechtigungen und Fehlerbehandlung lohnt sich eine besonders genaue Kontrolle. Neue Abhängigkeiten und Konfigurationsänderungen brauchen eine eigene Erklärung.
Tests aus Regeln ableiten
Testen Sie 99,99 Euro, genau 100 Euro und 100,01 Euro. Prüfen Sie zusätzlich die Reaktion auf eine leere Eingabe und darauf, wie Geldbeträge gerundet werden. Schreiben Sie den Sollwert aus der Fachregel auf, bevor Sie sich vom erzeugten Ergebnis leiten lassen. Wenn Implementierung und Tests aus demselben falschen Verständnis stammen, können beide zusammen grün werden.
GitHub weist für Copilot-Vorschläge auf die Notwendigkeit menschlicher Prüfung hin. Das gilt auch für Werkzeuge, die Dateien im Terminal oder Editor verändern können. Arbeiten Sie mit einem separaten Branch und prüfen Sie, welche Projektteile und Zugangsdaten der Assistent überhaupt sehen kann. Der Toolkatalog hilft bei der Auswahl einer Oberfläche; die Freigabe bleibt Teil Ihres Entwicklungsprozesses.