Code bằng Codex từ điện thoại, với Mac Studio, Notion và Todoist

1. Máy chạy bộ thành chỗ làm việc

Brian Morrison mở video bằng một cảnh quay trong tầng hầm. Anh nói rằng nhờ AI, đây thật ra là nơi anh làm được phần lớn công việc của mình dạo gần đây (theo video đăng ngày 12/10/2026), và trong video này anh sẽ cho xem anh làm điều đó như thế nào.

Anh xin bỏ qua chuyện tầng hầm đang bừa bộn, rồi nói rõ hơn: chiếc máy chạy bộ thật ra là nơi anh làm được rất nhiều việc cho các side project của mình dạo này. Lý do anh đưa ra là Codex có một tính năng mà anh gọi là "thực sự rất hay": bạn có thể dựng một remote environment để làm trung tâm cho toàn bộ việc phát triển phần mềm của mình (theo Brian, video đăng ngày 12/10/2026). Và đó đúng là điều anh đã làm, với một chiếc Mac Studio.

2. Một Mac Studio làm trung tâm, cộng Notion và Todoist

Brian kể setup của mình (video đăng ngày 12/10/2026): chiếc Mac Studio được nối với Codex. Anh có thể mở project mới thẳng từ Codex, trên điện thoại hay trên máy tính, anh tự sửa lại là desktop hay laptop, rồi kết nối với các folder và project đang chạy hoặc đang lưu local trên chiếc Mac Studio đó. Sau đó, theo lời anh, về cơ bản Codex làm mọi thứ cho anh mỗi khi anh ra một lệnh.

Bên trên lớp đó, anh còn dựng một hệ thống làm việc mà anh gọi là "khá hay", nối Codex với Notion và Todoist (theo Brian, video đăng ngày 12/10/2026). Mục đích có hai phần. Thứ nhất là để mọi việc được ghi lại nhanh và được bắt tay làm nhanh. Thứ hai là để anh có những bước hành động cụ thể (actionable steps) trong Todoist, nhằm chắc chắn rằng công việc trên các project thật sự đang tiến lên đúng cách.

Anh giải thích vì sao cần điều đó: phải thừa nhận là cuộc sống bận rộn. Và đôi khi những thứ nho nhỏ mình build bên lề cứ thế trôi dần sang một bên. Theo Brian, đây là một setup và một cách làm rất tốt giúp anh tránh chuyện đó, trong khi vẫn luôn làm việc được trên các thứ của mình một cách hiệu quả (video đăng ngày 12/10/2026).

3. Làm việc từ hàng chờ, từ trong xe, trên đường mòn

Brian nói máy chạy bộ chỉ là một ví dụ. Anh kể (video đăng ngày 12/10/2026) rằng anh đã từng đứng xếp hàng ở cửa hàng, ở siêu thị, gõ lệnh vào Codex để nó tiếp tục làm việc trên các app của anh trong khi anh đang đi làm việc khác. Anh đã làm việc đó từ trong xe, rồi anh nói rõ thêm: không phải lúc đang lái. Anh cũng đã thử khi đang đi bộ trên những con đường mòn và những chỗ tương tự. Anh nhận xét: "khá là hay".

Từ đó anh chuyển vào phần chính: đi qua workflow của mình và cho xem cách anh dựng toàn bộ chuyện này. Anh nói mong người xem có thể rút ra được vài ý về cách dùng một số kỹ năng hoặc kỹ thuật này để nâng cấp môi trường phát triển theo kiểu agentic workflow của chính mình.

4. Kiến trúc: Mac Studio headless chạy Codex server

Brian tả kiến trúc (video đăng ngày 12/10/2026): trong home lab của anh có một chiếc Mac Studio chạy headless, và trên đó chạy Codex server. Bên trong chiếc Mac Studio, anh có các folder riêng chứa toàn bộ repository của mình, mỗi folder là một project.

Cách workflow chạy như sau, theo Brian (video đăng ngày 12/10/2026). Trên điện thoại, anh mở Codex và gửi một tin nhắn cho Codex trong repository, hay trong chat làm việc đang nối với repository đó. Codex sẽ tự khởi động và cố gắng thực hiện mọi thay đổi: phân tích code, làm tất cả những gì nó cho là cần để implement feature cụ thể đó.

5. Một vòng làm việc, từ điện thoại tới Notion, Todoist rồi quay lại

Khi đã xong phần code, theo cách Brian đã cài (video đăng ngày 12/10/2026), Codex sẽ gọi sang Notion để cập nhật trạng thái của các work item trong một database anh ghi ở đó. Nếu có việc gì cần anh làm thủ công để đẩy việc tiến lên, nó sẽ tạo thêm một mục trong Todoist của anh. Cuối cùng, khi mọi thứ đã xong, nó báo lại về điện thoại: nó đã làm chính xác những gì, cái gì đã sẵn sàng, và anh có thể cần làm gì để các project cá nhân tiếp tục tiến lên.

