Einstieg & Setup

Einstieg und Setup

0:00 KI-Unterstützung beim Programmieren kennen die meisten inzwischen aus dem Editor: Sie tippen, und der Vorschlag erscheint. Dieses Seminar geht einen anderen Weg. Es bringt die Hilfe dorthin, wo viele Entwicklerinnen und Entwickler ohnehin den halben Tag verbringen — ins Terminal. Das klingt nach einem Detail, ist aber ein Unterschied in der Arbeitsweise: Statt zwischen Editor, Browser und Konsole zu springen, bleiben Sie an einem Ort.

0:25 In diesem ersten Modul richten wir die GitHub Copilot CLI ein, melden uns an und setzen den ersten Prompt ab. Danach ist die Grundlage gelegt, auf der alle weiteren Module aufbauen.

Agentisches Coding im Terminal

0:36 Acht Punkte liegen vor uns, und sie folgen einer bewussten Reihenfolge. Erst klären wir, wofür dieses Werkzeug überhaupt gedacht ist und wann es sich gegenüber den anderen Copilot-Zugängen lohnt. Dann installieren wir, melden uns an und arbeiten mit dem ersten Prompt. Zum Schluss geht es um die Modellwahl — ein Thema, das viele überspringen und das doch unmittelbar auf die Kosten durchschlägt.

0:59 Alles Weitere, also Modi, Kontext, Agenten und externe Datenquellen, hat später ein eigenes Modul. Vier Dinge nehmen Sie aus diesem Modul mit. Sie haben die CLI installiert und angemeldet — über npm, Homebrew oder ein Token, je nachdem, was zu Ihrer Umgebung passt. Sie können einordnen, wann das Terminal der richtige Zugang zu Copilot ist und wann eben nicht.

1:20 Sie haben den ersten Prompt gegen ein echtes Projekt abgesetzt statt gegen ein Spielbeispiel. Und Sie wählen das Modell bewusst, statt es laufen zu lassen. Der letzte Punkt wirkt am unscheinbarsten und zahlt sich am schnellsten aus.

Kursüberblick und Voraussetzungen

1:35 Bevor wir irgendetwas installieren, lohnt sich ein Blick auf das Ganze: Was bringt dieses Werkzeug mit, was setzen wir voraus, und woran arbeiten wir in den kommenden Modulen? Das klingt nach Formalität, spart aber später Zeit — vor allem, weil Sie dann wissen, welche Fragen in diesem Modul noch nicht beantwortet werden.

1:52 Und weil dieses Werkzeug in einem Feld unterwegs ist, in dem sich vieles im Monatstakt ändert, trennen wir von Anfang an das Beständige vom Flüchtigen. Stellen Sie sich einen Kollegen vor, der neben Ihnen sitzt, Ihr Projekt gelesen hat und auf Zuruf Befehle ausführt. Ungefähr so arbeitet ein agentisches Coding-Werkzeug.

2:10 Der entscheidende Unterschied zur klassischen Autovervoll- ständigung liegt im Wort „agentisch": Die CLI schlägt nicht nur Text vor, sie ruft Werkzeuge auf, liest Dateien, ändert sie und führt Kommandos aus. Sie arbeitet dabei immer im aktuellen Arbeitsverzeichnis — was klingt wie ein technisches Detail, ist in Wahrheit die wichtigste Regel des Tages.

2:30 Wer im falschen Ordner startet, bekommt Antworten über das falsche Projekt. Der eigentliche Gewinn liegt weniger in der Geschwindigkeit als im ungestörten Arbeiten. Jeder Wechsel zwischen Terminal, Editor und Browser kostet Sie ein paar Sekunden und, schlimmer, den Faden. Wenn die Rückfrage dort beantwortet wird, wo Sie ohnehin stehen, bleibt der Kopf beim Problem.

2:52 Dazu kommt, dass die CLI das Projekt als Ganzes liest und nicht nur den Ausschnitt, den Sie gerade markiert haben. Und sie ist erweiterbar — mit eigenen Spezialisten und externen Datenquellen. Das ist der Bogen, den wir bis Modul fünf spannen. Hinter dieser Reihenfolge steckt eine Logik: Wir gehen von der Kontrolle zur Erweiterung. Erst richten wir das Werkzeug ein.

3:14 Dann lernen Sie in Modul zwei, wie viel Leine Sie dem Agenten geben — das ist die Frage nach der Kontrolle. Modul drei dreht sich um Kontext, also darum, was der Agent überhaupt sieht; das entscheidet über die Qualität der Antworten. Erst danach erweitern wir mit eigenen Agenten, Skills und externen Servern. Diese Reihenfolge ist kein Zufall: Wer erweitert, bevor er steuert, baut sich Komplexität auf, die er nicht mehr beurteilen kann.

