Aus einer guten Übergabe eine Entwickler-Pipeline machen

Ein brauchbarer Arbeitsablauf hat ein erkennbares Ergebnis. Eine Pipeline automatisiert einzelne Schritte auf dem Weg dorthin. Beginne mit einer Aufgabe, die du bereits von Hand lösen kannst. So lässt sich erkennen, ob die Automatisierung wirklich hilft.

Die Übung ist eine kleine Codeänderung: Wartezeit korrigieren, Diff prüfen und über die Annahme entscheiden. Dasselbe Verfahren passt zu technischen Recherchen oder Berichten aus CI-Daten.

Übergib die Aufgabe zunächst manuell

Gib dem Implementierer Aufgabe, relevante Dateien und Abnahmekriterien. Sammle danach den genauen Diff, Testergebnisse, Quellenrevision und offene Fragen. Ein Reviewer erhält die Originalbelege und soll konkrete Befunde liefern.

Das Review lässt sich in Claude, ChatGPT oder Gemini mit einem bereitgestellten Paket durchführen. Ein Coding-Agent kann bei passendem Zugriff den Checkout untersuchen. Halte fest, wo die Ausführung tatsächlich stattfindet.

Aufgabe: Erster Wiederholungsversuch nach 1 Sekunde; Obergrenze 30 Sekunden.
Eingaben: retry.js und caller.js auf der dokumentierten Basisrevision.
Änderung: Exponent anpassen, Zählweise ab eins erhalten.
Prüfungen: Original scheitert bei 1; Kandidat besteht 1, 2 und 6.
Offen: Verhalten bei null oder negativen Versuchen.
Ergebnis: Befunde mit Datei, Zeile, Fehlerablauf und vorgeschlagener Prüfung.

Bewahre die Quelldateien bei der Zusammenfassung auf. Der Reviewer braucht eine Möglichkeit, ihre Aussagen selbst zu prüfen.

Automatisiere einen zuverlässigen Schritt

Beginne mit deterministischer Sammlung: Diff exportieren, freigegebene Eingabedateien kopieren, bekannte Tests ausführen und ein Dateiverzeichnis mit Prüfsummen erstellen. Das Review bleibt zunächst manuell. Schon das spart wiederholte Übertragungen.

Ersetze danach bei Bedarf den Review-Schritt durch einen nativen Adapter. Codex bietet beispielsweise einen nicht interaktiven Aufruf mit strukturierter Ausgabe. Entpacke die Antwort, prüfe ihren Inhalt und liefere sie an denselben menschlichen Entscheidungspunkt. Die Tool-Anleitungen beschreiben die jeweiligen Schnittstellen.

Für manuelle und automatisierte Varianten gelten dieselben Abnahmekriterien.

Ergänze einen zweiten Anbieter gezielt

Lass einen zweiten Reviewer denselben eingefrorenen Diff unabhängig prüfen. Er soll den ersten Bericht vorher nicht sehen. Führe Befunde anhand ihrer Belege und beobachtbaren Folgen zusammen.

Miss, welche nützlichen Fehler ein zusätzlicher Schritt findet und wie viel Prüfarbeit er erzeugt. Mehrere Modelle können dieselbe falsche Annahme teilen. Prüfe einen Widerspruch oder bringe die tatsächliche Entscheidung zum Menschen.

Lass den Koordinator entscheiden, was laufen darf

Der Koordinator verwaltet Schritte, Datenempfänger, Grenzen und Freigaben. Ein Modell darf weitere Arbeit vorschlagen, sich aber keine neue Befugnis geben. Werkzeugberechtigung und Abnahme eines Ergebnisses sind unterschiedliche Entscheidungen.

Lies Ergebnisse und Freigaben, bevor du Implementierung oder Veröffentlichung verbindest. Der nächste konkrete Schritt muss mit Ergebnis und Ziel prüfbar sein.

Was schiefgeht

Ohne Übergabeformat wandert die ganze Unterhaltung weiter. Der Reviewer liest nur die Zusammenfassung des Autors. Ein Wiederholungsversuch arbeitet unbemerkt auf einem neueren Checkout. Ein Ausfall führt zu einem nicht ausgewählten Datenempfänger.

Definiere Eingaben, Ausgaben, Grenzen und Fehlerverhalten für jeden Schritt. Beginne mit dem reinen Review-Ablauf (Englisch).

So prüfst du das Ergebnis

Führe eine Aufgabe von Hand und automatisiert aus. Vergleiche tatsächliche Eingaben, Befunde, Tests und Entscheidungen. Baue einen bekannten Fehler ein und kontrolliere, ob er im letzten Review-Paket ankommt.

Brich einen Schritt ab und lehne eine Freigabe ab. Beides darf nicht als Erfolg gelten. Notiere Zeit, manuelle Korrekturen und Verbrauch.