Przykład poprawki w kodzie dla początkujących

Załóżmy, że formularz nowego zadania pozwala wysłać samą spację jako tytuł. Aplikacja powinna odrzucać pustą wartość po usunięciu białych znaków i pokazać czytelny komunikat. To mały, ograniczony problem, który można sprawdzić bez przebudowy całej aplikacji.

To fikcyjny przykład użycia Codex w repozytorium demonstracyjnym. Nie twierdzi, że agent wykonał lub przetestował zmianę. W praktyce interfejs i dostępne możliwości narzędzia mogą zależeć od produktu, planu oraz konfiguracji. Sprawdź aktualną dokumentację OpenAI.

Zapisz zachowanie przed zmianą

Zanim poprosisz asystenta programistycznego o poprawkę, opisz błąd jako warunek, który da się odtworzyć. W tym przykładzie formularz przyjmuje „ ”, czyli tekst zawierający wyłącznie spacje. Oczekiwany rezultat: wysłanie nie dochodzi do skutku, użytkownik widzi informację o wymaganym tytule, a poprawne wartości nadal działają.

Nie zaczynaj od zdania „napraw formularz”. Bez kryterium akceptacji agent może zmienić zbyt wiele albo wybrać zachowanie, którego nie chcesz. Krótka reprodukcja i oczekiwany wynik tworzą test dla poprawki.

Krok 1: sprawdź repozytorium i zakres

Użyj kopii roboczej projektu. Zanim agent rozpocznie analizę, sprawdź bieżącą gałąź, niezatwierdzone zmiany i instrukcje repozytorium. Zachowaj własne poprawki. Nie podawaj sekretów, tokenów API ani danych klientów w promptach.

Agent pracujący z projektem może mieć dostęp do plików lub narzędzi zależnie od środowiska i zatwierdzonych uprawnień. Przeczytaj prośby o dostęp i polecenia, zanim je zaakceptujesz. W pierwszym ćwiczeniu trzymaj się małego projektu testowego.

Krok 2: poproś agenta o plan, nie od razu o implementację

Przy błędzie z kilkoma zależnościami najpierw poproś o znalezienie walidacji, opis aktualnego przepływu i mały plan. Niech Codex wskaże pliki oraz istniejące testy. Jeśli proponuje zmianę API, dodatkową bibliotekę albo refaktoryzację poza zakresem, poproś o prostsze rozwiązanie.

Plan pozwala zatrzymać pracę przed modyfikacją plików. To dobry moment, by dopytać o założenia, których nie ma w opisie.

Jak ocenić plan poprawki?

Plan powinien łączyć przyczynę błędu z minimalną zmianą i kontrolą wyniku. Sprawdź, czy asystent odnalazł właściwy formularz i walidację, a nie tylko miejsce renderowania. Poproś o wskazanie istniejącego wzorca komunikatów oraz testów w projekcie.

  • Czy warunek walidacji obejmuje pusty tekst i same białe znaki?
  • Czy poprawne wartości pozostają bez zmian?
  • Które pliki mają się zmienić i dlaczego?
  • Jak sprawdzisz regresję oraz komunikat dla użytkownika?

Krok 3: przejrzyj propozycję kodu

Po zaakceptowaniu planu poproś asystenta o implementację w ograniczonym zakresie. Przejrzyj diff w repozytorium: czy trim dotyczy walidacji, czy nie zmieniono wartości wysyłanej dalej bez potrzeby i czy komunikat jest zgodny z projektem? Wybierz rozwiązanie, które potrafisz wyjaśnić.

Krok 4: sprawdź testy i ręczne przypadki

Uruchom testy poleceniem opisanym w dokumentacji projektu. Jeśli istnieją testy jednostkowe walidacji, sprawdź pusty tekst, same spacje oraz prawidłowy tytuł. Jeżeli testów brakuje, dodaj prosty przypadek zgodny z używanym stosem albo wykonaj ręczną kontrolę formularza.

Sam komunikat o sukcesie w terminalu nie potwierdza jeszcze, że interfejs działa poprawnie. Sprawdź widoczność błędu, brak wysłania formularza i brak regresji dla poprawnej wartości.

  • Pusty tekst: zapis zablokowany.
  • Tekst z samymi spacjami: zapis zablokowany.
  • Poprawny tytuł: zachowanie bez zmian.
  • Błąd walidacji jest zrozumiały i dostępny dla użytkownika.

Co zrobić, jeśli Codex zmieni za dużo?

Porównaj diff z zakresem zadania. Jeśli poprawka zmieniła inne pola, strukturę API lub kilka niezwiązanych plików, poproś o wyjaśnienie i przywrócenie zmian poza zaakceptowanym zakresem. Możesz podzielić zadanie na mniejsze kroki i zlecić ponownie tylko brakującą część.

Nie akceptuj poprawki, której działania nie rozumiesz. Przy błędach uruchomionych testów przekaż konkretny komunikat i poproś o diagnozę, nie o losowe zmiany. Własna kontrola diffu i historii Git pozostaje częścią pracy.

Kiedy ta metoda jest dobrym zadaniem dla Codex?

Mała walidacja jest dobrym ćwiczeniem, bo ma jasne wejście, wynik i kilka łatwych przypadków testowych. Większy feature, zmiana bezpieczeństwa, migracja danych lub działanie na produkcji wymagają dodatkowego planowania i przeglądu przez osobę znającą system.

Jeśli chcesz uczyć się pracy z agentem kodującym, zacznij od problemu, którego rezultat możesz sprawdzić. Asystent pomaga analizować i proponować kod, lecz odpowiedzialność za zaakceptowaną zmianę i jej wdrożenie należy do zespołu.

Co sprawdzić przed commitem?

Przed zatwierdzeniem zmian upewnij się, że testy są wykonane, diff nie zawiera przypadkowych plików, a komunikat walidacji jest zgodny z wymaganiami. Jeśli nie potrafisz streścić zmiany w dwóch zdaniach, poproś agenta o wyjaśnienie albo wróć do kodu.

Commit wykonuj zgodnie z procedurą projektu i po własnej akceptacji. Uprawnienia agenta, uruchamianie poleceń i dostęp do repozytorium kontroluj w ustawieniach używanego produktu.

Zrób code review przed akceptacją

Code review to przegląd zmiany pod kątem zgodności z wymaganiami, jakości kodu i skutków dla reszty aplikacji. Przeczytaj diff plik po pliku, sprawdź działanie walidacji i odszukaj powiązane testy w repozytorium. Jeśli pojawi się failing test, ustal, czy błąd wynika z poprawki czy wcześniejszego stanu projektu.

Mały flow — opis problemu, plan, implementacja i kontrola — jest łatwiejszy do oceny niż prośba o naprawę całego codebase. Jeśli pracujesz w aplikacji desktopowej, IDE lub VS Code, sprawdź aktualne możliwości i konfigurację w dokumentacji OpenAI. Sposób pracy oraz dostępne funkcje mogą się zmieniać.