Interaktionsmodi & Befehle

Interaktionsmodi und Befehle

0:00 Im ersten Modul haben wir die CLI eingerichtet und die ersten Fragen gestellt. Jetzt kommt die Frage, die im Alltag den größten Unterschied macht: Wie viel Eigenständigkeit geben Sie diesem Werkzeug? Zwischen „fragt vor jeder Änderung nach" und „arbeitet einen ganzen Plan allein durch" liegen mehrere Stufen, und die Wahl dazwischen ist keine Geschmacksfrage.

0:20 Sie entscheidet darüber, ob Sie am Ende Arbeit gespart oder Arbeit bekommen haben. In diesem Modul lernen Sie die vier Arbeitsweisen kennen, den Wechsel zwischen ihnen und die Handvoll Befehle, die Sie tatsächlich jeden Tag brauchen.

Vier Modi, ein Werkzeug

0:33 Der Bogen dieses Moduls führt von der engsten zur weitesten Leine. Wir beginnen beim Standardmodus, in dem nichts ohne Ihre Zustimmung passiert. Danach kommt der Plan-Modus, in dem zunächst gedacht und noch nichts gebaut wird. Dann der programmatische Aufruf für Skripte, der gar keine Sitzung mehr kennt. Und schließlich der Autopilot, der einen Plan ohne Zwischenfragen abarbeitet. Zum Schluss sammeln wir die Befehle ein, die dabei immer wieder vorkommen.

1:00 Diese vier Punkte hängen enger zusammen, als sie aussehen. Die Modi zu kennen nützt wenig, wenn Sie im Betrieb nicht schnell zwischen ihnen wechseln — deshalb das Tastenkürzel. Und der Plan, den Sie im dritten Punkt erzeugen, ist genau das, was der Autopilot später abarbeitet. Am Ende steht eine kleine Auswahl an Befehlen.

1:19 Klein ist dabei Absicht: Die CLI bringt Dutzende mit, aber im Alltag tragen Sie mit einer Handvoll durch den Tag.

Die vier Modi im Überblick

1:26 Verschaffen wir uns zuerst den Überblick. Vier Arbeitsweisen klingen nach viel, aber sie unterscheiden sich in genau einer Eigenschaft — und wenn Sie die einmal verstanden haben, ordnet sich der Rest von selbst. Es geht um die Frage, wann das Werkzeug bei Ihnen nachfragt. Und diese Frage hat handfeste Folgen — für Ihr Tempo, für Ihre Kontrolle und für das verbrauchte Kontingent.

1:48 Eine Unterscheidung lohnt sich gleich zu Beginn, weil sie in vielen Anleitungen verschwimmt. Drei dieser Arbeitsweisen sind Modi einer laufenden Sitzung: Sie sitzen vor dem Werkzeug und schalten mit einem Tastendruck um, so wie Sie am Auto zwischen Fahrstufen wechseln, ohne auszusteigen. Die vierte ist etwas anderes. Der programmatische Aufruf startet gar keine Sitzung, sondern übergibt eine Frage, nimmt die Antwort entgegen und ist fertig.

2:13 Wer das trennt, versteht sofort, warum es dort keine Rückfragen gibt — es ist niemand da, der sie beantworten könnte. Lesen Sie diese Tabelle als Skala, nicht als Liste. Von oben nach unten nimmt die Zahl der Unterbrechungen ab und die Verantwortung, die Sie vorher übernehmen, zu. Im Standardmodus tragen Sie die Verantwortung laufend, in kleinen Portionen — jede Rückfrage ist eine Entscheidung.

2:36 Beim Autopilot tragen Sie sie vollständig im Voraus, denn danach fragt niemand mehr. Der Plan-Modus ist die Brücke dazwischen: Er verlagert Ihre Entscheidungen nach vorn, in eine Phase, in der Korrekturen noch nichts kosten. Genau deshalb gehören Plan und Autopilot zusammen. Warum lohnt sich der Aufwand, hier bewusst zu wählen? Weil beide Fehler Geld kosten, nur auf unterschiedliche Weise.

