Compound Engineering: Triết lý kỹ thuật AI-native

• Mỗi đơn vị công việc kỹ thuật là một phương pháp phát triển phần mềm kiểu lãi kép giúp công việc về sau trở nên dễ hơn, với trọng tâm là vòng lặp 4 bước (lập kế hoạch → thực thi → review → lãi kép hóa) để hệ thống hóa việc cộng tác với AI agent
• Trong vòng lặp lặp lại, 80% thời gian của kỹ sư nên được dành cho lập kế hoạch và review, còn 20% phân bổ cho thực thi và lãi kép hóa
• Được phân phối dưới dạng plugin, bao gồm 26 agent chuyên biệt, 23 lệnh workflow và 13 kỹ năng, có thể cài trên Claude Code, OpenCode và Codex
• Đưa ra 8 quan niệm cố hữu của phát triển phần mềm truyền thống (như code phải được viết bằng tay, mọi dòng đều phải review thủ công, v.v.) như những niềm tin cần từ bỏ, và cho rằng cần áp dụng các nguyên tắc mới để mã hóa sở thích vào trong hệ thống
• Phân chia mức độ áp dụng AI của lập trình viên từ cấp 0 (phát triển thủ công) đến cấp 5 (thực thi song song trên cloud), đồng thời đưa ra một framework toàn diện mở rộng từ cách lên cấp ở từng giai đoạn đến cộng tác nhóm, thiết kế, nghiên cứu và marketing

---

Triết lý cốt lõi

• Nguyên tắc cốt lõi là mỗi đơn vị công việc kỹ thuật phải khiến các công việc sau đó trở nên dễ dàng hơn
• Codebase truyền thống làm độ phức tạp tăng dần mỗi khi thêm tính năng, khiến sau 10 năm người ta phải tốn nhiều thời gian hơn để vật lộn với hệ thống
• Trong Compound Engineering, tính năng sẽ dạy cho hệ thống những năng lực mới, sửa lỗi sẽ loại bỏ cả một nhóm lỗi tương lai, còn các pattern được chuyển hóa thành công cụ để codebase theo thời gian ngày càng dễ hiểu, dễ sửa và đáng tin cậy hơn

Vòng lặp chính: Plan → Work → Review → Compound

• Mỗi đội tại Every vận hành 5 sản phẩm (Cora, Monologue, Sparkle, Spiral, Every.to) chủ yếu bằng các nhóm kỹ thuật một người, và thứ giúp điều này khả thi chính là vòng lặp 4 bước
• Ba bước đầu (lập kế hoạch, thực thi, review) là phổ biến, nhưng điểm khác biệt then chốt là ở bước Compound thứ 4, nơi lợi ích lãi kép được tích lũy
• Dù là sửa bug trong 5 phút hay phát triển tính năng kéo dài vài ngày, đều dùng cùng một vòng lặp, chỉ điều chỉnh thời gian dành cho từng bước

• Bước 1: Plan (lập kế hoạch)

  • Hiểu yêu cầu: xác định cần làm gì, vì sao phải làm và có những ràng buộc nào
  • Khảo sát codebase: phân tích cách các tính năng tương tự đang hoạt động và các pattern hiện có
  • Nghiên cứu bên ngoài: kiểm tra tài liệu framework và best practice trong ngành
  • Thiết kế giải pháp: quyết định cách tiếp cận và các file cần thay đổi
  • Xác thực kế hoạch: kiểm tra tính đầy đủ và nhất quán của toàn bộ kế hoạch

• Bước 2: Work (thực thi)

  • Thiết lập môi trường cô lập: tách công việc bằng Git worktree (bản sao cô lập của repository) hoặc branch
  • Thực thi kế hoạch: agent triển khai theo từng bước
  • Chạy kiểm chứng: sau mỗi thay đổi, chạy test, linting (kiểm tra mã tự động) và type check
  • Theo dõi tiến độ và điều chỉnh kế hoạch khi phát sinh vấn đề
  • Nếu tin vào kế hoạch, không cần phải canh từng dòng code một

• Bước 3: Review

  • Nhiều agent thực hiện review code song song
  • Phân loại mức độ ưu tiên của các phát hiện thành P1 (bắt buộc sửa), P2 (khuyến nghị sửa), P3 (điểm cải thiện)
  • Agent sửa vấn đề dựa trên phản hồi review và kiểm chứng kết quả sau khi sửa
  • Ghi lại pattern: tài liệu hóa điều gì đã sai để ngăn tái diễn