3:40 Fangen wir mit dem Unspektakulärsten an, das aber erstaunlich oft schiefgeht: dem richtigen Verzeichnis. Legen Sie sich das Beispielprojekt bereit und prüfen Sie, dass Sie wirklich darin stehen. VoltFinder ist bewusst eine kleine Anwendung ohne Framework-Überbau — es geht in diesem Seminar um das Werkzeug, nicht um die App.

3:59 Der Erfolg ist hier angenehm objektiv: Die Dateien sind da, und die Versionsverwaltung antwortet. Diese zwei Minuten sind gut investiert, denn alles Folgende passiert in genau diesem Ordner. Wer das Projekt vorher unter Versionskontrolle stellt, hat später bei jeder Änderung einen ehrlichen Vergleich zur Hand.

Warum die GitHub Copilot CLI?

4:17 Bevor wir installieren, noch eine Frage, die im Alltag gern übersprungen wird: Warum eigentlich dieser Zugang? Copilot gibt es an mehreren Stellen, und die Wahl ist keine Glaubensfrage, sondern hängt davon ab, wie Sie arbeiten. Schauen wir uns die Familie kurz an. Vor allem geht es um die Frage, woran Sie erkennen, dass eine Aufgabe ins Terminal gehört und nicht in den Editor. Die Antwort darauf ist überraschend einfach.

4:43 Copilot ist kein einzelnes Programm, sondern eher eine Familie von Zugängen zu demselben Dienst. Vergleichbar mit Ihrem Bankkonto: Sie erreichen es über die App, über die Website oder am Automaten — es bleibt dasselbe Konto, nur der Weg unterscheidet sich. Genauso liegt hinter Editor-Integration, Copilot-App, GitHub.com und der CLI dieselbe Lizenz. Wichtig ist das aus einem praktischen Grund: Sie müssen sich nicht entscheiden.

5:08 Die Frage lautet nicht, welcher Zugang der beste ist, sondern welcher zur jeweiligen Aufgabe passt. Die meisten Entwicklerinnen und Entwickler nutzen am Ende zwei oder drei davon nebeneinander, ohne groß darüber nachzudenken. Ein Muster fällt auf, wenn man die Zeilen von oben nach unten liest: Je weiter Sie nach unten kommen, desto größer wird der Arbeitsschritt.

5:30 Im Editor geht es um einzelne Zeilen, während Sie tippen. Auf GitHub.com geht es um Issues und Pull Requests, also um ganze Vorgänge. Und in der CLI geht es um Aufgaben, die mehrere Dateien und mehrere Befehle umfassen. Daraus folgt die praktische Regel: Für kleine, punktuelle Ergänzungen bleiben Sie im Editor. Sobald eine Aufgabe aus mehreren Schritten besteht, spielt die CLI ihre Stärke aus.

5:55 Diese vier Punkte lassen sich zu einer Aussage verdichten: Die CLI ist kein Textgenerator, sondern ein Mitarbeiter mit Werkzeugkasten. Sie beantwortet nicht nur Fragen zum Code, sie erledigt auch die Arbeit drumherum — Tests erzeugen, Fehler suchen, Commits schreiben. Das ist ein echter Gewinn an Tempo. Es ist aber auch der Grund, warum wir uns in Modul zwei so ausführlich mit den Modi beschäftigen. Wer Arbeit delegiert, muss festlegen können, wie weit die Vollmacht reicht.

6:22 Genau diese Vollmacht ist der Unterschied zwischen einem Werkzeug, das Ihnen Arbeit abnimmt, und einem, das Ihnen Arbeit macht. Vier Dinge übersieht man am Anfang gern. Erstens die Lizenz: Ohne aktives Copilot-Abo startet das Werkzeug schlicht nicht — das klärt man besser vorher als vor laufender Runde. Zweitens die Tragweite des Wortes „agentisch": Hier entstehen echte Änderungen an echten Dateien, nicht nur Vorschläge.

6:48 Drittens die Frage des Vertrauens: In einem fremden Repository sollten Sie genau hinsehen, welchem Verzeichnis Sie Zugriff geben. Und viertens die Kosten. Jede Antwort verbraucht Kontingent — nicht dramatisch, aber eben auch nicht umsonst. Das Thema kommt im vierten Kapitel zurück.

Installieren und anmelden