3:00 Wer im Standardmodus einen fertig geplanten Umbau durchführt, bestätigt fünfzig Rückfragen und ist genervt. Wer im Autopilot eine vage Idee losschickt, bekommt viel Code, den niemand bestellt hat — und bezahlt dafür. Der programmatische Aufruf wiederum öffnet eine Tür, die viele gar nicht sehen: Die CLI lässt sich in Skripte und Pipelines einbauen.

3:21 Damit wird aus einem Werkzeug für den Schreibtisch eines für die Automatisierung.

Interaktiv arbeiten

3:26 Fangen wir mit der Arbeitsweise an, in der Sie die meiste Zeit verbringen werden. Sie ist die Voreinstellung, und sie ist es aus gutem Grund: Hier behalten Sie die Kontrolle über jeden Schritt, der etwas verändert. Alles, was wir danach besprechen, ist eine bewusste Abweichung von dieser Voreinstellung. Wer sie versteht, versteht auch, was die anderen Modi weglassen.

3:48 Der Standardmodus funktioniert wie ein Gespräch mit einem sehr gründlichen Kollegen: Er fragt nach, bevor er etwas anfasst. Diese Rückfragen sind der eigentliche Schutzmechanismus des Werkzeugs — bei jeder Dateiänderung, jedem Befehl, jedem Zugriff nach außen. Sie können jede Rückfrage einmalig beantworten oder dauerhaft.

4:06 Und genau dort liegt die Stelle, an der man sich selbst austrickst: Ein „nicht mehr fragen" ist bequem im Moment und gilt weit über diesen Moment hinaus. Treffen Sie diese Entscheidung bewusst, nicht im Vorbeiklicken. Worauf es hier ankommt, sind nicht die Befehle, sondern zwei Gewohnheiten. Die erste: der Wechsel ins Projektverzeichnis, bevor Sie starten — das kennen Sie aus dem ersten Modul, und es bleibt die häufigste Fehlerquelle.

4:32 Die zweite steht als Kommentar in der letzten Zeile: das Tastenkürzel, das zwischen den Modi umschaltet. Es wirkt sofort und mitten in der Sitzung. Sie können also mit einer Frage beginnen, für den Umbau in den Plan-Modus wechseln und danach zurück. Ein Blick auf die Statuszeile zeigt jederzeit, wo Sie gerade stehen. Diese vier Fallen haben denselben Kern: Bequemlichkeit im Moment. Ein vager Auftrag ist schneller getippt als ein präziser — und produziert Code, den Sie hinterher lesen müssen.

5:02 Ein weggeklickter Berechtigungsdialog spart zwei Sekunden und nimmt Ihnen die letzte Kontrollinstanz. Eine lange Sitzung fühlt sich effizient an und schleppt doch den ganzen erledigten Kram mit. Das Muster lohnt sich zu merken, denn es wiederholt sich in jedem der folgenden Kapitel: Was kurzfristig Aufwand spart, kostet mittelfristig Kontrolle.

5:22 Bei dieser Aufgabe geht es weniger um das Ergebnis als um den Zuschnitt des Auftrags. Ein Feature, das sich in einem Zug umsetzen lässt, ist klein genug, dass Sie das Ergebnis noch beurteilen können. Der Erfolg wird bewusst am Diff gemessen, nicht an der Zusammenfassung des Werkzeugs — die klingt nämlich immer gut. Deshalb der Hinweis, vorher zu committen: Nur dann ist der Vergleich ehrlich.

5:45 Wenn im Diff Dateien auftauchen, von denen im Auftrag nie die Rede war, haben Sie genau das gelernt, worum es hier geht.

Der Plan-Modus

5:52 Jetzt kommen wir zu der Arbeitsweise, die den größten Unterschied macht — und die am häufigsten übersprungen wird, weil sie sich anfühlt wie Verzögerung. Sie ist das Gegenteil davon. Denn was hier nach zusätzlichem Schritt aussieht, ist in Wahrheit der Schritt, der Ihnen die meisten Umwege erspart — und nebenbei ein Artefakt hinterlässt, das Sie weiterverwenden können.