• Bước 4: Compound (lãi kép hóa) — bước quan trọng nhất

  • Phát triển truyền thống kết thúc ở bước 3, nhưng ở bước Compound, việc cải tiến hệ thống được tích lũy
  • Nếu ba bước đầu tạo ra tính năng, thì bước 4 tạo ra hệ thống giúp làm ra tính năng tốt hơn
  • Công việc thực hiện:
    • Ghi lại điều gì hiệu quả, điều gì không hiệu quả và những insight nào có thể tái sử dụng
    • Thêm metadata, tag và category bằng YAML frontmatter để có thể tìm kiếm
    • Thêm pattern mới vào CLAUDE.md và tạo agent mới nếu cần
    • Kiểm tra câu hỏi: "Lần sau hệ thống có thể tự động phát hiện vấn đề này không?"

Cấu hình plugin

• 26 agent chuyên biệt: review (14), research, design, workflow, documentation... mỗi loại tối ưu cho một nhiệm vụ cụ thể
• 23 lệnh workflow: vòng lặp chính + tiện ích
• 13 kỹ năng: cung cấp chuyên môn theo miền như kiến trúc agent-native, style guide, v.v.
• Có thể cài đặt zero-config trên Claude Code, OpenCode (thử nghiệm) và Codex (thử nghiệm)

• Cấu trúc file

  • CLAUDE.md: file quan trọng nhất mà agent đọc khi bắt đầu mỗi session, dùng để lưu preference, pattern và ngữ cảnh dự án
  • docs/solutions/: các vấn đề đã được giải quyết được tích lũy thành tài liệu có thể tìm kiếm, xây dựng tri thức tổ chức (institutional knowledge)
  • docs/brainstorms/: lưu đầu ra của lệnh brainstorm
  • docs/plans/: lưu đầu ra của lệnh plan
  • todos/: theo dõi hạng mục công việc theo mức ưu tiên và trạng thái

Các lệnh cốt lõi

• /workflows:brainstorm

  • Lệnh dùng khi chưa rõ cần xây gì
  • Sau khi nghiên cứu repo ở mức nhẹ, hệ thống sẽ làm rõ từng điểm bằng cách đặt câu hỏi lần lượt về mục tiêu, người dùng, ràng buộc và edge case
  • AI đề xuất cách tiếp cận, và kết quả được lưu vào docs/brainstorms/ để handoff sang /workflows:plan

• /workflows:plan

  • Chỉ cần mô tả điều mong muốn, hệ thống sẽ trả về kế hoạch triển khai
  • Chạy 3 agent nghiên cứu song song: repo-research-analyst (pattern trong codebase), framework-docs-researcher (tài liệu), best-practices-researcher (tiêu chuẩn ngành)
  • Agent spec-flow-analyzer phân tích luồng người dùng và edge case
  • Khi bật chế độ ultrathink, /deepen-plan sẽ tự động chạy để kích hoạt hơn 40 agent nghiên cứu song song

• /workflows:work

  • Bước agent viết code thực tế
  • Gồm 4 phase: quick start (tạo Git worktree và thiết lập branch) → execute (triển khai theo từng task kèm theo dõi tiến độ) → quality check (tùy chọn kích hoạt hơn 5 agent reviewer) → ship it (chạy linting, tạo PR)

• /workflows:review

  • PR được hơn 14 agent chuyên biệt review đồng thời theo kiểu song song
  • Bao gồm security (security-sentinel), performance (performance-oracle), architecture (architecture-strategist), data integrity (data-integrity-guardian), code quality (code-simplicity-reviewer), reviewer theo framework (DHH-rails, Kieran-rails/python/typescript), kiểm chứng triển khai, race condition ở frontend và reviewer agent-native
  • Đầu ra là một danh sách ưu tiên duy nhất, được phân loại thành P1 (critical), P2 (quan trọng), P3 (nhỏ)
  • Có thể tự động sửa các phát hiện bằng lệnh /resolve_pr_parallel (ưu tiên P1, mỗi lần sửa chạy trong môi trường cô lập)
  • Có thể lọc các phát hiện bằng lệnh /triage theo kiểu duyệt từng mục để phê duyệt/bỏ qua/tùy chỉnh

• /workflows:compound

  • Tài liệu hóa các vấn đề đã được giải quyết để tham chiếu trong tương lai
  • Kích hoạt 6 sub-agent song song: context analyzer, solution extractor, related docs finder, prevention strategist, category classifier, documentation writer
  • Tạo ra Markdown có thể tìm kiếm với YAML frontmatter

