Codex lokal, im Web und in der Cloud

Codex lokal, im Web und in der Cloud

0:00 Wenn ein Auftrag zwanzig Minuten läuft, stellt sich eine praktische Frage: Müssen Sie dabei zusehen? Meistens nicht — und genau dann kann er woanders laufen. In diesem Modul geht es um die Wahl des Ortes: lokal auf Ihrer Maschine, wo Ihr aktueller Stand und Ihre Zugänge liegen, oder in einer Cloud-Umgebung, die mit einer frischen Kopie des Repositorys arbeitet.

0:21 Beide können dasselbe. Was sie unterscheidet, ist nicht die Fähigkeit des Agenten, sondern das, was er vorfindet.

Codex lokal, im Web und in der Cloud

0:29 Der Leitsatz: Die Frage ist nicht, wo es geht, sondern wo es hingehört. Acht Kapitel führen vom Vergleich der Umgebungen über die Auswahlkriterien bis zur Rückführung der Ergebnisse. Dazwischen liegen zwei Themen, die man oft erst nach dem ersten Fehlversuch ernst nimmt: was beim Wechsel zwischen Umgebungen verloren geht, und wie vollständig ein Auftrag sein muss, wenn niemand nachfragen kann.

0:51 Beispielprojekt bleibt kanuverleih.

Lokale und cloudbasierte Ausführung

0:53 Beginnen wir mit dem Vergleich. Beide Umgebungen führen denselben Agenten aus, mit denselben Fähigkeiten. Der Unterschied liegt in der Umgebung selbst — und der ist größer, als man zunächst denkt. Sehen wir uns an, worin er besteht und was die Cloud voraussetzt, damit dort überhaupt gearbeitet werden kann. Lokal läuft der Agent auf Ihrer Maschine, sieht Ihren Arbeitsstand und nutzt Ihre Werkzeuge.

1:18 In der Cloud arbeitet er in einer isolierten Umgebung mit einer Kopie des Repositorys und liefert am Ende ein Ergebnis zurück. Das Bild dazu: Sie geben eine Aufgabe an ein externes Büro. Dort sitzt jemand genauso Kompetentes — aber er hat nur die Unterlagen, die Sie mitgeschickt haben. Nicht Ihren Schreibtisch, nicht Ihre Notizen, nicht die halbfertige Skizze.

1:39 Vier Vergleichszeilen. Der Arbeitsstand: Ihr aktueller gegenüber einem frischen Klon. Die Aufsicht: direkt mit Freigaben gegenüber asynchron. Die Werkzeuge: Ihre Umgebung gegenüber einer eingerichteten. Und die Parallelität: begrenzt gegenüber mehreren Aufgaben gleichzeitig. Die Fußzeile fasst zusammen, worauf es ankommt: Der Unterschied ist nicht die Fähigkeit des Agenten, sondern was er vorfindet.

2:05 Wer das verinnerlicht, trifft die Wahl fast automatisch richtig. Vier Voraussetzungen. Das Repository muss erreichbar und freigegeben sein. Die Umgebung muss eingerichtet werden können — Abhängigkeiten, Werkzeuge, alles, was Ihr Projekt zum Bauen braucht. Der Auftrag muss ohne Rückfragen auskommen. Und das Ergebnis muss sich am Diff bewerten lassen.

2:27 Die zweite Voraussetzung ist die, an der die meisten ersten Versuche scheitern: Was auf Ihrem Rechner über Jahre gewachsen ist, muss dort in einem Einrichtungsschritt reproduziert werden. Der erste Punkt ist die häufigste Überraschung: Die Cloud kennt weder Ihre lokalen Dienste noch Ihre Zugangsdaten. Eine laufende Datenbank auf Ihrem Rechner gibt es dort nicht.