6:13 Im Plan-Modus entsteht kein Code. Das Werkzeug sieht sich Ihr Projekt an, stellt Rückfragen und schreibt einen strukturierten Plan mit Häkchen zum Abarbeiten. Erst wenn Sie zustimmen, passiert etwas. Der Vergleich mit einer Baustelle drängt sich auf: Man kann sofort anfangen zu mauern, oder man zeichnet erst und merkt dabei, dass die Tür an der falschen Stelle sitzt.

6:34 Der entscheidende Punkt ist aber ein anderer — der Plan ist eine Datei. Damit wird aus einer Absicht etwas Prüfbares, das Sie lesen, ändern und im Repository ablegen können. Der rote Faden dieser fünf Schritte ist eine Verschiebung: Alle Rückfragen wandern nach vorn, in eine Phase, in der Korrekturen nichts kosten. Sie formulieren den Auftrag, beantworten Fragen nach Technik und Umfang, und bekommen einen Plan. Der vierte Schritt ist der, den man gern überspringt: Lesen und korrigieren.

7:03 Ein Plan, den Sie ungelesen freigeben, ist kein Plan, sondern ein Bauchgefühl mit Häkchen. Wer hier fünf Minuten investiert, spart sich später den Umbau — und kann den fertigen Plan direkt in den Autopilot geben. Der Gewinn ist gleich mehrfach. Rückfragen kommen vor der Arbeit statt nach der Fehlinvestition — das ist der offensichtliche Teil.

7:24 Interessanter ist der zweite: Ein guter Plan hebt auch kleinere, günstigere Modelle. Die Denkarbeit steckt im Plan, die Umsetzung ist danach oft Routine. Und schließlich bleibt etwas übrig, das über den Moment hinausreicht. Wer den Plan im Repository ablegt, kann Monate später nachvollziehen, warum der Code so aussieht, wie er aussieht. Das ist Dokumentation, die nebenbei entsteht.

7:48 Diese Aufgabe verlangt bewusst Zurückhaltung: Es soll nichts gebaut werden. Prüfen Sie stattdessen den Plan wie einen Text, den ein Kollege Ihnen vorlegt. Nennt er die betroffenen Dateien? Stehen die Schritte in einer Reihenfolge, die funktioniert? Und vor allem: Steht darin, woran man erkennt, dass die Arbeit fertig ist?

8:08 Der Hinweis, den Plan einmal bewusst abzulehnen, ist ernst gemeint. Erst wenn Sie erlebt haben, wie eine Nachschärfung den Plan verändert, wird diese Arbeitsweise zur Gewohnheit.

Der programmatische Modus

8:19 Die nächste Arbeitsweise fällt aus der Reihe. Hier sitzt niemand vor dem Bildschirm, hier gibt es kein Gespräch — und genau deshalb ist sie für Automatisierung interessant. Sie ist damit die einzige der vier Arbeitsweisen, die nicht am Schreibtisch stattfindet, sondern in Skripten, Hooks und nächtlichen Läufen. Der programmatische Aufruf ist der Einzelschuss: Sie übergeben die Frage direkt beim Start, bekommen die Antwort und das Programm beendet sich.

8:46 Man kann es sich wie den Schalter am Drive-in vorstellen — einmal bestellen, einmal bekommen, weiterfahren. Kein Nachfassen, keine Sitzung. Wichtig ist die Konsequenz daraus: Weil niemand Rückfragen beantworten kann, werden sie nicht gestellt, sondern abgelehnt. Ihr Auftrag muss also vollständig sein. Dafür lässt sich die Ausgabe weiterverarbeiten — und damit wird das Werkzeug Teil Ihrer Skripte.

9:10 Dieses Beispiel ist bewusst klein, zeigt aber das ganze Muster: Frage rein, Text raus, Text weiterverwendet. Die Ausgabe landet in einer Datei und von dort in den Commit. Genau an dieser Stelle wird der Unterschied zum interaktiven Arbeiten greifbar — das Ergebnis ist nicht zum Lesen da, sondern zum Weiterreichen. Denken Sie den Gedanken weiter: Ein Skript kann den Prompt selbst zusammensetzen, etwa aus dem Namen eines Branches oder dem Inhalt eines Tickets.

