Năm thói quen làm engineering với Opus 5.5 cho long task

1. Opus 5.5 và PandaCode, một app không hề nhỏ

AICodeKing mở đầu bằng một lời kể về cách anh làm việc: theo anh (video đăng ngày 23/10/2026), từ khi Claude Opus 5.5 ra mắt, anh dùng nó cho gần như toàn bộ việc coding của mình. Project lớn nhất anh build bằng Opus 5.5 là PandaCode, desktop app cho coding agent mà anh đã giới thiệu trong một video trước.

Anh nhấn mạnh PandaCode không phải một app nhỏ. Theo AICodeKing (video đăng ngày 23/10/2026), nó chạy Claude Code, Codex, Kimi, GLM và các agent khác trong cùng một cửa sổ. Nó có worktree, task board, agent team, bot, browser tích hợp, simulator và máy ảo.

Thẻ Opus 5.5, long task trong PandaCode, trạng thái Working lúc 3:40 AM, trên nền phong cảnh hồ và núi — Hình mở đầu video: một thẻ "Opus 5.5 · long task · PandaCode" đang ở trạng thái Working lúc 3:40 sáng, với thanh tiến độ mới chạy được hơn một nửa.

Theo lời anh (video đăng ngày 23/10/2026), phần lớn code đó do Opus viết, và phần lớn đến từ những long task, tức những lần agent làm việc một tiếng hoặc hơn mà không cần anh. Nhiều người nói với anh rằng Opus bắt đầu tốt rồi lạc hướng ở các task dài. Anh kể lúc đầu chính anh cũng gặp vấn đề đó. Nhưng theo thời gian, anh tìm ra vài thói quen sửa được phần lớn chuyện này.

2. Năm thói quen cho long task

Trong video này, anh chia sẻ cách anh làm engineering với Opus 5.5, và với mỗi thói quen anh dùng ví dụ thật từ PandaCode. Có năm điều:

Giữ prompt đơn giản.
Cho agent một benchmark.
Yêu cầu test tốt.
Đưa agent reference design.
Luôn dùng orchestration.

Rồi anh vào thẳng nội dung chính.

Hình 2.1Năm thói quen AICodeKing dùng khi giao long task cho Opus 5.5, theo đúng thứ tự trong video. Thói quen cuối, orchestration, được anh gọi là quan trọng nhất.

3. Thói quen 1: giữ prompt đơn giản, để agent tự tìm đường

Thói quen đầu tiên là giữ prompt đơn giản và để agent tự tìm ra phần còn lại. Anh thừa nhận lúc đầu nghe điều này có vẻ sai. Theo anh, phần lớn hướng dẫn bảo bạn viết một prompt dài với workflow từng bước: đầu tiên đọc mấy file này, rồi lập kế hoạch, rồi sửa file này, rồi chạy lệnh này. Anh cũng làm như vậy trong một thời gian dài.

Nhưng theo kinh nghiệm của anh (video đăng ngày 23/10/2026), khi bạn build những thứ thật, workflow dài đó thường làm kết quả tệ hơn. Agent đi theo các bước của bạn ngay cả khi có một con đường tốt hơn, và theo AICodeKing, Opus 5.5 thật sự giỏi tìm ra con đường tốt hơn đó. Nó đọc code, thấy các phần nối với nhau thế nào, rồi chọn một thứ tự làm việc hợp lý cho chính codebase này.

Hình 3.1Ý của thói quen thứ nhất theo lời AICodeKing (video đăng ngày 23/10/2026): một workflow viết sẵn khoá agent vào các bước của bạn, còn một prompt ngắn để agent đọc code và tự chọn đường đi.

4. Ví dụ: tính năng Resume at reset chỉ với ba câu prompt

Ví dụ anh đưa ra là lần thêm tính năng Resume at reset vào PandaCode. Prompt của anh dài khoảng ba câu. Anh nói rằng một agent có thể chạm giới hạn sử dụng (usage limit) giữa chừng một task. Khi chuyện đó xảy ra, PandaCode nên chờ giới hạn được reset rồi tự tiếp tục task (theo video đăng ngày 23/10/2026). Anh cũng nói người dùng phải hủy được việc này. Chỉ có vậy.

Anh không bảo agent đọc file nào, cũng không bảo nó lưu thời điểm reset bằng cách nào. Theo AICodeKing (video đăng ngày 23/10/2026), Opus tự tìm ra phần code về usage ở những chỗ mà mỗi agent báo cáo giới hạn của nó, rồi build tính năng xoay quanh phần đó.