2:49 Der zweite ist tückisch — ignorierte Dateien fehlen im Klon, auch die nötigen; lokale Konfigurationsdateien stehen oft in der Ignorierliste. Der dritte betrifft den Netzzugriff, ohne den Installationen scheitern. Und der vierte ist schlicht, aber folgenreich: Ein nicht committeter Stand existiert dort nicht.

Die passende Umgebung wählen

3:08 Jetzt zur eigentlichen Entscheidung. Sie lässt sich auf zwei Fragen reduzieren, und wenn beide mit Nein beantwortet werden, ist die Sache klar. Sehen wir uns diese beiden Fragen an, dazu eine Zuordnung typischer Aufgaben und die Schritte, mit denen man eine Aufgabe für die Cloud vorbereitet. Die Wahl folgt zwei Fragen: Braucht die Aufgabe Ihren Rechner — Zugänge, Dienste, halbfertigen Stand? Und müssen Sie dabei sein, um Rückfragen zu beantworten?

3:34 Zwei Nein bedeuten: Sie kann weg. Das ist eine erfreulich einfache Regel, und sie funktioniert in der Praxis gut. Die meisten Aufgaben, bei denen Menschen zögern, scheitern nicht an der ersten Frage, sondern an der zweiten — weil der Auftrag nicht klar genug ist, um ohne Rückfragen auszukommen. Vier Gegenüberstellungen. Nach lokal gehören: halbfertiger Arbeitsstand, lokale Datenbank und Dienste, enge Zusammenarbeit, Aufgaben mit Zugangsdaten.

4:01 In die Cloud gehören: ein sauberer Branch, alles was im Repository liegt, ein klar umrissener Auftrag, mehrere Aufgaben parallel. Die Fußzeile weist auf einen Denkfehler hin, den man leicht macht: Wer bei jeder Aufgabe dabei sein muss, verschenkt den Vorteil der Cloud. Der Gewinn liegt in der Gleichzeitigkeit, nicht in der Geschwindigkeit des einzelnen Laufs.

4:24 Fünf Schritte. Prüfen, ob die Aufgabe lokale Mittel braucht. Prüfen, ob Rückfragen zu erwarten sind. Bei zweimal Nein in die Cloud geben. Den Auftrag vollständig und ohne Annahmen formulieren. Und das Ergebnis als Diff prüfen wie jeden Beitrag. Die Fußzeile hebt Schritt vier hervor, denn er entscheidet: In der Cloud gibt es niemanden, der nachfragt.

4:46 Jede Lücke im Auftrag wird stillschweigend vom Agenten gefüllt — und das merken Sie erst, wenn das Ergebnis vorliegt. Der erste Punkt: Aufgaben delegieren, die den halbfertigen Stand brauchen. Der Agent bekommt den letzten Commit, nicht Ihren Arbeitsstand. Der zweite: Rückfragen einplanen, wo niemand antwortet. Der dritte betrifft die Erkundung — für ein tastendes Verstehen ist der Dialog schneller als ein Auftrag, der einmal losläuft und irgendwann etwas liefert.

5:15 Und der vierte ist eine Disziplinfrage: Ergebnisse annehmen, ohne sie lokal geprüft zu haben.

Hintergrundaufgaben delegieren

5:21 Sprechen wir über den eigentlichen Gewinn dieser Arbeitsweise. Er liegt nicht darin, dass etwas schneller fertig wird — sondern darin, dass es fertig wird, während Sie an etwas anderem arbeiten. Sehen wir uns an, was sich dafür eignet und wie man verhindert, dass das ständige Nachsehen den Vorteil wieder auffrisst. Delegierbar ist, was ohne Aufsicht bis zu einem prüfbaren Ergebnis kommt: eine Erhebung, eine mechanische Änderung, ein Testausbau.