• /lfg

  • Khi mô tả một tính năng, agent sẽ thực hiện toàn bộ từ lập kế hoạch, triển khai đến review để gửi một PR có thể merge
  • Chuỗi hóa toàn bộ pipeline gồm plan → deepen-plan → work → review → resolve findings → browser tests → feature video → compound
  • Sau khi kế hoạch được phê duyệt thì tạm dừng, rồi tự động thực thi với hơn 50 agent hoạt động xuyên suốt mọi giai đoạn

8 niềm tin cần từ bỏ

• "Code phải được viết bằng tay"

  • Yêu cầu thực sự là viết ra mã tốt, có thể bảo trì và giải quyết đúng vấn đề, còn ai là người gõ phím thì không quan trọng

• "Mọi dòng đều phải được review thủ công"

  • Review thủ công từng dòng chỉ là một cách để đảm bảo chất lượng; các hệ thống tự động bắt được cùng loại vấn đề cũng hoàn toàn hợp lệ
  • Nếu không thể tin vào kết quả, đừng bù đắp bằng cách tự làm; hãy sửa hệ thống

• "Giải pháp phải đến từ kỹ sư"

  • Vì AI có thể nghiên cứu hướng tiếp cận, phân tích trade-off và đề xuất phương án, vai trò của kỹ sư là bổ sung gu (taste) — phán đoán giải pháp nào phù hợp với codebase này, đội ngũ này và bối cảnh này

• "Code là đầu ra chính"

  • Hệ thống tạo ra code có giá trị hơn từng đoạn code riêng lẻ
  • Quan trọng hơn một bản triển khai xuất sắc là quy trình tạo ra các bản triển khai tốt một cách nhất quán

• "Viết code là công việc cốt lõi"

  • Công việc của lập trình viên là chuyển giao giá trị (ship value), và code chỉ là một trong các đầu vào
  • Lập kế hoạch, review, huấn luyện hệ thống đều là công việc

• "Lần thử đầu tiên phải tốt"

  • Tỷ lệ lỗi của lần thử đầu là 95%, lần thứ hai cũng là 50%
  • Đây không phải thất bại mà là một quy trình; cần tập trung vào vòng lặp nhanh để lần thử thứ ba hoàn thành nhanh hơn lần đầu

• "Code là sự thể hiện bản thân"

  • Code thuộc về đội ngũ, sản phẩm và người dùng; nếu không xem code là sự thể hiện bản thân, việc tiếp nhận phản hồi, refactor và tranh luận về chất lượng sẽ dễ dàng hơn

• "Gõ nhiều hơn thì học được nhiều hơn"

  • Ngày nay sự hiểu biết quan trọng hơn trí nhớ cơ bắp
  • Một lập trình viên review 10 triển khai do AI tạo ra sẽ hiểu nhiều pattern hơn so với người tự tay gõ 2 cái

Thách thức tâm lý trong quá trình chuyển đổi

• Cảm giác như làm ít việc hơn khi gõ ít đi: thực tế, việc chỉ dẫn cho agent đòi hỏi suy nghĩ nhiều hơn cả triển khai
• Lo lắng trước việc thực thi tự chủ: không phải từ bỏ quyền kiểm soát, mà là mã hóa quyền kiểm soát vào các ràng buộc, quy tắc và quy trình review
• Câu hỏi "Cái này có phải do mình làm ra không?": việc lập kế hoạch, review và đảm bảo tiêu chuẩn chất lượng chính là phần việc đó; AI chỉ đảm nhận khâu viết

Những niềm tin cần tiếp nhận

• Trích xuất gu vào trong hệ thống

  • Gu của lập trình viên như quy ước đặt tên, pattern xử lý lỗi, cách tiếp cận test... thường không được tài liệu hóa mà nằm trong đầu các kỹ sư cấp cao
  • Cần ghi lại những sở thích này trong CLAUDE.md hoặc AGENTS.md, rồi xây dựng agent và skill chuyên biệt cho review, test, triển khai để AI trực tiếp tạo ra code có thể được phê duyệt

