Codex-Maxxing: Biến AI thành trợ lý đắc lực cho lập trình và quản lý công việc

Codex-Maxxing là thuật ngữ mô tả việc tối ưu hóa việc sử dụng OpenAI Codex vượt ra ngoài giới hạn của một công cụ lập trình thông thường. Trước đây, tôi chủ yếu sử dụng các tác nhân AI (coding agents) để tạo diff, thay đổi kho lưu trữ (repo) và triển khai mã nguồn. Tuy nhiên, kể từ tháng 11, tôi bắt đầu đẩy chúng vào các công việc tri thức khác như tạo bài thuyết trình trên Slidev, ghi chú bằng giọng nói và sản xuất các tài liệu khác như PDF, bảng tính hay slide deck.

Bản nâng cấp ứng dụng Codex gần đây là thứ đầu tiên tôi sử dụng khiến chế độ làm việc rộng lớn này cảm thấy tự nhiên. Codex vẫn xuất sắc cho việc viết code, nhưng sự thay đổi thú vị hơn là nó mang lại cho công việc của tôi một nơi để "sống". Điều thay đổi hành vi của tôi là học cách cung cấp cho công việc một vòng lặp vận hành (operating loop): một luồng hội thoại bền vững, bộ nhớ chia sẻ, các công cụ có thể tác động lên máy tính, cách điều hướng và tiếp tục nhiệm vụ, cũng như một giao diện để tôi xem xét kết quả.

Luồng hoạt động bền vững (Durable Threads)

Yếu tố đầu tiên thay đổi hành vi của tôi là tính năng "Compaction" (nén dữ liệu). Đây là quá trình nén một luồng hội thoại dài để nó có thể tiếp tục mà không cần mang theo mọi tin nhắn cũ. Hiện tại, tôi duy trì một luồng ghim (pinned thread) cho mọi luồng công việc quan trọng: luồng Trưởng ban Nhân sự (Chief of Staff), Agents SDK, OpenAI CLI, Codex cho mã nguồn mở và một luồng để giám sát Twitter.

Đây không phải là các cuộc trò chuyện ngắn. Chúng là những "megathreads" mà tôi đã nén trong nhiều tháng. Chúng tích lũy lịch sử, sở thích và các quyết định cũ mà tôi không muốn tạo lại mỗi khi quay lại. Tuy nhiên, có một sự đánh đổi. Các luồng dài hạn không miễn phí. Nếu bạn truy cập lại chúng sau này, cuộc trò chuyện có thể không còn trong bộ nhớ cache, dẫn đến chi phí cao hơn so với một luồng ngắn mới. Nhưng với những công việc quan trọng, tính liên tục là xứng đáng.

Đầu vào giọng nói và Điều hướng (Voice Input & Steering)

Đầu vào giọng nói giúp đưa nhiều suy nghĩ thực tế của tôi vào Codex hơn. Lợi ích không phải là tốc độ, mà là tác nhân nhận được phiên bản chưa qua chỉnh sửa của suy nghĩ tôi. Codex có đầu vào giọng nói tích hợp, nhưng tôi cũng sử dụng Wispr Flow vì tính năng chép âm toàn hệ thống thay đổi lượng ngữ cảnh tôi có thể cung cấp cho mọi thứ.

Ví dụ, khi lên kế hoạch cho một công việc, tôi có thể nói: "Tôi nhớ có một tên Ben nào đó trên Slack đã nhắc đến việc này, tôi không nhớ chính xác là gì, chỉ cần đi xem thôi." Câu này quá mơ hồ và khó chịu để gõ, nhưng hoàn toàn tự nhiên để nói.

Tính năng "Steering" (điều hướng) trở nên hữu ích hơn khi kết hợp với giọng nói. Steering cho phép bạn thêm hướng dẫn trong khi Codex đang làm việc thay vì đợi bước hiện tại hoàn tất. Nếu tôi đang xem xét một trang web, tôi có thể tiếp tục nói trong khi nhìn vào nó: "làm cái này nhỏ hơn đi", "nội dung này sai rồi", "khoảng cách giữa hai thứ này cảm thấy không ổn"... Tôi không cần đợi từng bước hoàn tất trước khi quyết định bước tiếp theo.

Bộ nhớ (Memory)

Khi các luồng bắt đầu kéo dài hơn, chúng cần bộ nhớ chia sẻ bên ngoài bất kỳ repo nào. Bước đi quan trọng không chỉ là bảo toàn lịch sử tin nhắn. Một luồng dài có thể nhớ nhiều điều, nhưng bộ nhớ đó bị mắc kẹt trong luồng trừ khi các phần hữu ích được tuần tự hóa ở đâu đó bền vững.

Mục đích của hệ thống bộ nhớ là biến những gì luồng học được thành một tạo tác (artifact) mà tôi có thể kiểm tra, chỉnh sửa, so sánh diff và tái sử dụng. Hầu hết các luồng dài hạn của tôi bắt đầu trong một kho lưu trữ Obsidian (vault) với cấu trúc thư mục rõ ràng. Kho lưu trữ là nơi tác nhân sống, tách biệt với bất kỳ dự án cụ thể nào. Các repo chứa mã nguồn, còn vault chứa ngữ cảnh xoay quanh công việc của tôi: con người, quyết định, các vòng lặp mở, ghi chú hàng ngày và trạng thái dự án.