5:47 Der Gewinn ist nicht Geschwindigkeit, sondern Gleichzeitigkeit. Diese Unterscheidung ist wichtig für die Erwartung. Ein Cloud-Lauf ist nicht schneller als ein lokaler — er ist eher langsamer, weil die Umgebung erst eingerichtet werden muss. Sein Vorteil ist, dass er Ihre Aufmerksamkeit nicht bindet. Vier Kategorien. Erhebungen über viele Dateien — langwierig, mechanisch, gut prüfbar. Mechanische Umbauten mit klarer Regel. Testabdeckung an einer benannten Stelle ausbauen.

6:17 Und Formalien wie Dokumentation nachziehen. Was diese vier verbindet: Sie haben ein klares Fertig-Kriterium und brauchen unterwegs keine Entscheidungen. Genau das sind die Aufgaben, bei denen Ihre Anwesenheit nichts beiträgt — und deshalb gut anderswo laufen können. Fünf Schritte. Eine Aufgabe wählen, die Sie nicht blockiert. Den Auftrag samt Erfolgskriterium formulieren. Abschicken und an anderer Stelle weiterarbeiten.

6:44 Das Ergebnis in einem Block prüfen, nicht nebenbei. Und Verwertbares übernehmen, den Rest verwerfen. Die Fußzeile erklärt Schritt vier: Ständiges Nachsehen frisst den Vorteil wieder auf. Wer alle drei Minuten nachschaut, ob der Lauf fertig ist, hat seine Aufmerksamkeit genauso gebunden wie beim lokalen Zusehen — nur mit mehr Kontextwechseln.

7:06 Der erste Punkt ist die Grenze, die wir schon aus Modul sechs kennen: Zu viele parallele Aufgaben überfordern das Prüfen. Der zweite ist ärgerlich und passiert leicht — Delegiertes, das Sie selbst gerade brauchen, blockiert Sie doppelt. Der dritte ist eine Frage der Bearbeitungszeit: Ergebnisse liegen lassen und später nicht mehr verstehen, worum es ging.

7:27 Und der vierte ist ein Planungsfehler: Aufträge, die auf einem Zwischenstand aufbauen, den es in der Cloud nicht gibt.

Lokale Ressourcen gezielt nutzen

7:34 Bei all den Vorzügen der Cloud sollte man den lokalen Weg nicht abschreiben. Es gibt Dinge, die es nur auf Ihrem Rechner gibt — und für die es keinen Ersatz gibt. Sehen wir uns an, welche das sind und wann lokal nicht nur möglich, sondern klar überlegen ist. Lokale Arbeit hat einen Vorteil, den keine Cloud bietet: den echten Zustand.

7:54 Laufende Dienste, gefüllte Datenbanken, halbfertige Änderungen und Zugänge zu internen Systemen existieren nur hier. Das klingt banal, ist aber der Grund, warum lokal die Voreinstellung bleibt und bleiben sollte. Die Cloud arbeitet mit dem, was im Repository steht. Alles, was Ihr System darüber hinaus ausmacht — und das ist in gewachsenen Projekten erstaunlich viel —, existiert dort nicht.

8:18 Vier Ressourcen mit ihrem jeweiligen Grund. Laufende Dienste: Ihr Zustand entsteht zur Laufzeit und lässt sich nicht mitschicken. Die Testdatenbank: Die Daten liegen nicht im Repository. Interne Netze: von außen schlicht nicht erreichbar. Und halbfertige Arbeit: nicht committet, also nicht sichtbar. Die Fußzeile zieht das Fazit: Genau diese vier Punkte sind der Grund, warum lokal die Voreinstellung bleibt — und warum die Cloud eine bewusste Entscheidung ist, keine Verbesserung per se.

8:49 Vier Situationen. Fehlersuche mit laufendem System — dort brauchen Sie den echten Zustand. Arbeiten an nicht committeten Ständen. Aufgaben mit vielen kleinen Rückfragen, bei denen der Dialog schneller ist als jede Auftragsformulierung. Und alles, was interne Systeme berührt. In diesen vier Fällen ist die Frage nach der Cloud gar nicht erst zu stellen — man würde Aufwand betreiben, um am Ende weniger zu erreichen.

