GitHub Copilot im Java-Projekt

GitHub Copilot im Java-Projekt

0:00 Der zweite Tag beginnt mit dem Werkzeug. Und ich sage bewusst „beginnt", denn er endet nicht damit. Die Bedienung ist in einer Stunde gelernt — was länger dauert, ist die Frage, wie sich die Arbeit zwischen Ihnen und dem Werkzeug aufteilt. Genau darum geht es in diesem Modul. Wir richten die Umgebung ein, klären, wann Sie im Editor und wann im Terminal arbeiten, und entwickeln eine Prüfroutine, die kurz genug ist, dass Sie sie auch am Freitagnachmittag noch anwenden.

GitHub Copilot im Java-Projekt

0:28 Der zweite Tag gehört der Zusammenarbeit mit dem Werkzeug — heute noch als Assistent, morgen als Agent. Wir bleiben bewusst nah am Java-Alltag: Kontext aus einem Maven-Projekt, Vorschläge in Spring-Code, Prüfung gegen die Konventionen von gestern. Was Sie zu Bedienung und Modi vertiefen möchten, findet sich im Seminar zur Copilot CLI. Hier interessiert uns, wie das Werkzeug auf Lagerwerk trifft.

0:52 Vier Ziele für dieses Modul. Erstens eine funktionierende Arbeitsumgebung auf Lagerwerk — klingt banal, kostet erfahrungsgemäß die meiste Zeit. Zweitens eine klare Arbeitsteilung zwischen Editor und Terminal, damit Sie nicht bei jeder Aufgabe neu überlegen. Drittens der bewusste Umgang mit Kontext: zeigen statt suchen lassen. Und viertens eine Prüfroutine für generierten Java-Code.

1:16 Der vierte Punkt ist der, der Sie am längsten begleitet — wir wenden dieselbe Routine im sechsten und im siebten Modul wieder an.

Einrichtung in IDE und Terminal

1:24 Fangen wir mit dem Handwerklichen an. Einmal sauber aufsetzen, dann müssen wir nicht mehr darüber reden. Planen Sie hier ruhig Geduld ein: Erfahrungsgemäß ist nicht die Installation die Bremse, sondern der Firmenzugang. Und weil das in Ihrem Haus genauso sein wird, ist das keine verlorene Zeit — Sie erleben hier im Kleinen, was ein Pilotprojekt im Großen erwartet.

1:46 Es gibt zwei Zugänge zum selben Werkzeug: die Erweiterung in der Entwicklungsumgebung und das Kommandozeilenwerkzeug. Beide nutzen denselben Zugang, unterscheiden sich aber in zwei Punkten deutlich — wie viel vom Projekt sie sehen und wie selbstständig sie arbeiten. Das Bild dazu: Der eine ist der Kollege, der Ihnen über die Schulter schaut und beim Tippen hilft.

2:06 Der andere ist der, dem Sie eine Aufgabe geben und der eine Weile allein arbeitet. Beide sind nützlich, aber nicht für dasselbe. Fünf Schritte, und der eigentliche ist der letzte. Die ersten vier sind Installation und Anmeldung — das steht in jeder Anleitung. Schritt fünf steht in keiner: das Ergebnis gegen den Code prüfen. Stellen Sie eine Frage, deren Antwort Sie überprüfen können, und sehen Sie nach. Warum das wichtig ist?

2:33 Weil Sie damit die Gewohnheit setzen, bevor Sie in Zeitdruck geraten. Wer die erste Antwort ungeprüft übernimmt, übernimmt auch die fünfzigste ungeprüft. Und irgendwann ist eine dabei, die nicht stimmt. Der zweite Punkt ist der, den Sie mit ins Haus nehmen: Zugangsfragen kosten im Seminar Zeit, im Projekt Wochen. Was wir hier in einer halben Stunde erledigen, ist in vielen Unternehmen ein Vorgang mit mehreren Beteiligten.

3:00 Wenn Sie also nach dem Seminar ein Pilotprojekt planen, setzen Sie diesen Punkt an den Anfang und nicht ans Ende. Der dritte Punkt ist der didaktische: Wer beide Wege kennt, wählt später bewusst. Ohne diesen Vergleich wählt man das, was man zuerst gesehen hat. Der erste Punkt ist der häufigste und der undankbarste: Firmen-Proxy und Zertifikate blockieren lautlos.

