Doradztwo OpenAI Codex dla repozytoriów i zespołów

W konfiguracji lokalnej CLI pracuje na checkoucie na maszynie danego inżyniera, na jego koncie, w ramach sandboxa i zasad zatwierdzania, które konfigurujesz. Agent w chmurze pracuje na klonie w środowisku utrzymywanym przez OpenAI, z własnymi krokami konfiguracji, sekretami i regułami sieciowymi. Rozszerzenie IDE i aplikację desktopową można podłączyć na różne sposoby, więc to, gdzie faktycznie pracują, ustalamy dla konkretnej konfiguracji, zamiast to zakładać. Zasady napisane dla jednego wariantu nie przenoszą się na drugi, więc zakres każdego, którego chcesz używać, ustalamy osobno.

To, dokąd trafiają prompty i kontekst repozytorium, zależy od faktycznie skonfigurowanego dostawcy: mogą to być modele OpenAI albo, jeśli CLI jest tak ustawione, inny dostawca lub model uruchomiony lokalnie. Lokalne uruchomienie samo w sobie nie oznacza, że nic nie opuszcza maszyny. To, co jest wysyłane, z jakiego konta i jak długo przechowywane, zależy od wariantu pracy, konfiguracji i twojej umowy z dostawcą. Dokumentujemy przepływ dla każdego wariantu w takiej postaci, w jakiej jest skonfigurowany, a osoby odpowiedzialne u ciebie za dane i umowy porównują go z tą umową i aktualną dokumentacją dostawcy.

• Tryb sandboxa i zasady zatwierdzania dla każdego repozytorium: co działa bez pytania, co wymaga zgody, co jest wyłączone
• Dostęp do sieci z sandboxa oraz, jeśli jest włączony, rejestry i usługi potrzebne do builda
• Typ konta, dostęp do modeli i to, kto nimi zarządza
• Wspólne ustawienia w wersjonowanej konfiguracji zamiast domyślnych wartości na poszczególnych laptopach
• Zakres repozytoriów i danych ustalony przed pilotażem

Pilotaż prowadzimy interaktywnie: mała grupa, kilka reprezentatywnych zadań, zwykłe code review i wymagane kontrole. Pokazuje on, które rodzaje zadań w tym repozytorium wracają w stanie nadającym się do scalenia, a które kosztują w review więcej, niż oszczędzają przy pisaniu.

Uruchomienia nieinteraktywne, w CI albo jako zadania w chmurze, to osobna decyzja, bo zawodzą w inny sposób: nikt nie patrzy, gdy przebieg zaczyna iść w złą stronę. Proponujemy je dla wąskich, dobrze opisanych prac, przy których kontrole poza agentem wychwycą złą zmianę, a o pushach i scalaniu decyduje kod pipeline'u, nie agent. Poświadczenia dostępne w takim przebiegu są ograniczone do tego jednego zadania.

• Najpierw praca interaktywna, na zadaniach, których wynik recenzent przeczyta za jednym podejściem
• Uruchomienia bez nadzoru tylko za testami i review, których agent nie może zmienić
• Nakład pracy w review mierzony obok przepustowości: poprawki, wycofania i uwagi z review według zespołu, zadania i modelu, bez oceniania poszczególnych osób

Z zespołem pracujemy w twoich repozytoriach, na zadaniach z backlogu. Sesje skupiają się na decyzjach, które wymagają wprawy: jak pociąć zadanie, żeby diff dało się przejrzeć, jaki kontekst podać, a co zostawić w AGENTS.md, kiedy przebieg odjechał na tyle, że taniej zacząć od nowa, niż dalej go korygować, i jak recenzować zmianę, której się samemu nie pisało. Zespoły, które korzystają też z agenta w chmurze, ćwiczą delegowanie osobno, bo review pull requesta z przebiegu, którego nikt nie obserwował, to inna praca niż review diffa, którym się samemu sterowało. Na koniec zespół ustala konwencje dla plików z instrukcjami i review, żeby konfiguracja nie zależała od tego, kto ją ustawiał.

Twój zespół zachowuje pliki z instrukcjami, konfigurację sandboxa i zatwierdzania, runbooki oraz pomiary porównawcze z pilotażu. Powody każdej decyzji są spisane, żeby twoi inżynierowie mogli zmieniać konfigurację bez nas.