9:14 Diese Übung führt zu einer Liste, die Sie im Team teilen können: Welche Aufgaben müssen zwingend lokal bleiben, und welche Ressource bindet sie jeweils? Der Hinweis enthält die eigentliche Aufforderung: Prüfen Sie die Liste kritisch, denn manches ist nur aus Gewohnheit lokal. Es lohnt sich, bei jedem Eintrag zu fragen, ob die bindende Ressource wirklich unverzichtbar ist — oder ob sie sich in der Cloud-Umgebung bereitstellen ließe.

Cloud Tasks für größere Arbeiten

9:39 Jetzt zur praktischen Seite des Cloud-Laufs. Was passiert dort eigentlich, und was muss man vorbereiten, damit es funktioniert? Der häufigste Grund für einen gescheiterten Cloud-Lauf ist banal und liegt vor dem eigentlichen Auftrag. Sehen wir uns an, welcher das ist. In der Cloud wird das Repository geklont, die Umgebung eingerichtet, der Auftrag ausgeführt und ein Ergebnis zurückgegeben — meist als Diff oder als Pull Request.

10:05 Der Lauf ist isoliert und ohne Zugriff auf Ihre Maschine. Der zweite Schritt, das Einrichten, ist der, den Sie beeinflussen müssen. Denn dort wird aus einem nackten Klon eine Umgebung, in der Ihr Projekt baut und testet — und was Sie dort nicht hinterlegen, fehlt. Fünf Schritte. Die Einrichtungsschritte der Umgebung hinterlegen. Den Auftrag mit Kontext und Erfolgskriterium formulieren. Den Lauf starten und weiterarbeiten.

10:31 Das Ergebnis als Diff prüfen und lokal nachbauen. Und übernehmen oder mit geschärftem Auftrag wiederholen. Die Fußzeile nennt den erwähnten Hauptgrund für Fehlschläge: Die Einrichtung aus Schritt eins. Es lohnt sich, dafür einmal Zeit zu investieren — sie zahlt sich bei jedem weiteren Lauf aus. Vier Anlässe. Mehrere unabhängige Aufgaben zugleich. Läufe, die länger dauern als Ihre Aufmerksamkeit — und das sind mehr, als man zugibt.

10:58 Arbeiten, die Ihren Arbeitsstand nicht stören sollen; Sie müssen also nichts wegräumen. Und Ergebnisse, die ohnehin als Pull Request landen. Der letzte Punkt ist der eleganteste: Wenn das Ergebnis sowieso über einen Pull Request kommt, ist der Umweg über die Cloud gar kein Umweg mehr. Der erste Punkt ist die schon erwähnte Falle mit ignorierten Dateien: Konfiguration und Beispieldaten fehlen im Klon, weil sie in der Ignorierliste stehen.

11:25 Der zweite betrifft den fehlenden Netzzugriff, der Installationen scheitern lässt. Der dritte ist die Konsequenz einer unvollständigen Einrichtung: Ohne sie schlägt jeder Testlauf fehl — und der Agent versucht dann, das Problem im Code zu suchen. Und der vierte: Lange Läufe ohne Zwischenstand sind schwer zu beurteilen.

Übergänge zwischen Umgebungen

11:43 Kommen wir zu einem Punkt, den man meist erst nach dem ersten Mal versteht. Wenn Sie zwischen lokal und Cloud wechseln, wandert Ihr Code mit — aber nicht das Gespräch. Sehen wir uns an, was dabei genau verloren geht und mit welchen Handgriffen man den Verlust klein hält. Ein Wechsel zwischen lokal und Cloud überträgt Code, aber keinen Gesprächskontext.

