Copilot verstehen: Funktionen, Datenfluss, Grenzen

Dieser Kurs setzt voraus, dass Sie die Kladde aus K2 kennen: C#, Git und Pull Requests, Tests mit xUnit. Er zeigt, wie Sie GitHub Copilot im Arbeitsalltag so einsetzen, dass der Code nicht schlechter wird. Diese erste Lektion klärt, was Copilot ist, wohin Ihre Eingaben gehen, wo die Grenzen liegen und wer für das Ergebnis einsteht. Erst danach lernen Sie in W3.1.2, wie man gute Prompts schreibt.

Eine Vorbemerkung zur Ehrlichkeit dieses Kurses. Copilot antwortet nicht vorhersagbar: Dieselbe Frage kann heute und morgen verschiedene Antworten geben. Der Kurs zeigt deshalb nie „die" Antwort von Copilot, sondern schreibt „eine mögliche Antwort" und lehrt, was an ihr zu prüfen ist. Oberflächen und Befehle, die beim Schreiben nur gegen die Dokumentation gelesen und nicht gegen Copilot ausgeführt wurden, tragen den Vermerk „nicht gegen Copilot ausgeführt". Tarife, Guthaben und Modelle ändern sich schneller als ein Kurs: Dazu stehen hier keine Zahlen, nur die Fragen, die Sie der Dokumentation stellen.

Was GitHub Copilot ist

GitHub Copilot ist ein Assistent, der mit einem großen Sprachmodell Code vorschlägt, Fragen zu Code beantwortet und Aufgaben ausführt. Er tritt in mehreren Formen auf, und für jede gilt eine andere Frage: Wer entscheidet, was geschieht, und was verlässt Ihren Rechner?

Zur Einordnung, was die Dokumentation zu den Formen sagt (gelesen auf docs.github.com und Microsoft Learn, ohne Datum und Version):

