Dacă vrei să introduci Codex în echipa de dezvoltare, începe cu o modificare mică într-un proiect pe care îl cunoașteți. O problemă cu pași de reproducere și un rezultat ușor de verificat îți permite să vezi unde ajută instrumentul și câtă muncă de revizuire rămâne.
Un exemplu potrivit pentru prima încercare: formularul de contact afișează un mesaj de succes chiar dacă salvarea eșuează. Echipa știe cum să reproducă problema și ce ar trebui să se întâmple după corectare. Exemplul de mai jos este o propunere de exercițiu, nu un rezultat măsurat într-un proiect Chronic.
Pregătește proiectul pentru lucru
Verifică întâi că aplicația pornește și că testele existente pot fi rulate. Dacă un test eșuează deja, notează asta. Altfel, la final nu vei ști dacă problema a apărut odată cu modificarea.
Lucrează pe o ramură separată și folosește date de test. Alege accesul necesar sarcinii: pentru corectarea afișării unei erori nu ar trebui să fie nevoie de parola bazei de date din producție.
Codex are mecanisme de control pentru permisiuni și aprobarea acțiunilor. Configurația potrivită depinde de mediul în care îl folosești. Verifică setările cu persoana care administrează proiectul, înainte de a începe exercițiul.
Pune regulile proiectului în AGENTS.md
Codex poate citi instrucțiuni din fișiere AGENTS.md. În fișierul proiectului poți explica unde se află aplicația, cum se pornește și ce comenzi folosesc colegii pentru verificări. Documentația OpenAI explică și cum se combină instrucțiunile generale cu cele din directoarele proiectului.
Păstrează aici lucruri verificabile. „Rulează verificarea tipurilor și testele formularului” este mai util decât „scrie cod de calitate”. Notează dacă mesajele pentru utilizatori trebuie să fie în română sau dacă proiectul are deja o componentă pentru afișarea erorilor.
Nu transforma fișierul într-o listă de recomandări fără legătură cu aplicația. Dacă aceeași regulă este deja aplicată automat de proiect, poți indica verificarea care o acoperă.
Descrie comportamentul dorit
Pentru exemplul formularului, cererea ar putea fi: „Când salvarea unei solicitări eșuează, formularul afișează acum mesajul de succes. Găsește cauza și corectează comportamentul. Utilizatorul trebuie să vadă un mesaj de eroare și să își păstreze datele introduse. Verifică și trimiterea reușită. Folosește date de test.”
Cererea spune când apare problema și cum arată rezolvarea. Dacă nu știi unde este codul, poți cere mai întâi să fie urmărit traseul trimiterii, de la formular la salvare. Verifică explicația înainte să ceri modificarea dacă sunt implicate zone pe care echipa nu le cunoaște bine.
Revizuiește modificarea, nu doar explicația
La final, citește diferențele de cod. Pentru acest exercițiu, verifică dacă a fost corectată condiția de succes, dacă datele rămân în formular la eroare și dacă noul mesaj poate fi văzut de utilizator.
Rulează cazul nereușit și cazul reușit. Verifică și o apăsare repetată a butonului, dacă există riscul de a trimite de două ori aceeași cerere. Un test care trece fără să acopere problema inițială nu este o verificare suficientă.
Dacă instrumentul nu a putut rula o comandă, păstrează acest lucru în descrierea schimbării. „Nu a fost verificat” și „a trecut verificarea” trebuie să rămână informații distincte.
Măsoară tot timpul de lucru
Notează cât a durat pregătirea cererii, lucrul instrumentului, revizuirea și eventualele corecturi. Nu evalua rezultatul doar după cât de repede a apărut primul cod.
După câteva sarcini, comparați unde a fost util: înțelegerea unui proiect, o corectură, pregătirea unui test sau o modificare de interfață. Pe această bază puteți decide ce instrucțiuni păstrați și ce sarcini sunt potrivite pentru echipă. Nu este nevoie să schimbați întregul proces de dezvoltare după prima încercare.