7:06 Genug Einordnung — jetzt wird installiert. Der praktische Teil ist erfreulich kurz: ein Befehl für die Installation, ein Befehl für die Anmeldung. Interessant sind vor allem die Stellen, an denen es trotzdem klemmt. Und das sind fast immer dieselben drei: eine zu alte Laufzeitumgebung, ein abgelaufener Code, eine fehlende Freigabe der Organisation. Wer sie kennt, spart sich die Fehlersuche.

7:31 Die Installation folgt dem, was Sie von anderen Kommandozeilenwerkzeugen kennen: global installieren, im Projekt starten. Spannender ist die Anmeldung, denn es gibt zwei Wege, und sie zielen auf unterschiedliche Situationen. Der interaktive Weg führt über den Browser — Sie bekommen einen Code angezeigt und bestätigen ihn dort. Das ist der Normalfall am Arbeitsplatz.

7:53 Der zweite Weg läuft über ein Token in einer Umgebungsvariablen. Den brauchen Sie überall dort, wo niemand vor dem Bildschirm sitzt, der etwas bestätigen könnte: in Skripten und in der Build-Pipeline. Worauf es hier ankommt, sind zwei Zeilen, die leicht untergehen. Die erste ist die Node-Version: Alles unterhalb von 22 führt zu Fehlern, die auf den ersten Blick nach etwas anderem aussehen.

8:17 Wer Node über einen Versionsmanager verwaltet, prüft das besser einmal bewusst. Die zweite ist der Wechsel ins Projektverzeichnis. Genau dort entscheidet sich, worüber die CLI später redet. Ob Sie über npm oder Homebrew installieren, ist dagegen Geschmackssache — beides führt zum selben Werkzeug. Für Windows gibt es zusätzlich den Weg über den Paketmanager oder das Installskript.

8:40 Der rote Faden dieser fünf Schritte ist ein Umweg über den Browser, und der hat einen guten Grund: Ihr Passwort wandert nie durch das Terminal. Sie starten das Werkzeug, es meldet, dass noch niemand angemeldet ist, und Sie bekommen einen kurzen Code. Den tragen Sie im Browser ein, bestätigen den Zugriff — und sind zurück in der Konsole. Ein Schritt wird gern unterschätzt: die Bestätigung für die Organisation.

9:04 Wer in mehreren Organisationen Mitglied ist, muss den Zugriff dort ausdrücklich freigeben, sonst ist man zwar angemeldet, kommt aber an keine Repositories. Die ersten drei Punkte sind Varianten desselben Musters: Man ist scheinbar fertig, aber irgendetwas fehlt. Die Node-Version ist zu alt, der Code ist abgelaufen, oder die Organisation hat den Zugriff nie freigegeben.

9:26 In allen Fällen hilft es, den Anmeldebefehl einfach noch einmal aufzurufen, statt lange zu suchen. Der vierte Punkt ist anderer Natur und wichtiger: Ein Token, das Sie direkt in die Konsole tippen, landet in der Kommando-History — und die liest sich später jeder, der Zugriff auf die Maschine hat. Zugangsdaten gehören in eine Datei oder in die Umgebung, nicht in die History.

9:48 Diese Aufgabe hat einen erzieherischen Nebeneffekt. Es geht nicht nur darum, dass die Installation läuft, sondern darum, den Erfolg zu belegen statt ihn zu vermuten. Der Nachweis ist einfach: Das Werkzeug startet im Projektordner, die Statuszeile verlangt keine Anmeldung mehr, und eine erste Frage wird beantwortet. Wer keinen Browser zur Hand hat, nimmt den Token-Weg — das ist zugleich eine gute Übung für später, wenn dieselbe Anmeldung in einer Pipeline gebraucht wird.

10:15 Notieren Sie sich, welchen Weg Sie genommen haben — spätestens beim nächsten Rechner ist das die erste Frage.

Der erste Prompt und die Modellwahl

10:22 Jetzt haben wir ein einsatzbereites Werkzeug — und stellen ihm die erste Frage. Dabei geht es um zwei Dinge zugleich: wie ein guter Einstiegs-Prompt aussieht, und wer die Antwort eigentlich berechnet. Das zweite entscheidet über Ihre Kosten. Und das deutlicher, als die meisten am Anfang vermuten. Wir schauen uns deshalb nicht nur an, was Sie fragen können, sondern auch, wer die Antwort berechnet.

10:46 Ein Prompt in der CLI ist keine Suchanfrage. Wenn Sie eine Suchmaschine fragen, bekommen Sie Fundstellen. Wenn Sie hier fragen, passiert etwas anderes: Das Werkzeug sieht sich das Verzeichnis an, öffnet Dateien und antwortet auf dieser Grundlage. Sie beauftragen also jemanden, der nachschaut, statt jemanden, der aus dem Gedächtnis antwortet. Und wie bei einem Auftrag stellt sich die Frage, wer ihn ausführt.

