Codex و گردش کار چند عاملی: کار با عوامل بدون از دست دادن کنترل

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

1~
2اولین باری که یک عامل کدگذاری واقعاً یک باگ را برای شما برطرف می کند، واکنش تقریباً همیشه یکسان است: ترکیبی از اشتیاق و سوء ظن. خوبه، حتما اما سپس به تفاوت نگاه می‌کنید و از خود می‌پرسید: "بسیار خوب، اما او دقیقاً چه چیزی را لمس کرد؟ آیا می‌توانم به او اعتماد کنم؟ آیا فردا دوباره به همان روش این کار را انجام خواهد داد؟".
3~
4اینجاست که فکر می کنم قسمت جالب شروع می شود. نه زمانی که عامل یک تابع را می نویسد، بلکه زمانی که به اندازه کافی قادر به انجام کارهای کامل می شود: مخزن را بخوانید، یک پچ ایجاد کنید، آزمایش ها را اجرا کنید، یک PR را باز کنید، پس از یک نظر بازبینی برگردید. Codex دقیقاً در این جهت حرکت می کند: کار پس زمینه، درخت کاری جداگانه، مرورگر یکپارچه، اتوماسیون، پلاگین، حافظه و کنترل های مجوز صریح تر.
5~
6نکته این نیست که آینده ای را تصور کنید که در آن هیچ کس دیگر کد نمی خواند. این آینده ای وحشتناک و همچنین کاملا ساده لوحانه خواهد بود. نکته این است که بفهمیم چگونه با عواملی کار کنیم که می توانند کارهای زیادی انجام دهند بدون اینکه به آنها اجازه انجام همه کارها را بدهند.
7~
8## تغییر عادت
9~
10با تکمیل خودکار سنتی شما همیشه در فرمان بودید. هوش مصنوعی خطی را پیشنهاد کرد، شما تصمیم گرفتید. با این حال، با یک نماینده، رابطه تغییر می کند: شما به او هدف می دهید و او چندین مرحله را به تنهایی طی می کند.
11~
12این قدرتمند است، اما مشکل را تغییر می دهد. سوال دیگر فقط این نیست که "آیا مدل می تواند برنامه ریزی کند؟". سوال می شود:
13~
14- آیا به او محدوده به اندازه کافی کوچک دادم؟
15- آیا می دانید چگونه نتیجه را بررسی کنید؟
16- آیا من در یک محیط ایزوله کار می کنم؟
17- آیا بررسی نهایی هنوز انسانی و دقیق است؟
18~
19یک گردش کار سالم بیشتر شبیه این است تا یک عصای جادویی:
20~
21```mermaid
22flowchart LR
23    Idea[وظیفه انسانی] --> Scope[هدف کوچک و قابل تأیید]
24    Scope --> Agent[عامل در درخت کاری جدا شده است]
25    Agent --> Checks[تست، لینت، ساخت، مرورگر]
26    Checks --> Review[بررسی انسانی]
27    Review --> Merge[ادغام یا تکرار جدید]
28    Review --> Iterate[نظرات دقیق در مورد تفاوت]
29    Iterate --> Agent
30```
31~
32کمتر رمانتیک به نظر می رسد تا "عامل همه چیز را می سازد"، اما بسیار بهتر عمل می کند. و همچنین نحوه کار تیم هایی است که با انسان ها خوب هستند: وظایف روشن، بازخورد سریع، مسئولیت پذیری صریح.
33~
34## اعلان خوب تقریباً یک بلیط خوب است
35~
36خطرناک‌ترین اخطار، مبهم اما مطمئن است: "صفحه فاکتورها را اصلاح کنید"، "معماری را بهبود بخشید"، "پاکسازی ماژول احراز هویت". اینها درخواست هایی هستند که سازنده به نظر می رسند و تفاوت های زیادی ایجاد می کنند. اما بعد متوجه می شوید که مشغول باستان شناسی هستید.
37~
38یک پیام مفید خسته کننده تر است. به عنوان مثال: اجرای صادرات CSV برای صفحه فاکتورها، با دانستن اینکه جدول در `app/(dashboard)/invoices/page.tsx` است، پرس و جوها در `src/server/invoices.ts` هستند و از قبل الگوی مشابهی در `app/(dashboard)/reports` وجود دارد.
39~
40سپس محدودیت‌های واضح اضافه کنید: طرح پایگاه داده را تغییر ندهید، اگر یک ابزار کوچک کافی است، وابستگی اضافه نکنید، سبک رابط کاربری موجود را حفظ کنید. و با تأیید ببندید: `npm test -- invoices` و `npm run build`.
41~
42این نوع خلاصه برای "توضیح بهتر برای هوش مصنوعی" نیست. این بیش از هر چیز به شما کمک می کند تا آنچه را که به شما تفویض می کنید روشن تر کند. اگر نمی توانید آن را به طور مشخص بنویسید، شاید کار هنوز برای یک نماینده آماده نشده باشد.
43~
44## سه شغلی که با کمال میل محول می کنم
45~
46اولی کار تکراری اما قابل تأیید است: افزودن آزمایش‌ها، انتقال تماس‌ها به یک API داخلی جدید، به‌روزرسانی واردات، جایگزینی مؤلفه‌های منسوخ، رفع خطاهای TypeScript. در اینجا نماینده می تواند ساعت ها را ذخیره کند و خطر قابل کنترل است.
47~
48دوم کار اکتشافی است: "این کل کجا محاسبه می شود"، "برای من توضیح دهید که چرا این تست شکننده است"، "اشکال را دوباره تولید کنید و به من بگویید به نظر می رسد کدام فایل ها تحت تاثیر قرار گرفته اند". حتی زمانی که فوراً پچ تولید نمی کند، می تواند شناسایی مفیدی انجام دهد.
49~
50سومین کار تعمیر و نگهداری مکرر است: به‌روزرسانی‌های کوچک وابستگی، پاک‌سازی پرچم‌های ویژگی قدیمی، خلاصه‌ای از PR مسدود شده، بررسی TODO‌های فراموش‌شده. این پر زرق و برق نیست، اما دقیقاً نوعی از کار است که تمایل به انباشته شدن دارد.
51~
52## سه شغلی که من انسان نگه می دارم
53~
54تصمیمات محصول انسانی باقی می ماند. اگر تغییری نحوه پرداخت کاربر را تغییر دهد، داده‌ها را حذف کند، قیمت‌ها را ببیند یا یک مجوز را درک کند، من یک فرد مسئول می‌خواهم.
55~
56مرزهای امنیتی نیز مستحق توجه انسان هستند: اعتبار، نقش ها، نشانه ها، ثبت داده های حساس، انتقال پایگاه داده. یک عامل می تواند به اجرا کمک کند، اما نباید تنها تصمیم گیرنده باشد.
57~
58در نهایت، من هر چیزی را که نیاز به ذوق معماری داشته باشد، نگه می دارم. یک عامل می‌تواند یک Refactor را پیشنهاد کند، اما درک اینکه آیا یک انتزاع واقعاً ضروری است یا اینکه آیا ما فقط مشکلی را که وجود ندارد صیقل می‌دهیم، کار باقی می‌ماند.
59~
60## بررسی اختیاری نیست
61~
62وسوسه، وقتی یک عامل خوب است، اعتماد به سبز CI است. قابل درک است. همچنین زمانی است که مشکلات شروع می شود.
63~
64من همیشه حداقل به پنج چیز نگاه می کنم:
65~
661. آیا پچ فقط وظیفه درخواستی را حل می کند؟
672. آیا او فایل هایی را که ربطی به آن نداشتند، لمس کرده است؟
683. آیا آزمون‌ها رفتار بدیع را پوشش می‌دهند یا فقط شانس خوشحال کننده را؟
694. آیا کد از الگوهای محلی پیروی می کند؟
705. آیا خطاها مانند بقیه پروژه ها رسیدگی می شود؟
71~
72وقتی چیزی اشتباه است، بازخورد باید مشخص باشد. "اصلاحش کن" تنبل است. بهتر: این ابزار `parseMoney` را به `src/lib/money.ts` کپی می کند. دوباره از آن تابع استفاده کنید، یک آزمایش برای مورد EUR اضافه کنید و API عمومی ماژول صورت‌حساب را تغییر ندهید.
73~
74نمایندگان به نظرات کوچک و قابل تأیید بسیار بهتر پاسخ می دهند. عجیب است که مردم هم همینطور.
75~
76## نرده های محافظ ارزش تلاش را دارد
77~
78اگر یک عامل بتواند فایل‌ها را بخواند، کد بنویسد و دستورات را اجرا کند، باید به عنوان یک فرآیند قدرتمند تلقی شود. نیازی به پارانویا نیست، شما نیاز به بهداشت دارید.
79~
80از درخت ها یا شاخه های جداگانه استفاده کنید. بنابراین می‌توانید تفاوت‌ها را مقایسه کنید، آزمایش‌های ناموفق را دور بریزید، و کار عامل را با کاری که انجام می‌دادید مخلوط نکنید.
81~
82محدود کردن مجوزها دستوراتی مانند `rg`، `git diff`، `npm test` و `npm run build` می توانند کاملا رایگان باشند. استقرار، انتقال پایگاه داده، دسترسی به اسرار و دستورات مخرب باید صریح باقی بماند.
83~
84دسترسی به شبکه را زمانی که به آن نیاز ندارید کاهش دهید. برای بسیاری از وظایف، اسناد رسمی، رجیستری بسته و خدمات داخلی خاص کافی است. سطح کمتر، شگفتی های کمتر.
85~
86ردیابی اقدامات هنگامی که یک وصله در حال بررسی قرار می‌گیرد، باید بتوانید دستورات، دستورات اجرا شده، تست‌های پاس شده و فایل‌های اصلاح شده را بازسازی کنید. نه برای ایجاد بوروکراسی، بلکه برای اینکه بتوانیم بفهمیم اگر مشکلی پیش بیاید چه اتفاقی افتاده است.
87~
88## یک راه آسان برای شروع به عنوان یک تیم
89~
90اگر بخواهم عوامل را به یک تیم کوچک معرفی کنم، بدون انقلاب های بزرگ شروع می کنم.
91~
92من یک برچسب `agent-ready` برای مسائل با دامنه واضح ایجاد می کنم. من یک الگو با زمینه، محدودیت ها و دستورات تأیید اضافه می کنم. من می خواهم برای روابط عمومی کوچک، به طور ایده آل زیر چند صد خط. برای تغییرات قابل مشاهده به آزمایش یا اسکرین شات نیاز دارم. و مهمتر از همه، من فردی را مسئول ادغام نگه می دارم.
93~
94بعد از دو هفته به داده‌ها نگاه می‌کردم: کدام کارها واقعاً سریع‌تر شده‌اند، کدام بررسی‌ها سنگین بودند، کدام درخواست‌ها گیج‌کننده بودند، کدام بخش‌های پایگاه کد برای واگذاری آن‌قدر شکننده هستند.
95~
96این رویکردی کمتر تماشایی نسبت به "از امروز همه کارها را با عوامل انجام خواهیم داد" است، اما این رویکردی است که به شما امکان می دهد بدون پشیمانی به هفته سوم برسید.
97~
98## انسانی ترین بخش
99~
100نکته خنده‌دار این است که هرچه عوامل مستقل‌تر شوند، مهارت‌های کلاسیک دوباره اهمیت بیشتری پیدا می‌کنند: نوشتن یک بلیط خوب، ایجاد برش‌های کوچک، ایجاد تست، خواندن تفاوت‌ها، برقراری ارتباط. عامل به کسانی که قبلاً می دانند چگونه خوب کار کنند سرعت می بخشد. همچنین هرج و مرج کسانی را که بد تفویض می کنند، تشدید می کند.
101~
102بنابراین نه، من گردش کار چند عاملی را میانبری برای توقف انجام مهندسی نمی بینم. من آن‌ها را راهی برای انتقال انرژی بیشتر به بخش‌های مهم می‌دانم: تصمیم‌گیری برای ساخت چه چیزی، اطمینان از کارکرد آن، قابل فهم نگه داشتن سیستم.
103~
104نمایندگان می توانند همکاران ناهمزمان عالی بسازند. اما یک همکار ناهمزمان، برای مفید بودن، نیاز به زمینه، مرزها و بررسی دارد. درست مثل بقیه.
105~
106## منابع مفید
107~
108- [Codex برای (تقریبا) همه چیز - OpenAI](https://openai.com/index/codex-for-almost-everything/)
109- [اجرای کدکس با خیال راحت در OpenAI](https://openai.com/index/running-codex-safely/)
110- [معرفی Codex - OpenAI](https://openai.com/index/introducing-codex/)
111- [چیزهای جدید با عامل کدنویسی 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

2اولین باری که یک عامل کدگذاری واقعاً یک باگ را برای شما برطرف می کند، واکنش تقریباً همیشه یکسان است: ترکیبی از اشتیاق و سوء ظن. خوبه، حتما اما سپس به تفاوت نگاه می‌کنید و از خود می‌پرسید: "بسیار خوب، اما او دقیقاً چه چیزی را لمس کرد؟ آیا می‌توانم به او اعتماد کنم؟ آیا فردا دوباره به همان روش این کار را انجام خواهد داد؟".

4اینجاست که فکر می کنم قسمت جالب شروع می شود. نه زمانی که عامل یک تابع را می نویسد، بلکه زمانی که به اندازه کافی قادر به انجام کارهای کامل می شود: مخزن را بخوانید، یک پچ ایجاد کنید، آزمایش ها را اجرا کنید، یک PR را باز کنید، پس از یک نظر بازبینی برگردید. Codex دقیقاً در این جهت حرکت می کند: کار پس زمینه، درخت کاری جداگانه، مرورگر یکپارچه، اتوماسیون، پلاگین، حافظه و کنترل های مجوز صریح تر.

6نکته این نیست که آینده ای را تصور کنید که در آن هیچ کس دیگر کد نمی خواند. این آینده ای وحشتناک و همچنین کاملا ساده لوحانه خواهد بود. نکته این است که بفهمیم چگونه با عواملی کار کنیم که می توانند کارهای زیادی انجام دهند بدون اینکه به آنها اجازه انجام همه کارها را بدهند.

8## تغییر عادت

10با تکمیل خودکار سنتی شما همیشه در فرمان بودید. هوش مصنوعی خطی را پیشنهاد کرد، شما تصمیم گرفتید. با این حال، با یک نماینده، رابطه تغییر می کند: شما به او هدف می دهید و او چندین مرحله را به تنهایی طی می کند.

11~

12این قدرتمند است، اما مشکل را تغییر می دهد. سوال دیگر فقط این نیست که "آیا مدل می تواند برنامه ریزی کند؟". سوال می شود:

13~

14- آیا به او محدوده به اندازه کافی کوچک دادم؟

15- آیا می دانید چگونه نتیجه را بررسی کنید؟

16- آیا من در یک محیط ایزوله کار می کنم؟

17- آیا بررسی نهایی هنوز انسانی و دقیق است؟

18~

19یک گردش کار سالم بیشتر شبیه این است تا یک عصای جادویی:

20~

21```mermaid

22flowchart LR

23 Idea[وظیفه انسانی] --> Scope[هدف کوچک و قابل تأیید]

24 Scope --> Agent[عامل در درخت کاری جدا شده است]

25 Agent --> Checks[تست، لینت، ساخت، مرورگر]

26 Checks --> Review[بررسی انسانی]

27 Review --> Merge[ادغام یا تکرار جدید]

28 Review --> Iterate[نظرات دقیق در مورد تفاوت]

29 Iterate --> Agent

30```

31~

32کمتر رمانتیک به نظر می رسد تا "عامل همه چیز را می سازد"، اما بسیار بهتر عمل می کند. و همچنین نحوه کار تیم هایی است که با انسان ها خوب هستند: وظایف روشن، بازخورد سریع، مسئولیت پذیری صریح.

33~

34## اعلان خوب تقریباً یک بلیط خوب است

35~

36خطرناک‌ترین اخطار، مبهم اما مطمئن است: "صفحه فاکتورها را اصلاح کنید"، "معماری را بهبود بخشید"، "پاکسازی ماژول احراز هویت". اینها درخواست هایی هستند که سازنده به نظر می رسند و تفاوت های زیادی ایجاد می کنند. اما بعد متوجه می شوید که مشغول باستان شناسی هستید.

37~

38یک پیام مفید خسته کننده تر است. به عنوان مثال: اجرای صادرات CSV برای صفحه فاکتورها، با دانستن اینکه جدول در `app/(dashboard)/invoices/page.tsx` است، پرس و جوها در `src/server/invoices.ts` هستند و از قبل الگوی مشابهی در `app/(dashboard)/reports` وجود دارد.

39~

40سپس محدودیت‌های واضح اضافه کنید: طرح پایگاه داده را تغییر ندهید، اگر یک ابزار کوچک کافی است، وابستگی اضافه نکنید، سبک رابط کاربری موجود را حفظ کنید. و با تأیید ببندید: `npm test -- invoices` و `npm run build`.

41~

42این نوع خلاصه برای "توضیح بهتر برای هوش مصنوعی" نیست. این بیش از هر چیز به شما کمک می کند تا آنچه را که به شما تفویض می کنید روشن تر کند. اگر نمی توانید آن را به طور مشخص بنویسید، شاید کار هنوز برای یک نماینده آماده نشده باشد.

43~

44## سه شغلی که با کمال میل محول می کنم

45~

46اولی کار تکراری اما قابل تأیید است: افزودن آزمایش‌ها، انتقال تماس‌ها به یک API داخلی جدید، به‌روزرسانی واردات، جایگزینی مؤلفه‌های منسوخ، رفع خطاهای TypeScript. در اینجا نماینده می تواند ساعت ها را ذخیره کند و خطر قابل کنترل است.

47~

48دوم کار اکتشافی است: "این کل کجا محاسبه می شود"، "برای من توضیح دهید که چرا این تست شکننده است"، "اشکال را دوباره تولید کنید و به من بگویید به نظر می رسد کدام فایل ها تحت تاثیر قرار گرفته اند". حتی زمانی که فوراً پچ تولید نمی کند، می تواند شناسایی مفیدی انجام دهد.

49~

50سومین کار تعمیر و نگهداری مکرر است: به‌روزرسانی‌های کوچک وابستگی، پاک‌سازی پرچم‌های ویژگی قدیمی، خلاصه‌ای از PR مسدود شده، بررسی TODO‌های فراموش‌شده. این پر زرق و برق نیست، اما دقیقاً نوعی از کار است که تمایل به انباشته شدن دارد.

51~

52## سه شغلی که من انسان نگه می دارم

53~

54تصمیمات محصول انسانی باقی می ماند. اگر تغییری نحوه پرداخت کاربر را تغییر دهد، داده‌ها را حذف کند، قیمت‌ها را ببیند یا یک مجوز را درک کند، من یک فرد مسئول می‌خواهم.

55~

56مرزهای امنیتی نیز مستحق توجه انسان هستند: اعتبار، نقش ها، نشانه ها، ثبت داده های حساس، انتقال پایگاه داده. یک عامل می تواند به اجرا کمک کند، اما نباید تنها تصمیم گیرنده باشد.

57~

58در نهایت، من هر چیزی را که نیاز به ذوق معماری داشته باشد، نگه می دارم. یک عامل می‌تواند یک Refactor را پیشنهاد کند، اما درک اینکه آیا یک انتزاع واقعاً ضروری است یا اینکه آیا ما فقط مشکلی را که وجود ندارد صیقل می‌دهیم، کار باقی می‌ماند.

59~

60## بررسی اختیاری نیست

61~

62وسوسه، وقتی یک عامل خوب است، اعتماد به سبز CI است. قابل درک است. همچنین زمانی است که مشکلات شروع می شود.

63~

64من همیشه حداقل به پنج چیز نگاه می کنم:

65~

661. آیا پچ فقط وظیفه درخواستی را حل می کند؟

672. آیا او فایل هایی را که ربطی به آن نداشتند، لمس کرده است؟

683. آیا آزمون‌ها رفتار بدیع را پوشش می‌دهند یا فقط شانس خوشحال کننده را؟

694. آیا کد از الگوهای محلی پیروی می کند؟

705. آیا خطاها مانند بقیه پروژه ها رسیدگی می شود؟

71~

72وقتی چیزی اشتباه است، بازخورد باید مشخص باشد. "اصلاحش کن" تنبل است. بهتر: این ابزار `parseMoney` را به `src/lib/money.ts` کپی می کند. دوباره از آن تابع استفاده کنید، یک آزمایش برای مورد EUR اضافه کنید و API عمومی ماژول صورت‌حساب را تغییر ندهید.

73~

74نمایندگان به نظرات کوچک و قابل تأیید بسیار بهتر پاسخ می دهند. عجیب است که مردم هم همینطور.

75~

76## نرده های محافظ ارزش تلاش را دارد

77~

78اگر یک عامل بتواند فایل‌ها را بخواند، کد بنویسد و دستورات را اجرا کند، باید به عنوان یک فرآیند قدرتمند تلقی شود. نیازی به پارانویا نیست، شما نیاز به بهداشت دارید.

79~

80از درخت ها یا شاخه های جداگانه استفاده کنید. بنابراین می‌توانید تفاوت‌ها را مقایسه کنید، آزمایش‌های ناموفق را دور بریزید، و کار عامل را با کاری که انجام می‌دادید مخلوط نکنید.

81~

82محدود کردن مجوزها دستوراتی مانند `rg`، `git diff`، `npm test` و `npm run build` می توانند کاملا رایگان باشند. استقرار، انتقال پایگاه داده، دسترسی به اسرار و دستورات مخرب باید صریح باقی بماند.

83~

84دسترسی به شبکه را زمانی که به آن نیاز ندارید کاهش دهید. برای بسیاری از وظایف، اسناد رسمی، رجیستری بسته و خدمات داخلی خاص کافی است. سطح کمتر، شگفتی های کمتر.

85~

86ردیابی اقدامات هنگامی که یک وصله در حال بررسی قرار می‌گیرد، باید بتوانید دستورات، دستورات اجرا شده، تست‌های پاس شده و فایل‌های اصلاح شده را بازسازی کنید. نه برای ایجاد بوروکراسی، بلکه برای اینکه بتوانیم بفهمیم اگر مشکلی پیش بیاید چه اتفاقی افتاده است.

87~

88## یک راه آسان برای شروع به عنوان یک تیم

89~

90اگر بخواهم عوامل را به یک تیم کوچک معرفی کنم، بدون انقلاب های بزرگ شروع می کنم.

91~

92من یک برچسب `agent-ready` برای مسائل با دامنه واضح ایجاد می کنم. من یک الگو با زمینه، محدودیت ها و دستورات تأیید اضافه می کنم. من می خواهم برای روابط عمومی کوچک، به طور ایده آل زیر چند صد خط. برای تغییرات قابل مشاهده به آزمایش یا اسکرین شات نیاز دارم. و مهمتر از همه، من فردی را مسئول ادغام نگه می دارم.

93~

94بعد از دو هفته به داده‌ها نگاه می‌کردم: کدام کارها واقعاً سریع‌تر شده‌اند، کدام بررسی‌ها سنگین بودند، کدام درخواست‌ها گیج‌کننده بودند، کدام بخش‌های پایگاه کد برای واگذاری آن‌قدر شکننده هستند.

95~

96این رویکردی کمتر تماشایی نسبت به "از امروز همه کارها را با عوامل انجام خواهیم داد" است، اما این رویکردی است که به شما امکان می دهد بدون پشیمانی به هفته سوم برسید.

97~

98## انسانی ترین بخش

99~

100نکته خنده‌دار این است که هرچه عوامل مستقل‌تر شوند، مهارت‌های کلاسیک دوباره اهمیت بیشتری پیدا می‌کنند: نوشتن یک بلیط خوب، ایجاد برش‌های کوچک، ایجاد تست، خواندن تفاوت‌ها، برقراری ارتباط. عامل به کسانی که قبلاً می دانند چگونه خوب کار کنند سرعت می بخشد. همچنین هرج و مرج کسانی را که بد تفویض می کنند، تشدید می کند.

101~

102بنابراین نه، من گردش کار چند عاملی را میانبری برای توقف انجام مهندسی نمی بینم. من آن‌ها را راهی برای انتقال انرژی بیشتر به بخش‌های مهم می‌دانم: تصمیم‌گیری برای ساخت چه چیزی، اطمینان از کارکرد آن، قابل فهم نگه داشتن سیستم.

103~

104نمایندگان می توانند همکاران ناهمزمان عالی بسازند. اما یک همکار ناهمزمان، برای مفید بودن، نیاز به زمینه، مرزها و بررسی دارد. درست مثل بقیه.

105~

106## منابع مفید

107~

108- [Codex برای (تقریبا) همه چیز - OpenAI](https://openai.com/index/codex-for-almost-everything/)

109- [اجرای کدکس با خیال راحت در OpenAI](https://openai.com/index/running-codex-safely/)

110- [معرفی Codex - OpenAI](https://openai.com/index/introducing-codex/)

111- [چیزهای جدید با عامل کدنویسی GitHub Copilot](https://github.blog/ai-and-ml/github-copilot/whats-new-with-github-copilot-coding-agent/)

112~