- Cấu trúc khiến tốc độ xử lý công việc chậm đi theo cấp số nhân khi số bước phê duyệt·kiểm tra trong tổ chức tăng lên được giải thích, kèm các ví dụ thực tế cho thấy mỗi bước phê duyệt gây ra độ trễ khoảng 10 lần
- Dù các công cụ AI coding có thể tăng mạnh tốc độ viết mã, độ trễ (latency) của pipeline review phía sau không giảm, nên hiệu quả cải thiện tốc độ tổng thể là rất nhỏ
- Áp dụng triết lý chất lượng trong sản xuất của W. E. Deming vào phần mềm, bài viết chỉ ra rằng cách thêm các bước QA lại làm xấu đi cả chất lượng lẫn tốc độ
- Cần giảm review nhưng đồng thời thay thế bằng văn hóa chất lượng dựa trên mô-đun hóa và niềm tin, và điểm cốt lõi là cải tiến cấu trúc để bản thân review trở nên không còn cần thiết
- Các nhóm nhỏ có lợi thế trong thời đại AI, và cần tái thiết kế tổ chức lẫn hệ thống theo cách kết hợp các thành phần nhỏ mà đẹp
Quy luật: các bước review tạo ra độ trễ gấp 10 lần
- Tương tự quy luật hiệu ứng mạng, khi quy mô nhóm tăng lên sẽ phát sinh chi phí điều phối, nên tăng gấp đôi nhân sự không đồng nghĩa tốc độ cũng tăng gấp đôi
- Một kinh nghiệm thực tế từ nhiều thập kỷ trước: mỗi khi thêm một bước review, toàn bộ quy trình chậm đi 10 lần
- Không có cơ sở lý thuyết chặt chẽ, nhưng đây là hiện tượng lặp đi lặp lại trong thực tế
- Thời gian được đo ở đây không phải nỗ lực (effort) mà là thời gian trôi theo đồng hồ thực tế (wall clock time), và phần lớn thời gian tăng thêm là thời gian chờ
- Ví dụ cụ thể:
- Viết mã để sửa một lỗi đơn giản: 30 phút
- Code review bởi đồng nghiệp ngồi cạnh: 300 phút (khoảng 5 giờ, nửa ngày)
- Phê duyệt tài liệu thiết kế từ đội kiến trúc sư: 50 giờ (khoảng 1 tuần)
- Đưa vào lịch trình của đội khác (ví dụ: yêu cầu tính năng từ khách hàng): 500 giờ (12 tuần, 1 quý tài chính)
- Ngay cả bước tiếp theo là 10 quý (khoảng 2,5 năm) cũng không phải điều phi thực tế; ở một công ty tương đối nhỏ như Tailscale, mức độ chậm trễ này vẫn xảy ra khi đổi hướng sản phẩm
AI không thể giải quyết vấn đề này
- Dù Claude có thể làm xong phần coding 30 phút chỉ trong 3 phút, bạn vẫn chỉ có hai lựa chọn: tiết kiệm 27 phút để tự lặp lại review với AI, hoặc đưa đoạn mã chưa được kiểm chứng cho reviewer
- Reviewer vẫn phải mất 5 giờ, và nếu bạn chuyển tiếp đoạn mã mà chính mình còn chưa đọc thì reviewer sẽ khó chịu
- Người ta nói giá trị thật của agentic coding là hoàn thành dự án lớn mất 1 tuần chỉ trong vài giờ, nhưng kết quả thường quá lớn để reviewer kiểm tra trong một lần
- Phải chia nhỏ ra, và mỗi phần lại phát sinh chu kỳ review 5 giờ
- Không có tài liệu thiết kế nên cũng không có kiến trúc có chủ đích, cuối cùng lại quay về các cuộc họp review thiết kế
- Kết quả là dự án hoàn thành trong 2 giờ lại quay về thành 1 tuần
Cách duy nhất là giảm review
- Tiền đề của lý thuyết điểm kỳ dị (Singularity): hệ thống ngày càng thông minh hơn tạo ra những hệ thống còn thông minh hơn, và nếu thời gian cho mỗi đơn vị cải tiến tiến về 0 thì tăng trưởng sẽ bùng nổ
- Lý do để không tin vào lý thuyết này: phần lớn thời gian để hoàn thành một việc không phải thời gian làm thực tế mà là thời gian trôi thực tế, tức chờ đợi và trì hoãn
- Độ trễ không thể bị vượt qua bằng brute force
Chẳng lẽ lại không review?
- Nhiều người đã nhận ra triệu chứng này: bước đầu của pipeline (mã do AI tạo) nhanh hơn, nhưng các bước review phía sau mới là điểm nghẽn
- Giải pháp trực giác là: dừng review lại → kể cả sản phẩm có thô sơ, nếu rẻ hơn 100 lần thì chỉ cần tạo ra 1% giá trị là hòa vốn
- Nhưng bên dưới logic này là một giả định khá ngớ ngẩn
- Đường cong rơi vào điên loạn của nhà phát triển AI (AI Developer's Descent Into Madness):
- Tạo prototype nhanh đến kinh ngạc → cảm giác như có siêu năng lực
- Prototype phát sinh lỗi → bảo AI sửa
- Mỗi lần sửa đổi lại phát sinh bug mới đúng bằng số bug vừa sửa
- Tự lừa mình rằng nếu agent AI tự review code của nó thì nó sẽ tìm ra bug của chính nó
- Nhận ra bản thân đang trực tiếp chuyển dữ liệu qua lại giữa các agent
- Nhận thấy cần có framework cho agent
- Dùng agent để viết framework agent
- Quay lại bước 1
- Vì Claude Code chỉ mới thực sự dùng được từ vài tháng trước nên vòng lặp này cũng chỉ mới bắt đầu gần đây, và rất nhiều đồng nghiệp cùng những người được kính trọng đang mắc kẹt trong chu kỳ này
Vì sao người ta review
- Khi công ty phát triển, các bước cộng tác·review·quản lý tăng lên để ngăn sai sót, vì khi quy mô lớn hơn thì chi phí của sai lầm cũng tăng
- Sẽ đến lúc giá trị gia tăng trung bình của một tính năng mới thấp hơn tổn thất trung bình do bug mới mà nó gây ra
- Vì không có cách làm tăng giá trị của tính năng, tổ chức sẽ chuyển sang hướng giảm tổn thất
- Nếu tăng kiểm tra và kiểm soát, tốc độ sẽ chậm lại nhưng chất lượng có vẻ tăng đơn điệu (monotonically increasing), nên trông giống nền tảng cho cải tiến liên tục
- Nhưng “nhiều kiểm tra và kiểm soát hơn” không phải cách duy nhất để cải thiện chất lượng, mà còn là một cách nguy hiểm
“Đảm bảo chất lượng (QA)” lại làm giảm chất lượng
- Bài viết viện dẫn triết lý chất lượng mà W. E. Deming đã phổ biến trong ngành sản xuất ô tô Nhật Bản
- Vấn đề của bước QA trong nhà máy: làm widget → kiểm tra/QA → loại bỏ hàng không đạt → để tránh sót tiếp tục thêm QA vòng hai
- Trong mô hình toán học đơn giản, điều này nghe có lý (nếu mỗi bước QA bắt được 90% lỗi thì qua 2 bước sẽ giảm 100 lần)
- Nhưng trong môi trường có con người hành động tự chủ (agentic humans), incentive bị méo mó:
- Đội QA thứ hai có nhiệm vụ đánh giá đội QA thứ nhất → không có động lực tích cực để tìm ra thứ sẽ khiến đồng nghiệp bị sa thải
- Đội QA thứ nhất lại giảm nỗ lực vì kỳ vọng đội thứ hai sẽ bắt lỗi
- Đội làm widget cũng lơ là tự kiểm tra vì đã có QA đứng sau → tỷ lệ loại bỏ 10% nghe còn dễ chấp nhận hơn việc chậm thêm 20%
- Tái thiết kế kỹ thuật trên diện rộng để nâng chất lượng bị né tránh vì chi phí quá cao
- Toyota Production System đã loại bỏ hoàn toàn bước QA riêng biệt và trao cho mọi người nút “dừng dây chuyền”
- Các hãng ô tô Mỹ cũng lắp nút tương tự nhưng không ai bấm → vì sợ bị sa thải
Niềm tin (Trust)
- Sự khác biệt giữa hệ thống Nhật thành công và hệ thống Mỹ thất bại là niềm tin
- Niềm tin giữa cá nhân với nhau: cấp trên thực sự muốn biết về mọi khuyết tật và khi phát hiện thì nên dừng dây chuyền
- Niềm tin giữa các nhà quản lý: tin rằng ban lãnh đạo thực sự nghiêm túc với chất lượng
- Niềm tin trong ban lãnh đạo: tin rằng nếu có hệ thống và incentive đúng, mỗi cá nhân sẽ làm ra công việc chất lượng cao và tự phát hiện lỗi của mình
- Điều kiện bổ sung: phải có niềm tin rằng hệ thống thực sự hoạt động → trước hết cần một hệ thống hoạt động thật
Tính dễ sai (Fallibility)
- AI coder thường xuyên viết mã tệ, và ở điểm này thì không khác gì lập trình viên con người
- Cách tiếp cận của Deming không có lời giải ma thuật → kỹ sư phải thiết kế chất lượng theo hướng từ dưới lên cho toàn bộ hệ thống
- Mỗi khi có sự cố, cần hỏi “chuyện này đã xảy ra như thế nào?” rồi dùng postmortem và Five Whys để tìm nguyên nhân gốc và sửa nó
- “Coder đã làm sai” không phải nguyên nhân gốc mà chỉ là triệu chứng → cần tìm nguyên nhân cấu trúc khiến coder có thể phạm sai lầm đó
- Vai trò thật sự của code reviewer không phải là review code, mà là khiến chính các comment review của mình trở nên không còn cần thiết
- Cải thiện hệ thống để loại comment đó không còn xuất hiện trong tương lai
- Mục tiêu phải là trạng thái không cần review
- Ví dụ: những người tạo ra
go fmt → xóa sổ vĩnh viễn các comment review về khoảng trắng → đó mới là kỹ thuật thực sự
- Khi review phát hiện ra sai sót thì lỗi đã xảy ra rồi → nguyên nhân gốc đã trôi qua mất
Tính mô-đun (Modularity)
- Pipeline review (các bước QA) không hoạt động, làm chậm tốc độ và còn che giấu nguyên nhân gốc, khiến việc xử lý nguyên nhân càng khó hơn
- Sức hấp dẫn của AI coding nằm ở chỗ bước đầu của pipeline nhanh vượt trội → tạo cảm giác siêu năng lực
- Có lẽ đây là động lực đủ lớn để giải quyết những vấn đề bị văn hóa code review che khuất suốt 20 năm và thay thế bằng một văn hóa chất lượng thật sự
- Một nửa phe lạc quan là đúng: cần thu hẹp các bước review, nhưng nếu thu hẹp mà không có gì thay thế thì sẽ dẫn đến những thảm họa kiểu Ford Pinto hay máy bay Boeing gần đây
- Cũng như cách Deming đã mang tới cho ngành sản xuất, cần một cú lật bàn toàn bộ gói chuyển đổi (table flip) → hệ thống “chất lượng toàn diện” không thể chỉ áp dụng một nửa
- Muốn loại bỏ review thì đồng thời phải khiến nó trở nên không cần thiết
- Có thể áp dụng hoàn chỉnh hệ thống mới ở quy mô nhỏ:
- Giống như các hãng ô tô Mỹ kiểu cũ mua linh kiện chất lượng cao từ nhà cung cấp Nhật Bản
- Nếu linh kiện được làm tốt thì có thể bỏ nhiều bước QA ở nơi khác → độ phức tạp của việc “lắp ráp các bộ phận” giảm mạnh
- Có thể ghép các thứ nhỏ mà đẹp để tạo ra một thứ lớn mà đẹp
- Những nhóm nhỏ tin tưởng lẫn nhau sẽ tạo ra từng component riêng lẻ khi họ biết chất lượng có ý nghĩa gì với chính họ
- Đội khách hàng phải mô tả rõ chất lượng có ý nghĩa gì với họ → chất lượng sẽ lan tỏa từ dưới lên
Thiết kế tổ chức cho các nhóm nhỏ trong thời đại AI
- Startup nhỏ có thể có lợi thế hơn trong thế giới mới vì ít người hơn nên vốn dĩ đã có ít bước review hơn
- Một số startup sẽ tìm ra cách tạo ra component chất lượng cao với tốc độ nhanh, số còn lại sẽ thất bại → chất lượng do chọn lọc tự nhiên
- Các công ty lớn đã đóng cứng vào hệ thống review chậm chạp nên nếu bỏ nó đi có thể gây ra hỗn loạn hoàn toàn
- Dù công ty lớn hay nhỏ, đội ngũ kỹ thuật vẫn có thể nhỏ hơn và có thể định nghĩa rõ ràng hơn các interface giữa các nhóm
- Có thể hình dung mô hình nhiều nhóm trong cùng một công ty cùng cạnh tranh phát triển một component giống nhau
- Mỗi nhóm gồm vài người và các bot coding
- Thử 100 cách rồi chọn cách tốt nhất → chất lượng do tiến hóa
- Code thì rẻ, nhưng ý tưởng tốt vẫn đắt → có thể thử nghiệm ý tưởng mới nhanh hơn trước
- Có thể xuất hiện một điểm tối ưu mới trên phổ liên tục monolith–microservices
- Microservices bị mang tiếng xấu vì quá nhỏ, nhưng trong nghĩa gốc thì “micro” service là kích cỡ phù hợp để “một đội hai pizza” xây dựng và vận hành
- Trong thời đại AI, mức này có thể là “một pizza và thêm chút token”
- Nhờ tốc độ coding mới, có thể thử nghiệm ranh giới mô-đun nhanh hơn
- Tính năng (feature) vẫn khó, nhưng refactoring và kiểm thử tích hợp tự động lại là lĩnh vực AI làm khá tốt
- Có thể thử tách các mô-đun mà trước đây không dám tách → số dòng code có thể tăng, nhưng vẫn rẻ hơn chi phí điều phối khi một nhóm lớn phải bảo trì cả hai phía
- Mọi đội đều đang có những monolith quá lớn và quá nhiều bước review
- Dù chưa thể đạt tới điểm kỳ dị, ta vẫn có thể thiết kế ra một thế giới tốt hơn rất nhiều → vấn đề này có thể giải được
- Cốt lõi là niềm tin
2 bình luận
Lần đầu tôi thấy
go fmt: Không, sao lại không thể format theo gu của tôi được chứ..!Bây giờ: Tại sao format lại cần gu?
Ý kiến Hacker News
Có thể không cần review ngay từ đầu
Nếu đẩy review sang bên trái để biến nó thành các buổi thiết kế code, nêu vấn đề trong daily, và xử lý phần khó bằng pair programming thì phần lớn mục đích của review sẽ biến mất
10% còn lại như tên biến, khoảng trắng, pattern có thể tự động hóa bằng linter
Cuối cùng, điều quan trọng là xây dựng một văn hóa đội ngũ dựa trên sự tin cậy, nơi mọi người có thể tin tưởng và viết code theo các thỏa thuận chung của team
Chỉ khi triển khai thực tế mới nhận ra vấn đề
Hầu như chưa bao giờ mọi thứ diễn ra đúng hoàn toàn theo kế hoạch. Rốt cuộc vẫn cần các cuộc họp kiến trúc lặp đi lặp lại, nhưng như vậy lại rơi vào vũng lầy họp tuần
Khi họ thậm chí không còn review cả đoạn code do chính mình viết ra, thì niềm tin đã gây dựng sụp đổ trong chớp mắt
Giống như Toyota Production System, nếu muốn loại bỏ bước QA thì cần có sự tin cậy để mọi thành viên có thể dừng lại ngay khi phát hiện lỗi
Pipeline review chỉ che giấu vấn đề và làm chậm tốc độ
Chỉ riêng câu này đã giống như định nghĩa của địa ngục
Cách này hoạt động khá tốt. Mọi người tự viết test và cũng tự kiểm tra thủ công
Chúng tôi còn xây dựng lưới an toàn có thể rollback deployment lỗi trong 10 phút
Code review là một thế tiến thoái lưỡng nan của người làm việc tự nguyện
Vì việc “review nhiều PR” không được đánh giá bằng việc “phát hành nhiều tính năng”
Cuối cùng, mọi người chỉ tích cực review khi nó ảnh hưởng trực tiếp đến công việc của chính họ
Nhưng vì code có tính linh hoạt, merge nhanh rồi sửa tiếp có thể lại đem đến sự hội tụ nhanh hơn
Đặc biệt, động lực lớn là bắt bug sớm để giảm áp lực on-call
Ngay cả khi chưa hiểu hết, việc để lại câu hỏi cũng rất hữu ích cho học tập
Nếu muốn trở thành leader, bạn nên review nhiều code và cả tài liệu thiết kế
Bài viết này đã diễn đạt rõ ràng những gì vốn là trực giác và kinh nghiệm của tôi
Tôi vốn đã thích sản phẩm của Tailscale, nhưng giờ có lẽ sẽ trở thành fan của CEO luôn
Cảm ơn Avery vì bài viết này, tôi định chia sẻ nó rộng rãi
Valve là một trong số ít công ty hiểu được giới hạn của băng thông giao tiếp
Tổ chức càng lớn thì gánh nặng giao tiếp càng tăng theo cấp số nhân
Có lẽ các công ty khác giờ cũng nên nhận ra rồi, nhưng thực tế vẫn chưa
Việc review được xử lý trong vòng 5 giờ đã là điều đáng ngạc nhiên
Phần lớn nơi khác tính bằng vài ngày
Nhưng nếu có một văn hóa cho phép mọi lập trình viên dừng lại ngay khi phát hiện bug, thì có thể review là không cần thiết
Thực tế thì đây là một cấu trúc nơi cá nhân bị bất lợi nếu không đạt mục tiêu release
Công ty hiện tại review xong trong vài phút, nhưng nợ kỹ thuật tăng vọt
Sau một khoảng thời gian sẽ tự động có tin nhắn “đang chờ review”
Mọi thứ đều bị đo lường, và áp lực thành tích rất nặng
Nếu quy mô team vừa phải, thói quen này có thể học được và lan rộng được
Cả business lẫn lập trình viên đều không mấy quan tâm
Tỷ lệ giá trị so với công sức của review thường bị bỏ qua
Nếu review thực sự không nâng cao chất lượng thì thời gian đó là lãng phí
Thay vì tranh cãi tiểu tiết, chỉ cần xác nhận “nó có chạy không” rồi merge nhanh sẽ hiệu quả hơn
Sau đó cải thiện bằng các commit tiếp theo là được
Review nên là một checkpoint ngắn để xác nhận hướng đi
Tôi hoàn toàn đồng ý với câu “việc của reviewer là loại bỏ sự cần thiết của review”
Bài viết giả định một quy trình tuần tự, nhưng thực tế công việc diễn ra song song
Nếu xử lý nhiều bug cùng lúc thì độ trễ review không phải vấn đề quá lớn
Cốt lõi là điều chỉnh số lượng công việc đồng thời (N)
Liên kết
Tốc độ review PR càng chậm thì chi phí context switching càng lớn
Kết quả tính toán cho thấy tăng tốc review có thể cải thiện năng suất đáng kể
Tôi đồng cảm với câu “mục tiêu của reviewer là khiến review trở nên không cần thiết”,
nhưng khi phạm vi của sự tin cậy mở rộng ra ngoài công ty thì câu chuyện sẽ khác
Ví dụ, nếu
npm updatephát tán mã độc thì phản ứng sau đó là quá muộnDù dựa trên niềm tin, đôi khi vẫn có những điểm cần sự xác minh của con người
Các manager nhấn mạnh năng suất nhưng đồng thời vẫn duy trì những quy trình làm chậm tốc độ
Đây là vấn đề phức tạp nên khó thể nói đơn giản là tốt hay xấu
Người vận hành phải đồng thời chịu trách nhiệm cho cả năng suất và an toàn
Trước sự cố thì năng suất được nhấn mạnh, sau sự cố thì an toàn được nhấn mạnh
Người ngoài thường không hiểu rõ sự cân bằng của vai trò kép này
Liên kết liên quan