Đánh giá thực tế khi dùng OpenAI Codex

• OpenAI Codex là agent lập trình đa tác vụ dựa trên tích hợp GitHub, cung cấp giao diện cho phép ra lệnh song song nhiều công việc bằng ngôn ngữ tự nhiên
• Người dùng có thể dồn nhanh khối lượng công việc của cả ngày và giao luôn việc tự động tạo branch cũng như mở PR, đồng thời có thể dùng trên thiết bị di động, nên về lâu dài có thể hỗ trợ quy trình làm việc ưu tiên từ xa
• Tuy vậy hiện tại vẫn có các vấn đề như xử lý lỗi còn kém, chất lượng mã không ổn định, khó cập nhật branch hiện có, sandbox chặn mạng, nên không phù hợp cho các tác vụ refactor quan trọng
• Codex hữu ích cho tự động hóa các tác vụ bảo trì nhỏ, và khá thực dụng trong việc xử lý nhanh các công việc lặp lại
• Nếu sau này có thêm cải tiến mô hình, pha trộn nhiều mô hình, và các tính năng tích hợp nâng cao, nó có thể phát triển thành một công cụ điều phối cấp cao

---

Cách OpenAI Codex hoạt động

• OpenAI Codex có UI dựa trên chat, có thể truy cập qua lời mời hoặc gói Pro $200/tháng
• Người dùng phải trải qua xác thực nhiều bước để phê duyệt ứng dụng Codex GitHub cho từng tổ chức, sau đó Codex sao chép kho mã vào sandbox riêng để thay mặt thực thi lệnh và tạo branch
• Nếu quản lý hàng chục kho mã công khai và riêng tư, hiệu quả chuyển đổi giữa nhiều dự án và quản lý hàng đợi công việc là rất tốt
• Nếu chỉ quản lý 1~2 kho mã, dùng LLM hiện có hoặc trình soạn thảo tích hợp AI có thể là lựa chọn gọn nhẹ hơn

Điểm mạnh của Codex

• Xử lý song song nhiều công việc và giao diện

  • Có thể chỉ định kho mã và branch cho từng công việc, nên luồng đăng ký song song khối lượng việc của cả ngày bằng ngôn ngữ tự nhiên khá tự nhiên
  • Codex khuyến khích cách xử lý nhiều công việc cùng lúc, và điều này rất phù hợp với thói quen làm việc của tác giả

• Quy trình làm việc linh hoạt và hỗ trợ di động

  • Codex hoạt động thân thiện với di động ngay cả trên smartphone, nên có tiềm năng làm việc hiệu quả cả ngoài văn phòng
  • Mục tiêu là một kịch bản sử dụng lý tưởng: đăng ký nhiều việc khi bắt đầu ngày làm việc, rồi tiếp tục quản lý kế hoạch và tiến độ ngay cả khi đang ở ngoài

• Phản hồi qua chat và tạo PR

  • Có thể dễ dàng xem log và trạng thái của công việc đang chạy qua giao diện chat, đồng thời đưa thêm chỉ thị
  • Nếu hài lòng với thay đổi, Codex sẽ tạo Pull Request (sau đây gọi là PR) và tự động hoàn thiện phần mô tả
  • Việc có thể kiểm tra log thực thi và lịch sử lệnh theo từng bước là một điểm tốt

Những điểm cần cải thiện

• Xử lý lỗi chưa đầy đủ

  • Việc thiếu phản hồi rõ ràng trong các tình huống khởi động công việc hoặc tạo PR thất bại làm giảm trải nghiệm sử dụng

• Chất lượng mã và việc thực thi tác vụ một lần

  • Mô hình Codex thuộc dòng GPT-3 và hỗ trợ hơn 12 ngôn ngữ, nhưng khi chạy song song thì mức độ hài lòng chỉ đạt khoảng 40-60%
  • Nó hữu ích cho các tác vụ bảo trì nhỏ, nhưng với refactor quy mô lớn thì việc tạo PR lặp đi lặp lại khiến hiệu quả sử dụng giảm đi

• Không hỗ trợ cập nhật liên tục trong một branch

  • Việc khó liên kết các commit liên tiếp vào PR và branch hiện có khiến các tác vụ refactor nhiều giai đoạn trở nên kém hiệu quả
  • Hiện tại, Codex phù hợp hơn với các công việc đơn giản có thể giao ngay trong một tác vụ đơn lẻ