Thanh vàng Usage limit reached, Resets 3:16 AM với nút Resume at reset và Continue now phía trên ô prompt — Tính năng Resume at reset trong bản PandaCode ở video đăng ngày 23/10/2026: một thanh vàng "Usage limit reached · Resets 3:16 AM" nằm trên ô prompt, với ô chọn Resume at reset, nút Continue now và nút đóng. Bên dưới là dòng trạng thái "Make search feel instant: 5-hour usage limit reached". Nhãn cam trong video tóm ý: chờ reset rồi tự tiếp tục.

Anh nói nếu tự viết các bước, anh đã bỏ sót một vài phần trong số đó, vì anh không nhớ hết chúng nằm ở đâu.

5. Một prompt đơn giản cần có ba thứ

Vậy một prompt đơn giản nên có gì? Theo AICodeKing, ba thứ:

Bạn muốn gì.
Làm sao bạn biết là đã xong.
Những gì agent không được đụng vào nếu chưa hỏi bạn. Ví dụ: đừng đổi định dạng database, hoặc đừng xoá dữ liệu người dùng.

Giữ mục tiêu và giới hạn thật rõ, còn con đường thì để cho agent. Anh gọi đây là thay đổi lớn nhất anh từng làm, và kể rằng các long task của anh tốt lên nhiều sau đó (video đăng ngày 23/10/2026).

Hình 5.1Khung prompt ba phần mà AICodeKing đề xuất: mục tiêu, tiêu chí xong, và những giới hạn agent phải hỏi trước khi vượt qua.

6. Thói quen 2: cho agent một benchmark

Tiếp theo là benchmark. Thói quen thứ hai là yêu cầu agent làm một benchmark trước, rồi mới bảo nó cải thiện con số đó. Benchmark có thể là bất cứ thứ gì: app mở nhanh cỡ nào, dùng bao nhiêu bộ nhớ, một trang tải mất bao lâu, hay một danh sách render lại bao nhiêu lần khi một mục thay đổi. Bạn quan tâm thứ gì, hãy biến nó thành một con số trước.

Bốn thẻ app opens, memory, page load, list renders và dòng turn it into a number first — Slide "it can be anything": bốn thẻ là thời gian app mở (giây), bộ nhớ (MB), thời gian tải trang (giây) và số lần list render trên mỗi thay đổi. Dòng bên dưới: "turn it into a number first", biến nó thành một con số trước.

Vì sao điều này quan trọng, theo AICodeKing (video đăng ngày 23/10/2026)? Vì "làm nó nhanh hơn" là một mục tiêu yếu. Agent đổi một ít code, nói app giờ đã nhanh hơn, và bạn không thật sự kiểm được. Còn khi có benchmark, agent có một nguồn sự thật (source of truth). Nó chạy benchmark, thực hiện một thay đổi, rồi chạy lại benchmark. Nếu con số không tốt lên, nó biết ngay và thử cách khác. Bạn không phải ngồi đó phán xét từng thay đổi.

Theo anh (video đăng ngày 23/10/2026), điều này hoàn hảo cho long task. Benchmark cho agent một mục tiêu rõ ràng, nên nó làm việc được rất lâu mà không cần bạn. Nó không dừng ở ý tưởng đầu tiên, vì con số cho nó biết vẫn còn việc phải làm.

7. Ví dụ: cửa sổ mở nhanh hơn, bộ nhớ nhỏ hơn

Anh kể (video đăng ngày 23/10/2026) đã làm điều này rất nhiều với PandaCode. Ví dụ, anh muốn app cho cảm giác thật nhẹ. Nên trước hết anh nhờ Opus viết một benchmark nhỏ, đo thời gian cửa sổ mở ra và lượng bộ nhớ app dùng khi rảnh. Rồi anh bảo nó làm hai con số đó nhỏ lại.

Terminal chạy cat scripts/measure.mjs, một script Node 32 dòng đo kích thước asset, binary và bộ nhớ tiến trình — Script benchmark trong repo PandaCode, như video đăng ngày 23/10/2026 cho thấy: lệnh `cat scripts/measure.mjs` in ra một file Node 32 dòng. Nó đọc kích thước các file trong `dist/assets` (cả bản gzip), kích thước binary `src-tauri/target/release/pandacode` (được khoanh lại), rồi dùng `ps` để lấy bộ nhớ RSS của tiến trình pandacode và các tiến trình con, kèm ghi chú rằng RSS chỉ là số đo tại một thời điểm.

