Vom sichtbaren Ergebnis zum eigenständig bearbeitbaren Projekt

Wo sind wir?

Wir knüpfen direkt an Modul 1 an.

Dort haben wir mit ChatGPT eine Webseite oder lokale Anwendung geplant und erstellt. ChatGPT hat uns Inhalte und Code geliefert, viele praktische Schritte mussten wir jedoch noch selbst durchführen.

Was machen wir?

Wir betrachten gemeinsam:

• Was haben wir in Modul 1 erzeugt?
• Welche Dateien gehören zu unserer Anwendung?
• Welche Schritte mussten wir selbst ausführen?
• Wo mussten wir Inhalte kopieren oder Dateien anlegen?
• Welche Änderungen mussten wir manuell übertragen?
• Welche Fehler mussten wir selbst zurückmelden?
• Was könnte Codex davon übernehmen?
• Was erwarten wir heute von Codex?

Wir sammeln außerdem mögliche Erweiterungen für unsere Anwendung:

• Welche Funktion fehlt noch?
• Was könnte einfacher oder komfortabler werden?
• Welche Arbeit würden wir normalerweise nicht selbst umsetzen können?
• Welche Idee möchten wir heute sichtbar machen?

Warum machen wir das?

Der Unterschied zwischen ChatGPT und Codex wird verständlicher, wenn wir betrachten, welche Arbeit bisher bei uns lag.

Unser Ziel

Wir erkennen: Die Methodik aus Modul 1 bleibt bestehen. Codex kann jedoch zusätzlich direkt in unserem Projekt handeln.

Wo sind wir?

Wir kennen ChatGPT als Werkzeug zum Erklären, Planen und Erzeugen von Ergebnissen.

Nun betrachten wir ein Werkzeug, das zusätzlich Dateien lesen, verändern und Arbeitsprozesse ausführen kann.

Was machen wir?

Wir klären:

• Was ist Codex?
• Was ist ein Coding-Agent?
• Was unterscheidet einen Agenten von einem normalen Chat?
• Was ist ein Projekt?
• Welche Informationen kann Codex aus einem Projektordner gewinnen?
• Welche Dateien darf Codex bearbeiten?
• Welche Befehle kann Codex ausführen?
• Warum benötigt Codex Berechtigungen?
• Wo liegen Möglichkeiten und Grenzen?

Codex kann innerhalb eines Projekts vorhandene Dateien untersuchen, Änderungen planen, Dateien bearbeiten und lokale Entwicklungswerkzeuge ausführen. Es kann sowohl über eine Entwicklungsumgebung wie Visual Studio Code als auch über eine Kommandozeile verwendet werden.

Warum machen wir das?

Wer Codex nur wie einen normalen Chat verwendet, nutzt einen großen Teil seiner Möglichkeiten nicht.

Wer Codex dagegen blind handeln lässt, ohne Ziele, Grenzen und Prüfungen festzulegen, verliert schnell die Kontrolle über das Projekt.

Unser Ziel

Wir betrachten Codex nicht als selbstständigen Programmierer, dem wir einfach alles überlassen.

Wir verstehen Codex als einen handlungsfähigen Projektmitarbeiter, der klare Aufgaben, ausreichenden Kontext, begrenzte Berechtigungen und kontrollierbare Arbeitsschritte benötigt.

Wo sind wir?

Bevor Codex in einem Projekt arbeiten kann, benötigen wir einen klar abgegrenzten Arbeitsbereich.

Was machen wir?

Wir betrachten und verwenden:

• Visual Studio Code,
• die Codex-Integration,
• den Projektordner,
• die Dateiübersicht,
• den Editor,
• das integrierte Terminal,
• die Codex-Unterhaltung,
• die Anzeige von Änderungen,
• die Browser- oder Anwendungsvorschau.

Wir stellen sicher:

• Codex ist mit dem ChatGPT-Konto verbunden,
• ein Projektordner kann geöffnet werden,
• Dateien können angezeigt und gespeichert werden,
• die Anwendung kann lokal gestartet oder geöffnet werden,
• Änderungen können nachvollzogen werden.

Wir sprechen außerdem über Berechtigungen:

• Auf welchen Ordner darf Codex zugreifen?
• Welche Befehle darf Codex ausführen?
• Wann müssen wir eine Aktion bestätigen?
• Welche Zugriffe lehnen wir ab?
• Welche vertraulichen Informationen gehören nicht in ein Projekt?