• Quy tắc 50/50

  • 50% thời gian kỹ thuật nên dành cho phát triển tính năng, 50% cho cải thiện hệ thống
  • Truyền thống là 90% tính năng / 10% việc khác, nhưng việc tạo agent review, tài liệu hóa pattern, xây dựng trình tạo test... là khoản đầu tư giúp các tính năng trong tương lai dễ làm hơn
  • Đầu tư 1 giờ cho agent review có thể tiết kiệm 10 giờ review trong 1 năm

• Tin vào quy trình và xây dựng lưới an toàn

  • Muốn mở rộng hỗ trợ của AI thì con người không thể review mọi dòng, nên mấu chốt là xây dựng guardrail như test, review tự động, monitoring
  • Nếu không thể tin vào đầu ra, đừng quay lại review thủ công mà hãy bổ sung hệ thống để khiến bước đó trở nên đáng tin cậy

• Cấu hình môi trường theo hướng agent-native

  • Agent phải làm được mọi thứ mà lập trình viên có thể thấy hoặc làm: chạy test, kiểm tra log production, debug bằng screenshot, tạo PR...
  • Mọi việc không cho phép agent làm thì bạn sẽ phải tự tay làm thủ công

• Tận dụng tính song song

  • Điểm nghẽn trước đây là sự chú ý của con người (mỗi lần một tác vụ), nhưng điểm nghẽn mới là compute (số agent có thể chạy đồng thời)
  • Chạy nhiều agent, nhiều tính năng cùng lúc, và thực hiện review, test, tài liệu hóa song song

• Kế hoạch là code mới

  • Tài liệu kế hoạch giờ là đầu ra quan trọng nhất
  • Thay vì viết code trước rồi mới tài liệu hóa, nếu viết kế hoạch trước thì đó sẽ là nguồn chân lý duy nhất để agent tạo code, test và xác minh
  • Sửa ý tưởng trên giấy rẻ hơn sửa trong code

• Tóm tắt các nguyên tắc cốt lõi

  • Mỗi đơn vị công việc phải khiến công việc tiếp theo trở nên dễ hơn
  • Hãy nhúng gu vào hệ thống thay vì để nó xuất hiện trong review
  • Đừng tự làm trực tiếp, hãy dạy hệ thống
  • Đừng dựa vào quy trình review, hãy xây dựng lưới an toàn
  • Hãy cấu trúc môi trường theo hướng agent-native
  • Áp dụng tư duy lãi kép ở mọi nơi
  • Chấp nhận sự khó chịu của việc ủy quyền, và chọn kết quả chưa hoàn hảo nhưng có thể mở rộng thay vì kết quả hoàn hảo nhưng không thể mở rộng
  • Viết ít code hơn và chuyển giao nhiều giá trị hơn
  • Những nguyên tắc này có thể mở rộng vượt ra ngoài kỹ thuật sang thiết kế, nghiên cứu, viết lách và mọi lĩnh vực nơi việc mã hóa gu và bối cảnh đều hữu ích

Các giai đoạn phát triển của lập trình viên (thang 5 bậc)

• Stage 0: Phát triển thủ công

  • Viết code từng dòng không có AI, nghiên cứu bằng tài liệu và Stack Overflow, debug bằng câu lệnh print
  • Cách này đã tạo ra phần mềm tốt trong nhiều thập kỷ, nhưng đến năm 2025 thì không còn đủ nhanh

• Stage 1: Hỗ trợ dựa trên chat

  • Hỏi ChatGPT, Claude, Cursor... để lấy snippet code rồi copy-paste phần hữu ích
  • AI tăng tốc nghiên cứu và sinh boilerplate, nhưng vẫn tự review mọi dòng và giữ toàn quyền kiểm soát

• Stage 2: Công cụ agentic + review từng dòng

  • Các công cụ agentic như Claude Code, Cursor Composer, Copilot Chat đọc file và trực tiếp thay đổi trong codebase
  • Kỹ sư đóng vai trò người gác cổng, phê duyệt hoặc từ chối mọi đề xuất của agent
  • Phần lớn lập trình viên mắc kẹt ở giai đoạn này, nên không tận dụng được lợi ích của việc ủy quyền cho AI

• Stage 3: Ưu tiên kế hoạch, review ở cấp độ PR

  • Đây là giai đoạn mọi thứ thay đổi: cùng AI soạn kế hoạch chi tiết bao gồm yêu cầu, cách tiếp cận và edge case
  • Sau khi lập kế hoạch, AI triển khai mà không cần giám sát; đầu ra được review dưới dạng PR
  • Compound Engineering bắt đầu từ đây — việc lập kế hoạch, triển khai và review trong mỗi chu kỳ sẽ dạy cho hệ thống, giúp chu kỳ sau nhanh hơn và dễ hơn