• Hạn chế truy cập mạng trong sandbox thực thi

  • Do thiết kế có chủ đích, không thể truy cập mạng bên ngoài, nên tồn tại giới hạn với nhiều tác vụ thực tế như cập nhật package hay xử lý dependency
  • Ví dụ: sẽ không hoạt động nếu yêu cầu cài đặt package từ bên ngoài
  • Những việc này vẫn phải tự xử lý cục bộ hoặc tiếp tục dựa vào các bot sẵn có như Dependabot

Did it unlock insane productivity gains for me?

• Tác giả vẫn chưa cảm nhận được mức tăng năng suất bùng nổ
• Để Codex thực sự dẫn tới một bước nhảy vọt về năng suất thì cần
  • cải tiến thiết kế tùy biến và thuật toán để nhiều tác vụ hơn có thể được giải quyết trọn gói trong một lần
  • cải thiện luồng cập nhật PR trên branch hiện có
  • tăng cường năng lực ủy quyền/quản lý tích hợp, đồng thời mở rộng tích hợp với nhiều OpenAI API hơn
  • Codex phải tiến hóa thành một bộ điều phối cấp cao
• Hiện tại Codex đặc biệt hữu dụng cho việc tự động hóa bảo trì thường lệ và các cập nhật nhỏ
• Với phát triển tính năng lớn và refactor quy mô lớn, cách cộng tác cùng IDE và hỗ trợ từ LLM vẫn phù hợp hơn

Final Thoughts

• Codex là một công cụ âm thầm nhưng đáng kỳ vọng
• Xét tới những tính năng sẽ còn được hoàn thiện trong tương lai, nó có khả năng lớn trở thành điểm khởi đầu cho công việc và công cụ điều phối
• Hiện tại là thời điểm phù hợp để tập trung vào các tác vụ nhẹ, lặp lại và chờ đợi các cải tiến tiếp theo

[yangeok]

Có vẻ vẫn chưa đến mức đáng để đốt 200 đô.

[GN⁺]

Ý kiến trên Hacker News

• Tôi là người đăng ký Plus và đã nâng cấp lên Pro để thử Codex, nhưng thành thật mà nói thì trải nghiệm của tôi khá thất vọng
  UX dường như vẫn chưa được định hình ổn, và việc không biết phải chờ bao lâu mới có kết quả cũng khá bực bội
  Nhờ tính chất bất đồng bộ của Codex nên ít ra vẫn có thể chạy nhiều tác vụ cùng lúc
  Một điều tôi không hài lòng nữa là để công cụ này dùng được hữu ích thì phải tự chỉ định môi trường riêng
  Không thể chạy các container cần cho việc kiểm thử nên mức độ hữu dụng giảm đi đáng kể
  Môi trường lại còn bị cô lập hoàn toàn khỏi internet nên khả năng tận dụng bị hạn chế
  Lý do o3 của ChatGPT mạnh là vì nó có thể tự dùng web để tìm kiếm thông tin, còn Codex thì thiếu phần đó
  Nếu so sánh thì tôi cũng hay dùng Claude, và khi tạo project từ repo GitHub làm nguồn, nó tìm ra cả những bug lạ trong các ứng dụng React phức tạp khá tốt
  Gemini cũng hỗ trợ kiểu tính năng này tốt nhờ context window rộng
  Tất nhiên tôi cũng hiểu định hướng mà OpenAI đang nhắm tới
  Tôi muốn Codex thật sự như một đồng nghiệp, có thể nhận nhiều việc và tự giải quyết, nhưng ở thời điểm hiện tại nó cho cảm giác tập trung quá nhiều vào pull request
  Vì vậy tôi đã hạ lại xuống Plus và định chờ thêm một thời gian

  • Tôi nghĩ hỗ trợ container là điều bắt buộc

