Jak zacząć z Codexem bezpiecznie: pierwszy mały projekt

Wybierz zadanie, które da się jednoznacznie sprawdzić

Dobre pierwsze zadanie ma jeden rezultat i niewielki obszar. „Zbuduj mi aplikację” nie spełnia żadnego z tych warunków. „W kopii strony zmień tekst przycisku, nie ruszając obsługi płatności, a potem pokaż zmienione pliki i uruchom istniejące testy” ma wyraźne granice.

Jeśli nie ma testów, zapisz manualne kryterium: strona ma się zbudować, przycisk ma prowadzić do określonego miejsca, a widok mobilny nie może się rozjechać. Codex potrzebuje sposobu rozpoznania sukcesu tak samo jak człowiek.

Przygotuj bezpieczne środowisko przed pierwszym poleceniem

1. 01
   Pracuj na kopii lub w systemie wersji

   Upewnij się, że możesz wrócić do znanego stanu. W Git utwórz osobną gałąź i sprawdź, czy nie ma cudzych niezapisanych zmian.

2. 02
   Otwórz właściwy katalog

   Kontekstem Codexa są dostępne foldery. Nie wybieraj szerokiego katalogu z prywatnymi dokumentami, jeśli zadanie dotyczy jednej aplikacji.

3. 03
   Ogranicz uprawnienia

   Dostęp do sieci, sekretów i operacji zewnętrznych włączaj tylko wtedy, gdy są naprawdę potrzebne i rozumiesz wpływ.

4. 04
   Poznaj polecenia testowe

   Znajdź instrukcję uruchomienia projektu, testów i budowania. Bez tego trudno odróżnić poprawną zmianę od pliku, który tylko wygląda wiarygodnie.

5. 05
   Zatrzymaj publikację

   Pierwsza sesja powinna kończyć się lokalnym wynikiem do przeglądu. Wdrożenie, wiadomość lub zapis produkcyjny wymagają osobnej decyzji.

Nie powierzaj pierwszej sesji operacji, której nie umiesz cofnąć. Najpierw naucz się czytać zakres zmiany i dowód jej działania.

Prompt do pierwszego zadania w Codexie

Użyj prostego wzorca: „W tym projekcie [opisz rezultat]. Najpierw przeczytaj instrukcje projektu i wskaż pliki, których dotyczy zmiana. Zachowaj [ważne ograniczenia]. Nie zmieniaj [obszar poza zakresem]. Po wdrożeniu uruchom [test lub kontrola], pokaż podsumowanie diffu i zatrzymaj się przed publikacją”.

Przykład: „Na stronie testowej popraw komunikat pustego koszyka, aby wyjaśniał następny krok. Zachowaj obecny wygląd i logikę zakupów. Nie zmieniaj API ani zależności. Uruchom testy interfejsu, sprawdź widok mobilny i pokaż dokładne pliki. Niczego nie wdrażaj”.

• Rezultat: konkretne zachowanie użytkownika albo plik, który ma powstać.
• Kontekst: właściwy katalog, błąd, screenshot lub kroki reprodukcji.
• Granice: elementy, których nie wolno zmieniać i działania wymagające zgody.
• Weryfikacja: test, build, kontrola wizualna albo policzalny readback.

Jak przeczytać diff bez bycia programistą

Diff pokazuje linie usunięte i dodane. Najpierw sprawdź zakres: czy zmieniono tylko oczekiwane pliki. Potem odszukaj tekst lub zachowanie, o które prosiłeś. Zwróć uwagę na duże bloki zmian, nowe zależności, pliki konfiguracyjne oraz fragmenty niezwiązane z zadaniem.

Poproś Codexa o wyjaśnienie każdej zmiany prostym językiem, ale nie opieraj kontroli wyłącznie na jego własnym podsumowaniu. Otwórz pliki i zobacz różnicę. Jeśli zakres jest większy niż uzgodniono, zatrzymaj pracę i poproś o mniejszą poprawkę.

Test, readback i bezpieczny punkt zakończenia

Brak błędu w terminalu nie dowodzi, że funkcja działa. Uruchom test najbliższy zmianie, a następnie rzeczywisty scenariusz: otwórz stronę, kliknij przepływ, sprawdź wygenerowany plik albo odczytaj stan po zapisie. W przypadku interfejsu zobacz telefon i komputer.

Na koniec zapisz mały checkpoint: co zmieniono, jakie testy przeszły, co pozostało nieweryfikowane i jak wrócić do poprzedniego stanu. Dopiero po tym osobno decyduj o commicie, pushu i wdrożeniu. Pierwszy projekt jest udany, gdy rozumiesz nie tylko wynik, lecz także ślad prowadzący do niego.