Flux de lucru Codex și multi-agen: lucrați cu agenți fără a pierde controlul

spinny:~/writing $ vim codex-multi-agent-workflows.md

1~
2Prima dată când un agent de codificare remediază o eroare pentru dvs., reacția este aproape întotdeauna aceeași: un amestec de entuziasm și suspiciune. Frumos, sigur. Dar apoi te uiți la diferență și te întrebi: "Ok, dar ce anume s-a atins? Pot să am încredere în el? O să mai facă și mâine la fel?".
3~
4De acolo cred că începe partea interesantă. Nu atunci când agentul scrie o funcție, ci când devine suficient de capabil să preia lucrări întregi: citiți depozitul, creați un patch, rulați teste, deschideți un PR, reveniți după un comentariu de revizuire. Codex se mișcă tocmai în această direcție: lucru în fundal, arbori de lucru separat, browser integrat, automatizări, pluginuri, memorie și controale mai explicite ale permisiunilor.
5~
6Ideea este să nu ne imaginăm un viitor în care nimeni să nu mai citească cod. Ar fi un viitor teribil, precum și destul de naiv. Ideea este să vă dați seama cum să lucrați cu agenți care pot face multe fără a-i lăsa să facă totul.
7~
8## Schimbarea obiceiului
9~
10Cu autocompletarea tradițională ai fost mereu la volan. AI-ul a sugerat o linie, ați decis. Cu un agent, însă, relația se schimbă: îi dai un scop și el parcurge mai mulți pași de unul singur.
11~
12Acest lucru este puternic, dar schimbă problema. Întrebarea nu mai este doar „modelul poate programa?”. Întrebarea devine:
13~
14- I-am dat o rază suficient de mică?
15- știi cum să verifici rezultatul?
16- Lucrez într-un mediu izolat?
17- Revizuirea finală este încă umană și atentă?
18~
19Un flux de lucru sănătos arată mai mult așa decât o baghetă magică:
20~
21```mermaid
22flowchart LR
23    Idea[Sarcina umană] --> Scope[Scop mic, verificabil]
24    Scope --> Agent[Agent în arborele de lucru izolat]
25    Agent --> Checks[Testați, scame, construiți, browser]
26    Checks --> Review[Revizuire umană]
27    Review --> Merge[Îmbinare sau o nouă iterație]
28    Review --> Iterate[Comentarii precise despre diferență]
29    Iterate --> Agent
30```
31~
32Sună mai puțin romantic decât „agentul construiește totul”, dar funcționează mult mai bine. Și așa funcționează echipele care sunt bune cu oamenii: sarcini clare, feedback rapid, responsabilitate explicită.
33~
34## Promptul bun este aproape un bilet bun
35~
36Cel mai periculos prompt este cel vag, dar încrezător: „remediați pagina de facturi”, „îmbunătățiți arhitectura”, „curățați modulul de autentificare”. Acestea sunt cereri care sună productiv și generează diferențe uriașe. Dar apoi te trezești că faci arheologie.
37~
38Un prompt util este mai plictisitor. De exemplu: implementați exportul CSV pentru pagina de facturi, știind că tabelul este în `app/(dashboard)/invoices/page.tsx`, interogările sunt în `src/server/invoices.ts` și există deja un model similar în `app/(dashboard)/reports`.
39~
40Apoi adăugați constrângeri clare: nu modificați schema bazei de date, nu adăugați dependențe dacă un utilitar mic este suficient, păstrați stilul UI existent. Și închideți cu verificarea: `npm test -- invoices` și `npm run build`.
41~
42Acest tip de brief nu este pentru a „explica mai bine AI”. Servește mai presus de toate pentru a vă face mai clar ceea ce delegați. Dacă nu o poți nota în mod concret, poate că sarcina nu este încă pregătită pentru un agent.
43~
44## Trei joburi pe care le deleg de bunăvoie
45~
46Prima este munca repetitivă, dar verificabilă: adăugarea de teste, migrarea apelurilor către un nou API intern, actualizarea importurilor, înlocuirea componentelor depreciate, remedierea erorilor TypeScript. Aici agentul poate economisi ore și riscul este controlabil.
47~
48Al doilea este munca de explorare: „găsește unde se calculează acest total”, „explicați-mi de ce acest test este fragil”, „reproduceți bug-ul și spuneți-mi ce fișiere par a fi afectate”. Chiar și atunci când nu produce un patch imediat, poate face recunoaștere utilă.
49~
50Al treilea este munca de întreținere recurentă: mici actualizări ale dependențelor, curățarea semnalizatoarelor vechi de caracteristici, rezumatul PR-urilor blocate, verificarea TODO uitate. Nu este plin de farmec, dar este exact genul de muncă care tinde să se adune.
51~
52## Trei locuri de muncă pe care le păstrez uman
53~
54Deciziile legate de produse rămân umane. Dacă o modificare modifică modul în care un utilizator plătește, șterge date, vede prețuri sau înțelege o permisiune, vreau o persoană responsabilă.
55~
56Granițele de securitate merită, de asemenea, atenție umană: autentificare, roluri, jetoane, înregistrarea datelor sensibile, migrarea bazelor de date. Un agent poate ajuta la implementare, dar nu trebuie să fie singurul care ia decizii.
57~
58În sfârșit, păstrez tot ce necesită un gust arhitectural uman. Un agent poate propune un refactor, dar a înțelege dacă o abstracție este cu adevărat necesară sau dacă doar lustruim o problemă inexistentă rămâne o treabă.
59~
60## Revizuirea nu este opțională
61~
62Tentația, când un agent este bun, este să ai încredere în verdele CI. Este de înțeles. Tot atunci încep problemele.
63~
64Mă uit întotdeauna la cel puțin cinci lucruri:
65~
661. Patch-ul rezolvă doar sarcina solicitată?
672. A atins fișiere care nu aveau nicio legătură cu asta?
683. Testele acoperă un comportament nou sau doar șansa fericită?
694. Urmează codul tipare locale?
705. Erorile sunt tratate ca în restul proiectului?
71~
72Când ceva nu este în regulă, feedback-ul trebuie să fie specific. „Remediază-l” este leneș. Mai bine: acest utilitar dublează `parseMoney` în `src/lib/money.ts`; reutilizați acea funcție, adăugați un test pentru cazul EUR și nu modificați API-ul public al modulului de facturare.
73~
74Agenții răspund mult mai bine la comentariile mici, verificabile. În mod curios, la fel și oamenii.
75~
76## Balustrade merită efortul
77~
78Dacă un agent poate citi fișiere, scrie cod și executa comenzi, ar trebui tratat ca un proces puternic. Nu e nevoie de paranoia, ai nevoie de igienă.
79~
80Utilizați arbori de lucru sau ramuri separate. Așa că puteți compara diferențele, puteți arunca experimentele eșuate și nu amestecați munca agentului cu ceea ce făceai.
81~
82Limitați permisiunile. Comenzi precum `rg`, `git diff`, `npm test` și `npm run build` pot fi destul de gratuite. Implementările, migrarea bazelor de date, accesul la secrete și comenzile distructive trebuie să rămână explicite.
83~
84Reduceți accesul la rețea atunci când nu aveți nevoie de el. Pentru multe sarcini, documentația oficială, registrul pachetelor și serviciile interne specifice sunt suficiente. Mai puțină suprafață, mai puține surprize.
85~
86Urmăriți acțiunile. Când un patch ajunge în examinare, ar trebui să puteți reconstrui solicitările, comenzile executate, testele trecute și fișierele modificate. Nu pentru a crea birocrație, ci pentru a putea înțelege ce s-a întâmplat dacă ceva nu merge bine.
87~
88## O modalitate ușoară de a începe ca o echipă
89~
90Dacă ar fi să introduc agenți într-o echipă mică, aș începe fără revoluții majore.
91~
92Aș crea o etichetă `agent-ready` pentru probleme cu domeniu clar. Aș adăuga un șablon cu context, constrângeri și comenzi de verificare. Aș cere PR mic, ideal sub câteva sute de rânduri. Aș avea nevoie de testare sau capturi de ecran pentru modificări vizibile. Și mai presus de toate aș păstra o persoană responsabilă de fuziune.
93~
94După două săptămâni m-aș uita la date: ce sarcini au fost cu adevărat accelerate, ce recenzii au fost grele, ce solicitări erau confuze, ce părți ale bazei de cod sunt prea fragile pentru a fi delegate.
95~
96Este o abordare mai puțin spectaculoasă decât „de azi vom face totul cu agenții”, dar este cea care îți permite să ajungi la a treia săptămână fără regrete.
97~
98## Partea cea mai umană
99~
100Lucrul amuzant este că, cu cât agenții devin mai autonomi, cu atât abilitățile clasice redevin mai importante: scrierea unui bilet bun, efectuarea de mici tăieturi, crearea de teste, citirea diferențelor, comunicarea compromisurilor. Agentul îi accelerează pe cei care deja știu să lucreze bine. De asemenea, amplifică haosul celor care deleg prost.
101~
102Deci nu, nu văd fluxurile de lucru cu mai mulți agenți ca pe o scurtătură pentru a nu mai face inginerie. Le văd ca pe o modalitate de a transfera mai multă energie către părțile care contează: a decide ce să construiască, a se asigura că funcționează, a menține sistemul de înțeles.
103~
104Agenții pot face colegi asincroni grozavi. Dar un coleg asincron, pentru a fi util, are nevoie de context, limite și revizuire. La fel ca toți ceilalți.
105~
106## Surse utile
107~
108- [Codex pentru (aproape) totul - OpenAI](https://openai.com/index/codex-for-almost-everything/)
109- [Rularea Codex în siguranță la OpenAI](https://openai.com/index/running-codex-safely/)
110- [Vă prezentăm Codex - OpenAI](https://openai.com/index/introducing-codex/)
111- [Ce este nou cu agentul de codare GitHub Copilot](https://github.blog/ai-and-ml/github-copilot/whats-new-with-github-copilot-coding-agent/)
112~

NORMAL · codex-multi-agent-workflows.md [readonly]112 lines · :q to close

2Prima dată când un agent de codificare remediază o eroare pentru dvs., reacția este aproape întotdeauna aceeași: un amestec de entuziasm și suspiciune. Frumos, sigur. Dar apoi te uiți la diferență și te întrebi: "Ok, dar ce anume s-a atins? Pot să am încredere în el? O să mai facă și mâine la fel?".

4De acolo cred că începe partea interesantă. Nu atunci când agentul scrie o funcție, ci când devine suficient de capabil să preia lucrări întregi: citiți depozitul, creați un patch, rulați teste, deschideți un PR, reveniți după un comentariu de revizuire. Codex se mișcă tocmai în această direcție: lucru în fundal, arbori de lucru separat, browser integrat, automatizări, pluginuri, memorie și controale mai explicite ale permisiunilor.

6Ideea este să nu ne imaginăm un viitor în care nimeni să nu mai citească cod. Ar fi un viitor teribil, precum și destul de naiv. Ideea este să vă dați seama cum să lucrați cu agenți care pot face multe fără a-i lăsa să facă totul.

8## Schimbarea obiceiului

10Cu autocompletarea tradițională ai fost mereu la volan. AI-ul a sugerat o linie, ați decis. Cu un agent, însă, relația se schimbă: îi dai un scop și el parcurge mai mulți pași de unul singur.

11~

12Acest lucru este puternic, dar schimbă problema. Întrebarea nu mai este doar „modelul poate programa?”. Întrebarea devine:

13~

14- I-am dat o rază suficient de mică?

15- știi cum să verifici rezultatul?

16- Lucrez într-un mediu izolat?

17- Revizuirea finală este încă umană și atentă?

18~

19Un flux de lucru sănătos arată mai mult așa decât o baghetă magică:

20~

21```mermaid

22flowchart LR

23 Idea[Sarcina umană] --> Scope[Scop mic, verificabil]

24 Scope --> Agent[Agent în arborele de lucru izolat]

25 Agent --> Checks[Testați, scame, construiți, browser]

26 Checks --> Review[Revizuire umană]

27 Review --> Merge[Îmbinare sau o nouă iterație]

28 Review --> Iterate[Comentarii precise despre diferență]

29 Iterate --> Agent

30```

31~

32Sună mai puțin romantic decât „agentul construiește totul”, dar funcționează mult mai bine. Și așa funcționează echipele care sunt bune cu oamenii: sarcini clare, feedback rapid, responsabilitate explicită.

33~

34## Promptul bun este aproape un bilet bun

35~

36Cel mai periculos prompt este cel vag, dar încrezător: „remediați pagina de facturi”, „îmbunătățiți arhitectura”, „curățați modulul de autentificare”. Acestea sunt cereri care sună productiv și generează diferențe uriașe. Dar apoi te trezești că faci arheologie.

37~

38Un prompt util este mai plictisitor. De exemplu: implementați exportul CSV pentru pagina de facturi, știind că tabelul este în `app/(dashboard)/invoices/page.tsx`, interogările sunt în `src/server/invoices.ts` și există deja un model similar în `app/(dashboard)/reports`.

39~

40Apoi adăugați constrângeri clare: nu modificați schema bazei de date, nu adăugați dependențe dacă un utilitar mic este suficient, păstrați stilul UI existent. Și închideți cu verificarea: `npm test -- invoices` și `npm run build`.

41~

42Acest tip de brief nu este pentru a „explica mai bine AI”. Servește mai presus de toate pentru a vă face mai clar ceea ce delegați. Dacă nu o poți nota în mod concret, poate că sarcina nu este încă pregătită pentru un agent.

43~

44## Trei joburi pe care le deleg de bunăvoie

45~

46Prima este munca repetitivă, dar verificabilă: adăugarea de teste, migrarea apelurilor către un nou API intern, actualizarea importurilor, înlocuirea componentelor depreciate, remedierea erorilor TypeScript. Aici agentul poate economisi ore și riscul este controlabil.

47~

48Al doilea este munca de explorare: „găsește unde se calculează acest total”, „explicați-mi de ce acest test este fragil”, „reproduceți bug-ul și spuneți-mi ce fișiere par a fi afectate”. Chiar și atunci când nu produce un patch imediat, poate face recunoaștere utilă.

49~

50Al treilea este munca de întreținere recurentă: mici actualizări ale dependențelor, curățarea semnalizatoarelor vechi de caracteristici, rezumatul PR-urilor blocate, verificarea TODO uitate. Nu este plin de farmec, dar este exact genul de muncă care tinde să se adune.

51~

52## Trei locuri de muncă pe care le păstrez uman

53~

54Deciziile legate de produse rămân umane. Dacă o modificare modifică modul în care un utilizator plătește, șterge date, vede prețuri sau înțelege o permisiune, vreau o persoană responsabilă.

55~

56Granițele de securitate merită, de asemenea, atenție umană: autentificare, roluri, jetoane, înregistrarea datelor sensibile, migrarea bazelor de date. Un agent poate ajuta la implementare, dar nu trebuie să fie singurul care ia decizii.

57~

58În sfârșit, păstrez tot ce necesită un gust arhitectural uman. Un agent poate propune un refactor, dar a înțelege dacă o abstracție este cu adevărat necesară sau dacă doar lustruim o problemă inexistentă rămâne o treabă.

59~

60## Revizuirea nu este opțională

61~

62Tentația, când un agent este bun, este să ai încredere în verdele CI. Este de înțeles. Tot atunci încep problemele.

63~

64Mă uit întotdeauna la cel puțin cinci lucruri:

65~

661. Patch-ul rezolvă doar sarcina solicitată?

672. A atins fișiere care nu aveau nicio legătură cu asta?

683. Testele acoperă un comportament nou sau doar șansa fericită?

694. Urmează codul tipare locale?

705. Erorile sunt tratate ca în restul proiectului?

71~

72Când ceva nu este în regulă, feedback-ul trebuie să fie specific. „Remediază-l” este leneș. Mai bine: acest utilitar dublează `parseMoney` în `src/lib/money.ts`; reutilizați acea funcție, adăugați un test pentru cazul EUR și nu modificați API-ul public al modulului de facturare.

73~

74Agenții răspund mult mai bine la comentariile mici, verificabile. În mod curios, la fel și oamenii.

75~

76## Balustrade merită efortul

77~

78Dacă un agent poate citi fișiere, scrie cod și executa comenzi, ar trebui tratat ca un proces puternic. Nu e nevoie de paranoia, ai nevoie de igienă.

79~

80Utilizați arbori de lucru sau ramuri separate. Așa că puteți compara diferențele, puteți arunca experimentele eșuate și nu amestecați munca agentului cu ceea ce făceai.

81~

82Limitați permisiunile. Comenzi precum `rg`, `git diff`, `npm test` și `npm run build` pot fi destul de gratuite. Implementările, migrarea bazelor de date, accesul la secrete și comenzile distructive trebuie să rămână explicite.

83~

84Reduceți accesul la rețea atunci când nu aveți nevoie de el. Pentru multe sarcini, documentația oficială, registrul pachetelor și serviciile interne specifice sunt suficiente. Mai puțină suprafață, mai puține surprize.

85~

86Urmăriți acțiunile. Când un patch ajunge în examinare, ar trebui să puteți reconstrui solicitările, comenzile executate, testele trecute și fișierele modificate. Nu pentru a crea birocrație, ci pentru a putea înțelege ce s-a întâmplat dacă ceva nu merge bine.

87~

88## O modalitate ușoară de a începe ca o echipă

89~

90Dacă ar fi să introduc agenți într-o echipă mică, aș începe fără revoluții majore.

91~

92Aș crea o etichetă `agent-ready` pentru probleme cu domeniu clar. Aș adăuga un șablon cu context, constrângeri și comenzi de verificare. Aș cere PR mic, ideal sub câteva sute de rânduri. Aș avea nevoie de testare sau capturi de ecran pentru modificări vizibile. Și mai presus de toate aș păstra o persoană responsabilă de fuziune.

93~

94După două săptămâni m-aș uita la date: ce sarcini au fost cu adevărat accelerate, ce recenzii au fost grele, ce solicitări erau confuze, ce părți ale bazei de cod sunt prea fragile pentru a fi delegate.

95~

96Este o abordare mai puțin spectaculoasă decât „de azi vom face totul cu agenții”, dar este cea care îți permite să ajungi la a treia săptămână fără regrete.

97~

98## Partea cea mai umană

99~

100Lucrul amuzant este că, cu cât agenții devin mai autonomi, cu atât abilitățile clasice redevin mai importante: scrierea unui bilet bun, efectuarea de mici tăieturi, crearea de teste, citirea diferențelor, comunicarea compromisurilor. Agentul îi accelerează pe cei care deja știu să lucreze bine. De asemenea, amplifică haosul celor care deleg prost.

101~

102Deci nu, nu văd fluxurile de lucru cu mai mulți agenți ca pe o scurtătură pentru a nu mai face inginerie. Le văd ca pe o modalitate de a transfera mai multă energie către părțile care contează: a decide ce să construiască, a se asigura că funcționează, a menține sistemul de înțeles.

103~

104Agenții pot face colegi asincroni grozavi. Dar un coleg asincron, pentru a fi util, are nevoie de context, limite și revizuire. La fel ca toți ceilalți.

105~

106## Surse utile

107~

108- [Codex pentru (aproape) totul - OpenAI](https://openai.com/index/codex-for-almost-everything/)

109- [Rularea Codex în siguranță la OpenAI](https://openai.com/index/running-codex-safely/)

110- [Vă prezentăm Codex - OpenAI](https://openai.com/index/introducing-codex/)

111- [Ce este nou cu agentul de codare GitHub Copilot](https://github.blog/ai-and-ml/github-copilot/whats-new-with-github-copilot-coding-agent/)

112~