• Stage 4: Ý tưởng → PR (một máy đơn)

  • Chỉ cần đưa ra ý tưởng, agent sẽ xử lý toàn bộ: nghiên cứu codebase, lập kế hoạch, triển khai, test, tự review, xử lý issue và tạo PR
  • Sự tham gia được thu gọn còn 3 bước: nêu ý tưởng, review PR, merge
  • Tuy vậy, vẫn chỉ chạy từng việc một trên một máy tính

• Stage 5: Thực thi song song trên cloud (đa thiết bị)

  • Chuyển việc thực thi lên cloud để chạy song song
  • Giao đồng thời 3 agent cho 3 tính năng, rồi review khi PR hoàn tất
  • Agent còn có thể theo dõi phản hồi và chủ động đề xuất chỉnh sửa
  • Vai trò không còn là người đóng góp cá nhân mà là người chỉ huy một hạm đội agent

Hướng dẫn lên cấp

• 0 → 1: Bắt đầu cộng tác

  • Chọn một công cụ (như Cursor with Opus 4.5 hoặc Claude Code) và dùng hằng ngày
  • Trước khi viết mã, hãy nhờ AI giải thích mã hiện có để kiểm tra mức độ hiểu
  • Ủy quyền từ phần boilerplate trước, như test, file cấu hình, các hàm lặp lại
  • Review mọi dòng để học hỏi
  • Công việc cộng dồn theo lãi kép: liên tục ghi lại những prompt hoạt động tốt

• 1 → 2: Cho phép agent truy cập

  • Chuyển sang chế độ agentic để cấp cho agent quyền truy cập hệ thống tệp
  • Bắt đầu từ những thay đổi hẹp, một tệp - một mục tiêu, như “thêm test cho hàm này”
  • Xây dựng trực giác về độ tin cậy bằng cách phê duyệt/từ chối từng hành động
  • Review diff để tập trung vào phần đã thay đổi
  • Công việc cộng dồn theo lãi kép: tạo file CLAUDE.md, thêm ghi chú khi agent mắc lỗi

• 2 → 3: Tin vào kế hoạch (bước chuyển cốt lõi)

  • Viết kế hoạch tường minh cho yêu cầu, cách tiếp cận và các edge case
  • Cho phép AI đọc codebase, tìm pattern và đề xuất hướng tiếp cận
  • Sau khi viết kế hoạch, giao phần triển khai cho agent và rời khỏi chỗ cho đến khi xong
  • Review ở cấp độ PR thay vì từng bước hay từng dòng mã
  • Công việc cộng dồn theo lãi kép: sau mỗi lần triển khai, tài liệu hóa những gì kế hoạch đã bỏ sót

• 3 → 4: Trình bày kết quả thay vì chỉ dẫn

  • Cung cấp kết quả (outcome) như “thêm thông báo email cho bình luận mới”, còn cách triển khai để agent quyết định
  • Vì agent hiểu codebase và có thể nghiên cứu, nên việc lập kế hoạch cũng là trách nhiệm của agent
  • Review cách tiếp cận trước khi triển khai để chặn sớm hướng đi sai
  • Công việc cộng dồn theo lãi kép: xây dựng thư viện chỉ dẫn theo định hướng kết quả đã chứng minh hiệu quả

• 4 → 5: Song song hóa mọi thứ

  • Chuyển việc thực thi lên cloud để gỡ nút thắt cổ chai của máy cục bộ
  • Giao đồng thời 3 tính năng cho 3 agent
  • Tổ chức ý tưởng, bug và cải tiến thành hàng đợi để agent xử lý lần lượt
  • Kích hoạt để agent theo dõi phản hồi người dùng và chủ động đề xuất tính năng
  • Công việc cộng dồn theo lãi kép: phân biệt và tài liệu hóa các tác vụ có thể chạy song song và các tác vụ vốn mang tính tuần tự

3 câu hỏi trước khi phê duyệt đầu ra của AI

• “Quyết định khó nhất ở đây là gì?” — khuyến khích AI bộc lộ các phần hóc búa và các điểm cần phán đoán
• “Bạn đã loại bỏ những phương án nào, và vì sao?” — kiểm tra các lựa chọn đã được cân nhắc để bắt được lựa chọn sai
• “Phần nào bạn ít chắc chắn nhất?” — buộc LLM thừa nhận điểm yếu của chính mình, nhưng chỉ trả lời nếu được hỏi trực tiếp