• Inline-Vorschläge und Chat. Vorschläge werden nur übernommen, wenn die Nutzerin oder der Nutzer sie annimmt. Der Chat ist für Fragen rund ums Programmieren gedacht, nicht für beliebige Themen.
• Agent-Modus im Editor. Er heißt „Agent" und wird im Modus-Menü des Chats gewählt (in Visual Studio nach der Dokumentation ab Version 17.14). Er entscheidet selbst, welche Dateien er ändert, und führt Befehle aus; nach der Dokumentation geben Sie Befehle standardmäßig frei, bevor sie laufen. Jeder Prompt verbraucht Guthaben. W3.2.1 geht darauf ein.
• Cloud-Agent. Er läuft auf github.com („Copilot in the cloud") in einer Sandbox oder in GitHub Actions, je Aufgabe ein Branch und ein Pull Request, nur mit Leserechten auf das Repository, in dem er arbeitet. Auch das behandelt W3.2.1.
• Code-Review. Copilot kann einen Pull Request prüfen; die Dokumentation nennt Stufen (Lite, Balanced als Standard, Max in der öffentlichen Vorschau). Er liest Anweisungsdateien (W3.2.2) und lässt Abhängigkeitsdateien, Logs und SVG aus. Ein Review von Copilot zählt nicht zu den geforderten Freigaben, solange nichts anderes eingestellt ist.
• Zusammenfassungen von Pull Requests. Copilot kann sie schreiben; Dateien mit mehr als 400 Änderungen lässt es dabei aus.

Zwei Punkte zur Abrechnung, ohne Zahlen: Die Dokumentation nennt mehrere Tarife und ein Guthabensystem. Chat, CLI und Cloud-Agent verbrauchen Guthaben, Code-Vervollständigungen nicht. Wie viel Guthaben Ihr Tarif enthält und was passiert, wenn es aufgebraucht ist, lesen Sie in der aktuellen Dokumentation und fragen Ihre Administration. Der Kurs nennt es nicht, weil es morgen anders sein kann.

Wie ein Prompt entsteht und wohin er geht

Wenn Sie im Chat eine Frage stellen, sendet der Editor nicht nur Ihren Text. Nach der Dokumentation von GitHub geht der Prompt zusammen mit Kontext an das Modell:

• Ihre Frage oder Anweisung,
• Inhalt der offenen Dateien und, wenn Sie etwas markiert haben, die Auswahl,
• der Name des Repositorys,
• der bisherige Chatverlauf,
• Anweisungsdateien des Repositorys, falls es welche gibt (W3.2.2).

Danach laufen nach der Dokumentation Filter über Eingabe und Ausgabe (Inhaltsfilter). Eine optionale Websuche über Bing gibt es nur, wenn die Administration sie freigegeben hat. Wählt jemand ein Modell über einen eigenen Schlüssel („BYOK", Bring Your Own Key), gehen Prompt und Antwort an den dort gewählten Anbieter, und dessen Bedingungen gelten (W3.2.3).

Was daraus folgt, ist wichtiger als jedes Schaubild:

1. Alles, was im Kontext steht, kann den Rechner verlassen. Eine offene Datei mit einem Schlüssel, eine Testdatei mit echten Kundendaten: Beides gehört nicht in den Prompt und, solange Copilot die Datei als Kontext nutzt, auch nicht in den offenen Editor. Die Regeln dazu stehen in W3.2.3; für heute gilt: Geheimnisse und personenbezogene Daten gehören nicht in einen Prompt.
2. Der Kontext bestimmt die Antwort. Was Copilot nicht sieht, kennt es nicht. W3.1.2 baut darauf auf.
3. Der Chatverlauf zählt als Kontext. Ein langer Verlauf mit Irrwegen ist schlechter Kontext.

Was die Dokumentation nicht beantwortet. Zwei Fragen, die die Datenschutzabteilung stellen wird, standen auf den gelesenen Seiten nicht: ob Prompts zum Training von Modellen dienen, und wie lange Chats im Editor aufbewahrt werden. Der Kurs behauptet dazu nichts. Die Antworten stehen im Trust Center von GitHub und in den Bedingungen Ihres Tarifs; lesen Sie sie dort, für Ihren Tarif, und notieren Sie die Antwort mit dem Tag, an dem Sie sie gelesen haben.

Grenzen großer Sprachmodelle

Ein Sprachmodell erzeugt wahrscheinlich passenden Text, es prüft keine Wahrheit. Drei Folgen sind für die Arbeit mit Code wichtig.

Es erfindet. Das Modell setzt fort, was plausibel klingt: eine Methode, die es nicht gibt, einen Parameter, der anders heißt, ein Paket, das nie existiert hat. Das fällt beim Bauen meist auf (der Compiler meldet es). Gefährlicher sind Antworten, die kompilieren und das Falsche tun.

Es ist veraltet. Das Modell kennt den Stand seines Trainings, nicht den heutigen. Neue Versionen, geänderte Schnittstellen und Sicherheitsmeldungen kennt es womöglich nicht. Sagt Ihnen Copilot, ein Paket sei „aktuell" oder eine Lücke „behoben", prüfen Sie es bei der Quelle (Dokumentation, NuGet, Sicherheitsmeldung).

Es ist nicht deterministisch. Dieselbe Frage kann verschiedene Antworten liefern. Ein Ergebnis, das einmal stimmte, ist kein Beleg dafür, dass es wieder stimmt. Darum prüfen Sie die Antwort, nicht den Weg dorthin: Tests, Compiler, Review.

Ein Beispiel aus der Kladde

Die Kladde hat seit K1 ein Wertobjekt TimeRange mit der Regel, wann sich zwei Zeiträume überschneiden. Zwei Termine, von denen einer um 10:00 Uhr endet und der nächste um 10:00 Uhr beginnt, überschneiden sich nicht. Die Regel in der Kladde:

public bool Overlaps(TimeRange other) => Start < other.End && other.Start < End;

Stellen Sie sich vor, Sie bitten Copilot im Chat: „Schreibe eine Methode Overlaps für TimeRange." Eine mögliche Antwort (so nicht gegen Copilot ausgeführt, sondern als Beispiel für eine typische Fehlerform) wäre:

public bool Overlaps(TimeRange other) => Start <= other.End && other.Start <= End;

Die Methode kompiliert, sie sieht richtig aus, sie funktioniert für fast alle Eingaben. Sie ist falsch an genau einer Stelle, der Kante: Zwei Termine „9 bis 10 Uhr" und „10 bis 11 Uhr" gelten mit <= als überlappend. In der Kladde würde die Buchung des zweiten Termins mit dem Code appointment.time.overlaps und 409 abgelehnt, obwohl nichts kollidiert (K2, Lektion 2.4.7). Kein Compiler und kein Blick auf den Code zeigen das zuverlässig. Ein Test zeigt es:

[Fact]
public void TwoRangesThatOnlyTouchDoNotOverlap()
{
    DateTimeOffset ten = new(2000, 1, 1, 10, 0, 0, TimeSpan.Zero);
    TimeRange morning = new(ten.AddHours(-1), ten);
    TimeRange next = new(ten, ten.AddHours(1));

    Assert.False(morning.Overlaps(next));
}

Die Lehre ist nicht „Copilot schreibt falschen Code". Die Lehre ist: Die Randfälle kennen Sie, nicht das Modell. Ein Test, den Sie vor dem Übernehmen schreiben, kostet Minuten und fängt diese Fehlerform. W3.2.2 vertieft das: erzeugte Tests, die nichts prüfen.

Verantwortungsvoller Einsatz: Wer haftet?

Die Anwendungskarten von GitHub für Inline-Vorschläge und Chat sagen es deutlich: Nutzerinnen und Nutzer tragen alle Risiken des erzeugten Codes. Gemeint sind Sicherheitslücken, Fehler und die Verletzung geistigen Eigentums. Praktisch heißt das:

• Sie übernehmen den Code, also gehört er Ihnen. Im Pull Request steht Ihr Name, nicht der von Copilot. Ein Review fragt nicht, wer die Zeile geschrieben hat, sondern ob sie stimmt.
• Sie prüfen so, als hätte ein fremder Entwickler den Code geschrieben, den Sie nicht kennen und nicht befragen können: Versteht man jede Zeile? Gibt es Tests für Randfälle? Werden Eingaben geprüft? Gibt es Geheimnisse, Pfade oder Annahmen, die nur für ein Beispiel gelten?
• Sie fragen, was Sie nicht verstehen. Ein Chat, der Code erklärt, ist ein Hilfsmittel zum Prüfen. Was Sie nach der Erklärung nicht erklären können, übernehmen Sie nicht.
• Sie benutzen den Chat für die Aufgabe, für die er gedacht ist: Programmieren. Fragen außerhalb davon sind nach der Anwendungskarte nicht der vorgesehene Einsatz.

Treffer auf öffentlichen Code

Ein Sprachmodell kann Code erzeugen, der Code aus einem öffentlichen Repository ähnelt oder gleicht. Dafür gibt es in Copilot einen Filter. Nach der Dokumentation:

• Der Filter vergleicht einen Ausschnitt von rund 150 Zeichen Code um den Vorschlag mit öffentlichem Code.
• Je nach Einstellung wird ein Vorschlag mit Treffer blockiert oder mit Quelle und Lizenz gezeigt.
• Treffer sind nach den Angaben der Seite selten (unter einem Prozent der Vorschläge).

Was der Filter nicht kann: Er garantiert nicht, dass ein Vorschlag frei von fremden Rechten ist. Er vergleicht nur einen Ausschnitt, nur mit öffentlichem Code. Die Entscheidung, wie Ihr Team mit Treffern umgeht, ist keine technische: Sie gehört in die Regeln Ihrer Organisation und im Zweifel zur Rechtsabteilung. Wo die Einstellung heißt und wer sie ändern darf, hängt vom Tarif ab (Konto oder Organisation): Sie suchen sie in Übung 2.

Copilot im Editor einrichten

Der Kurs setzt keinen bestimmten Editor voraus; die Übungen nennen Visual Studio Code und, wo es abweicht, Visual Studio. Für beide gilt:

1. Ein GitHub-Konto mit Copilot-Zugang. Der Zugang kommt aus einem eigenen Tarif oder aus der Organisation, die Ihnen einen Platz gibt. Welcher Tarif gilt, ist eine Frage an Ihre Administration, nicht an diesen Kurs.
2. Copilot im Editor installieren und anmelden. Die Schritte beschreibt die Dokumentation Ihres Editors (nicht gegen Copilot ausgeführt). Wo Copilot danach erscheint (Statusleiste, Chat), steht in derselben Dokumentation.
3. Die Einstellungen ansehen, bevor Sie loslegen: ob Vorschläge beim Tippen erscheinen und für welche Sprachen, ob ein Vorschlag, der öffentlichem Code gleicht, blockiert oder gezeigt wird, und welche Richtlinien Ihre Organisation vorgibt.
4. Das Repository wählen, in dem Sie üben: nicht die Kladde auf main, sondern einen eigenen Branch oder ein Übungsprojekt.

Vorschläge und Chat lernen Sie am besten an einer kleinen, bekannten Aufgabe kennen, deren Ergebnis Sie prüfen können. Die Kladde bietet sich an: Sie kennen ihre Regeln aus K1 und K2.

# Nie ungeprüft übernehmen

| Was | Prüfung vor dem Übernehmen |
| --- | --- |
| SQL oder EF-Core-Abfragen, die ändern oder löschen | Abfrage lesen, gegen Testdatenbank laufen lassen, Migration prüfen |
| Code, der Eingaben verarbeitet | Was passiert bei leer, zu lang, falsch kodiert? Test dafür schreiben |
| Anmeldung, Rechte, Tokens | nach der Dokumentation des Anbieters prüfen, nie aus dem Gedächtnis des Modells |
| Zeit, Zeitzonen, Sommerzeit | Tests mit festen Uhren; Kanten (Mitternacht, Umstellung) selbst benennen |
| Regeln mit Grenzwerten (Überlappung, Fristen) | Kantentests vor dem Übernehmen |
| neue Pakete oder Versionen | Gibt es das Paket? Wer pflegt es? Lizenz? Meldungen zu Lücken? |
| Aussagen „das ist aktuell/behoben" | Quelle öffnen und das Datum lesen |
| Code, den man nicht erklären kann | nicht übernehmen; erst erklären lassen, dann prüfen |

Nie in einen Prompt: Zugangsdaten und Schlüssel, personenbezogene Daten echter Menschen, Inhalte, die ein Vertrag mit Kundschaft nicht
weitergeben lässt.

Was Sie jetzt können

• Sie unterscheiden Inline-Vorschläge, Chat, Agent-Modus, Copilot CLI, Cloud-Agent und Code-Review und wissen, wer jeweils entscheidet.
• Sie beschreiben, welchen Kontext der Editor mit dem Prompt sendet, und benennen, was die Dokumentation zum Training und zur Aufbewahrung offen lässt.
• Sie nennen die drei Grenzen: erfindet, veraltet, nicht deterministisch, und prüfen eine Antwort an Randfällen statt am ersten Eindruck.
• Sie erklären, dass Sie für erzeugten Code einstehen, und ordnen den Filter für Treffer auf öffentlichen Code richtig ein.
• Sie haben Copilot eingerichtet, einen Vorschlag angenommen und einen abgelehnt, und eine Liste, was Sie nie ungeprüft übernehmen.

Weiterlesen

• What is GitHub Copilot?: die Funktionen von Copilot im Überblick.
• Responsible use of GitHub Copilot inline suggestions: Anwendungskarte für Inline-Vorschläge.
• Responsible use of GitHub Copilot Chat in your IDE: Anwendungskarte für den Chat.
• GitHub Copilot Trust Center: Fragen zu Datenschutz, Training und Aufbewahrung.
• GitHub Copilot Fundamentals, Teil 1: Lernpfad auf Microsoft Learn.
• Responsible AI with GitHub Copilot: Modul auf Microsoft Learn, das erste im Lernpfad Fundamentals Teil 1.