Theo số đo của AICodeKing (video đăng ngày 23/10/2026), giờ cửa sổ mở ra trong khoảng một phần ba giây, và app dùng khoảng 130 đến 160 MB bộ nhớ khi rảnh. Anh nói anh không đạt được mức đó bằng một prompt khôn ngoan nào. Anh đạt được vì agent đo được mọi thay đổi.

8. Ví dụ: follow-up từ tám giây xuống bốn giây

Một ví dụ khác là follow-up trong Claude Code. Anh nhờ Opus đo thời gian từ lúc anh gửi một tin nhắn follow-up tới lúc chữ đầu tiên của câu trả lời hiện ra. Theo số đo của anh (video đăng ngày 23/10/2026), con số ban đầu khoảng tám giây. Có con số đó rồi, Opus thử vài ý tưởng. Ý tưởng hiệu quả là khởi động tiến trình kế tiếp ở nền ngay khi một turn kết thúc. Giờ con số là khoảng bốn giây, theo số đo của anh trong video đăng ngày 23/10/2026, và anh nói vậy là khá tốt.

Hình 8.1Hai con số AICodeKing tự đo với follow-up trong Claude Code chạy qua PandaCode, nêu trong video đăng ngày 23/10/2026.

Nên nếu có gì đó chậm hay nặng, đừng chỉ nói "làm nó nhanh hơn". Hãy nói: viết một benchmark cho việc này, cho tôi xem con số, rồi làm con số đó tốt lên. Anh nói đó là một thay đổi nhỏ trong prompt, nhưng kết quả tốt hơn rất nhiều.

9. Thói quen 3: bắt agent viết test tốt

Giờ tới test. Thói quen thứ ba là bắt agent viết test tốt, và bắt mọi thay đổi phải pass các test đó trước khi bạn nhìn vào. Theo AICodeKing (video đăng ngày 23/10/2026), Opus viết code rất tốt, nhưng đôi khi nó viết rất ít test. Bạn yêu cầu một tính năng và nhận được tính năng đó với một test nhỏ, hoặc không có test nào. Rồi bạn mở app và thấy một lỗi cơ bản ngay trong mười giây đầu. Chuyện đó tốn thời gian của bạn, và trên một long task thì tốn rất nhiều.

Nên anh luôn yêu cầu thẳng. Anh bảo agent nghĩ xem tính năng có thể hỏng theo những cách nào và viết test cho các trường hợp đó. Không phải một trăm test chẳng kiểm gì, mà là một bộ test nhỏ được nghĩ kỹ: trường hợp rỗng, trường hợp lỗi, trường hợp hai việc xảy ra cùng lúc.

Rồi luật rất đơn giản (video đăng ngày 23/10/2026): không có gì tới tay anh cho tới khi nó pass test. Nếu một test fail, agent sửa nó trước. Nên tới lúc anh xem việc, các lỗi cơ bản đã biến mất, và anh chỉ phải nhìn những thứ cần tới con người.

Slide the rule: nothing comes to me until it passes, với the agent, the tests, me và mũi tên fails, it fixes it first — Slide "the rule": không có gì tới tay anh cho tới khi nó pass. Agent gửi việc sang test; nếu fail, một mũi tên đỏ quay về agent ("fails → it fixes it first"); chỉ khi test có dấu tích xanh thì việc mới tới "me".

10. Ví dụ: test cho nút merge worktree, và một dòng cho file CLAUDE.md

Ví dụ của anh là tính năng merge worktree trong PandaCode. Theo AICodeKing (video đăng ngày 23/10/2026), khi bạn bấm Merge into main, PandaCode merge các commit của agent vào branch main trên máy bạn. Đó là một hành động rủi ro, vì một lần merge hỏng có thể phá project của bạn.

Nên trước khi tin nó, anh nhờ Opus viết test cho những trường hợp có thể sai. Chuyện gì xảy ra khi bạn có thay đổi chưa commit? Chuyện gì xảy ra khi có conflict? Các test quy định rằng trong cả hai trường hợp, PandaCode phải dừng lại và không thay đổi gì, và theo anh (video đăng ngày 23/10/2026), đó đúng là cách nó chạy. Anh không bao giờ phải tự tìm những bug đó, vì test đã tìm ra chúng trước.