9:36 Damit entstehen kleine Automatisierungen, für die man früher ein eigenes Werkzeug gebraucht hätte. Der Nutzen liegt weniger in der einzelnen Antwort als in der Anschlussfähigkeit. Alles, was in einer Shell läuft, kann diese Antwort weiterverwenden — ein Git-Hook, ein Build-Schritt, ein nächtlicher Lauf. Am Ende jedes Aufrufs steht außerdem eine Abrechnung: verbrauchtes Kontingent, Laufzeit, Umfang. Das klingt nach Buchhaltung und ist in Wahrheit ein Steuerungsinstrument.

10:05 Wer eine Automatisierung baut, sollte wissen, was ein Durchlauf kostet, bevor er ihn hundertmal am Tag ausführt. Die ersten beiden Punkte sind zwei Seiten derselben Medaille: Kein Nachfassen heißt, der Prompt muss vollständig sein — und was Rückfragen erfordert, wird schlicht abgelehnt. Der dritte Punkt ist der gefährlichste. Eine Ausgabe, die Sie ungeprüft weiterreichen, macht aus einem einzelnen Fehler einen Automatismus, der ihn wiederholt.

10:32 Und viertens die Kosten: In einer Pipeline läuft der Aufruf nicht einmal, sondern bei jedem Push. Ohne Limit merken Sie das erst, wenn das Kontingent aufgebraucht ist.

Der Autopilot-Modus

10:42 Kommen wir zur weitesten Leine. Der Autopilot arbeitet einen Auftrag ohne Zwischenfragen durch — was großartig klingt und genau dann funktioniert, wenn Sie vorher gesagt haben, wann er fertig ist. Zwei Dinge schauen wir uns deshalb genau an: die Leitplanken, die einen Lauf begrenzen, und die Frage, woran das Werkzeug erkennt, dass es fertig ist.

11:02 Der Name ist gut gewählt, denn der Autopilot im Flugzeug fliegt auch nicht irgendwohin, sondern zu einem gesetzten Ziel. Genauso hier: Das Werkzeug arbeitet Schritt für Schritt weiter, bis es die Aufgabe für erledigt hält. Der entscheidende Halbsatz ist „für erledigt hält". Ohne beschriebene Erfolgskriterien entscheidet das Werkzeug selbst, wann Schluss ist — und trifft diese Entscheidung womöglich früher oder später als Sie.

11:28 Deshalb gehört der Autopilot mit dem Plan-Modus zusammen. Der Plan liefert das Ziel, der Autopilot fliegt es an. Hier lohnt sich der Blick auf das, was neben dem eigentlichen Auftrag steht. Die erste Zusatzangabe erteilt alle Rechte — das ist bequem und in einem fremden Repository eine schlechte Idee. Die zweite deckelt die Zahl der Schritte, und das ist die eigentliche Versicherung: Sie begrenzt, wie lange ein Irrweg weiterlaufen kann, bevor jemand hinschaut.

11:55 Beide gehören zusammen. Wer volle Rechte gibt, ohne die Schrittzahl zu begrenzen, hat kein Sicherheitsnetz mehr. Und wer die Rechte weglässt, bekommt oft einen Lauf, der auf halber Strecke stehen bleibt. Der Reiz liegt auf der Hand: Ein geprüfter Plan wird umgesetzt, ohne dass Sie fünfzigmal bestätigen. Wichtiger ist zu verstehen, wo die Grenzen verlaufen.

12:17 Zwei davon setzen Sie selbst — die Schrittzahl und die erteilten Rechte. Eine dritte setzt das Werkzeug: Die Arbeit bleibt im Arbeitsverzeichnis, was darüber hinausgreift, wird abgelehnt. Diese drei Grenzen zusammen machen aus einem riskanten Konzept ein handhabbares. Ohne sie wäre der Autopilot ein Werkzeug, das man nur mit sehr viel Vertrauen einsetzen könnte.