Kiến trúc agent-native

• Trọng tâm là trao cho agent năng lực tương đương với lập trình viên
• Nếu agent không thể chạy test thì bạn phải tự chạy, nếu nó không xem được log thì bạn phải tự debug, nên mọi năng lực không được cấp phép đều chuyển thành công việc thủ công

• Checklist agent-native

  • Môi trường phát triển: chạy ứng dụng cục bộ, chạy test suite, chạy linter và type checker, migration DB, seed dữ liệu phát triển
  • Công việc Git: tạo branch, commit, push lên remote, tạo PR, đọc bình luận PR
  • Debugging: xem log local/production (chỉ đọc), chụp ảnh màn hình UI, kiểm tra request mạng, truy cập hệ thống theo dõi lỗi (như Sentry)

• Triển khai agent-native theo từng bước

  • Level 1 (phát triển cơ bản): truy cập tệp, chạy test, Git commit — có thể thực hiện Compound Engineering cơ bản
  • Level 2 (toàn bộ local): truy cập trình duyệt, log local, tạo PR — có thể làm Stage 3~4
  • Level 3 (khả năng quan sát production): log production (chỉ đọc), theo dõi lỗi, dashboard giám sát — agent có thể debug chủ động
  • Level 4 (tích hợp toàn diện): hệ thống ticket, khả năng deploy, tích hợp dịch vụ bên ngoài — có thể làm Stage 5

• Tư duy agent-native

  • Khi xây dựng tính năng: “Agent sẽ tương tác với thứ này như thế nào?”
  • Khi debug: “Agent cần có khả năng nhìn thấy điều gì?”
  • Khi tài liệu hóa: “Agent có thể hiểu được điều này không?”

Skip Permissions

• Cờ --dangerously-skip-permissions của Claude Code sẽ vô hiệu hóa các yêu cầu xin quyền ở mỗi hành động
• Cái tên được cố ý đặt nghe đáng sợ để buộc người dùng suy nghĩ cẩn trọng trước khi dùng

• Khi nào nên dùng

  • Nên dùng: khi có kế hoạch và hệ thống review tốt, khi làm việc trong môi trường sandbox, khi cần tốc độ
  • Nên hạn chế: khi đang học (vì yêu cầu quyền giúp hiểu hơn), khi làm với mã production, khi chưa có cơ chế rollback

• Cơ chế an toàn khi bỏ qua quyền

  • Git là lưới an toàn: công việc của agent được ghi trong Git và có thể khôi phục bằng git reset --hard HEAD~1
  • Test bắt lỗi: chạy test trước khi merge
  • Review trước khi merge: có thể bỏ qua quyền trong lúc triển khai nhưng nhất định phải review cuối cùng
  • Cô lập rủi ro bằng Worktree: thử nghiệm các tác vụ rủi ro trong thư mục tách biệt

• Tính toán năng suất

  • Nếu không bỏ qua quyền, sẽ có prompt xuất hiện khoảng mỗi 30 giây, và việc nhập “y” liên tục làm mất tập trung
  • Nếu bỏ qua quyền, có thể duy trì trạng thái flow, đạt vòng lặp nhanh hơn 5~10 lần, tiết kiệm thời gian nhiều hơn đáng kể so với rủi ro thỉnh thoảng phải rollback

Quy trình thiết kế

• Cách tiếp cận Baby App

  • Tạo dự án dùng một lần (baby app) để có thể lặp lại tự do mà không phải lo về test, kiến trúc hay thay đổi phá vỡ tương thích
  • Khi đã hài lòng với thiết kế, trích xuất màu sắc, khoảng cách, typography và pattern component để chuyển sang dự án chính

• Vòng lặp khám phá UX

  • Tạo nhiều phiên bản, chia sẻ prototype có thể hoạt động cho người dùng để thu thập phản hồi qua thao tác click-through
  • Khác với mockup Figma, nó thực sự có thể bấm được
  • Prototype dùng để học hỏi, sau đó xây lại từ đầu với kế hoạch phù hợp

• Cộng tác với designer: luồng Compound

  • Luồng truyền thống: mockup của designer → lập trình viên diễn giải → lặp lại chỉnh sửa
  • Luồng Compound: mockup Figma của designer → đưa link Figma vào /plan → AI triển khai → agent figma-design-sync kiểm tra xem phần triển khai có khớp mockup không → designer review phiên bản live thay vì ảnh chụp màn hình