Codex verwendet lokal Schutzmechanismen, die Datei-, Befehls- und Netzwerkzugriffe begrenzen. Genehmigungen bestimmen, bei welchen Aktionen Codex vor der Ausführung nachfragen muss.

Warum machen wir das?

Codex kann nur zuverlässig arbeiten, wenn es weiß, wo das Projekt liegt, welche Dateien dazugehören und welche Aktionen erlaubt sind.

Unser Ziel

Jeder Teilnehmer verfügt über eine funktionierende und verständliche Arbeitsumgebung.

Wo sind wir?

Unsere Arbeitsumgebung ist vorbereitet. Nun legen wir fest, wie wir Codex Aufgaben übertragen.

Was machen wir?

Wir verwenden einen wiederkehrenden Ablauf:

1. Ziel und gewünschtes Ergebnis klären
2. Projekt und Ausgangslage bereitstellen
3. Codex das Projekt untersuchen lassen
4. Wissenslücken und Rückfragen klären
5. Erfolgskriterien festlegen
6. Aufgabe in kleine Schritte zerlegen
7. Einen Umsetzungsplan erstellen lassen
8. Einen begrenzten Arbeitsschritt freigeben
9. Änderungen und ausgeführte Befehle prüfen
10. Ergebnis praktisch testen
11. Fehler oder Abweichungen zurückmelden
12. Lösung korrigieren und erneut testen
13. Funktionsfähigen Stand sichern
14. Projekt dokumentieren

Warum machen wir das?

Auch Codex löst komplexe Aufgaben nicht zuverlässig durch einen einzigen magischen Auftrag.

Je größer eine Aufgabe ist, desto wichtiger werden:

• ein klarer Projektzustand,
• verständliche Anforderungen,
• kleine Arbeitsschritte,
• überprüfbare Zwischenstände,
• eindeutige Erfolgskriterien.

Unser Ziel

Wir lernen eine Methodik, die wir später auf Webseiten, Automationen, Skripte, Programme, Serverkonfigurationen und andere technische Projekte übertragen können.

Wo sind wir?

Wir kennen die Oberfläche und unsere Arbeitsmethodik. Nun führen wir erstmals gemeinsam eine vollständige Aufgabe durch.

Was machen wir?

Wir öffnen ein vorbereitetes, überschaubares Beispielprojekt.

Codex erhält zunächst nicht den Auftrag, sofort etwas zu verändern.

Wir lassen Codex:

• den Projektordner untersuchen,
• vorhandene Dateien benennen,
• die Aufgabe der Dateien erklären,
• beschreiben, wie die Anwendung gestartet wird,
• mögliche Probleme erkennen,
• Rückfragen stellen.

Anschließend geben wir eine kleine Aufgabe vor, beispielsweise:

• eine Überschrift ändern,
• einen neuen Bereich ergänzen,
• einen Button hinzufügen,
• eine fehlerhafte Berechnung korrigieren,
• eine Darstellung verbessern.

Wir gehen gemeinsam durch den vollständigen Ablauf:

• Auftrag formulieren,
• Erfolgskriterium bestimmen,
• Änderung planen lassen,
• Änderung freigeben,
• bearbeitete Dateien prüfen,
• Anwendung starten,
• Ergebnis testen,
• bei Bedarf korrigieren.

Warum machen wir das?

Bevor wir Codex eine umfangreiche Aufgabe übertragen, müssen wir den vollständigen Arbeitsablauf an einer kleinen und überschaubaren Änderung erleben.

Unser Ziel

Wir verstehen: Codex liefert nicht nur einen Vorschlag. Es verändert das Projekt, bis ein überprüfbares Ergebnis entstanden ist.

Wo sind wir?

Wir verfügen bereits über ein sichtbares Ergebnis aus Modul 1.

Codex kennt dieses Projekt jedoch noch nicht.

Was machen wir?

Wir legen einen klaren Projektordner an und übernehmen die vorhandenen Dateien.

Anschließend lassen wir Codex das Projekt untersuchen.

Codex soll uns erklären:

• Welche Dateien sind vorhanden?
• Welche Aufgabe erfüllt jede Datei?
• Wie hängen die Dateien zusammen?
• Wie wird die Anwendung gestartet?
• Welche Funktionen sind bereits enthalten?
• Welche Teile sind möglicherweise fehlerhaft oder unvollständig?
• Welche Struktur sollte verbessert werden?
• Welche Informationen fehlen Codex?

Wir lassen eine kurze Projektübersicht erstellen:

• aktueller Zustand,
• vorhandene Funktionen,
• bekannte Einschränkungen,
• mögliche Erweiterungen,
• empfohlene nächste Schritte.

Warum machen wir das?

Ein neuer Mitarbeiter sollte nicht sofort Änderungen vornehmen, ohne zunächst das bestehende Projekt zu verstehen.

Das Gleiche gilt für Codex.

Unser Ziel

Codex und Teilnehmer verfügen über ein gemeinsames Verständnis des aktuellen Projektzustands.

Wo sind wir?

Wir kennen den aktuellen Zustand unseres Projekts.

Nun legen wir fest, was die Anwendung zusätzlich können soll.

Was machen wir?

Wir bestimmen eine konkrete Erweiterung.

Mögliche Beispiele:

• ein Rechner oder Kalkulator,
• eine interaktive Checkliste,
• ein Generator,
• eine Planungshilfe,
• ein Formular mit Auswertung,
• eine Speicherfunktion,
• eine Druckansicht,
• eine Such- oder Filterfunktion,
• eine übersichtlichere Benutzerführung.

Wir beschreiben:

• Welches Problem soll gelöst werden?
• Wer verwendet die Funktion?
• Welche Eingaben gibt es?
• Was soll verarbeitet werden?
• Welche Ausgabe soll entstehen?
• Wie soll die Funktion aussehen?
• Was darf sich am bestehenden Projekt nicht verändern?
• Woran erkennen wir, dass die Funktion funktioniert?

Codex soll daraus zunächst einen Plan erstellen:

• Welche Dateien müssen verändert werden?
• Müssen neue Dateien angelegt werden?
• In welchen Schritten soll die Umsetzung erfolgen?
• Welche Risiken oder offenen Fragen bestehen?
• Wie wird das Ergebnis getestet?

Warum machen wir das?

Ein guter Plan verhindert, dass Codex unnötig viele Dateien verändert oder eine technisch funktionierende, aber inhaltlich falsche Lösung entwickelt.

Unser Ziel

Aus unserer Idee entsteht ein klarer und überprüfbarer Umsetzungsauftrag.

Wo sind wir?

Unser Projekt ist bekannt und der Umsetzungsplan wurde geprüft.

Nun darf Codex im Projekt arbeiten.

Was machen wir?

Wir beauftragen Codex, die geplante Erweiterung schrittweise umzusetzen.

Dabei beobachten wir:

• Welche Dateien werden geöffnet?
• Welche Dateien werden verändert?
• Welche neuen Dateien werden angelegt?
• Welche Befehle möchte Codex ausführen?
• Welche Entscheidungen trifft Codex?
• Welche Rückfragen stellt Codex?
• Welche Zwischenergebnisse entstehen?

Nach einem größeren Arbeitsschritt lassen wir Codex zusammenfassen:

• Was wurde verändert?
• Warum wurde es verändert?
• Welche Dateien sind betroffen?
• Was funktioniert bereits?
• Was muss noch getestet werden?
• Welche bekannten Einschränkungen bestehen?

Warum machen wir das?

Wir möchten erleben, wie Codex nicht nur Code erzeugt, sondern eine Aufgabe direkt innerhalb eines bestehenden Projekts umsetzt.

Unser Ziel

Unsere Anwendung verfügt über eine neue, sichtbare und grundsätzlich funktionsfähige Erweiterung.

Wo sind wir?

Codex hat die Erweiterung umgesetzt.

Das bedeutet noch nicht automatisch, dass sie vollständig funktioniert.

Was machen wir?

Wir starten oder öffnen die Anwendung und führen einen systematischen Test durch.

Wir prüfen:

• Wird die Anwendung korrekt angezeigt?
• Funktionieren alle bisherigen Bestandteile weiterhin?
• Funktioniert die neue Erweiterung?
• Werden Eingaben korrekt verarbeitet?
• Entstehen die erwarteten Ausgaben?
• Was passiert bei leeren oder falschen Eingaben?
• Gibt es Fehlermeldungen?
• Ist die Bedienung verständlich?
• Entspricht das Ergebnis unseren Anforderungen?

Wenn ein Fehler auftritt, melden wir nicht nur: Es funktioniert nicht.

Wir beschreiben stattdessen:

• Was haben wir getan?
• Was haben wir erwartet?
• Was ist tatsächlich passiert?
• Ist eine Fehlermeldung sichtbar?
• Seit welcher Änderung tritt das Problem auf?
• Kann der Fehler wiederholt werden?