Tôi cũng giữ vault dưới dạng một GitHub repo. Điều này mang lại cho tôi hai thứ: nó có thể hoạt động trên đám mây và các diff trở thành bề mặt xem xét cho bộ nhớ. Khi tác nhân cập nhật vault, tôi có thể đọc diff và xem nó nghĩ điều gì đủ quan trọng để nhớ.

Sử dụng Máy tính và Trình duyệt (Computer and Browser Use)

Khi một luồng có bộ nhớ, câu hỏi tiếp theo là nó có thể chạm vào cái gì. Sự phân biệt hữu ích nhất trong đầu tôi là:

• $browser: dành cho các bề mặt web cục bộ tôi muốn kiểm tra và chú thích.
• @chrome: dành cho trạng thái trình duyệt đã đăng nhập và nhiều tab.
• @computer: dành cho công việc chỉ tồn tại dưới dạng GUI.

Nếu tôi đang lặp lại trên một ứng dụng cục bộ, tôi muốn $browser. Nếu tôi cần làm việc trong phiên trình duyệt đã đăng nhập, tôi muốn @chrome. Nếu cách duy nhất để thực hiện tác vụ là nhấp qua ứng dụng desktop, tôi muốn @computer.

Điều khiển từ xa và Heartbeats

Tính năng "Remote control" (điều khiển từ xa) khiến các vòng lặp dài này cảm thấy di động hơn. Codex có thể tiếp tục làm việc từ máy tính nơi các tệp, quyền hạn và thiết lập cục bộ của bạn đã tồn tại, trong khi bạn kiểm tra từ điện thoại, xem xét những gì nó tìm thấy, trả lời câu hỏi hoặc phê duyệt bước tiếp theo.

"Heartbeats" (nhịp đập) là thứ khiến các luồng ghim lặp lại. Một Heartbeat là tự động hóa cục bộ trong luồng. Bạn có thể nói, "giữ mắt trên cái này mỗi vài giờ", và luồng có thể tự lên lịch. Một luồng có thể có nhiều lịch trình, chạy cho đến khi một điều kiện nào đó được đáp ứng và điều chỉnh nhịp độ của nó theo thời gian.

Ví dụ, luồng "Trưởng ban Nhân sự" của tôi chạy mỗi 30 phút để kiểm tra Slack và Gmail tìm các tin nhắn chưa trả lời cần sự chú ý của tôi, giúp tôi ưu tiên những gì quan trọng nhất và soạn thảo câu trả lời.

Mục tiêu (Goals)

Tính năng mới nhất mà tôi vẫn đang học cách sử dụng tốt là "Goals" (Mục tiêu). Bạn nên tham vọng với chúng. Một mục tiêu yếu là "triển khai kế hoạch trong tệp Markdown này". Một mục tiêu mạnh có tiêu chí thành công thực tế mà tác nhân có thể hướng tới.

Ví dụ, gần đây tôi đã thử di chuyển thư viện Python Rich sang Rust. Vì dự án gốc đã có bộ kiểm tra đơn vị (unit test) lớn, tôi có thể đặt mục tiêu: di chuyển Rich sang Rust, nhưng nó phải vượt qua tất cả các bài kiểm tra đơn vị từ thư viện gốc. Bộ kiểm tra đó cung cấp một "người tiên tri" thực sự: bản port Rust chưa hoàn thành cho đến khi nó vượt qua các bài kiểm tra giống như thư viện Python.

Bảng điều khiển bên (Side Panel)

Phần của Codex mà tôi hào hứng nhất là bảng điều khiển bên (side panel). Dễ dàng nghĩ rằng đây là nơi diễn ra các bản xem trước, nhưng điều đó chưa đủ. Bảng điều khiển bên là nơi Codex ngừng chỉ là một ứng dụng trò chuyện và bắt đầu trở thành nơi công việc diễn ra. Đối với tôi, nó thực hiện ba công việc: kiểm tra tạo tác, vận hành bề mặt web và xem xét các thay đổi.

Markdown, bảng tính, CSV, PDF và slide đều có thể sống ở đó. Điều quan trọng không chỉ là Codex có thể tạo ra tạo tác, mà là tôi có thể kiểm tra và chú thích chúng mà không làm gián đoạn vòng lặp. Trình duyệt trong ứng dụng thậm chí còn thú vị hơn. Tác nhân có thể nhìn thấy nó, kiểm soát nó bằng JavaScript thông qua $browser, và tôi có thể để lại chú thích trực tiếp lên những gì tôi đang nhìn.

Tôi thường yêu cầu mô hình tạo một tệp index.html duy nhất với JavaScript và CSS, mở nó trong bảng điều khiển bên và bắt đầu tương tác ngay lập tức. Không cần máy chủ. Khi đầu ra là một ứng dụng nhỏ thay vì chỉ là một tài liệu, mối quan hệ thay đổi. Codex ngày càng có thể gặp gỡ chúng ta ở những nơi chúng ta sống. Càng nhiều nơi Codex có thể ghi nhớ, truy cập lại, kiểm tra và hành động, công việc của tôi càng ít bị "chết" giữa các lần nhắc lệnh.