Vận Hành Một Tổ Chức Kỹ Thuật AI-Native
Điểm chính
- Khi agentic coding trở thành cách làm việc mặc định, các quy trình cũ như planning dài hạn, context gathering thủ công và review mọi thứ bằng người đều phải được viết lại.
- Claude Code không chỉ thay đổi tốc độ viết code; nó làm thay đổi cả cách tổ chức team, cách giao quyền, và cách đo xem workflow nào còn đáng giữ.
- Để chuyển sang mô hình AI-native, bạn cần vừa thay đổi quy trình, vừa tạo kỷ luật dùng công cụ, vừa sẵn sàng bỏ các nghi thức cũ không còn giá trị.
Nhiều năm qua, bandwidth của engineering luôn là phần đắt nhất khi xây ứng dụng. Toàn bộ quy trình chúng ta từng dùng để planning và shipping phần mềm — ban đầu là waterfall, rồi đến agile — đều được thiết kế xoay quanh chi phí đó.
Fiona Fung, Director of Engineering cho Claude Code và Claude Cowork, kể rằng cô bắt đầu sự nghiệp đầu những năm 2000 ở Visual Studio. Hồi đó, phần mềm còn được ship trên CD-ROM và bị buộc bởi các deadline sản xuất cứng. Khi việc phân phối chuyển sang online, team bắt đầu tăng dần tần suất release và cập nhật liên tục. Còn bây giờ, một lần nữa cách làm việc lại thay đổi, lần này xoay quanh thời gian và con người cần để viết phần mềm.
Ở Claude Code team, việc viết code, viết test và refactor giờ hiếm khi là nút thắt nữa. Nhưng bottleneck không biến mất khi agentic coding thay thế phần thao tác gõ code. Nó chỉ chuyển sang chỗ khác: verification, code review và security.
Bạn có thể tạo ra rất nhiều code rất nhanh, nhưng lập tức nảy ra những câu hỏi mới: code này có đúng không, ai sẽ maintain nó, và làm sao để con người theo kịp tốc độ review code khi AI đang tăng throughput quá nhanh?
Những quy trình cũ lặng lẽ ngừng hoạt động
Ta thường đặt quy trình vào chỗ nào đó vì nó giải quyết một khoảng trống hoặc giúp mọi thứ chạy tốt hơn. Nhưng khi khoảng trống đó không còn tồn tại nữa, những quy trình ấy hiếm khi tự biến mất.
Khi Claude Code team bắt đầu dùng agentic coding như cách làm việc mặc định, rất nhiều quy trình hiện có đã không còn hoạt động như cũ. Dưới đây là các norm được viết lại, và lý do.
Planning: chuyển roadmap sang just-in-time
Norm cũ là dành nhiều thời gian hơn cho pre-planning vì chi phí coding trước đây rất đắt. Khi Fiona mới gia nhập Claude Code team, họ viết một roadmap 6 tháng khá tốt. Nhưng vì Claude Code làm mọi thứ thay đổi quá nhanh, đến tháng thứ ba roadmap đó đã lỗi thời.
Engineering speed và throughput bây giờ đã khác, nên cách lên sprint cũng thay đổi. Fiona gọi đây là just-in-time planning, gần giống JIT compiling: làm đúng lượng việc cần thiết, đúng lúc cần thiết. Nghi thức planning chuyển từ design docs sang thảo luận ngay trong PR hoặc prototype. Vì thị trường thay đổi nhanh, team cũng không làm quá nhiều product review. Quy trình bây giờ là: prototype trước, đưa cho nhiều internal users dùng, rồi xử lý feedback của họ ngay.
Context gathering: hỏi Claude, không hỏi tác giả
Khi engineer còn tự viết code, bước đầu tiên để trả lời phần lớn câu hỏi là tìm đúng người đã viết đoạn code đó. Nhưng giờ đây, vì mọi PR đều có Claude hỗ trợ, câu hỏi “Ai tạo thay đổi này?” không còn đủ nữa.
Norm mới là đi sâu hơn một tầng: bạn thực sự cần biết điều gì? Ví dụ: bạn đang muốn tìm ai gây ra regression, cần một chuyên gia để trả lời câu hỏi của khách hàng, hay chỉ cần context cho một quyết định? Hãy hỏi Claude theo hướng đó, và kiểm tra xem Claude có thể trả lời trực tiếp không, có thể dùng thêm dữ liệu và context không.
Ở Claude Code team, bất kể câu hỏi nào, họ cũng tự hỏi thêm: “Có cách nào tự động hóa việc này không?” Chẳng hạn, việc để Claude tóm tắt customer feedback channels mỗi sáng từ một nghi thức thủ công cùng ly cà phê đã trở thành một thứ chạy tự động ở nền.
Code review: trust but verify
Team dùng Code Review rất nhiều. Claude lo toàn bộ phần style và linting, xử lý các request phản hồi trên PR, bắt bug rồi sửa trước khi commit đầy đủ, và thêm test.
Chỗ họ vẫn muốn có con người là phần chuyên môn sâu. Với legal review, Fiona luôn muốn legal partner tham gia để đánh giá mức chấp nhận rủi ro. Với trust boundaries và code nhạy cảm về security, cô muốn domain expert cùng xem. Product manager và designer cũng cần tham gia khi vấn đề liên quan đến product sense và taste.
Điều quan trọng là phải liên tục đánh giá lại, vì mức cân bằng giữa trust và verify sẽ thay đổi khi model tiến bộ. Những gì bạn cần con người xử lý hôm nay có thể khác với model tiếp theo.
Team makeup: làm mờ vai trò
Claude và AI đã làm thay đổi vai trò của mọi người trong team. PM giờ code nhiều hơn hẳn, và đó là một điều rất thú vị để thấy. Với Claude, những người vốn không phải lập trình viên giờ có thể làm nhiều engineering hơn, còn engineer thì bắt đầu nhận thêm các việc như content và design — những thứ trước đây không nằm ở phía kỹ thuật.
Trong engineering team của Claude Code, Fiona tập trung mạnh vào hai profile. Một là creative builders có product sense: những người thích tưởng tượng, tò mò sâu và đam mê ship sản phẩm giải quyết vấn đề. Profile còn lại là engineer có deep systems expertise. Ví dụ, khi cô gia nhập team, cô nhận ra đội đang thiếu các chuyên gia hệ thống. Điều đó trở nên rất cần thiết khi xây Claude Code on the Web, vì team cần bảo đảm Claude chạy được ở mọi nơi.
Điều cô chú ý ít hơn là raw throughput; phần đó model xử lý rồi. Câu hỏi quan trọng hơn là ở đâu vẫn cần human expertise, và đó mới là chỗ nên tập trung.
Bảng before/after
Planning
- Trước: roadmap sản phẩm 6 tháng.
- Sau: just-in-time planning; prototype, đưa cho internal users, rồi xử lý phản hồi.
Context gathering
- Trước: tìm đúng người viết code rồi hỏi họ.
- Sau: hỏi Claude trước; rồi kiểm tra xem câu hỏi đó có thể tự động hóa không.
Code review
- Trước: con người review mọi thứ.
- Sau: Claude xử lý style, bug và test; con người review ở những chỗ cần domain expertise.
Team makeup
- Trước: vai trò cố định — engineer viết code, PM lên kế hoạch, designer thiết kế.
- Sau: vai trò mờ đi — PM prototype, engineer làm thêm design và context; tuyển theo creative builders và deep systems expertise.
Cách họ rollout các norm mới
Khi các norm này thay đổi, một số phần được áp đặt như nguyên tắc cứng của team, còn một số khác thì để các pod nhỏ tự tìm cách làm.
Claude Code core team có một số nguyên tắc “must do” không thể thương lượng:
Dogfood sản phẩm của chính mình một cách triệt để
Mọi thành viên trong team Claude Code, kể cả các đối tác cross-functional, đều dùng Claude Code và cả Claude Cowork. Họ luôn tìm cách để Claude giúp họ làm việc nhanh hơn và hiệu quả hơn.
Giữ team phẳng nhất có thể
Khi Fiona gia nhập Claude Code, cô muốn mọi manager ban đầu phải đi từ IC trước, học cách trở thành engineer hiệu quả bằng cách ship, rồi thật sự sống qua và hiểu cảm giác làm engineer ở Anthropic là như thế nào.
Team Claude Code và Claude Cowork chỉ có một mission chung. Managers hỗ trợ các pod công việc nhưng vẫn giữ team linh hoạt, để người ta có thể chuyển sang nơi nào có việc cần làm.
Không ngại giết những quy trình không còn tác dụng
Cuối cùng, team liên tục đặt câu hỏi vì sao mình làm mọi thứ theo cách hiện tại. Khi một thứ không còn hợp lý nữa, các thành viên có quyền rõ ràng để chất vấn và khai tử quy trình cũ.
Trong khuôn khổ vài nguyên tắc đó, mỗi pod vẫn có khá nhiều quyền tự chủ. Họ có không gian để điều chỉnh cách dùng Claude cho triage, cách tổ chức planning ritual hoặc standup, và workflow nào sẽ được “Claudify” trước.
Làm sao biết các quy trình mới đã ăn vào team
Fiona đưa ra ba chỉ số mà mọi engineering leader nên bắt đầu theo dõi khi rollout thay đổi.
Onboarding ramp time giảm xuống
Bao lâu thì một engineer, designer hoặc PM bắt đầu làm việc hiệu quả? Trong team của cô, tốc độ này nhanh hơn hẳn một năm trước, và engineer giờ có thể ship code thật ngay trong tuần đầu tiên.
PR cycle time giảm xuống
Đây là chỉ số đáng xem sâu hơn vì nó có thể giúp bạn nhận ra pipeline của mình đang nghẽn ở đâu khi scale. Khi team tạo ra nhiều code hơn, build system và continuous integration (CI) đôi khi sẽ không theo kịp.
Claude-assisted commits tăng lên
Ở Claude Code, mặc định mỗi commit đều có Claude hỗ trợ. Fiona nói cô gần như chưa thấy commit nào không có Claude hỗ trợ trong bốn tháng gần đây.
Nhưng đừng nhầm throughput với thành công. Throughput chỉ là một metric; metric thật là thứ bạn đang cố giải quyết. Khi có alignment đúng, throughput sẽ giúp bạn giải quyết vấn đề nhanh hơn, chứ không phải là mục tiêu tự thân.
Bắt đầu từ đâu
Nếu chỉ để lại một lời khuyên, Fiona muốn bạn chọn workflow ồn ào nhất của mình. Đó có thể là workflow tốn kém nhất, một việc bạn hay né, hoặc thứ mà team không thích làm. Rồi hỏi: nó còn thực sự phục vụ mục đích của nó không? Nếu có, có thể tự động hóa nó được không?
Cô từng ở trong một team có một buổi review hằng tuần rất tốn kém, với cả đám người ngồi trong phòng họp. Cô nhận ra mọi người đều mở laptop, chỉ ngẩng đầu lên khi đến lượt mình báo cáo trạng thái, rồi lại cúi xuống laptop. Cô hỏi một câu rất đơn giản: “Tại sao chúng ta còn họp này nữa? Có vẻ nó đang làm tốn thời gian của mọi người.” Chỉ một câu đó đã khiến cả team nhận ra cuộc họp không cần thiết, và họ hủy nó.
Vậy nên câu hỏi dành cho bạn là: workflow kỹ thuật nào trong team của bạn có thể nên được tự động hóa, hoặc thậm chí bỏ hẳn?
Kết luận
Chuyển sang tổ chức kỹ thuật AI-native không chỉ là đổi công cụ viết code. Nó kéo theo việc viết lại planning, context gathering, code review, cách chia vai trong team và cả cách bạn đo xem quy trình nào còn xứng đáng tồn tại.
Điểm mấu chốt là dùng Claude để giảm những việc đắt và ồn ào nhất, rồi giữ con người ở đúng chỗ họ tạo ra giá trị cao nhất: phán đoán chuyên môn, ranh giới tin cậy, và taste.
Nếu một workflow không còn phục vụ mục đích của nó, cứ mạnh dạn viết lại hoặc bỏ nó đi.
Bình luận