3:21 Sie bekommen keine hilfreiche Meldung, sondern eine Zeitüberschreitung oder gar nichts — und suchen den Fehler beim Werkzeug, obwohl er im Netz liegt. Wenn bei Ihnen etwas nicht funktioniert und der Nachbar hat dasselbe Setup laufen, ist das der erste Verdacht. Und der letzte Punkt schließt an Schritt fünf von eben an: Eine erste Frage ohne Prüfung ist eine vertane Gelegenheit — dann bleibt eine falsche Annahme unbemerkt im Raum stehen.

Wann IDE, wann Terminal

3:46 Im zweiten Kapitel klären wir eine Frage, die banal wirkt und im Alltag ständig auftaucht: Wo arbeite ich eigentlich? Wer das jedes Mal neu entscheidet, verliert kleine Mengen Zeit — aber sehr oft. Deshalb erarbeiten wir eine Zuordnung, die Sie danach nicht mehr überdenken müssen. Und die, wie Sie sehen werden, eine klare Tendenz hat.

4:06 Die Stärke im Editor liegt dort, wo Sie ohnehin gerade hinsehen: Vervollständigung, eine kurze Frage zur Methode unter dem Cursor, ein Blick auf die Klasse. Der Lesefluss wird nicht unterbrochen. Die Stärke im Terminal liegt bei allem, was über eine Datei hinausgeht — mehrere Dateien ändern, Kommandos ausführen, Abläufe wiederholbar machen.

4:26 Der praktische Unterschied ist Nachvollziehbarkeit: Im Terminal sehen Sie hinterher genau, welche Dateien angefasst wurden. Im Editor ist es Ihnen passiert, während Sie geschrieben haben. Die Logik hinter dieser Tabelle ist eine einzige Frage: Bleibt die Arbeit in meinem Sichtfeld oder nicht? Alles, was in einer Datei stattfindet und Sie beim Schreiben begleitet, gehört in den Editor.

4:48 Alles, was mehrere Dateien berührt, etwas ausführt oder morgen genauso wieder laufen soll, gehört ins Terminal. Und beachten Sie die Fußzeile, die ist meine persönliche Empfehlung: Im Zweifel Terminal. Nicht weil es besser ist, sondern weil dort nachvollziehbar bleibt, was tatsächlich passiert ist — und Nachvollziehbarkeit ist das, was Sie beim Prüfen brauchen.

5:09 Der vierte Punkt ist der, an den man zuletzt denkt: Wiederholbarkeit entsteht nur dort, wo der Auftrag als Text vorliegt. Eine gute Vervollständigung im Editor ist ein Moment — sie ist weg, sobald Sie weiterschreiben. Ein Auftrag im Terminal ist ein Text, den Sie aufbewahren, verbessern und beim nächsten Mal wiederverwenden können.

5:29 Genau daraus entstehen im Laufe der Zeit die Bausteine, mit denen ein Team arbeitet. Und genau daraus entsteht im fünften Modul die Anweisungsdatei. Der letzte Punkt ist der subtilste: Vervollständigungen annehmen, während man eigentlich nachdenkt. Das passiert häufiger, als man zugibt. Sie überlegen noch, wie Sie das Problem angehen, und das Werkzeug schlägt eine plausible Fortsetzung vor — und plötzlich schreiben Sie die Lösung von jemand anderem, ohne die eigene zu Ende gedacht zu haben.

5:58 Bei einfachem Code ist das egal. Bei fachlichen Entscheidungen nicht. Meine Empfehlung: Wenn Sie merken, dass Sie noch überlegen, kurz weiterschreiben statt annehmen.

Kontext gezielt bereitstellen

6:08 Im dritten Kapitel geht es um den Hebel mit der größten Wirkung: welche Dateien das Werkzeug überhaupt zu sehen bekommt. Im dritten Modul haben wir geklärt, warum Auswahl wichtiger ist als Menge — jetzt wird es praktisch. Und wir machen die Probe aufs Exempel: dieselbe Frage einmal ohne und einmal mit Referenzen. Der Unterschied überrascht regelmäßig auch die, die es vorher schon wussten.

6:31 Sie können Dateien, Ordner und Vorgänge ausdrücklich in den Kontext holen, statt das Werkzeug selbst suchen zu lassen. In einem kleinen Projekt ist der Unterschied gering — dort findet es das Richtige ohnehin. In einem Java-Projekt mit vierhundert Klassen, von denen fünfzehn ähnlich heißen, ist er erheblich. Das ist wie der Unterschied zwischen „such mal im Archiv" und „Ordner 14, dritte Mappe". Beides führt zum Ziel, aber nur eines davon zuverlässig und in vertretbarer Zeit.