Terminal in một test Rust tên merging_a_worktree_lands_committed_work_on_main_and_refuses_unsafe_states — Test do Opus viết cho thao tác merge, như video đăng ngày 23/10/2026 cho thấy: lệnh `sed -n '1663,1696p' src-tauri/src/workspace.rs` in ra hàm test `merging_a_worktree_lands_committed_work_on_main_and_refuses_unsafe_states`. Các comment trong code nói rõ từng ca: thay đổi chưa commit trong worktree không bao giờ được merge; merge thành công đưa commit vào main; merge lần nữa không còn gì để mang sang; và một conflict thì huỷ sạch, main giữ phiên bản của nó và không để lại merge dở dang.

Anh nói thêm (video đăng ngày 23/10/2026), test cũng giúp rất nhiều cho long task, vì agent đổi nhiều file trong suốt một tiếng. Không có test, một thay đổi ở chỗ này có thể lặng lẽ phá một thứ ở chỗ khác. Có test, agent thấy chỗ hỏng đó ngay và sửa trước khi đi tiếp.

Nếu muốn, bạn có thể đặt điều này vào file CLAUDE.md để khỏi phải gõ lại mỗi lần. Câu anh gợi ý đại ý như sau:

Write careful tests for every feature and run all tests before you say that you're done.

11. Thói quen 4: đưa agent reference design

Giờ nói về design. Thói quen thứ tư là đưa cho agent reference design. Design mang tính chủ quan. Khi bạn nói "làm cho nó đẹp", agent phải đoán xem đẹp với bạn nghĩa là gì. Và theo AICodeKing (video đăng ngày 23/10/2026), khi model đoán, bạn thường nhận được đúng cái vẻ ngoài chung chung mà bạn đã thấy cả trăm lần: gradient tím, thẻ bo góc to, đại loại vậy.

Nên đừng bắt nó đoán. Tìm những design bạn thật sự thích và đưa cho agent. Theo video đăng ngày 23/10/2026, anh nói bạn có thể lấy chúng từ những trang như recent.design hay Dribbble. Chụp vài màn hình về layout, màu sắc và các chi tiết nhỏ bạn muốn, đính kèm vào prompt và nói: làm cho nó có cảm giác như thế này.

Trang dribbble.com với lưới các shot design, vài shot được khoanh và các nhãn layout, attach them to your prompt, small details — Trang Dribbble trong video đăng ngày 23/10/2026: một lưới các design, vài cái được khoanh màu cam với các nhãn "layout" và "small details", cùng dòng "attach them to your prompt" ở giữa, tức chọn ảnh tham khảo rồi đính kèm vào prompt.

Theo AICodeKing (video đăng ngày 23/10/2026), Opus 5.5 đọc ảnh tham khảo rất giỏi. Nó nắm được khoảng cách, cỡ chữ, màu sắc và cảm giác chung. Nên kết quả gần với thứ bạn có trong đầu, và bạn mất ít thời gian hơn nhiều cho những chỉnh sửa nhỏ.

Theo AICodeKing (video đăng ngày 23/10/2026), anh đã làm như vậy cho giao diện của PandaCode: thanh approval phía trên ô prompt, hàng nhỏ "Worked for" ẩn các bước của agent, và task board. Anh có reference design cho tất cả những phần đó. Agent không tự nghĩ ra phong cách ấy; nó đi theo các reference của anh.

12. Moodboard và công cụ sketch trong PandaCode

Anh thích cách làm này đến mức đã đưa nó vào PandaCode. Theo AICodeKing (video đăng ngày 23/10/2026), bạn tạo được moodboard trong app. Moodboard là một bộ ảnh tham khảo cho một project, kèm chú thích. Bạn đính board vào một tin nhắn, và agent cũng tự mở được các board. Nhờ vậy reference của bạn ở lại cùng project, và mọi task mới đều dùng được chúng.

Hộp thoại Moodboards với board Visual direction chứa ảnh layout.png và ô What should the agent notice? — Hộp thoại Moodboards trong bản PandaCode ở video đăng ngày 23/10/2026: board "Visual direction" có một ảnh `layout.png`, ô chú thích "What should the agent notice?", nút Add images và nút Attach to task. Dòng chữ phía trên tóm ý: một board là các ảnh tham khảo cộng chú thích.

Theo video đăng ngày 23/10/2026, app còn có một công cụ sketch. Nếu không tìm được reference nào, cứ vẽ một layout thô và gửi bản vẽ đó. Thành thật mà nói, theo anh, ngay cả một bản sketch xấu vẫn tốt hơn là không có reference nào.

13. Thói quen 5: luôn dùng orchestration