• Mã hóa gu thiết kế

  • Cùng designer làm vài tính năng, rồi ghi lại các pattern đã phát hiện được (màu sắc ưa thích, bố cục form, v.v.) vào file kỹ năng
  • AI có thể tạo ra thiết kế hợp gu của designer ngay cả khi không có designer tham gia

• Agent thiết kế

  • design-iterator: phân tích ảnh chụp màn hình của thiết kế hiện tại và lặp lại cải tiến để tinh chỉnh dần
  • figma-design-sync: lấy thiết kế từ Figma, so sánh với phần triển khai và tự động sửa các khác biệt
  • design-implementation-reviewer: kiểm tra phần triển khai có khớp với spec Figma hay không để bắt lỗi thị giác trước khi tới tay người dùng

Vibe Coding

• Cách tiếp cận dành cho những người chỉ muốn kết quả chứ không quan tâm đến bản thân mã nguồn: product manager, designer, dự án cá nhân, v.v.
• Bỏ qua cả chiếc thang và đi thẳng tới Stage 4: mô tả điều mình muốn → agent xử lý toàn bộ kế hoạch, mã, test, review và PR
• Phù hợp khi: dự án cá nhân, prototype, thử nghiệm, tìm hiểu “liệu điều này có khả thi không?”, công cụ nội bộ, khám phá UX
• Không phù hợp khi: hệ thống production có người dùng, mã do người khác phải bảo trì, ứng dụng nhạy cảm về bảo mật, hệ thống tối quan trọng về hiệu năng

• Nghịch lý của vibe coding

  • Vibe coding thậm chí có thể cải thiện khả năng lập kế hoạch
  • Khi chưa biết phải xây gì, hãy tạo prototype để thu thập phản hồi người dùng, rồi xóa mọi thứ và bắt đầu lại với một kế hoạch đúng đắn
  • Phân bổ tối ưu: khám phá bằng vibe coding, xây dựng bằng spec — ở phần triển khai cuối cùng, spec luôn chiến thắng

Cộng tác nhóm

• Động lực nhóm mới

  • Truyền thống: người A viết code → người B review → thảo luận comment trong PR → phê duyệt rồi merge
  • Compound: người A tạo kế hoạch → AI triển khai → AI agent review → người B review lại phần review của AI → con người phê duyệt rồi merge

• Tiêu chuẩn nhóm

  • Phê duyệt kế hoạch: im lặng không có nghĩa là đồng ý, nên cần sign-off rõ ràng trước khi triển khai
  • Quyền sở hữu PR: bất kể ai là người viết code, người bắt đầu công việc là chủ sở hữu PR, chịu trách nhiệm về chất lượng kế hoạch, review, chỉnh sửa và tác động sau khi merge
  • Trọng tâm review của con người: trong PR mà AI review agent đã phân tích, con người sẽ review xoay quanh ý định (intent) chứ không phải lỗi cú pháp, bảo mật, hiệu năng hay style — "có khớp với những gì đã thống nhất không?", "cách tiếp cận có hợp lý không?", "có vấn đề về business logic không?"

• Mẫu giao tiếp

  • Mặc định là bất đồng bộ: không cần họp để tạo, review và phê duyệt kế hoạch, "tôi đã tạo tài liệu kế hoạch rồi, nhờ mọi người comment trong hôm nay"
  • Bàn giao rõ ràng: bao gồm trạng thái, những gì đã hoàn thành, phần việc còn lại, ngữ cảnh và cách tiếp tục

• Mẫu mở rộng

  • Quyền sở hữu rõ ràng + cập nhật bất đồng bộ: mỗi tính năng lớn có một người phụ trách lập kế hoạch, theo dõi, review, merge và cập nhật cho nhóm
  • Feature flag + PR nhỏ: càng nhiều người deploy nhanh thì xung đột merge càng tăng, hãy deploy theo đơn vị nhỏ, merge vào main thường xuyên và xử lý xung đột ngay lập tức
  • Tài liệu Compound = tri thức ngầm (tribal knowledge): thay vì "hãy hỏi Sarah, cô ấy rất rành về auth", Sarah chạy /compound để ghi lại giải pháp thì ai cũng có thể tìm kiếm

Nghiên cứu người dùng