7:00 Was Sie hier sehen, ist bewusst unspektakulär: zwei Aufträge mit ausdrücklichem Verweis auf Datei und Verzeichnis. Der Gewinn liegt nicht in der Syntax, sondern in der Genauigkeit — das Werkzeug liest die gemeinte Klasse, nicht eine ähnlich benannte. Und beachten Sie die Fußzeile, das ist eine typische Java-Falle: Ein Ordner als Referenz ist schnell größer als gedacht.

7:22 Ein Testverzeichnis mit vierzig Klassen füllt den Kontext, bevor die eigentliche Frage gestellt ist. Also vorher hineinsehen, wie viel dort tatsächlich liegt. Der vierte Punkt ist der, der beim Prüfen hilft: Referenzen machen nachvollziehbar, worauf eine Aussage beruht. Wenn Sie später eine Antwort bewerten, ist die erste Frage immer, welche Grundlage sie hatte. Haben Sie die Dateien selbst benannt, kennen Sie die Antwort.

7:48 Hat das Werkzeug gesucht, wissen Sie es nicht — und müssen den Umweg über die Werkzeugausgabe gehen. Der zweite Punkt ist der wirtschaftliche: Weniger Suchaufrufe bedeutet kürzere Wartezeit und geringere Kosten. Beides zugleich, ohne Zielkonflikt. Der dritte Punkt ist der, den ich am häufigsten sehe: Referenzen ersetzen keine klare Frage.

8:09 Es gibt eine Erwartung, dass man nur genug Kontext geben müsse und die Antwort ergebe sich von selbst. Das Gegenteil ist der Fall — je mehr Material, desto wichtiger wird die Frage, denn sie entscheidet, worauf das Werkzeug im Material überhaupt achtet. Die Kombination macht es: die richtigen Dateien und eine Frage mit Kriterien. Fehlt eines von beidem, wird die Antwort beliebig.

Vorschläge bewerten statt übernehmen

8:32 Jetzt kommt das Kapitel, das die Qualität Ihrer Arbeit mit dem Werkzeug langfristig bestimmt. Nicht das Erzeugen ist die Kunst — das ist einfach geworden und wird jeden Monat einfacher. Die Kunst ist das Bewerten. Und weil Bewerten anstrengend ist und Anstrengung im Alltag verliert, brauchen wir dafür etwas, das überlebt: kurz, immer gleich, ohne Nachdenken anwendbar.

8:54 Genau das entwickeln wir jetzt. Der wichtigste Satz dieses Moduls steht auf dieser Folie: Ein Vorschlag, der übersetzt und dessen Test grün ist, kann fachlich trotzdem falsch sein. Das ist keine theoretische Möglichkeit, sondern der Normalfall bei allem, was Fachlogik berührt — denn weder Compiler noch Test kennen Ihre Fachlichkeit.

9:14 Sie prüfen Form, nicht Absicht. Deshalb braucht es eine dritte Instanz, und die sind Sie. Damit das nicht in Beliebigkeit endet, braucht diese Prüfung eine feste Form. Nicht weil Sie sonst nachlässig wären, sondern weil man müde wird. Fünf Blicke, und der rote Faden ist bewusste Reihenfolge. Erst die Fachlichkeit — tut es, was gewollt war? Dann die Konventionen von gestern.

9:37 Dann zwei Fragen, die man leicht vergisst: Kamen Abhängigkeiten hinzu, und wurde außerhalb des Auftrags geändert? Genau diese beiden fangen die stillen Nebenwirkungen ab, die im Diff untergehen. Und zum Schluss die Frage nach dem Test: aussagekräftig oder nur grün? Wichtig ist die Fußzeile: fünf Blicke, keine Checkliste. Alles, was länger dauert als eine Minute, wird im Alltag übersprungen — und dann haben Sie gar keine Prüfung.

10:05 Der erste Punkt ist der ehrlichste auf dieser Folie: Eine feste Routine schlägt gutes Zureden an jedem müden Nachmittag. Vorsätze funktionieren, solange man ausgeruht ist. Gewohnheiten funktionieren auch danach. Der dritte Punkt ist der, der Ihnen im Team hilft: Wer nach Kriterien prüft, kann Ablehnung begründen. „Gefällt mir nicht" ist keine Grundlage für ein Gespräch. „Punkt drei — hier kommt eine Abhängigkeit dazu, die wir nicht besprochen haben" ist eine.

10:33 Und der letzte Punkt: Dieselbe Routine tragen wir in die Module sechs und sieben. Der erste Punkt ist der, den ich mir selbst immer wieder vorhalten muss: prüfen, was man selbst geschrieben hätte, statt was gefordert war. Das ist eine sehr natürliche Reaktion — man liest fremden Code und vergleicht mit der eigenen Lösung. Nur ist „anders als meins" kein Mangel.