• Tôi làm ở OpenAI, tuy không thuộc team Codex, nhưng đã có kinh nghiệm dùng Codex thành công trong nhiều dự án
  Cách tôi làm việc là như sau
  Luôn chạy cùng một prompt nhiều lần để tạo ra các kết quả khác nhau
  So sánh nhiều cách triển khai để tìm ra cái tốt nhất, rồi nghĩ xem nếu sửa prompt thế nào thì có thể dẫn tới kết quả tốt hơn
  Những phần model làm sai sẽ được sửa lại ngay trong prompt và áp dụng lặp lại
  Nếu chia công việc thành các đơn vị nhỏ và lặp đi lặp lại các thử nghiệm song song theo cách này, thì ngay cả dự án rất lớn cũng có thể hoàn thành trong vài giờ chỉ bằng việc tinh chỉnh prompt và review code
  Cách này rất hữu ích không chỉ cho các tác vụ chuyển đổi API mà cả với mã sâu như kernel Triton

  • "Chọn cách triển khai tốt nhất trong nhiều phương án, rồi nghĩ xem trong prompt cần thêm gì để dẫn tới kết quả tốt hơn"
    Tôi tò mò người không phải chuyên gia sẽ phân biệt thế nào đâu là cái 'tốt nhất'
    Rốt cuộc để tìm được hướng đi đúng vẫn cần chuyên môn trong lĩnh vực đó, và tôi nghĩ đây là bằng chứng cho thấy LLM chưa thể xóa sổ việc làm của kỹ sư phần mềm

  • Tôi nghĩ cách làm thủ công trực tiếp như vậy thực ra có thể trở thành nền tảng cho học tăng cường (RL)
    Nếu chỉ cần chỉnh UI một chút để dùng trải nghiệm này làm dữ liệu thật, có vẻ sẽ tạo ra được một bộ dữ liệu huấn luyện rất tốt

  • Tôi tò mò cách này thực tế nhanh hơn việc tự viết code bao nhiêu

  • Tôi muốn hỏi khi thay prompt mới mà có thay đổi quan trọng, liệu có khi nào anh bỏ luôn phần công việc đã làm trước đó không
    Nếu chỉ một thay đổi nhỏ mà lại ảnh hưởng lớn tới kết quả, và đó còn là bài toán không có ví dụ sẵn, thì có vẻ sẽ càng khó hơn
    Tôi nghĩ nếu cách làm này lặp lại liên tục thì ngược lại có thể khiến mình mệt hoặc xa rời bản chất vấn đề
    Với tôi nó có thể trông khá kém hiệu quả, nên tôi tò mò liệu người khác có kiên nhẫn hơn với kiểu lặp đi lặp lại này không