Anh nói người xem sẽ thấy trực tiếp trong Notion, nhưng về cơ bản có ba database anh dùng để theo dõi toàn bộ chuyện này (setup trong video đăng ngày 12/10/2026).

6. Ba database trong Notion và cách chúng nối với nhau

Ba database đó, theo Brian (video đăng ngày 12/10/2026):

• Products: chứa thông tin về chính project anh đang làm (theo Brian, video đăng ngày 12/10/2026).
• Work items: được Products link tới; một work item có thể coi như một ticket kiểu những ticket người ta ghi trong Linear hay JIRA (theo Brian, video đăng ngày 12/10/2026).
• Releases: chứa thông tin về một bản phát hành cụ thể, cộng thêm những thứ như các gạch đầu dòng anh muốn gửi đi trong một số newsletter, hay test plan trước khi thật sự ship, để anh đi qua và test mọi bề mặt của app (theo Brian, video đăng ngày 12/10/2026).

Ba database này nối qua lại với nhau như sơ đồ anh đưa lên màn hình (setup trong video đăng ngày 12/10/2026). Một project chứa nhiều work item. Nó cũng chứa nhiều release. Nhưng mỗi work item chỉ nên được link tới một release duy nhất.

Theo Brian (video đăng ngày 12/10/2026), cách nối này giúp anh giữ một vòng lặp chặt chẽ giữa cả ba database, để chúng phối hợp với nhau và đẩy các project của anh tiến lên.

7. Products database: danh sách mọi thứ đang làm

Để cụ thể hơn, Brian mở Products database trong Notion. Theo lời anh (video đăng ngày 12/10/2026), đây là nơi anh liệt kê mọi thứ anh đang làm, hoặc có thể sẽ bắt đầu làm trong thời gian tới. Đó là các project và product khác nhau. Không phải tất cả đều là sản phẩm anh định đem ra thị trường và bán, nhưng đây là một nền tảng tốt, liệt kê tất cả những thứ anh đang làm, những thứ đã ship, và những thứ tương tự.

Trên màn hình, bảng Products có các view Products, Board, Backlog, Shipped, và các cột Status, Kickoff date, Days since kickoff, Days to MVP, Launch date, Days since launch, Type. Các dòng gồm Agree on a Time, Coalesce Health, Daily Reps, GuardianForge, Kaizen Pulse, Waystone và WishPin, với các trạng thái như Shipped, In progress, Up next, Spinning down, và loại Mobile app, Web app hoặc Internal app (màn hình trong video đăng ngày 12/10/2026).

8. Tài liệu sản phẩm bên trong mỗi product

Brian mở một dòng để cho xem bên trong. Theo lời anh (video đăng ngày 12/10/2026), mỗi document ở đây chứa kiểu như product design document hay product requirements document của sản phẩm đó: tech stack, cấu trúc sản phẩm. Với một số product còn có thêm chi tiết về target audience, app làm gì và được build cho ai.

Anh giải thích lý do giữ những chi tiết đó: chúng có thể được agent dùng để giúp anh nghĩ ra kế hoạch marketing, và để tính xem anh muốn tinh chỉnh, tối ưu chính app đó thế nào cho hợp với target audience (theo Brian, video đăng ngày 12/10/2026).

9. Work items: board kanban, outcome, acceptance criteria, test plan

Products database được link tới Work items. Brian cho xem Work items database, dựng dưới dạng một board. Anh nói anh thích board kanban vì đó là một dòng chảy dễ chịu (a nice flow), dù thú thật là các agent quản lý phần lớn chỗ này giúp anh, và anh thậm chí không vào đây xem thường xuyên (theo Brian, video đăng ngày 12/10/2026). Nhưng anh thích cấu trúc này và thích việc dựng mọi thứ như vậy.

Anh đã mở sẵn một item: "Native feedback management MVP". Theo lời anh (video đăng ngày 12/10/2026), item này giải thích outcome là gì, mục tiêu là gì, phạm vi MVP. Nó có acceptance criteria, để các agent biết khi nào thì việc được coi là xong. Và cuối cùng là một bản phác thảo test plan cho lúc item đã được implement, để anh quay lại kiểm tra xem agent đã làm đúng những gì nó phải làm hay chưa.

Trên màn hình, phần Outcome của item ghi mục tiêu thay Featurebase bằng tính năng quản lý feedback native, có xác thực; MVP scope liệt kê các phần như component Convex lo requests, votes và messages, app iOS cho vận động viên tạo request và vote, và một dashboard Next.js cho admin; Acceptance criteria có những dòng như "Non-admin dashboard visitors cannot read the feedback queue."; Test plan là bốn ô checkbox (màn hình trong video đăng ngày 12/10/2026).

