Ihre Repositories und Teams für OpenAI Codex vorbereiten

Wir beginnen mit einem frischen Klon in der Sandbox und sehen uns an, was sich dort bauen und ausführen lässt. Wir prüfen Zugangsdaten, lokale Dienste, private Registries und generierten Code. Danach kümmern wir uns um die Stellen, an denen sich ein Lauf des Agenten am stärksten vom lokalen Lauf eines Engineers unterscheidet.

• Einträge in AGENTS.md zum Bauen, Testen und Linten des Codes
• Kurze Hinweise dazu, wie der Code aufgebaut ist, welche Konventionen gelten und wann eine Aufgabe als erledigt gilt
• Ein schnelles Test-Target, das bei jedem Lauf dasselbe Ergebnis liefert, und eine Kennzeichnung für jede langsame oder instabile Suite
• Pfade, die für den Agenten tabu sind: Migrationen, Infrastruktur, generierter Code und ins Repository kopierte Abhängigkeiten

Die CLI läuft im lokalen Checkout eines Engineers, mit dessen Konto und der Richtlinie, die Sie konfiguriert haben. Der Cloud-Agent klont das Repository in eine von OpenAI gehostete Umgebung, in der Secrets, Setup und Netzwerkregeln separat konfiguriert werden. Die Desktop-App und die IDE-Erweiterung können sich auf jeweils andere Weise verbinden, deshalb bekommt jede von ihnen eine eigene Richtlinie.

Auch wenn die CLI lokal läuft, gehen Ihre Prompts und der zugehörige Code an den jeweils eingerichteten Modellanbieter. Wir dokumentieren, wie diese Daten fließen. Wer bei Ihnen für die Daten und den Vertrag mit dem Anbieter verantwortlich ist, gleicht das anschließend mit dieser Vereinbarung ab.

• Ein Sandbox-Modus und eine Freigaberichtlinie für jedes Repository
• Was Codex über das Netzwerk erreichen darf, einschließlich Paket-Registries
• Die Art des Kontos, der Zugriff auf Modelle und wer die Administration übernimmt
• Einstellungen für das ganze Team, abgelegt in versionierten Konfigurationsdateien
• Welche Repositories und Daten dazugehören, vor dem Piloten festgelegt

Der Pilot läuft interaktiv: Eine kleine Gruppe von Engineers übernimmt einige typische Aufgaben, mit dem Review-Prozess und den erforderlichen Checks, die Sie bereits nutzen. Codex unbeaufsichtigt laufen zu lassen, in der CI oder in der Cloud, ist eine eigene Entscheidung, denn niemand sieht zu, wenn ein Lauf fehlschlägt. Wir empfehlen das nur für eng umrissene, klar spezifizierte Arbeit. Außerdem braucht es Checks, die der Agent nicht beeinflussen kann, Pipeline-Code, der allein über Pushes und Merges entscheidet, und Zugangsdaten, die auf genau diesen einen Job beschränkt sind.

• Zuerst interaktive Arbeit, mit Aufgaben, die kurz genug für ein einziges Review sind
• Läufe ohne Aufsicht nur dort, wo der Agent weder die Tests noch das Review verändern kann
• Reverts, Nacharbeit und Befunde aus dem Review, erfasst pro Modell, Aufgabe und Team, nie pro Person

Im Training arbeiten wir mit echten Einträgen aus Ihrem Backlog. Die Engineers üben, Arbeit in Diffs aufzuteilen, denen ein Reviewer folgen kann, und zu entscheiden, was in AGENTS.md gehört. Sie lernen außerdem, wann eine neue Session mehr bringt als weiteres Steuern und wie sie Änderungen beurteilen, die sie nicht selbst geschrieben haben. Die Delegation an den Cloud-Agenten bekommt eine eigene Session. Ein Lauf, den niemand beobachtet hat, braucht eine andere Art von Review als Änderungen, die Sie Schritt für Schritt gelenkt haben.

Jede Session gilt einem Team und findet in dessen eigenen Repositories statt. Wir führen sie remote oder bei Ihnen vor Ort in Polen und Deutschland durch, auf Englisch, Polnisch oder Deutsch.

• Der Anteil der Codex-Aufgaben, deren Ergebnis gemergt wird
• Wie oft die Sandbox oder eine Freigaberegel echte Arbeit blockiert und ob das berechtigt war
• Ausgaben pro akzeptierter Änderung, für Läufe in der CLI, in der IDE und in der Cloud