Codex soll anschließend:

• den Fehler nachvollziehen,
• mögliche Ursachen nennen,
• die wahrscheinlichste Ursache prüfen,
• eine Korrektur durchführen,
• und das Ergebnis erneut testen.

Warum machen wir das?

Code kann überzeugend aussehen und trotzdem falsch sein.

Eine Anwendung gilt erst dann als funktionsfähig, wenn ihr Verhalten praktisch überprüft wurde.

Unser Ziel

Wir lernen einen vollständigen Entwicklungszyklus kennen: Umsetzen, testen, Fehler beschreiben, korrigieren und erneut testen.

Wo sind wir?

Unsere Anwendung funktioniert.

Nun sorgen wir dafür, dass dieser Zustand nicht verloren geht und das Projekt später weiterverwendet werden kann.

Was machen wir?

Wir lassen Codex eine verständliche Projektdokumentation erstellen.

Diese soll enthalten:

• Zweck des Projekts,
• vorhandene Funktionen,
• Aufbau des Projektordners,
• wichtige Dateien,
• Anleitung zum Starten,
• Anleitung zum Testen,
• bekannte Einschränkungen,
• mögliche nächste Erweiterungen.

Wir sichern außerdem einen funktionsfähigen Projektstand.

Je nach gewähltem Ablauf verwenden wir:

• eine Sicherheitskopie des Projektordners,
• einen eindeutig benannten Zwischenstand,
• oder eine lokale Versionsverwaltung.

Wir lassen Codex abschließend prüfen:

• Sind alle benötigten Dateien vorhanden?
• Enthält das Projekt versehentlich temporäre Dateien?
• Gibt es sensible Daten oder Zugangsdaten?
• Kann das Projekt auf einem anderen System verstanden werden?
• Ist die Startanleitung vollständig?
• Welche Aufgabe sollte als Nächstes umgesetzt werden?

Übergang zu Modul 3

In Modul 2 arbeitet Codex innerhalb eines abgegrenzten Projekts auf unserem Computer.

In Modul 3 übertragen wir die grundlegende Methodik auf ein vollständigeres technisches System:

• eine virtuelle Maschine,
• ein Linux-System,
• Dienste und Programme,
• und einen Agenten, der über Telegram erreichbar wird.

Warum machen wir das?

Eine funktionierende Anwendung ist nur dann dauerhaft nutzbar, wenn wir wissen:

• wie sie aufgebaut ist,
• wie sie gestartet wird,
• wie sie getestet wird,
• und wie wir zu einem funktionierenden Stand zurückkehren können.

Unser Ziel

Wir verfügen über ein funktionsfähiges, nachvollziehbares und weiterentwickelbares Projekt.

Wo sind wir?

Wir betrachten den gesamten Weg des Tages.

Was machen wir?

Wir beantworten gemeinsam:

• Was hat Codex heute für uns übernommen?
• Welche Arbeit mussten wir weiterhin selbst leisten?
• Welche Aufgabe hätten wir ohne Codex vermutlich nicht umgesetzt?
• Wo hat Codex falsche Annahmen getroffen?
• Welche Rückfragen hätten wir früher stellen sollen?
• Welche Änderungen mussten wir korrigieren?
• Welche Berechtigungen haben wir erteilt oder abgelehnt?
• Wie haben wir erkannt, ob eine Funktion tatsächlich funktioniert?
• Welcher Schritt unserer Methodik war besonders hilfreich?
• Welche eigene Projektidee möchten wir mit Codex bearbeiten?

Wir greifen außerdem die Erwartungen vom Beginn des Tages erneut auf:

• Hat Codex das übernommen, was wir erwartet hatten?
• Wo war mehr Anleitung erforderlich als gedacht?
• Welche Aufgabe würden wir Codex inzwischen zutrauen?
• Welche Aufgabe würden wir Codex nicht unbeaufsichtigt übertragen?

Warum machen wir das?

Unser Ziel ist nicht nur eine Anwendung für den heutigen Tag.

Die Arbeitsmethodik soll anschließend auf eigene Projekte und neue technische Aufgaben übertragen werden können.

Unser Ziel

Jeder Teilnehmer kennt:

• den Unterschied zwischen ChatGPT und Codex,
• den grundlegenden Aufbau eines Projekts,
• den sicheren Codex-Arbeitsablauf,
• die Bedeutung von Plan, Prüfung und Test,
• und seinen nächsten eigenen Anwendungsfall.