- Fiona Fung, người dẫn dắt mảng engineering và product của
Claude CodevàCowork, chia sẻ cách đội ngũ viết lại các chuẩn mực làm việc khi AI dịch chuyển nút thắt cổ chai từ năng lực kỹ thuật (engineering bandwidth) sang khâu kiểm chứng, review, bảo mật và phối hợp liên chức năng. - Các thay đổi cụ thể gồm: lập kế hoạch "vừa kịp lúc" (JIT planning), giải quyết tranh luận kỹ thuật bằng cách sinh nhiều PR thay vì lên bảng trắng, đầu tư mạnh vào kiểm chứng và tự động hóa "shift left", và tin tưởng Claude có chọn lọc cho việc review nhưng giữ con người cho pháp lý, bảo mật và "gu" sản phẩm.
- Triết lý xuyên suốt là "điều từng phục vụ bạn có thể không còn phù hợp nữa" — giữ growth mindset, cho các pod quyền tường minh để "khai tử" quy trình cũ, giữ tổ chức phẳng, dogfooding mạnh, và rà soát lại quy trình "ồn ào" nhất của bạn.
Running an AI-native engineering org
- Nút thắt cổ chai đã dịch chuyển: trước đây engineering bandwidth và throughput code là thứ đắt đỏ, nhưng giờ code hiếm khi là khâu chậm, nên nút thắt chuyển sang kiểm chứng, code review, đối tác liên chức năng và bảo mật.
- Quy trình "âm thầm ngừng hiệu quả" — các đội thường chồng thêm quy trình (như chất đống SLA) mà ít khi loại bỏ, nên người dẫn dắt cần quyền tường minh để khai tử quy trình cũ và rà soát xem chúng còn phục vụ mục đích không.
- Lập kế hoạch theo kiểu vừa-kịp-lúc (
JIT planning): một roadmap 6 tháng nhanh chóng lỗi thời, nên đội làm ít pre-planning hơn và thay nghi thức design-doc bằng prototype và PR. - Trong tranh luận kỹ thuật, code thắng: thay vì lên bảng trắng, hãy sinh nhiều PR (Fiona đã tạo ba) để so sánh không chỉ cách hiện thực mà cả tác động lên mọi nơi gọi API — nhưng phải xây văn hóa để không bao giờ là "ai check-in cuối thì thắng".
- Kiểm chứng là khu vực đầu tư mới: "shift left" với nhiều tự động hóa hơn để bắt lỗi sớm, giúp mọi người ở mọi vai trò tự tin hơn với thay đổi của mình khi throughput tăng.
- Tin Claude cho styling, lint, phản hồi PR, bắt/sửa bug và thêm test; giữ con người cho review pháp lý, code bảo mật/biên giới tin cậy, và "gu" sản phẩm (minh họa qua Claude-người-tuyết trông giống nhân vật Mr. Peanut).
- Cơ cấu đội ưu tiên hai hồ sơ kỹ sư — người xây dựng sáng tạo có gu sản phẩm, và chuyên gia hệ thống chuyên sâu (ví dụ distributed systems cho Claude Code remote) — và ít ưu tiên throughput thô; vai trò đang mờ dần khi PM viết code và kỹ sư làm content/design nhờ Claude.
- Giữ tổ chức phẳng và gọn nhẹ: mọi quản lý bắt đầu làm IC trước để dogfood và tạo uy tín, code (cùng spec được check-in) là nguồn chân lý, và "Claudify mọi thứ có thể", trong khi vẫn để các pod tự chủ về workflow.
- Tín hiệu thành công: thời gian onboarding giảm mạnh, PR cycle time ngắn lại (cũng có thể lộ ra điểm nghẽn của CI/hạ tầng), và commit có Claude hỗ trợ tăng gần 100% — nhưng luôn gắn chỉ số với chất lượng và độ tin cậy sản phẩm, không chỉ số lượng.
dịch chuyển nút thắt cổ chai— sự dời điểm nghẽn từ throughput code sang kiểm chứng, review (bottleneck shift)âm thầm ngừng hiệu quả— khi một quy trình từng hữu ích trở nên lỗi thời mà không ai để ý (quietly stops working)JIT planning— lập kế hoạch "vừa kịp lúc" thay vì roadmap dài hạn (just-in-time planning)shift left— đẩy việc phát hiện lỗi và kiểm chứng lên sớm hơn trong pipeline (shift left)dogfooding— tự dùng sản phẩm của mình hằng ngày (dogfooding)routines— tự động hóa chạy theo lịch hoặc trigger trong Claude Code (routines)Claudify— giao một workflow thủ công cho Claude khi có thể (Claudify)nguồn chân lý— tài liệu/đối tượng có thẩm quyền mà đội dựa vào, ở đây là codebase (source of truth)pod— đội con nhỏ trong Claude Code có quyền tự chủ điều chỉnh nghi thức riêng (pod)tin nhưng phải kiểm chứng— dựa vào Claude nhưng giữ chuyên gia con người ở khâu rủi ro cao (trust but verify)
Sự dịch chuyển: nút thắt cổ chai đã thay đổi
Fiona Fung — dẫn dắt engineering và product của Claude Code và Cowork, từng lãnh đạo các đội ở Meta và Microsoft — chia sẻ những bài học khi xây dựng đội ngũ AI-native. Thông điệp lặp đi lặp lại của cô: "điều từng phục vụ bạn có thể không còn phù hợp nữa". Suốt nhiều năm, năng lực kỹ thuật (engineering bandwidth) là thứ đắt đỏ, và mọi quy trình ship phần mềm — từ waterfall đến agile — đều xây quanh giả định đó. Cô liên hệ tới đầu những năm 2000 khi làm Visual Studio 2005, lúc phần mềm còn ship qua CD-ROM và đĩa mềm với deadline cứng. Khi phân phối phần mềm online ra đời, cách ship thay đổi. Giờ đây nút thắt mới là: engineering bandwidth không còn đắt đỏ; trên đội Claude Code, code hiếm khi là khâu chậm và throughput tăng vọt.
Khi nút thắt rời khỏi việc gõ code (viết code, viết test, refactoring từng tốn kém), nó chuyển sang các khu vực khác: kiểm chứng, review, đối tác liên chức năng, bảo mật. Câu hỏi hàng đầu từ các lãnh đạo kỹ thuật là: con người làm sao theo kịp việc review, và bảo trì ra sao khi giờ ai cũng dễ dàng sinh ra nhiều code.
Những quy trình "âm thầm ngừng hiệu quả"
Fiona thích cụm từ "quietly stops working": ta đặt ra quy trình vì có lý do, nhưng hiếm khi quy trình tự khai tử — ta cứ chồng thêm. Cô kể về một đội có quá nhiều SLA đến mức phải stack-rank để kỹ sư biết SLA nào quan trọng hơn. Các nghi thức lập kế hoạch, quyền sở hữu code, review, cơ cấu đội (khi vai trò mờ dần, đối tác phi kỹ thuật cũng ship code) và chia sẻ kiến thức — tất cả đều đang thay đổi.
Các chuẩn mực được viết lại trên đội Claude Code
Lập kế hoạch (JIT planning): đội làm ít hơn nhiều. Một roadmap 6 tháng chỉ tốt được 3 tháng rồi lỗi thời, nên cô chuyển sang "vừa kịp lúc". Nghi thức design-doc trước mỗi lần code bị giảm; phần lớn thảo luận diễn ra qua PR và prototype thay vì doc, và ít product review vì bối cảnh thay đổi nhanh — "tìm được ý tưởng thì đi prototype".
Tranh luận kỹ thuật — code thắng: khi muốn refactoring để học codebase, thay vì lên bảng trắng với Boris, Fiona sinh ba PR. Điều này cho phép tranh luận không chỉ về cách hiện thực API mà cả tác động lên mọi nơi gọi vào API. Nhưng "xây dựng rẻ thì tranh luận đắt" làm văn hóa căn chỉnh càng quan trọng — tuyệt đối không để "ai check-in cuối thì thắng".
Kiểm chứng — khu vực đầu tư mới: vì throughput khác đi và có những cách hỏng mới, cô nhấn mạnh "shift left" — tự động hóa để bắt lỗi sớm gần nguồn. Khi vai trò mờ dần, designer cũng cần tự tin rằng code mình check-in không làm hỏng thứ khác.
Quyền sở hữu code: câu "ai làm thay đổi này?" giờ kỳ lạ vì PR đều có Claude hỗ trợ. Thay vào đó hãy "double-click" vào câu hỏi thật sự: đang tìm ai gây regression, hay tìm chuyên gia trả lời khách hàng, hay tìm ngữ cảnh? Rồi tự động hóa nếu được — ví dụ nghi thức tóm tắt kênh feedback buổi sáng nay đã thành một routine.
Review, cơ cấu đội và "gu" sản phẩm
Đội dựa nhiều vào Claude code review. Vấn đề là tin Claude ở đâu và giữ con người ở đâu. Claude làm tốt việc "trông" PR — styling, lint, phản hồi PR, bắt/sửa bug, thêm test. Con người vẫn cần cho chuyên môn theo nguyên tắc "tin nhưng phải kiểm chứng": review pháp lý, biên giới tin cậy và code nhạy cảm về bảo mật, và "gu" sản phẩm. Fiona kể chuyện vui khi nhờ Claude biến Claude thành người tuyết bằng ASCII art, nhưng đối tác design nhận xét nó giống nhân vật Mr. Peanut — minh họa giá trị của product sense.
Về cơ cấu đội, cô ưu tiên hai hồ sơ: người xây dựng sáng tạo có gu sản phẩm (những "người mơ mộng", tò mò, lặp đi lặp lại để có trải nghiệm thú vị) và chuyên gia hệ thống chuyên sâu (như distributed systems cho Claude Code remote). Cô ít ưu tiên throughput thô vì model đã giúp hiệu quả hơn nhiều. Vai trò mờ dần: PM viết code, còn kỹ sư nhờ Claude làm content/design (Claude từng là "đối tác content design" giúp cô viết survey ngắn gọn cho terminal).
Cơ cấu tổ chức, nguồn chân lý và cách triển khai
Org shape (chủ đề "gây tranh cãi"): thay vì tỷ lệ 10 IC trên 1 quản lý, Fiona giữ tổ chức phẳng và gọn. Cô yêu cầu mọi quản lý bắt đầu làm IC trước để dogfood, tạo uy tín và học cách làm kỹ sư hiệu quả — dù recruiter ban đầu nghĩ không quản lý nào chịu. Dogfooding mạnh là điều giúp cô ship sản phẩm tốt suốt sự nghiệp.
Nguồn chân lý: trên Claude Code, code là source of truth, giúp tránh độ trễ giữa tài liệu và code. Nếu đội có spec tốt, hãy check vào repo và để Claude kiểm tra code khớp spec.
Triển khai: có sự pha trộn giữa chuẩn mực bắt buộc (cần căn chỉnh toàn đội) và quyền tự chủ cho từng pod. Các nguyên tắc cốt lõi gồm "Claudify mọi thứ có thể" và — yêu thích nhất — "quyền tường minh để khai tử quy trình cũ" (ví dụ stand-up từng là spreadsheet rồi thành một skill chạy bằng Claude). Cô để các pod tự chủ về triage, planning, stand-up, on-call và workflow nào nên Claudify trước.
Đo lường và tự rà soát
Ba tín hiệu thành công: thời gian onboarding giảm mạnh; PR cycle time ngắn lại (cũng có thể lộ điểm nghẽn CI/hạ tầng); và commit có Claude hỗ trợ tăng gần 100% (cô không thấy commit nào không có Claude hỗ trợ suốt ~4 tháng). Nhưng luôn gắn chỉ số với mục tiêu cuối — chất lượng và độ tin cậy sản phẩm, không chỉ số lượng code do AI sinh ra. Cô vẫn còn câu hỏi mở: liệu cơ cấu iOS/Android tách biệt còn hợp lý không; đẩy review tự động tới đâu; và vì model liên tục cải thiện nên cần định kỳ đánh giá lại "tin" hay "kiểm chứng". Lời khuyên cuối: hãy chọn workflow "ồn ào" nhất — đắt nhất hoặc khiến đội ngại nhất — và hỏi nó còn phục vụ mục đích gì không, như câu chuyện cô hủy một cuộc họp review hằng tuần 50 người chỉ bằng câu hỏi "tại sao ta vẫn họp?".
TL;DR
- Fiona Fung, người dẫn dắt mảng engineering và product của
Claude CodevàCowork, chia sẻ cách đội ngũ viết lại các chuẩn mực làm việc khi AI dịch chuyển nút thắt cổ chai từ năng lực kỹ thuật (engineering bandwidth) sang khâu kiểm chứng, review, bảo mật và phối hợp liên chức năng. - Các thay đổi cụ thể gồm: lập kế hoạch "vừa kịp lúc" (JIT planning), giải quyết tranh luận kỹ thuật bằng cách sinh nhiều PR thay vì lên bảng trắng, đầu tư mạnh vào kiểm chứng và tự động hóa "shift left", và tin tưởng Claude có chọn lọc cho việc review nhưng giữ con người cho pháp lý, bảo mật và "gu" sản phẩm.
- Triết lý xuyên suốt là "điều từng phục vụ bạn có thể không còn phù hợp nữa" — giữ growth mindset, cho các pod quyền tường minh để "khai tử" quy trình cũ, giữ tổ chức phẳng, dogfooding mạnh, và rà soát lại quy trình "ồn ào" nhất của bạn.
Điểm chính
- Nút thắt cổ chai đã dịch chuyển: trước đây engineering bandwidth và throughput code là thứ đắt đỏ, nhưng giờ code hiếm khi là khâu chậm, nên nút thắt chuyển sang kiểm chứng, code review, đối tác liên chức năng và bảo mật.
- Quy trình "âm thầm ngừng hiệu quả" — các đội thường chồng thêm quy trình (như chất đống SLA) mà ít khi loại bỏ, nên người dẫn dắt cần quyền tường minh để khai tử quy trình cũ và rà soát xem chúng còn phục vụ mục đích không.
- Lập kế hoạch theo kiểu vừa-kịp-lúc (
JIT planning): một roadmap 6 tháng nhanh chóng lỗi thời, nên đội làm ít pre-planning hơn và thay nghi thức design-doc bằng prototype và PR. - Trong tranh luận kỹ thuật, code thắng: thay vì lên bảng trắng, hãy sinh nhiều PR (Fiona đã tạo ba) để so sánh không chỉ cách hiện thực mà cả tác động lên mọi nơi gọi API — nhưng phải xây văn hóa để không bao giờ là "ai check-in cuối thì thắng".
- Kiểm chứng là khu vực đầu tư mới: "shift left" với nhiều tự động hóa hơn để bắt lỗi sớm, giúp mọi người ở mọi vai trò tự tin hơn với thay đổi của mình khi throughput tăng.
- Tin Claude cho styling, lint, phản hồi PR, bắt/sửa bug và thêm test; giữ con người cho review pháp lý, code bảo mật/biên giới tin cậy, và "gu" sản phẩm (minh họa qua Claude-người-tuyết trông giống nhân vật Mr. Peanut).
- Cơ cấu đội ưu tiên hai hồ sơ kỹ sư — người xây dựng sáng tạo có gu sản phẩm, và chuyên gia hệ thống chuyên sâu (ví dụ distributed systems cho Claude Code remote) — và ít ưu tiên throughput thô; vai trò đang mờ dần khi PM viết code và kỹ sư làm content/design nhờ Claude.
- Giữ tổ chức phẳng và gọn nhẹ: mọi quản lý bắt đầu làm IC trước để dogfood và tạo uy tín, code (cùng spec được check-in) là nguồn chân lý, và "Claudify mọi thứ có thể", trong khi vẫn để các pod tự chủ về workflow.
- Tín hiệu thành công: thời gian onboarding giảm mạnh, PR cycle time ngắn lại (cũng có thể lộ ra điểm nghẽn của CI/hạ tầng), và commit có Claude hỗ trợ tăng gần 100% — nhưng luôn gắn chỉ số với chất lượng và độ tin cậy sản phẩm, không chỉ số lượng.
Từ vựng
dịch chuyển nút thắt cổ chai— sự dời điểm nghẽn từ throughput code sang kiểm chứng, review (bottleneck shift)âm thầm ngừng hiệu quả— khi một quy trình từng hữu ích trở nên lỗi thời mà không ai để ý (quietly stops working)JIT planning— lập kế hoạch "vừa kịp lúc" thay vì roadmap dài hạn (just-in-time planning)shift left— đẩy việc phát hiện lỗi và kiểm chứng lên sớm hơn trong pipeline (shift left)dogfooding— tự dùng sản phẩm của mình hằng ngày (dogfooding)routines— tự động hóa chạy theo lịch hoặc trigger trong Claude Code (routines)Claudify— giao một workflow thủ công cho Claude khi có thể (Claudify)nguồn chân lý— tài liệu/đối tượng có thẩm quyền mà đội dựa vào, ở đây là codebase (source of truth)pod— đội con nhỏ trong Claude Code có quyền tự chủ điều chỉnh nghi thức riêng (pod)tin nhưng phải kiểm chứng— dựa vào Claude nhưng giữ chuyên gia con người ở khâu rủi ro cao (trust but verify)
Nội dung chi tiết
Sự dịch chuyển: nút thắt cổ chai đã thay đổi
Fiona Fung — dẫn dắt engineering và product của Claude Code và Cowork, từng lãnh đạo các đội ở Meta và Microsoft — chia sẻ những bài học khi xây dựng đội ngũ AI-native. Thông điệp lặp đi lặp lại của cô: "điều từng phục vụ bạn có thể không còn phù hợp nữa". Suốt nhiều năm, năng lực kỹ thuật (engineering bandwidth) là thứ đắt đỏ, và mọi quy trình ship phần mềm — từ waterfall đến agile — đều xây quanh giả định đó. Cô liên hệ tới đầu những năm 2000 khi làm Visual Studio 2005, lúc phần mềm còn ship qua CD-ROM và đĩa mềm với deadline cứng. Khi phân phối phần mềm online ra đời, cách ship thay đổi. Giờ đây nút thắt mới là: engineering bandwidth không còn đắt đỏ; trên đội Claude Code, code hiếm khi là khâu chậm và throughput tăng vọt.
Khi nút thắt rời khỏi việc gõ code (viết code, viết test, refactoring từng tốn kém), nó chuyển sang các khu vực khác: kiểm chứng, review, đối tác liên chức năng, bảo mật. Câu hỏi hàng đầu từ các lãnh đạo kỹ thuật là: con người làm sao theo kịp việc review, và bảo trì ra sao khi giờ ai cũng dễ dàng sinh ra nhiều code.
Những quy trình "âm thầm ngừng hiệu quả"
Fiona thích cụm từ "quietly stops working": ta đặt ra quy trình vì có lý do, nhưng hiếm khi quy trình tự khai tử — ta cứ chồng thêm. Cô kể về một đội có quá nhiều SLA đến mức phải stack-rank để kỹ sư biết SLA nào quan trọng hơn. Các nghi thức lập kế hoạch, quyền sở hữu code, review, cơ cấu đội (khi vai trò mờ dần, đối tác phi kỹ thuật cũng ship code) và chia sẻ kiến thức — tất cả đều đang thay đổi.
Các chuẩn mực được viết lại trên đội Claude Code
Lập kế hoạch (JIT planning): đội làm ít hơn nhiều. Một roadmap 6 tháng chỉ tốt được 3 tháng rồi lỗi thời, nên cô chuyển sang "vừa kịp lúc". Nghi thức design-doc trước mỗi lần code bị giảm; phần lớn thảo luận diễn ra qua PR và prototype thay vì doc, và ít product review vì bối cảnh thay đổi nhanh — "tìm được ý tưởng thì đi prototype".
Tranh luận kỹ thuật — code thắng: khi muốn refactoring để học codebase, thay vì lên bảng trắng với Boris, Fiona sinh ba PR. Điều này cho phép tranh luận không chỉ về cách hiện thực API mà cả tác động lên mọi nơi gọi vào API. Nhưng "xây dựng rẻ thì tranh luận đắt" làm văn hóa căn chỉnh càng quan trọng — tuyệt đối không để "ai check-in cuối thì thắng".
Kiểm chứng — khu vực đầu tư mới: vì throughput khác đi và có những cách hỏng mới, cô nhấn mạnh "shift left" — tự động hóa để bắt lỗi sớm gần nguồn. Khi vai trò mờ dần, designer cũng cần tự tin rằng code mình check-in không làm hỏng thứ khác.
Quyền sở hữu code: câu "ai làm thay đổi này?" giờ kỳ lạ vì PR đều có Claude hỗ trợ. Thay vào đó hãy "double-click" vào câu hỏi thật sự: đang tìm ai gây regression, hay tìm chuyên gia trả lời khách hàng, hay tìm ngữ cảnh? Rồi tự động hóa nếu được — ví dụ nghi thức tóm tắt kênh feedback buổi sáng nay đã thành một routine.
Review, cơ cấu đội và "gu" sản phẩm
Đội dựa nhiều vào Claude code review. Vấn đề là tin Claude ở đâu và giữ con người ở đâu. Claude làm tốt việc "trông" PR — styling, lint, phản hồi PR, bắt/sửa bug, thêm test. Con người vẫn cần cho chuyên môn theo nguyên tắc "tin nhưng phải kiểm chứng": review pháp lý, biên giới tin cậy và code nhạy cảm về bảo mật, và "gu" sản phẩm. Fiona kể chuyện vui khi nhờ Claude biến Claude thành người tuyết bằng ASCII art, nhưng đối tác design nhận xét nó giống nhân vật Mr. Peanut — minh họa giá trị của product sense.
Về cơ cấu đội, cô ưu tiên hai hồ sơ: người xây dựng sáng tạo có gu sản phẩm (những "người mơ mộng", tò mò, lặp đi lặp lại để có trải nghiệm thú vị) và chuyên gia hệ thống chuyên sâu (như distributed systems cho Claude Code remote). Cô ít ưu tiên throughput thô vì model đã giúp hiệu quả hơn nhiều. Vai trò mờ dần: PM viết code, còn kỹ sư nhờ Claude làm content/design (Claude từng là "đối tác content design" giúp cô viết survey ngắn gọn cho terminal).
Cơ cấu tổ chức, nguồn chân lý và cách triển khai
Org shape (chủ đề "gây tranh cãi"): thay vì tỷ lệ 10 IC trên 1 quản lý, Fiona giữ tổ chức phẳng và gọn. Cô yêu cầu mọi quản lý bắt đầu làm IC trước để dogfood, tạo uy tín và học cách làm kỹ sư hiệu quả — dù recruiter ban đầu nghĩ không quản lý nào chịu. Dogfooding mạnh là điều giúp cô ship sản phẩm tốt suốt sự nghiệp.
Nguồn chân lý: trên Claude Code, code là source of truth, giúp tránh độ trễ giữa tài liệu và code. Nếu đội có spec tốt, hãy check vào repo và để Claude kiểm tra code khớp spec.
Triển khai: có sự pha trộn giữa chuẩn mực bắt buộc (cần căn chỉnh toàn đội) và quyền tự chủ cho từng pod. Các nguyên tắc cốt lõi gồm "Claudify mọi thứ có thể" và — yêu thích nhất — "quyền tường minh để khai tử quy trình cũ" (ví dụ stand-up từng là spreadsheet rồi thành một skill chạy bằng Claude). Cô để các pod tự chủ về triage, planning, stand-up, on-call và workflow nào nên Claudify trước.
Đo lường và tự rà soát
Ba tín hiệu thành công: thời gian onboarding giảm mạnh; PR cycle time ngắn lại (cũng có thể lộ điểm nghẽn CI/hạ tầng); và commit có Claude hỗ trợ tăng gần 100% (cô không thấy commit nào không có Claude hỗ trợ suốt ~4 tháng). Nhưng luôn gắn chỉ số với mục tiêu cuối — chất lượng và độ tin cậy sản phẩm, không chỉ số lượng code do AI sinh ra. Cô vẫn còn câu hỏi mở: liệu cơ cấu iOS/Android tách biệt còn hợp lý không; đẩy review tự động tới đâu; và vì model liên tục cải thiện nên cần định kỳ đánh giá lại "tin" hay "kiểm chứng". Lời khuyên cuối: hãy chọn workflow "ồn ào" nhất — đắt nhất hoặc khiến đội ngại nhất — và hỏi nó còn phục vụ mục đích gì không, như câu chuyện cô hủy một cuộc họp review hằng tuần 50 người chỉ bằng câu hỏi "tại sao ta vẫn họp?".