10. Needs manual work, assignee và Hermes

Brian nói board này thật ra được chia theo hai cách, và đây là một trong những chỗ anh vẫn đang lưỡng lự, chưa chốt (video đăng ngày 12/10/2026). Anh có hai phần trên board.

Phần thứ nhất là "Needs manual work", về bản chất chỉ là một checkbox trong mỗi item. Theo Brian (video đăng ngày 12/10/2026), nó là một cái cờ để báo cho chính anh, hoặc cho cả hệ thống, rằng một con người phải tương tác với item này theo cách nào đó.

Anh mở rộng danh sách ra cho xem thêm: có assignee là Brian. Anh cũng có Hermes, theo lời anh là một thứ anh đang làm ở phía sau (video đăng ngày 12/10/2026). Trên board, một số item mang nhãn Hermes thay vì Brian.

11. Releases: release notes, test plan và vòng lặp với TestFlight

Quay lại với Work items, Brian nhắc lại luồng anh đã phác ở trên (setup trong video đăng ngày 12/10/2026): một khi một ticket được làm, nó sẽ được đẩy qua các bước của pipeline trên board. Nhưng ngoài ra, ticket còn được gắn vào version đang được làm cho một app cụ thể, tức là vào Releases.

Theo Brian (video đăng ngày 12/10/2026), vì anh đặt các rule bên trong repository theo một cách cụ thể, nên agent hiểu workflow của anh và biết cách dùng những database này. Agent cũng sẽ tự động tạo release notes, và tạo một test plan đầy đủ cho version đó. Khi anh build app và ship lên TestFlight, nơi anh làm QA, test plan này sẽ dẫn anh đi qua mọi thứ có thể đã thay đổi trong app và những gì anh cần làm để chắc chắn mọi thứ đã được sửa.

Anh thêm rằng nếu bạn build một web application thì có thể làm việc này trên một feature branch hay một feature deployment branch, hoặc trong một môi trường QA chuẩn hoá (theo Brian, video đăng ngày 12/10/2026).

Theo lời anh (video đăng ngày 12/10/2026), cách này cho anh một vòng feedback chặt: agent làm một việc, ship lên TestFlight, anh test và đảm bảo nó chạy khi mọi thay đổi đã vào. Rồi anh có thể qua lại với agent để sửa những chỗ chưa chạy đúng.

Brian nói màn hình này không cho thấy, nhưng ở các version đang làm anh cũng đã cài để hiện phần cập nhật cho App Store (video đăng ngày 12/10/2026). Như vậy, khi đã sẵn sàng phát hành lên App Store, các gạch đầu dòng cập nhật đã được chuẩn bị sẵn để anh chỉ việc điền vào.

12. Todoist làm nơi ghi những việc người phải làm

Cuối cùng, Brian nói về một phần mở rộng anh đang làm (video đăng ngày 12/10/2026). Thay vì để mọi việc anh phải tự làm bị gom chung hay bị chôn trong các work item trên Notion, Codex đã được dặn rằng nếu có việc gì anh cần làm, hãy tạo một work item, hay đúng hơn là một mục to-do, trong Todoist của anh.

Vì vậy, theo Brian, thực tế Todoist trở thành nơi ghi chính thức (point of record) những việc anh phải làm để các app tiếp tục có tiến triển, để chắc rằng khi cộng tác với agent thì các project anh đã quyết định theo đuổi vẫn đang tiến lên (video đăng ngày 12/10/2026).

Đến đây người xem đã thấy setup trong Notion trông như thế nào. Brian chuyển sang điện thoại và quay màn hình, để cho xem thực tế quá trình implement hoặc sửa một trong những việc mà anh biết mình cần làm trên Coalesce, app mới anh đang chuẩn bị ship (theo video đăng ngày 12/10/2026).

13. Demo: Coalesce và readiness indicator

Brian giới thiệu Coalesce là app anh đã làm trong vài tháng qua (tính đến video đăng ngày 12/10/2026). Một trong những thứ anh muốn thử là readiness indicator ở góc trên bên phải màn hình, chỉ để báo cho người dùng biết hôm nay cơ thể họ sẵn sàng tới đâu cho bất kỳ kiểu vận động nào.

Anh nói anh có thích kiểu chỉ hiện con số thuần, nhưng anh muốn xem nếu nó là một radial dial, một thanh tiến trình dạng vòng tròn thay vì chỉ có con số, thì trông sẽ thế nào.