12:04 Was in der einen Umgebung erarbeitet wurde, muss in der anderen erneut bereitgestellt werden — über Commits, Notizen oder die Spezifikation. Das ist die Stelle, an der sich Modul zwei auszahlt. Wer seine Erkenntnisse ohnehin in Dateien sichert statt im Verlauf, kann die Umgebung wechseln, ohne etwas zu verlieren. Wer alles im Chat gelassen hat, fängt drüben von vorn an.

12:27 Vier Dinge. Der Verlauf der Session und seine Zwischenschritte. Begründungen, die nur mündlich gefallen sind — also alles, was Sie im Gespräch entschieden haben. Nicht committete Stände. Und lokale Werkzeugausgaben und Messungen. Der zweite Punkt ist der schmerzhafteste, weil er unsichtbar ist: Sie haben eine Entwurfsentscheidung getroffen und begründet, und in der neuen Umgebung trifft der Agent sie noch einmal — möglicherweise anders.

12:53 Fünf Schritte für einen sauberen Wechsel. Vor dem Wechsel committen und pushen. Ergebnisse und Entscheidungen schriftlich festhalten. In der neuen Umgebung den Auftrag vollständig neu stellen — nicht so, als würde jemand sich erinnern. Das Ergebnis lokal nachbauen und prüfen. Und die Erkenntnisse zurück ins Repository schreiben. Die Fußzeile ist der Merksatz dieses Kapitels: Was nur im Chatverlauf steht, überlebt keinen Umgebungswechsel.

13:21 Der erste Punkt ist ein verbreiteter Irrtum: annehmen, der Agent kenne den vorherigen Lauf. Er kennt ihn nicht — es ist eine neue Sitzung in einer neuen Umgebung. Der zweite betrifft Zwischenstände, die nur lokal liegen. Der dritte ist eine Prüfdisziplin: Ergebnisse übernehmen, ohne sie lokal auszuführen. Und der vierte führt zu Konflikten, die niemand braucht: zwei Umgebungen parallel am selben Branch arbeiten lassen.

Entwicklungsaufträge vorbereiten

13:47 Damit sind wir bei der Kernfähigkeit für unbeaufsichtigtes Arbeiten: einen Auftrag zu formulieren, der wirklich vollständig ist. Das ist schwerer, als es klingt, weil wir es gewohnt sind, uns auf Rückfragen zu verlassen. Sehen wir uns an, was dazugehört — und welche Zeile die Rückfrage ersetzt. Ein Auftrag für einen unbeaufsichtigten Lauf muss vollständig sein: Ziel, Kontext, Erfolgskriterium, Grenzen — und alles, was ein Mensch sonst auf Rückfrage ergänzt hätte.

14:15 Der letzte Teil ist der schwierige. Denn was jemand auf Rückfrage ergänzen würde, weiß man erst, wenn die Rückfrage kommt. Deshalb hilft ein einfacher Trick, den wir uns auf der nächsten Folie ansehen: eine Regel dafür, was bei Unklarheit zu tun ist. Fünf Zeilen, von denen vier vertraut sind: Ziel, Kontext, Ergebnis, Grenzen.

14:35 Die fünfte ist die interessante — bei Unklarheit soll der Agent die Annahme dokumentieren statt zu raten. Die Fußzeile erklärt warum: Diese Zeile ersetzt die Rückfrage, die in der Cloud niemand stellen kann. Sie bekommen dann kein stillschweigend geratenes Ergebnis, sondern eines, das seine eigenen Annahmen offenlegt. Und die können Sie prüfen — das ist ein enormer Unterschied.

14:59 Vier Gründe. Der Auftrag setzt ungesagtes Wissen voraus — das ist der häufigste. Es fehlt ein Kriterium, wann fertig ist. Der Umfang ist nicht begrenzt. Und es ist nicht gesagt, was bei Unklarheit gilt. Alle vier haben eine Gemeinsamkeit: Sie fallen interaktiv gar nicht auf, weil Sie unbewusst nachsteuern. Erst wenn niemand nachsteuert, zeigt sich, dass der Auftrag von Anfang an unvollständig war.