12:39 Der erste Punkt ist der wichtigste dieses ganzen Kapitels: Ohne Erfolgskriterien läuft der Autopilot am Ziel vorbei, und zwar völlig überzeugt von sich selbst. Der zweite und dritte sind das Gegenstück zur vorigen Folie — volle Rechte ohne Schrittlimit ist die Kombination, mit der Kontingent still verbrennt. Der vierte Punkt klingt banal und wird trotzdem ständig übersehen: Prüfen Sie das Ergebnis am Diff, nicht an der Zusammenfassung.

13:04 Ein Werkzeug, das seine eigene Arbeit beurteilt, ist kein neutraler Gutachter. Hier fließt alles zusammen: der Plan aus Kapitel drei, die Leitplanken aus diesem Kapitel und die Prüfung am Diff. Der Erfolg hat drei Teile, und alle drei sind bewusst objektiv — der Lauf endet von selbst, die Punkte des Plans sind abgehakt, und es taucht keine Datei auf, die dort nichts zu suchen hat.

13:26 Der Hinweis mit dem Branch ist mehr als Formalie: Er macht aus einem mulmigen Gefühl ein beherrschbares Experiment. Wenn es schiefgeht, werfen Sie den Branch weg und haben trotzdem etwas gelernt.

Slash-Befehle für den Alltag

13:38 Zum Abschluss sammeln wir ein, was uns durch das ganze Modul begleitet hat: die Befehle, die nicht den Code steuern, sondern die Sitzung selbst. Es sind überraschend wenige, und sie haben alle denselben Zweck: die Sitzung in einem Zustand halten, in dem gute Antworten möglich bleiben. Damit schlagen wir zugleich die Brücke ins nächste Modul.

13:58 Diese Befehle sind so etwas wie die Schalter am Gerät, nicht die Arbeit damit. Sie wechseln das Modell, zeigen die Auslastung, beginnen von vorn oder holen Hilfe. Eingegeben werden sie im normalen Eingabefeld, und ein einzelner Schrägstrich öffnet die Liste. Das ist praktischer, als es klingt: Sie müssen nichts auswendig lernen.

14:17 Die Liste ist im Werkzeug, sie ist immer aktuell — und das ist bei einem Programm, das sich im Monatstakt ändert, mehr wert als jede gedruckte Übersicht. Diese Auswahl folgt einer einfachen Logik: Sie sind hier nach Häufigkeit sortiert, nicht nach Wichtigkeit. Ganz oben steht die Hilfe, weil sie alles andere überflüssig macht, was man sonst auswendig lernen müsste.

14:39 In der Mitte stehen die drei, die Ihren Tag prägen: Modell wechseln, Kontext ansehen, Verlauf verdichten. Die letzten beiden brauchen Sie mehrmals täglich, ohne darüber nachzudenken. Alles, was hier nicht steht — und das ist eine ganze Menge —, finden Sie im Zweifel über die Hilfe oder indem Sie das Werkzeug danach fragen. Es kennt seine eigene Dokumentation.

15:00 Zwei dieser Punkte greifen dem nächsten Modul vor, und das ist Absicht. Die Befehle für Auslastung und Verdichtung sind die Werkzeuge gegen ein volles Kontextfenster — was das genau bedeutet, klären wir gleich. Der praktische Rat für heute ist einfacher: Räumen Sie zwischen zwei Aufgaben auf. Eine frische Unterhaltung für ein neues Thema kostet nichts und schärft die Antworten spürbar.

15:23 Es ist wie beim Gespräch mit einem Kollegen — irgendwann sollte man sagen, dass es jetzt um etwas anderes geht.

Den Modus bewusst wählen

15:30 Fassen wir zusammen. Der Unterschied zwischen den Modi lässt sich auf einen Satz bringen: Der Standardmodus fragt nach, der Autopilot nicht. Dazwischen liegt der Plan-Modus als die günstigste Stelle, an der Sie Fehler finden können — nämlich bevor sie Code geworden sind. Und der programmatische Aufruf bringt das Werkzeug dorthin, wo niemand mehr zusieht: in Skripte und Pipelines. Im nächsten Modul geht es um die andere Hälfte guter Antworten.

15:56 Nicht darum, wie viel das Werkzeug darf, sondern darum, was es überhaupt sieht.