Giờ tới thói quen anh gọi là quan trọng nhất: luôn dùng orchestration. Theo AICodeKing (video đăng ngày 23/10/2026), khi một task lớn, một agent trong một cuộc chat là không đủ. Context đầy lên, agent quên các quyết định trước đó, và chất lượng đi xuống về cuối. Theo anh, đó là chỗ phần lớn long task thất bại.

Theo AICodeKing (video đăng ngày 23/10/2026), orchestration giải quyết chuyện này. Một agent dẫn dắt: nó lập kế hoạch, chia việc thành nhiều phần và giao mỗi phần cho một agent khác. Mỗi worker nhận một việc nhỏ, rõ ràng, với context mới. Agent dẫn dắt không tự viết hết code; nó kiểm tra việc và giữ bức tranh toàn cảnh.

Anh muốn điều này đến mức đã build nó vào PandaCode, dưới tên Agent Teams. Theo AICodeKing (video đăng ngày 23/10/2026), bấm nút Team trong ô prompt là bạn có một architect và các worker. Architect lập kế hoạch, giao mỗi phần cho một worker, và các worker chạy cùng lúc. Khi chúng xong, architect review việc của chúng và đưa bạn một bản tóm tắt cùng tất cả các file đã đổi.

Tooltip Team mode trên nút Team cạnh model picker Claude Opus 5.5 và Full access — Nút Team trong ô prompt (video đăng ngày 23/10/2026), cạnh model picker "Claude Opus 5.5" và mode Full access. Tooltip giải thích Team mode: model bạn chọn trở thành lead, lập kế hoạch, khởi động các agent khác song song, tự chọn model cho từng worker và review kết quả; muốn tự chọn worker thì ghi trong prompt, ví dụ "use Sonnet 5.5 workers" hay "have Codex review it".

14. Cách anh dựng team: Opus là architect, Sonnet là worker, Codex là reviewer

Đây là cách anh thường dựng team, và các nhận định về model dưới đây là ý kiến của AICodeKing trong video đăng ngày 23/10/2026:

Opus 5.5 là architect, vì theo anh nó giỏi nhất ở khâu lập kế hoạch và review (video đăng ngày 23/10/2026).
Sonnet làm phần lớn việc của worker, vì theo anh nó nhanh, rẻ hơn, và thật sự tốt khi việc đã rõ ràng (video đăng ngày 23/10/2026).
Codex là reviewer. Anh lý giải rằng một model thứ hai từ một công ty khác bắt được những lỗi khác, nên Codex thường tìm ra những thứ mà cả Opus lẫn Sonnet đều bỏ sót (theo AICodeKing, video đăng ngày 23/10/2026).

Hình 14.1Team mặc định của AICodeKing theo video đăng ngày 23/10/2026: Opus 5.5 lập kế hoạch và review, các worker Sonnet làm việc song song, và Codex review thêm từ một công ty khác.

Theo anh, phần hay là anh không phải tự quản lý gì cả. Anh đưa architect một prompt đơn giản và nó lo phần còn lại: theo AICodeKing (video đăng ngày 23/10/2026), nó quyết định dùng bao nhiêu worker, model nào hợp với việc nào, và khi nào gửi việc sang Codex để review. Anh gọi điều này là "just amazing".

15. Các thói quen vẫn chạy bên trong team, và ví dụ GitHub view

Theo AICodeKing (video đăng ngày 23/10/2026), tất cả các thói quen trước đó cũng chạy được bên trong team. Architect có thể nhờ một worker viết benchmark và một worker khác cải thiện con số. Nó có thể nhờ một worker viết test rồi bắt mọi worker khác pass các test đó. Nó có thể đưa moodboard cho worker phụ trách design. Nên team làm theo đúng những luật anh làm theo.

Slide inside the team: the habits still work, ba dòng benchmark, tests, moodboard và nhãn the team follows my rules — Slide "inside the team, the habits still work": một worker viết benchmark, worker khác cải thiện con số; một worker viết test, mọi worker pass chúng; worker design nhận moodboard. Nhãn cam: team làm theo luật của anh.

Ví dụ, theo AICodeKing (video đăng ngày 23/10/2026), phần lớn GitHub view của PandaCode đến từ một team task duy nhất. Anh yêu cầu một view có repo, pull request và issue với các thao tác một cú click. Architect giao phần dữ liệu cho một worker Sonnet, giao phần giao diện cùng reference design của anh cho một worker Sonnet khác, và giao phần test cho worker thứ ba. Rồi Codex review toàn bộ thay đổi. Khi việc quay về tay anh, nó đã pass test và đã trông giống các reference của anh.