Trong Notion, anh đã tạo sẵn work item cho việc này, đang nằm ở backlog. Trên màn hình là trang "Convert Today header RPE to circular progress indicator" với ID là WI-814 (demo trong video đăng ngày 12/10/2026). Brian thừa nhận anh không dùng cái số đó thường xuyên lắm, chủ yếu anh chỉ dùng link. Item có outcome và acceptance criteria, và theo lời anh, tất cả đều được tạo ra từ một cuộc trò chuyện trước đó với Codex (video đăng ngày 12/10/2026). Anh copy link của item.

14. Giao việc cho Codex từ ChatGPT trên điện thoại

Sang Codex. Brian chỉ ra rằng anh đang ở trang chính và không điều hướng tới đâu cả. Nếu vuốt sang trái, anh có thể chọn Codex (demo trong video đăng ngày 12/10/2026). Trên màn hình, menu bên của app ChatGPT có các mục Library, Projects, Plugins, Scheduled, Codex và Explore.

Theo Brian, anh có một loạt chat và project khác đã nối sẵn ở đây (demo trong video đăng ngày 12/10/2026). Anh tạo một chat mới cho Cross Train, tên mã của Coalesce, theo lời anh. Anh chỉ gõ "work on this item", chen thêm một câu "nếu tôi đánh vần được", dán link work item vào rồi bấm gửi, và chờ xem nó làm gì.

Brian nói sau khi làm việc vài phút, nó đã tìm ra context, xác định được chỗ trong app mà ticket nhắc tới, và sẽ bắt đầu lên kế hoạch cho các thay đổi còn lại trong code (demo trong video đăng ngày 12/10/2026). Trên màn hình, dòng trạng thái ghi "Working for 2m 7s". Codex viết rằng nó sẽ đọc work item và product context, rồi cập nhật phần Today header trên nhánh dev và kiểm tra trên điện thoại; nó ghi "Explored 5 files, 7 searches, 1 list", rồi giải thích nhãn "RPE" của ticket ứng với readiness score sẵn có trong Today header, không có giá trị RPE riêng, nên nó giữ nguyên điểm đó, biến thành một vòng 0–100, và giữ nhãn VoiceOver chi tiết cùng hành vi chạm để xem thêm.

15. Codex đẩy bản development build lên điện thoại

Đến đây, màn hình nhảy sang app Coalesce. Brian giải thích (demo trong video đăng ngày 12/10/2026): đó là vì một trong những rule anh đặt trong project repository là mỗi khi làm xong một thay đổi, nếu điện thoại của anh đang có mặt trên mạng local, cứ đẩy bản development build lên đó.

Anh đăng nhập vào app. Đăng nhập xong, ở góc trên giờ là một radial dial thay cho con số (demo trong video đăng ngày 12/10/2026). Anh nói thật lòng là anh khá thích nó, trông khá đẹp.

Theo Brian, về cơ bản là vậy. Nó vẫn đang chạy ở phía sau, có lẽ vẫn đang tinh chỉnh thêm, nhưng anh nghĩ người xem đã hiểu ý: nó sẽ làm mọi thay đổi cần thiết rồi đẩy lên điện thoại cho anh xem (demo trong video đăng ngày 12/10/2026).

Anh nói đây cũng là workflow thường ngày của anh (tính đến video đăng ngày 12/10/2026): anh thường đi bộ trên máy chạy bộ, vừa xem một video, vừa gõ và trò chuyện qua điện thoại, trong khi được một buổi tập kha khá hay ít nhất là vận động một chút. Anh tự sửa lời: không biết có nên gọi đó là một buổi tập không, nhưng chuyện đó không quan trọng.

16. Notion tự cập nhật, và trọn vòng end-to-end

Quay lại trang work item trong Notion, status đã được đổi thành done, và release đã được link vào (demo trong video đăng ngày 12/10/2026). Brian chạm vào release và cuộn xuống; anh đọc mục cuối của test plan: trên Home, xác nhận readiness hiển thị dưới dạng một chỉ báo tiến trình hình tròn có màu. Theo anh, đó chính xác là điều Codex đã làm. Trong phần release notes, nó cũng thêm một mục để thay đổi này được hiển thị cho khách hàng của anh.

Theo Brian, đó là toàn bộ luồng end-to-end (demo trong video đăng ngày 12/10/2026). Rõ ràng ở lần này anh không cần làm việc thủ công nào ngoài test plan, và test plan đã được ghi sẵn ở đây. Vì vậy không có gì được đẩy sang Todoist.

Anh kết lại: đó là workflow của anh, toàn bộ workflow agentic development từ xa giúp anh về cơ bản làm việc trên các project của mình từ bất cứ đâu trên thế giới, dù đang làm gì đi nữa, "for better or worse", tốt hay xấu cũng vậy (theo Brian, video đăng ngày 12/10/2026). Anh cảm ơn người xem đã ở lại tới cuối và chào tạm biệt.