15:26 Der Hinweis liefert den nützlichsten Prüfmaßstab: Lesen Sie den Auftrag mit den Augen von jemandem, der Ihr Projekt nicht kennt. Alles, was diese Person fragen würde, fehlt. Das ist derselbe Test, den man bei einer Anforderungsbeschreibung anwendet — und er funktioniert hier genauso. Das Erfolgskriterium ist deshalb zweistufig: Ein Kollege könnte den Auftrag ohne Nachfragen umsetzen, und der Cloud-Lauf liefert ein prüfbares Ergebnis.

Ergebnisse zurückführen

15:52 Zum Abschluss der Rückweg. Ein Diff aus der Cloud ist kein fertiges Ergebnis, sondern ein Vorschlag — und wird genauso behandelt wie jeder fremde Beitrag. Sehen wir uns an, welche Schritte dazugehören und warum der Testlauf auf Ihrer eigenen Maschine dabei unverzichtbar ist. Zurückführen heißt: Ergebnis lokal nachvollziehen, Tests selbst laufen lassen, Diff prüfen und erst dann übernehmen. Der Weg ist derselbe wie bei jedem fremden Beitrag.

16:18 Und das ist die richtige Haltung: Sie würden den Pull Request eines externen Dienstleisters auch nicht ungeprüft zusammenführen, nur weil bei ihm die Tests grün waren. Der einzige Unterschied ist, dass hier niemand beleidigt ist, wenn Sie den Beitrag verwerfen. Fünf Schritte. Branch oder Pull Request lokal auschecken. Abhängigkeiten installieren, den Build laufen lassen. Die Tests selbst ausführen, nicht der Meldung glauben.

16:44 Das Diff gegen den Auftrag prüfen. Und übernehmen, nachbessern oder verwerfen. Die Fußzeile begründet Schritt drei: Er fängt ab, was in einer anderen Umgebung anders läuft als bei Ihnen. Unterschiede in Versionen, Zeitzonen oder Zeichensätzen sind erstaunlich häufig — und in der Cloud fallen sie niemandem auf. Der erste Punkt ist die Kurzfassung: Grün in der Cloud heißt nicht grün bei Ihnen.

17:09 Der zweite folgt daraus — Umgebungsunterschiede erzeugen Fehler, die schwer zu erklären sind, weil man die andere Umgebung nicht vor sich hat. Der dritte betrifft die Menge: Mehrere Cloud-Ergebnisse gleichzeitig zusammenzuführen erzeugt Konflikte, die niemand geplant hat. Und der vierte ist eine menschliche Falle: Ergebnisse übernehmen, weil der Aufwand sonst verloren wäre.

17:31 Der Hinweis nennt die entscheidende Frage bei dieser Übung: Funktioniert etwas nur deshalb, weil die Cloud-Umgebung anders eingerichtet war? Diese Frage stellt man sich selten, und sie deckt regelmäßig etwas auf — eine Abhängigkeit, die dort neuer war, eine Umgebungsvariable, die anders gesetzt ist. Bauen, testen, Diff prüfen und dann begründet entscheiden. Ein begründetes Verwerfen ist dabei ein genauso gutes Ergebnis wie ein Übernehmen.

17:57 Vier Punkte zum Mitnehmen. Der Unterschied zwischen den Umgebungen ist nicht die Fähigkeit des Agenten, sondern was er vorfindet. Zwei Nein — keine lokalen Mittel, keine Rückfragen — heißt: delegierbar. Ein Umgebungswechsel überträgt Code, aber keinen Gesprächskontext; sichern Sie deshalb in Dateien statt im Verlauf. Und ein Diff aus der Cloud wird geprüft wie jeder fremde Beitrag. Im letzten Modul führen wir alles zusammen — an einer echten Anforderung, vom Auftrag bis zum Ergebnis.