11:10 Genau das ist die Modellwahl: ein Regler zwischen Qualität und Kosten, den Sie selbst in der Hand haben — oder bewusst der Automatik überlassen. Beide Beispiele haben eine Gemeinsamkeit: Sie ändern nichts. Das ist als Einstieg Absicht. Bevor Sie ein Werkzeug etwas umbauen lassen, sollten Sie sehen, wie gut es Ihr Projekt überhaupt versteht.

11:31 Der erste Prompt fragt nach dem Überblick, der zweite nach einer Bewertung. Achten Sie auf die zweite Formulierung: Sie nennt eine Datei und begrenzt die Antwort auf drei Punkte. Beides ist kein Zufall. Je konkreter Sie den Rahmen setzen, desto überprüfbarer wird die Antwort — und desto weniger Kontingent verbraucht sie.

11:51 Die Logik hinter diesen Schritten ist die eines Handwerkers, der zum passenden Werkzeug greift. Für den Alltag ist die Automatik eine gute Wahl: Sie nimmt für einfache Aufgaben ein kleines, günstiges Modell. Nur an zwei Stellen lohnt sich das bewusste Eingreifen — nach oben, wenn Sie etwas planen oder über Architektur nachdenken, und nach unten, wenn ein fertiger Plan nur noch umgesetzt werden muss.

12:13 Eine Warnung zu den Namen: Die Modellliste ändert sich fast monatlich. Merken Sie sich das Prinzip, nicht die Namen — die aus jedem Tutorial sind morgen veraltet. Hier steckt die vielleicht wichtigste Einsicht dieses Moduls: Die Modellwahl ist zuerst eine Kostenentscheidung. Das teuerste Modell liefert bei einer einfachen Aufgabe kein besseres Ergebnis, es kostet nur mehr. Umgekehrt gilt etwas Ermutigendes: Ein guter Plan hebt auch kleinere Modelle.

12:40 Die eigentliche Arbeit steckt im Denken vorher, nicht in der Rechenleistung danach. Deshalb ist die sichtbare Abrechnung nach jeder Antwort so nützlich — sie macht Gewohnheiten sichtbar, die sonst erst am Monatsende auffallen. Wer einmal gesehen hat, was eine beiläufige Frage kostet, formuliert die nächste anders. Diese Aufgabe prüft weniger das Werkzeug als Ihre Fragestellung. Eine allgemeine Frage bekommt eine allgemeine Antwort, und die ist nichts wert.

13:07 Erst wenn die Antwort konkrete Dateien nennt und einen Vorschlag macht, den Sie im Code wiederfinden, haben Sie etwas in der Hand. Nehmen Sie sich die Zeit für den Zusatz: dieselbe Frage noch einmal mit einem anderen Modell. Der Vergleich von Antwort und Verbrauch ist lehrreicher als jede Empfehlung, die ich Ihnen hier geben könnte.

13:26 Halten Sie beides kurz fest: In zwei Wochen ist der Eindruck weg, die Notiz nicht. Diese vier Fallen haben eine gemeinsame Wurzel: zu wenig Festlegung. Ein vager Prompt lässt offen, worum es geht — und bekommt entsprechend Beliebiges zurück. Ein blind gewähltes Spitzenmodell lässt offen, ob der Aufwand zur Aufgabe passt. Der falsche Ordner lässt offen, über welches Projekt geredet wird.

13:50 Und ein Modellname aus einem älteren Tutorial existiert womöglich gar nicht mehr. Die Gegenmittel sind unspektakulär: Datei nennen, Verzeichnis prüfen, Liste abfragen. Alles vier kostet Sekunden und spart Minuten. Es ist dieselbe Disziplin, die auch beim Delegieren an Menschen hilft — je klarer der Auftrag, desto seltener die Rückfrage.

Bereit für den Alltag

14:11 Damit steht das Fundament. Die CLI ist installiert, angemeldet und kennt Ihr Projekt, und Sie haben die ersten Antworten gesehen. Zwei Gedanken nehmen Sie mit: Der erste Prompt liest, statt zu ändern — das ist ein guter Einstieg in jedes fremde Projekt. Und die Modellwahl ist eine Kostenentscheidung, keine Nebensache. Im nächsten Modul geht es an die Frage, die im Alltag den größten Unterschied macht: Wie viel Eigenständigkeit geben Sie dem Werkzeug?

14:38 Wir schauen uns die vier Arbeitsweisen an — vom ständigen Nachfragen bis zum Durchlauf ohne Zwischenstopp.