16. Named team và ba mẹo nhỏ cho long task

Theo video đăng ngày 23/10/2026, bạn cũng lưu được named team trong phần settings của PandaCode. Ví dụ anh đưa ra: một team mạnh với Opus và Codex cho các tính năng khó, hoặc một team rẻ với các worker GLM cho việc đơn giản. Rồi bạn chọn team từ model picker như chọn một model bình thường, nên bạn ghép được team với task.

Sau đó anh chia sẻ vài điều nhỏ giúp ích cho long task nói chung. Các thao tác dưới đây là của bản PandaCode trong video đăng ngày 23/10/2026.

Thứ nhất, bạn vẫn làm việc tiếp được trong lúc agent đang làm. Theo video đăng ngày 23/10/2026, nhấn Enter thì tin nhắn của bạn vào một hàng đợi (queue), và PandaCode gửi nó đi khi agent làm xong. Nhấn Command-Enter thì bạn lái (steer) agent ngay lập tức mà không dừng nó. Nên nếu anh nhớ ra một yêu cầu giữa chừng một lượt chạy dài, anh không phải dừng mọi thứ.

Cửa sổ PandaCode với task Make search feel instant và nhãn 1, keep working while the agent works phía trên ô prompt — Mẹo thứ nhất trên màn hình (video đăng ngày 23/10/2026): task "Make search feel instant" trong project orbit, prompt gốc hỏi làm cho ô search phản hồi tức thì khi gõ, và nhãn cam "1 · keep working while the agent works" ngay trên ô prompt.

Thứ hai, đặt việc vào một worktree. Khi đó một long task chạy trên branch riêng của nó, và không thể phá những gì các agent khác làm trên main. Khi nó xong và test đã pass, theo video đăng ngày 23/10/2026, bạn merge nó bằng hai cú click.

Task trong worktree đã commit high-contrast theme trên branch riêng, nhãn tests pass, merge — Một task chạy trong worktree (video đăng ngày 23/10/2026): prompt "Add a high-contrast theme to the settings page", agent trả lời đã commit theme trên branch riêng `pandacode/add-a-high-contrast-theme-to-the`, và nhãn xanh "tests pass → merge".

Thứ ba, theo dõi giới hạn của bạn. Long task dùng rất nhiều token. Theo AICodeKing (video đăng ngày 23/10/2026), PandaCode hiển thị giới hạn năm giờ và giới hạn hàng tuần của Claude, và nếu bạn chạm giới hạn giữa chừng một task, chọn Resume at reset là task sẽ tự tiếp tục sau đó. Nên một long task không chết lúc hai giờ sáng chỉ vì bạn chạm giới hạn.

17. Nói thẳng về giới hạn, và tóm lại

Anh muốn nói thẳng một điều: theo AICodeKing (video đăng ngày 23/10/2026), các thói quen này không làm Opus hoàn hảo. Đôi khi architect chia việc theo một cách kỳ lạ. Đôi khi một worker đi sai hướng. Bạn vẫn phải xem kết quả. Nhưng bạn xem ít hơn nhiều, và khi xem thì các vấn đề cơ bản đã được sửa. Theo anh, đó mới là chỗ tiết kiệm thời gian thật sự.

Tóm lại:

Giữ prompt đơn giản và để Opus chọn đường đi (theo AICodeKing, video đăng ngày 23/10/2026).
Cho nó một benchmark để nó có một con số mà cải thiện.
Yêu cầu test cẩn thận và bắt mọi thay đổi pass chúng trước khi bạn xem.
Đưa nó reference design để nó không phải đoán.
Dùng orchestration, với Opus dẫn dắt, Sonnet làm worker và Codex làm reviewer, như cách anh dựng team trong video đăng ngày 23/10/2026.

Anh nói đó là cách anh build PandaCode, và là cách anh build gần như mọi thứ bây giờ (video đăng ngày 23/10/2026). Nhìn chung, theo ý kiến của AICodeKing trong video đăng ngày 23/10/2026, Opus 5.5 là model hợp nhất cho kiểu việc dài này vào lúc đó, nếu bạn cho nó đúng cách thiết lập.

Theo AICodeKing (video đăng ngày 23/10/2026), PandaCode miễn phí và mã nguồn mở, nên bạn có thể tự thử Agent Teams. Repo của nó nằm ở cuối trang. Anh kết video bằng lời mời người xem để lại suy nghĩ trong phần bình luận.