• Khoảng cách giữa nghiên cứu và phát triển

  • Truyền thống: researcher thực hiện phỏng vấn → viết báo cáo → bỏ đó trong Google Drive → developer không xem báo cáo → tính năng không phản ánh nhu cầu người dùng
  • Compound: nghiên cứu tạo ra insight có cấu trúc → insight được dùng làm ngữ cảnh cho kế hoạch → AI tham chiếu insight khi lập kế hoạch → dữ liệu sử dụng kiểm chứng insight → insight được tích lũy theo lãi kép

• Cấu trúc hóa nghiên cứu

  • Chuyển ghi chú phỏng vấn thô thành Markdown có cấu trúc để AI có thể tận dụng: gồm thông tin người tham gia, insight chính, trích dẫn, hàm ý, độ tin cậy (n/5 người tham gia)

• Tài liệu persona

  • Tạo tài liệu persona gồm mục tiêu, nỗi bức xúc và trích dẫn để AI có thể tham chiếu

• Lập kế hoạch dựa trên nghiên cứu

  • Khi chạy /workflows:plan, đưa vào ngữ cảnh nghiên cứu (kết quả phỏng vấn, mẫu persona, pain point hiện tại) để insight nghiên cứu được nối trực tiếp tới tính năng

Trích xuất mẫu từ dữ liệu

• Cách người dùng sử dụng sản phẩm là manh mối cho biết nên xây gì

• Các loại mẫu cần chú ý

  • Mẫu sử dụng quá mức: tính năng được dùng nhiều hơn dự kiến rất nhiều, truy cập lặp lại vào cùng một trang
  • Mẫu khó khăn: thời gian ở lại cao trên một trang đơn giản, lặp lại nhiều lần cùng một thao tác, vòng lặp lỗi → thử lại → lỗi
  • Mẫu đi đường vòng: xuất dữ liệu ở một nơi rồi nhập lại ở nơi khác, copy-paste giữa các màn hình, mở nhiều tab cùng lúc để so sánh
  • Mẫu rời bỏ: rơi rụng trong flow, tính năng đã bắt đầu nhưng không hoàn thành

• Từ mẫu đến tính năng

  • Người dùng copy-paste dữ liệu giữa các bảng 50 lần mỗi tuần → biến thành tính năng nút "đồng bộ sang bảng B"
  • Người dùng tạo project "template" rồi nhân bản → biến thành tính năng hỗ trợ template hạng nhất

Viết nội dung

• Đưa nội dung vào kế hoạch

  • Hầu hết các team coi nội dung là ưu tiên thấp và chỉ điền vào sau khi xây xong tính năng, nhưng nội dung là một phần của trải nghiệm người dùng
  • Nếu đưa các nội dung hướng tới người dùng như tiêu đề email, thông báo thành công, thông báo lỗi... vào ngay từ giai đoạn lập kế hoạch thì khi AI triển khai, phần nội dung đã sẵn sàng

• Mã hóa giọng điệu

  • Viết thành file kỹ năng các nguyên tắc (nói như con người, thông báo lỗi phải hữu ích, câu ngắn, từ ngữ rõ ràng) và các từ cần tránh (Invalid → didn't work, Error → giải thích điều gì đã xảy ra, v.v.)

• Review nội dung

  • Thêm review nội dung vào quy trình /workflows:review: agent copy-reviewer kiểm tra theo 4 tiêu chí độ rõ ràng, mức độ hữu ích, tông giọng, tính nhất quán

Product marketing

• Flow Compound

  • Kỹ sư tạo kế hoạch có bao gồm value proposition của sản phẩm → AI triển khai tính năng → AI tạo release note từ kế hoạch → tạo bài đăng mạng xã hội từ release note → tự động chụp screenshot bằng Playwright → kỹ sư review rồi phát hành tất cả cùng nhau
  • Mọi thứ chảy trong một nơi nên không cần handoff, không có lỗ hổng

• Tạo release note

  • Vì AI có cả kế hoạch, thay đổi code và test nên có thể nắm chính xác những gì đã được xây dựng
  • Ưu tiên lợi ích cho người dùng, kèm 1 ví dụ cụ thể, đề cập breaking change, trong phạm vi 200 từ

• Tạo changelog

  • Dùng lệnh /changelog để kiểm tra các lần merge gần đây vào main, đọc từng kế hoạch/PR và tạo changelog hấp dẫn

• Screenshot tự động

  • Dùng Playwright để tự động chụp screenshot phục vụ marketing, không cần nhờ engineering chụp screenshot, giải quyết vấn đề screenshot lỗi thời