• Tôi đã chia sẻ một bài review về Codex trong pod của team tôi (https://latent.space/p/codex)
  Đây là một model cực kỳ giỏi ở việc tạo code liền mạch trong một lần (pod xác nhận nó được fine-tune đặc biệt theo kiểu oneshot cho bài SWE của OpenAI)
  Tương đối thiếu các tính năng tích hợp (ví dụ: không có tích hợp trình duyệt, liên kết GitHub cũng còn yếu — vì nó yêu cầu mở pull request mới ở mỗi iteration nên việc thêm commit tiếp theo vào branch hiện có khá bất tiện và gây khó chịu)
  Dù vậy, tôi kỳ vọng các tính năng tích hợp kiểu này sẽ dần được cải thiện theo thời gian
  Việc có thể chạy đồng thời 60 instance Codex mỗi giờ là một khác biệt về chất so với Devin (đồng thời 5) hay Cursor (trước khi có background agent thì chỉ đồng thời 1)
  Cá nhân tôi không thực sự cảm nhận rõ khác biệt hiệu năng của model Codex, nhưng phía OpenAI mô tả Codex là hậu duệ từ GPT-3, trong khi thực tế nó là một bản fine-tune của o3

  • Tôi nghĩ chính tuyên bố “fine-tune của o3” cũng đủ gây bối rối
    Quy tắc đặt tên của OpenAI cũng dễ gây nhầm lẫn, và đây là vấn đề mà hầu hết công ty AI đều gặp
    Codex ban đầu là một model cũ dựa trên GPT-3, còn giờ thì cùng cái tên đó lại được tái sử dụng ở nhiều nơi như CLI và các công cụ khác
    Google cũng làm tương tự khi dùng “Gemini Ultra” cho cả tên model lẫn tên gói thuê bao, gây ra không ít nhầm lẫn

  • Điều bất tiện nhất với tôi là giới hạn truy cập mạng

    1. không thể git fetch, sync upstream hay sửa lỗi tích hợp
    2. không thể tải thêm thư viện ngoài để thử tích hợp
       Có vẻ họ còn chặn cả domain để apt install cũng không chạy được trong setup script
       Agent cũng có xu hướng cứ lao vào git grep trước thay vì cố nắm ngữ cảnh toàn bộ codebase (thấy rõ trên UI), nên tôi thấy cũng bình thường

  • Tôi tò mò nó khác gì so với Claude Code

• Tôi nghĩ khả năng chỉnh sửa nhanh nhiều repo cùng lúc là thật sự rất tuyệt
  Khi phải quản lý rất nhiều ứng dụng mẫu cùng lúc, việc đổi format README hay sửa link nếu lặp hơn 20 chỗ thì thực sự rất chán
  Nếu có thể giao mấy việc lặt vặt đó cho Codex rồi sau này tôi chỉ cần bấm nút merge thì tôi sẽ rất vui

  • Tôi cũng thấy y hệt
    Tôi đoán nó sẽ sớm tiến tới được như vậy
    Trước mắt có lẽ tôi sẽ dùng Codex để rải các tác vụ bảo trì nhỏ, còn các đợt refactor lớn hay phần phát triển quan trọng thì vẫn tiếp tục làm trong IDE

• Tôi tò mò liệu người không phải lập trình viên có thể dùng kiểu công cụ này để thay đổi code hay không
  Những việc như sửa nội dung hay đổi CSS đơn giản thì tôi thực sự không muốn tự làm, và vì có thể kiểm tra bằng mắt nên chỉ cần tôi review code là đủ
  Người không phải dev có thể xem ticket, bắt đầu làm việc, rồi chỉ cần nói kết quả là "trông ổn đấy", sau đó tôi kiểm tra lại
  Tôi nghĩ đây là workflow lý tưởng cho các bug nhỏ hoặc cải tiến tính năng nhỏ trong backlog

  • Tôi nghĩ các công cụ như AI Assist rốt cuộc có thể trở thành nền tảng low-code tốt nhất
    Tôi cũng mong sẽ có ngày kỹ sư phần mềm thật sự bị thay thế

  • Nhưng ngay cả thay đổi nội dung cũng nhiều khi cần suy nghĩ rất sâu
    Chỉ cần quy mô hơi lớn một chút là đã có phụ thuộc thượng nguồn và hạ nguồn, thêm một field thôi cũng có thể khiến cả hệ thống phải chú ý tới rất nhiều thứ
    Những thay đổi nhỏ kiểu CSS trông thì đơn giản, nhưng người dùng thực ra khó biết nó nhỏ tới mức nào

  • Các vấn đề như khả năng truy cập, đa nền tảng (mobile/desktop) và vô số chuyện khác cũng sẽ sớm phải học rất nhanh
    Thậm chí toàn bộ xu hướng này còn giống như một cái phễu đưa mọi người “đi vào” nghề kỹ sư phần mềm

• Với các tác vụ nhỏ, tôi nghĩ tỷ lệ thành công 40~60% đã là khá ổn
  Việc nó gặp khó ở những tác vụ phức tạp hơn, cần logic sâu hơn cũng là thông tin hữu ích để tham khảo

  • Theo tiêu chuẩn test của tôi, chỉ cần tác vụ đòi hỏi một chút tư duy phản biện thôi là Codex đã hoàn toàn lạc hướng
    Hiệu năng ở thời điểm này chỉ ở mức một kỹ sư junior rất tệ
    Ví dụ khi được yêu cầu chỉnh sửa, để xóa cảnh báo của compiler nó đã đổi hàng loạt giá trị của class thành nullable
    Bề ngoài thì vẫn chạy và compile được, nhưng đó là kết quả hoàn toàn sai vì làm mất luôn tính toàn vẹn dữ liệu
    Những trường hợp như vậy khá nhiều
    Nếu giao cả codebase cho Codex mà không giám sát thì tôi nghĩ technical debt sẽ tích tụ rất nhanh

• Kỳ vọng rằng Codex sẽ giúp chúng ta làm việc tốt trong khi mình vắng mặt nghe có vẻ quá lạc quan
  Với nhiều người, cái gọi là "làm việc hiệu quả dù mình không có mặt" thực chất lại rất gần với "hàng người thất nghiệp"

  • Bản thân việc các lập trình viên lại hào hứng với thay đổi này đã là điều lạ với tôi
    Tôi ngạc nhiên trước bầu không khí như thể một ngày nào đó chúng ta chỉ việc ngồi nhìn agent làm hết mọi thứ rồi vẫn được trả tiền
    Dù công việc có dễ hơn đi nữa, cuối cùng nó vẫn có thể đi theo hướng là chính việc làm đó biến mất

  • Trong lịch sử tăng năng suất, hầu như chưa từng có tiền lệ người lao động được hưởng thêm nhiều thời gian rảnh
    Kết cục thường là lợi nhuận cho cổ đông và lãnh đạo tăng lên, khối lượng công việc của số nhân viên còn lại tăng gấp đôi, còn phần còn lại thì thất nghiệp

  • Tôi nghĩ từ giờ đến lúc thất nghiệp hàng loạt vẫn còn cần thêm thời gian
    Để những model kiểu này thật sự xử lý đúng một dải công việc rộng ở mức 90~95% sẽ cần nỗ lực khổng lồ
    Cái gì cũng vậy, 60~70% đầu tiên thì dễ nhưng 5~10% cuối cùng mới là phần thật sự khó
    Như đã nói ở trên, việc chạy nhiều lần để lấy nhiều kết quả rồi chọn lọc hiện tại tốn kém hơn hẳn, và nếu áp dụng đồng loạt cho mọi việc thì chi phí suy luận cũng là vấn đề lớn
    Đến một thời điểm nào đó, code review sẽ càng trở nên bắt buộc nếu đó là code do máy tạo ra
    Với các dự án nhỏ hay tính năng quy mô nhỏ thì có thể tin vào phần việc của máy, nhưng với codebase cần duy trì lâu dài thì con người vẫn sẽ phải tiếp tục làm thiết kế kiến trúc và kiểm tra
    AI có thể giúp khám phá nhiều phương án nhanh hơn, nhưng quyết định cuối cùng vẫn là của con người, và chất lượng vẫn phải được giữ bằng thiết kế hoặc review trực tiếp
    Trong tương lai gần, có vẻ các team kỹ thuật sẽ tìm cách tận dụng tích cực các background agent
    Tôi hoài nghi cách làm kiểu giao phó toàn bộ như hiện nay cho một model mạnh
    Công việc review code bằng AI hiện khá bực bội nên cần workflow tốt hơn
    Trong vài năm tới, bản thân “background agent” sẽ trở thành hạ tầng bắt buộc ở từng công ty
    Phần lớn công ty có lẽ sẽ không tự host hạ tầng agent này mà sẽ dùng qua API
    Hạ tầng kỹ thuật cho agent-based engineering vẫn đang ở giai đoạn cực kỳ sơ khai nên cũng sẽ xuất hiện rất nhiều cơ hội việc làm mới (trong 3~5 năm tới)

  • Nếu nhìn lạc quan, thì khi làm ra thứ gì đó rẻ hơn (ví dụ: code), nhu cầu dành cho nó đôi khi lại tăng lên
    Có thể người không phải dev sẽ đóng vai trò quản lý, nhưng thực tế tôi thấy càng là việc quan trọng thì con người càng muốn giao cho người đáng tin cậy hơn (tức là con người)

  • Tôi nghĩ có thể ví lập trình viên phần mềm là ngựa, còn các agent model mới như Codex hay Claude Code là ô tô
    Có lẽ khung nhìn đúng sẽ là: một số con ngựa trở thành người lái ô tô, còn một số khác thì không còn phải kéo xe nữa nên trở thành thất nghiệp

• Tôi không tìm thấy nơi nào tổng hợp danh sách ngôn ngữ được hỗ trợ
  Trong phần giới thiệu chính thức hay các bài review cũng không thấy ghi rõ, đa số chỉ giải thích bằng ví dụ như sửa lỗi chính tả trên web

• Trông có vẻ là thứ có thể làm nhanh bằng gptel-tool chỉ trong một tuần

[horace]

Nếu dùng như một người làm công thì khá ổn!