10:55 Der dritte Punkt ist der, der über die Zeit gefährlich wird: Vertrauen wächst mit der Zahl guter Ergebnisse. Das ist menschlich und in Ordnung. Die Routine bleibt trotzdem — gerade dann, denn sie kostet ja nur eine Minute. Jetzt üben wir das. Nehmen Sie sich drei Vorschläge zu Lagerwerk und gehen Sie jeden durch die fünf Blicke.

11:15 Interessant ist dabei weniger, ob Sie annehmen oder ablehnen — interessant ist, welcher der fünf Blicke die Entscheidung getragen hat. Notieren Sie das. Sie werden feststellen, dass es meist ein oder zwei bestimmte sind, und das sagt etwas über Ihr Projekt aus. Bei manchen Teams ist es fast immer die Abhängigkeitsfrage.

11:33 Bei anderen fast immer die Aussagekraft der Tests.

Kosten und Verbrauch im Blick behalten

11:37 Zum Abschluss dieses Moduls ein Thema, das in technischen Seminaren gern untergeht und in Firmen sehr präsent ist: Was kostet das Ganze? Wenn Sie nach dem Seminar ein Pilotprojekt vorschlagen, wird Ihnen diese Frage gestellt. Es lohnt sich also, eine belastbare Antwort zu haben — und wie Sie sehen werden, verbessert die Antwort ganz nebenbei auch die Qualität.

11:58 Jede Anfrage verbraucht Kontingent. Das Überraschende daran: Der Verbrauch hängt weniger an der Zahl Ihrer Fragen als an der Menge des mitgeschickten Kontexts und an der Länge der Sitzung. Zehn kurze, gezielte Fragen können günstiger sein als eine einzige, bei der Sie ein halbes Modul mitschicken. Das ist wie beim Versand: Nicht die Zahl der Pakete entscheidet, sondern ihr Gewicht. Und das Angenehme daran ist, dass Sie beides steuern können, ohne auf etwas zu verzichten.

12:26 Die Logik dieser Tabelle ist einfach: Links steht jeweils, was Material erzeugt, rechts, wie man es begrenzt. Der interessanteste Eintrag ist der vierte — vollständige Reaktor-Bauläufe. Man denkt bei Kosten zuerst an Text, aber die Ausgabe eines Bauvorgangs landet ebenfalls im Kontext, und die ist bei Maven ausführlich. Und dann die Fußzeile, auf die es mir ankommt: Dieselben Maßnahmen verbessern auch die Antwortqualität. Es gibt hier keinen Zielkonflikt zwischen sparsam und gut.

12:55 Das ist selten und deshalb erwähnenswert. Der erste Punkt ist der praktische: Kosten sind in Firmen ein Freigabekriterium. Wer nicht sagen kann, was ein Team im Monat verbraucht, bekommt keine Freigabe für zwanzig Teams. Der zweite Punkt ist der, den ich Ihnen als Argument mitgeben möchte: Sparsamer Kontext liefert genauere Antworten. Sie müssen also nicht zwischen Qualität und Kosten wählen.

13:19 Und der letzte Punkt ist die Warnung: Lange Sitzungen kosten doppelt — Kontingent und Genauigkeit. Denn irgendwann verdrängt der Verlauf genau das, worum es eigentlich geht. Der erste Punkt ist die Gegenrichtung, und sie ist genauso teuer: Sparen am falschen Ende. Wer aus Kostengründen zu wenig Kontext gibt, bekommt eine unbrauchbare Antwort und fragt dreimal nach — unterm Strich teurer als einmal richtig.

13:44 Der letzte Punkt ist eine Bitte an die Skeptiker im Raum: Wenden Sie das Kostenargument gegen die teure Nutzung, nicht gegen jede Nutzung. „Das kostet ja" ist kein Argument, sondern ein Reflex. „Diese Arbeitsweise kostet dreimal so viel wie jene bei gleichem Ergebnis" ist eines. Damit haben Sie die Grundlage für den Rest des Seminars. Die Arbeitsumgebung steht und ist einmal gegen echten Code geprüft worden.

14:09 Editor und Terminal sind nach Aufgabentyp zugeordnet, Sie müssen also nicht mehr überlegen. Kontext geben Sie gezielt, mit ausdrücklichen Referenzen statt Suchenlassen. Und die Prüfroutine in fünf Blicken gilt ab jetzt für jedes Ergebnis. Im nächsten Modul wird aus dem Assistenten ein Agent — und das Erste, was er braucht, ist alles, was wir gestern über Lagerwerk beschlossen haben. Aufgeschrieben.