Quy trình làm việc của Codex và đa tác nhân: làm việc với các tác nhân mà không mất quyền kiểm soát

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

1~
2Lần đầu tiên một nhân viên viết mã thực sự sửa một lỗi cho bạn, phản ứng hầu như luôn giống nhau: sự nhiệt tình xen lẫn sự nghi ngờ. Đẹp, chắc chắn rồi. Nhưng sau đó bạn nhìn vào sự khác biệt và tự hỏi: "Ok, nhưng chính xác thì anh ấy đã chạm vào cái gì? Tôi có thể tin tưởng anh ấy không? Liệu ngày mai anh ấy có làm lại theo cách tương tự không?".
3~
4Đó là nơi tôi nghĩ phần thú vị bắt đầu. Không phải khi tác nhân viết một hàm, mà là khi nó có đủ khả năng để đảm nhận toàn bộ công việc: đọc kho lưu trữ, tạo bản vá, chạy thử nghiệm, mở PR, quay lại sau khi nhận xét đánh giá. Codex đang đi chính xác theo hướng đó: công việc nền, cây công việc riêng biệt, trình duyệt tích hợp, tự động hóa, plugin, bộ nhớ và các biện pháp kiểm soát quyền rõ ràng hơn.
5~
6Vấn đề không phải là tưởng tượng về một tương lai không còn ai đọc mã nữa. Đó sẽ là một tương lai khủng khiếp và khá ngây thơ. Vấn đề là tìm ra cách làm việc với những đại lý có thể làm được nhiều việc mà không để họ làm mọi thứ.
7~
8## Sự thay đổi thói quen
9~
10Với tính năng tự động hoàn thành truyền thống, bạn luôn ở trong tay lái. AI gợi ý một dòng, bạn quyết định. Tuy nhiên, với một người đại diện, mối quan hệ sẽ thay đổi: bạn giao cho anh ta một mục tiêu và anh ta sẽ tự mình thực hiện nhiều bước.
11~
12Điều này có tác dụng mạnh mẽ nhưng nó làm thay đổi vấn đề. Câu hỏi không còn chỉ là “mô hình có thể lập trình được không?”. Câu hỏi trở thành:
13~
14- Tôi đã cho anh ta một phạm vi đủ nhỏ chưa?
15- bạn có biết cách kiểm tra kết quả không?
16- Tôi có đang làm việc trong một môi trường biệt lập không?
17- Việc xem xét cuối cùng vẫn nhân văn và cẩn thận?
18~
19Một quy trình làm việc lành mạnh trông giống thế này hơn là một cây đũa thần:
20~
21```mermaid
22flowchart LR
23    Idea[Nhiệm vụ của con người] --> Scope[Mục đích nhỏ, có thể kiểm chứng]
24    Scope --> Agent[Đại lý trong Worktree bị cô lập]
25    Agent --> Checks[Kiểm tra, tìm lỗi mã nguồn, xây dựng, trình duyệt]
26    Checks --> Review[Đánh giá của con người]
27    Review --> Merge[Hợp nhất hoặc lặp lại mới]
28    Review --> Iterate[Nhận xét chính xác về sự khác biệt]
29    Iterate --> Agent
30```
31~
32Nghe có vẻ kém lãng mạn hơn "người đại diện xây dựng mọi thứ", nhưng nó hoạt động tốt hơn nhiều. Và đó cũng là cách các nhóm hòa hợp với con người làm việc: nhiệm vụ rõ ràng, phản hồi nhanh, trách nhiệm giải trình rõ ràng.
33~
34## Lời nhắc tốt gần như là một tấm vé tốt
35~
36Lời nhắc nguy hiểm nhất là lời nhắc mơ hồ nhưng đầy tự tin: "sửa trang hóa đơn", "cải thiện kiến trúc", "dọn dẹp mô-đun xác thực". Đây là những yêu cầu nghe có vẻ hiệu quả và tạo ra sự khác biệt lớn. Nhưng sau đó bạn thấy mình đang làm khảo cổ học.
37~
38Một lời nhắc hữu ích thì nhàm chán hơn. Ví dụ: triển khai xuất CSV cho trang hóa đơn, biết rằng bảng nằm trong `app/(dashboard)/invoices/page.tsx`, các truy vấn nằm trong `src/server/invoices.ts` và đã có mẫu tương tự trong `app/(dashboard)/reports`.
39~
40Sau đó, thêm các ràng buộc rõ ràng: không thay đổi lược đồ cơ sở dữ liệu, không thêm phần phụ thuộc nếu một tiện ích nhỏ là đủ, giữ nguyên kiểu giao diện người dùng hiện có. Và kết thúc bằng việc xác minh: `npm test -- invoices` và `npm run build`.
41~
42Kiểu tóm tắt này không phải để "giải thích rõ hơn cho AI". Trên hết, nó nhằm mục đích giúp bạn hiểu rõ hơn những gì bạn đang ủy quyền. Nếu bạn không thể viết nó ra một cách cụ thể, có thể nhiệm vụ đó chưa sẵn sàng đối với đại lý.
43~
44## Ba công việc mà tôi sẵn sàng giao phó
45~
46Đầu tiên là công việc lặp đi lặp lại nhưng có thể kiểm chứng: thêm thử nghiệm, di chuyển lệnh gọi sang API nội bộ mới, cập nhật nội dung nhập, thay thế các thành phần không dùng nữa, sửa lỗi TypeScript. Ở đây đại lý có thể tiết kiệm thời gian và rủi ro có thể kiểm soát được.
47~
48Thứ hai là công việc khám phá: "tìm nơi tính tổng số này", "giải thích cho tôi tại sao thử nghiệm này lại dễ hỏng", "tái tạo lỗi và cho tôi biết tệp nào có vẻ bị ảnh hưởng". Ngay cả khi nó không tạo ra bản vá ngay lập tức, nó vẫn có thể thực hiện công việc trinh sát hữu ích.
49~
50Thứ ba là công việc bảo trì định kỳ: cập nhật phần phụ thuộc nhỏ, dọn dẹp các cờ tính năng cũ, tóm tắt các PR bị chặn, kiểm tra các TODO bị quên. Nó không hào nhoáng, nhưng nó chính xác là loại công việc có xu hướng chồng chất.
51~
52## Ba công việc mà tôi giữ làm người
53~
54Các quyết định về sản phẩm vẫn mang tính con người. Nếu một thay đổi làm thay đổi cách người dùng thanh toán, xóa dữ liệu, xem giá hoặc hiểu quyền, tôi cần một người chịu trách nhiệm.
55~
56Các ranh giới bảo mật cũng đáng được con người quan tâm: xác thực, vai trò, mã thông báo, ghi nhật ký dữ liệu nhạy cảm, di chuyển cơ sở dữ liệu. Một tác nhân có thể giúp thực hiện nhưng không nhất thiết phải là người ra quyết định duy nhất.
57~
58Cuối cùng, tôi giữ lại mọi thứ đòi hỏi gu kiến trúc mang tính con người. Một tác nhân có thể đề xuất một trình tái cấu trúc, nhưng việc hiểu liệu sự trừu tượng hóa có thực sự cần thiết hay không hay liệu chúng ta chỉ đang giải quyết một vấn đề không tồn tại vẫn là một công việc.
59~
60## Việc xem xét không phải là tùy chọn
61~
62Sự cám dỗ, khi một đại lý tốt, là tin tưởng vào màu xanh lá cây của CI. Điều đó có thể hiểu được. Đó cũng là lúc vấn đề bắt đầu.
63~
64Tôi luôn xem xét ít nhất năm điều:
65~
661. Bản vá chỉ giải quyết được nhiệm vụ được yêu cầu?
672. Anh ấy có chạm vào những tập tin không liên quan gì không?
683. Các bài kiểm tra có bao gồm hành vi mới lạ hay chỉ là cơ hội may mắn?
694. Mã có tuân theo các mẫu địa phương không?
705. Các lỗi có được xử lý như trong phần còn lại của dự án không?
71~
72Khi có điều gì sai sót, phản hồi cần phải cụ thể. “Sửa nó” là lười biếng. Tốt hơn: tiện ích này sao chép `parseMoney` thành `src/lib/money.ts`; sử dụng lại chức năng đó, thêm thử nghiệm cho trường hợp EUR và không thay đổi API công khai của mô-đun thanh toán.
73~
74Các đại lý phản hồi tốt hơn nhiều đối với những nhận xét nhỏ, có thể kiểm chứng được. Thật kỳ lạ, mọi người cũng vậy.
75~
76## Lan can đáng nỗ lực
77~
78Nếu một tác nhân có thể đọc tệp, viết mã và thực thi lệnh thì nó phải được coi là một quy trình mạnh mẽ. Không cần hoang tưởng, bạn cần vệ sinh.
79~
80Sử dụng cây làm việc hoặc nhánh riêng biệt. Vì vậy, bạn có thể so sánh sự khác biệt, loại bỏ các thử nghiệm thất bại và không trộn lẫn công việc của nhân viên với những gì bạn đang làm.
81~
82Giới hạn quyền. Các lệnh như `rg`, `git diff`, `npm test` và `npm run build` có thể khá miễn phí. Việc triển khai, di chuyển cơ sở dữ liệu, quyền truy cập vào các bí mật và các lệnh phá hoại phải rõ ràng.
83~
84Giảm quyền truy cập mạng khi bạn không cần nó. Đối với nhiều nhiệm vụ, tài liệu chính thức, đăng ký gói và các dịch vụ nội bộ cụ thể là đủ. Diện tích bề mặt ít hơn, ít bất ngờ hơn.
85~
86Theo dõi hành động. Khi một bản vá được xem xét, bạn sẽ có thể xây dựng lại các lời nhắc, lệnh được thực thi, các bài kiểm tra đã vượt qua và các tệp được sửa đổi. Không phải để tạo ra sự quan liêu mà để có thể hiểu được điều gì đã xảy ra nếu có sự cố xảy ra.
87~
88## Một cách dễ dàng để bắt đầu với tư cách là một nhóm
89~
90Nếu tôi giới thiệu các đặc vụ vào một nhóm nhỏ, tôi sẽ bắt đầu mà không có những cuộc cách mạng lớn.
91~
92Tôi sẽ tạo nhãn `agent-ready` cho các vấn đề có phạm vi rõ ràng. Tôi sẽ thêm một mẫu có ngữ cảnh, các ràng buộc và các lệnh xác minh. Tôi sẽ yêu cầu PR nhỏ, lý tưởng nhất là dưới vài trăm dòng. Tôi sẽ yêu cầu kiểm tra hoặc chụp ảnh màn hình để biết những thay đổi rõ ràng. Và trên hết tôi sẽ để một người chịu trách nhiệm về việc sáp nhập.
93~
94Sau hai tuần, tôi sẽ xem xét dữ liệu: tác vụ nào thực sự được tăng tốc, bài đánh giá nào nặng nề, lời nhắc nào khó hiểu, phần nào của cơ sở mã quá mỏng manh để ủy quyền.
95~
96Đó là một cách tiếp cận kém ngoạn mục hơn so với "từ hôm nay chúng tôi sẽ làm mọi thứ với các đại lý", nhưng đó là cách cho phép bạn bước sang tuần thứ ba mà không phải hối tiếc.
97~
98## Phần con người nhất
99~
100Điều buồn cười là các tác nhân càng trở nên tự chủ thì các kỹ năng cổ điển càng trở nên quan trọng: viết một phiếu yêu cầu tốt, thực hiện các bước cắt nhỏ, thực hiện các bài kiểm tra, đọc các điểm khác biệt, truyền đạt sự đánh đổi. Đại lý tăng tốc cho những người đã biết làm việc tốt. Nó cũng khuếch đại sự hỗn loạn của những người giao việc không tốt.
101~
102Vì vậy, không, tôi không coi quy trình làm việc đa tác nhân là lối tắt để ngừng thực hiện kỹ thuật. Tôi coi chúng như một cách để chuyển nhiều năng lượng hơn sang những phần quan trọng: quyết định xây dựng cái gì, đảm bảo nó hoạt động, giữ cho hệ thống dễ hiểu.
103~
104Đại lý có thể trở thành đồng nghiệp không đồng bộ tuyệt vời. Nhưng để một đồng nghiệp không đồng bộ trở nên hữu ích, cần phải có bối cảnh, ranh giới và sự đánh giá. Cũng giống như những người khác.
105~
106## Nguồn hữu ích
107~
108- [Codex cho (gần như) mọi thứ - OpenAI](https://openai.com/index/codex-for-almost-everything/)
109- [Chạy Codex an toàn tại OpenAI](https://openai.com/index/running-codex-safely/)
110- [Giới thiệu Codex - OpenAI](https://openai.com/index/introducing-codex/)
111- [Có gì mới với tác nhân mã hóa 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

2Lần đầu tiên một nhân viên viết mã thực sự sửa một lỗi cho bạn, phản ứng hầu như luôn giống nhau: sự nhiệt tình xen lẫn sự nghi ngờ. Đẹp, chắc chắn rồi. Nhưng sau đó bạn nhìn vào sự khác biệt và tự hỏi: "Ok, nhưng chính xác thì anh ấy đã chạm vào cái gì? Tôi có thể tin tưởng anh ấy không? Liệu ngày mai anh ấy có làm lại theo cách tương tự không?".

4Đó là nơi tôi nghĩ phần thú vị bắt đầu. Không phải khi tác nhân viết một hàm, mà là khi nó có đủ khả năng để đảm nhận toàn bộ công việc: đọc kho lưu trữ, tạo bản vá, chạy thử nghiệm, mở PR, quay lại sau khi nhận xét đánh giá. Codex đang đi chính xác theo hướng đó: công việc nền, cây công việc riêng biệt, trình duyệt tích hợp, tự động hóa, plugin, bộ nhớ và các biện pháp kiểm soát quyền rõ ràng hơn.

6Vấn đề không phải là tưởng tượng về một tương lai không còn ai đọc mã nữa. Đó sẽ là một tương lai khủng khiếp và khá ngây thơ. Vấn đề là tìm ra cách làm việc với những đại lý có thể làm được nhiều việc mà không để họ làm mọi thứ.

8## Sự thay đổi thói quen

10Với tính năng tự động hoàn thành truyền thống, bạn luôn ở trong tay lái. AI gợi ý một dòng, bạn quyết định. Tuy nhiên, với một người đại diện, mối quan hệ sẽ thay đổi: bạn giao cho anh ta một mục tiêu và anh ta sẽ tự mình thực hiện nhiều bước.

11~

12Điều này có tác dụng mạnh mẽ nhưng nó làm thay đổi vấn đề. Câu hỏi không còn chỉ là “mô hình có thể lập trình được không?”. Câu hỏi trở thành:

13~

14- Tôi đã cho anh ta một phạm vi đủ nhỏ chưa?

15- bạn có biết cách kiểm tra kết quả không?

16- Tôi có đang làm việc trong một môi trường biệt lập không?

17- Việc xem xét cuối cùng vẫn nhân văn và cẩn thận?

18~

19Một quy trình làm việc lành mạnh trông giống thế này hơn là một cây đũa thần:

20~

21```mermaid

22flowchart LR

23 Idea[Nhiệm vụ của con người] --> Scope[Mục đích nhỏ, có thể kiểm chứng]

24 Scope --> Agent[Đại lý trong Worktree bị cô lập]

25 Agent --> Checks[Kiểm tra, tìm lỗi mã nguồn, xây dựng, trình duyệt]

26 Checks --> Review[Đánh giá của con người]

27 Review --> Merge[Hợp nhất hoặc lặp lại mới]

28 Review --> Iterate[Nhận xét chính xác về sự khác biệt]

29 Iterate --> Agent

30```

31~

32Nghe có vẻ kém lãng mạn hơn "người đại diện xây dựng mọi thứ", nhưng nó hoạt động tốt hơn nhiều. Và đó cũng là cách các nhóm hòa hợp với con người làm việc: nhiệm vụ rõ ràng, phản hồi nhanh, trách nhiệm giải trình rõ ràng.

33~

34## Lời nhắc tốt gần như là một tấm vé tốt

35~

36Lời nhắc nguy hiểm nhất là lời nhắc mơ hồ nhưng đầy tự tin: "sửa trang hóa đơn", "cải thiện kiến trúc", "dọn dẹp mô-đun xác thực". Đây là những yêu cầu nghe có vẻ hiệu quả và tạo ra sự khác biệt lớn. Nhưng sau đó bạn thấy mình đang làm khảo cổ học.

37~

38Một lời nhắc hữu ích thì nhàm chán hơn. Ví dụ: triển khai xuất CSV cho trang hóa đơn, biết rằng bảng nằm trong `app/(dashboard)/invoices/page.tsx`, các truy vấn nằm trong `src/server/invoices.ts` và đã có mẫu tương tự trong `app/(dashboard)/reports`.

39~

40Sau đó, thêm các ràng buộc rõ ràng: không thay đổi lược đồ cơ sở dữ liệu, không thêm phần phụ thuộc nếu một tiện ích nhỏ là đủ, giữ nguyên kiểu giao diện người dùng hiện có. Và kết thúc bằng việc xác minh: `npm test -- invoices` và `npm run build`.

41~

42Kiểu tóm tắt này không phải để "giải thích rõ hơn cho AI". Trên hết, nó nhằm mục đích giúp bạn hiểu rõ hơn những gì bạn đang ủy quyền. Nếu bạn không thể viết nó ra một cách cụ thể, có thể nhiệm vụ đó chưa sẵn sàng đối với đại lý.

43~

44## Ba công việc mà tôi sẵn sàng giao phó

45~

46Đầu tiên là công việc lặp đi lặp lại nhưng có thể kiểm chứng: thêm thử nghiệm, di chuyển lệnh gọi sang API nội bộ mới, cập nhật nội dung nhập, thay thế các thành phần không dùng nữa, sửa lỗi TypeScript. Ở đây đại lý có thể tiết kiệm thời gian và rủi ro có thể kiểm soát được.

47~

48Thứ hai là công việc khám phá: "tìm nơi tính tổng số này", "giải thích cho tôi tại sao thử nghiệm này lại dễ hỏng", "tái tạo lỗi và cho tôi biết tệp nào có vẻ bị ảnh hưởng". Ngay cả khi nó không tạo ra bản vá ngay lập tức, nó vẫn có thể thực hiện công việc trinh sát hữu ích.

49~

50Thứ ba là công việc bảo trì định kỳ: cập nhật phần phụ thuộc nhỏ, dọn dẹp các cờ tính năng cũ, tóm tắt các PR bị chặn, kiểm tra các TODO bị quên. Nó không hào nhoáng, nhưng nó chính xác là loại công việc có xu hướng chồng chất.

51~

52## Ba công việc mà tôi giữ làm người

53~

54Các quyết định về sản phẩm vẫn mang tính con người. Nếu một thay đổi làm thay đổi cách người dùng thanh toán, xóa dữ liệu, xem giá hoặc hiểu quyền, tôi cần một người chịu trách nhiệm.

55~

56Các ranh giới bảo mật cũng đáng được con người quan tâm: xác thực, vai trò, mã thông báo, ghi nhật ký dữ liệu nhạy cảm, di chuyển cơ sở dữ liệu. Một tác nhân có thể giúp thực hiện nhưng không nhất thiết phải là người ra quyết định duy nhất.

57~

58Cuối cùng, tôi giữ lại mọi thứ đòi hỏi gu kiến trúc mang tính con người. Một tác nhân có thể đề xuất một trình tái cấu trúc, nhưng việc hiểu liệu sự trừu tượng hóa có thực sự cần thiết hay không hay liệu chúng ta chỉ đang giải quyết một vấn đề không tồn tại vẫn là một công việc.

59~

60## Việc xem xét không phải là tùy chọn

61~

62Sự cám dỗ, khi một đại lý tốt, là tin tưởng vào màu xanh lá cây của CI. Điều đó có thể hiểu được. Đó cũng là lúc vấn đề bắt đầu.

63~

64Tôi luôn xem xét ít nhất năm điều:

65~

661. Bản vá chỉ giải quyết được nhiệm vụ được yêu cầu?

672. Anh ấy có chạm vào những tập tin không liên quan gì không?

683. Các bài kiểm tra có bao gồm hành vi mới lạ hay chỉ là cơ hội may mắn?

694. Mã có tuân theo các mẫu địa phương không?

705. Các lỗi có được xử lý như trong phần còn lại của dự án không?

71~

72Khi có điều gì sai sót, phản hồi cần phải cụ thể. “Sửa nó” là lười biếng. Tốt hơn: tiện ích này sao chép `parseMoney` thành `src/lib/money.ts`; sử dụng lại chức năng đó, thêm thử nghiệm cho trường hợp EUR và không thay đổi API công khai của mô-đun thanh toán.

73~

74Các đại lý phản hồi tốt hơn nhiều đối với những nhận xét nhỏ, có thể kiểm chứng được. Thật kỳ lạ, mọi người cũng vậy.

75~

76## Lan can đáng nỗ lực

77~

78Nếu một tác nhân có thể đọc tệp, viết mã và thực thi lệnh thì nó phải được coi là một quy trình mạnh mẽ. Không cần hoang tưởng, bạn cần vệ sinh.

79~

80Sử dụng cây làm việc hoặc nhánh riêng biệt. Vì vậy, bạn có thể so sánh sự khác biệt, loại bỏ các thử nghiệm thất bại và không trộn lẫn công việc của nhân viên với những gì bạn đang làm.

81~

82Giới hạn quyền. Các lệnh như `rg`, `git diff`, `npm test` và `npm run build` có thể khá miễn phí. Việc triển khai, di chuyển cơ sở dữ liệu, quyền truy cập vào các bí mật và các lệnh phá hoại phải rõ ràng.

83~

84Giảm quyền truy cập mạng khi bạn không cần nó. Đối với nhiều nhiệm vụ, tài liệu chính thức, đăng ký gói và các dịch vụ nội bộ cụ thể là đủ. Diện tích bề mặt ít hơn, ít bất ngờ hơn.

85~

86Theo dõi hành động. Khi một bản vá được xem xét, bạn sẽ có thể xây dựng lại các lời nhắc, lệnh được thực thi, các bài kiểm tra đã vượt qua và các tệp được sửa đổi. Không phải để tạo ra sự quan liêu mà để có thể hiểu được điều gì đã xảy ra nếu có sự cố xảy ra.

87~

88## Một cách dễ dàng để bắt đầu với tư cách là một nhóm

89~

90Nếu tôi giới thiệu các đặc vụ vào một nhóm nhỏ, tôi sẽ bắt đầu mà không có những cuộc cách mạng lớn.

91~

92Tôi sẽ tạo nhãn `agent-ready` cho các vấn đề có phạm vi rõ ràng. Tôi sẽ thêm một mẫu có ngữ cảnh, các ràng buộc và các lệnh xác minh. Tôi sẽ yêu cầu PR nhỏ, lý tưởng nhất là dưới vài trăm dòng. Tôi sẽ yêu cầu kiểm tra hoặc chụp ảnh màn hình để biết những thay đổi rõ ràng. Và trên hết tôi sẽ để một người chịu trách nhiệm về việc sáp nhập.

93~

94Sau hai tuần, tôi sẽ xem xét dữ liệu: tác vụ nào thực sự được tăng tốc, bài đánh giá nào nặng nề, lời nhắc nào khó hiểu, phần nào của cơ sở mã quá mỏng manh để ủy quyền.

95~

96Đó là một cách tiếp cận kém ngoạn mục hơn so với "từ hôm nay chúng tôi sẽ làm mọi thứ với các đại lý", nhưng đó là cách cho phép bạn bước sang tuần thứ ba mà không phải hối tiếc.

97~

98## Phần con người nhất

99~

100Điều buồn cười là các tác nhân càng trở nên tự chủ thì các kỹ năng cổ điển càng trở nên quan trọng: viết một phiếu yêu cầu tốt, thực hiện các bước cắt nhỏ, thực hiện các bài kiểm tra, đọc các điểm khác biệt, truyền đạt sự đánh đổi. Đại lý tăng tốc cho những người đã biết làm việc tốt. Nó cũng khuếch đại sự hỗn loạn của những người giao việc không tốt.

101~

102Vì vậy, không, tôi không coi quy trình làm việc đa tác nhân là lối tắt để ngừng thực hiện kỹ thuật. Tôi coi chúng như một cách để chuyển nhiều năng lượng hơn sang những phần quan trọng: quyết định xây dựng cái gì, đảm bảo nó hoạt động, giữ cho hệ thống dễ hiểu.

103~

104Đại lý có thể trở thành đồng nghiệp không đồng bộ tuyệt vời. Nhưng để một đồng nghiệp không đồng bộ trở nên hữu ích, cần phải có bối cảnh, ranh giới và sự đánh giá. Cũng giống như những người khác.

105~

106## Nguồn hữu ích

107~

108- [Codex cho (gần như) mọi thứ - OpenAI](https://openai.com/index/codex-for-almost-everything/)

109- [Chạy Codex an toàn tại OpenAI](https://openai.com/index/running-codex-safely/)

110- [Giới thiệu Codex - OpenAI](https://openai.com/index/introducing-codex/)

111- [Có gì mới với tác nhân mã hóa GitHub Copilot](https://github.blog/ai-and-ml/github-copilot/whats-new-with-github-copilot-coding-agent/)

112~