Mỗi lớp đánh giá đều khiến bạn chậm hơn gấp 10 lần

Mỗi lớp đánh giá đều khiến bạn chậm hơn gấp 10 lần

Tất cả chúng ta đều đã nghe nói về quy luật hiệu ứng mạng: giá trị của mạng tăng lên với bình phương số lượng thành viên. Hoặc chi phí liên lạc tăng lên bằng bình phương của số thành viên, hoặc có thể là n log n, hoặc đại loại thế, tùy vào cách bạn sắp xếp các thành viên. Dù sao cũng tăng gấp đôi một đội không tăng gấp đôi tốc độ của nó; có sự phối hợp chung. Chính xác như thế nào chi phí phụ thuộc nhiều vào việc bạn làm hỏng thiết kế tổ chức đến mức nào.

Nhưng có một nguyên tắc chung mà ai đó đã chỉ cho tôi cách đây nhiều thập kỷ, đó là bị mắc kẹt với tôi kể từ đó, vì nó đúng đến mức khó chịu. Quy tắc thật khó chịu vì điều đó có vẻ không có vẻ đúng. không có cơ sở lý thuyết cho nhận định này mà tôi từng nghe. Chưa hết, mỗi lần tôi hãy tìm nó, nó đây.

Chúng ta bắt đầu nhé:

Mỗi lớp phê duyệt đều khiến quy trình chậm hơn gấp 10 lần

Tôi biết bạn đang nghĩ gì. Thôi nào, 10x? Đó là rất nhiều. Thật không thể hiểu được. Chắc chắn chúng tôi đang phóng đại.

Không.

Nói rõ hơn, ở đây chúng tôi đang tính “thời gian trên đồng hồ treo tường” chứ không phải nỗ lực. Hầu như tất cả thời gian dư thừa đều dành cho việc ngồi và chờ đợi.

Nhìn này:

Viết mã sửa lỗi đơn giản
30 phút
Nhận mã này được người bên cạnh bạn đánh giá
300 phút → 5 giờ → nửa ngày
Trước tiên hãy nhận tài liệu thiết kế được nhóm kiến trúc sư của bạn phê duyệt
50 giờ → khoảng một tuần
Lên lịch của nhóm khác để làm tất cả những việc đó
(ví dụ: nếu khách hàng yêu cầu một tính năng)
500 giờ → 12 tuần → một quý tài chính

Tôi ước gì có thể nói với bạn rằng bước tiếp theo sẽ tăng lên — 10 quý hoặc khoảng 2,5 năm - quá điên rồ để suy ngẫm, nhưng không. Đó là cuộc sống của một người điều hành ngồi phía trên một nhóm cỡ trung bình; Tôi va vào nó mọi lúc ngay cả ở một công ty tương đối nhỏ như Tailscale nếu tôi muốn thay đổi hướng sản phẩm. (Và những người điều hành ngồi phía trên các nhóm lớn thực sự không thể tự làm công việc của mình. Đó là cái khác câu chuyện.)

AI không thể khắc phục được điều này

Trước hết, đây không phải là bài viết về AI, vì AI tác động trực tiếp đến về vấn đề này là tối thiểu. Được rồi, thay vào đó Claude có thể viết mã nó trong 3 phút của 30? Tuyệt vời quá, Claude, làm tốt lắm.

Bây giờ bạn có thể dành 27 phút để tự mình xem lại mã vòng lặp qua lại với AI (điều này thực sự khá thú vị); hoặc bạn tiết kiệm được 27 phút và gửi mã chưa được xác minh cho người đánh giá mã, người này vẫn sẽ thực hiện 5 tiếng như trước đây, nhưng bây giờ ai sẽ tức giận vì bạn bắt họ đọc sự cẩu thả mà bạn quá lười để tự đọc. Ít giá trị đã đạt được.

Bạn nói rằng đó không phải là giá trị của mã hóa tác nhân. Bạn không sử dụng một đại lý sửa chữa trong 30 phút. Bạn sử dụng nó cho một dự án khổng lồ kéo dài một tuần bây giờ bạn và Claude có thể làm được trong vài giờ nữa! Bây giờ chúng ta đang nói chuyện. Ngoại trừ không, bởi vì sự quái dị quá lớn nên người đánh giá của bạn sẽ cực kỳ tức giận rằng bạn đã không tự mình đọc nó và nó quá lớn để có thể xem lại trong một đoạn nên bạn phải cắt nó thành những miếng mới vừa ăn, mỗi miếng có thời gian xem xét lại là 5 giờ chu kỳ. Và không có tài liệu thiết kế nên không có kiến trúc có chủ ý, vì vậy cuối cùng ai đó sẽ phản đối điều đó và chúng ta bắt đầu với cuộc họp đánh giá tài liệu thiết kế và bây giờ là dự án quái đản kéo dài một tuần của bạn bạn đã làm trong hai giờ là... ồ. Một tuần nữa.

Tôi đoán tôi có thể gọi bài đăng này là Thiết kế hệ thống 4 (hoặc 5, hoặc bất cứ điều gì) Đến bây giờ, ai biết được, tôi đang viết bài này trên một chiếc máy bay không có wifi) bởi vì ừ, bạn đã đoán được rồi. Lại đến giờ Thiết kế Hệ thống.

Cách duy nhất để phát triển bền vững nhanh hơn là ít đánh giá hơn

Thật buồn cười, mọi người đã dự đoán về Điểm kỳ dị hàng chục năm nay rồi. Tiền đề là chúng ta xây dựng những hệ thống thông minh đến mức bản thân chúng có thể xây dựng hệ thống tiếp theo thậm chí còn thông minh hơn, xây dựng hệ thống tiếp theo thông minh hơn một, v.v. và khi chúng ta bắt đầu điều đó, nếu họ tiếp tục thông minh hơn đủ nhanh hơn thì thời gian tăng dần (t) để đạt được một đơn vị (u) của sự cải thiện tiến tới 0, do đó (u/t) tiến tới vô cùng và foom.

Dù sao thì, tôi chưa bao giờ tin vào lý thuyết này vì lý do đơn giản là chúng ta đã nêu ở trên: phần lớn thời gian cần thiết để hoàn thành mọi việc không thực sự là thời gian làm việc đó. It’s wall clock time. Chờ. Độ trễ.

Và bạn không thể vượt qua độ trễ bằng vũ lực.

Tôi biết bạn muốn. Tôi biết nhiều bạn hiện đang làm việc tại các công ty nơi mô hình kinh doanh phụ thuộc vào việc thực hiện chính xác điều đó.

Xin lỗi.

Nhưng bạn không thể không xem xét mọi thứ!

À, không, thực ra là có. Bạn thực sự không thể.

Hiện nay có rất nhiều người đã nhìn thấy triệu chứng: sự khởi đầu của đường dẫn (mã do AI tạo) nhanh hơn rất nhiều, nhưng tất cả các bước tiếp theo giai đoạn (đánh giá) quá chậm! Và thế là họ trực cảm được giải pháp hiển nhiên: dừng lại thì xem xét lại nhé!

Kết quả có thể là độ dốc, nhưng nếu độ dốc là 100x rẻ hơn thì nó chỉ cần cung cấp 1% giá trị trên mỗi đơn vị và nó vẫn là một cuộc mua bán công bằng. Và nếu giá trị trên mỗi đơn vị của bạn thậm chí chỉ bằng 2% giá trị của nó đã từng như vậy, bạn đã nhân đôi lợi nhuận của mình! Thật tuyệt vời.

Có một số giả định khá ngớ ngẩn làm cơ sở cho lý thuyết đó; bạn có thể hãy tưởng tượng chúng cho chính bạn. Chỉ cần nói rằng điều này tạo ra những gì tôi sẽ gọi Sự điên rồ của Nhà phát triển AI:

Ồ, tôi đã tạo ra nguyên mẫu này nhanh quá! Tôi có siêu năng lực!
Nguyên mẫu này đang gặp lỗi. Tôi sẽ bảo AI sửa lỗi.
Hmm, mọi thay đổi giờ đây đều gây ra nhiều lỗi mới như khi nó sửa được.
À há! Nhưng nếu tôi có một tác nhân AI cũng xem lại mã, nó có thể tìm thấy mã riêng của mình lỗi!
Đợi đã, tại sao cá nhân tôi lại chuyển dữ liệu qua lại giữa các đại lý
Tôi cần một khung tác nhân
Tôi có thể yêu cầu người đại diện của tôi viết khung tác nhân!
Quay lại bước 1

Thật đáng báo động khi tôi đã mất đi bao nhiêu bạn bè và đồng nghiệp đáng kính đến chu kỳ này rồi. Claude Code chỉ hoạt động tốt cách đây vài tháng, vì vậy điều gần đây mới bắt đầu xảy ra, nên tôi cho rằng chúng sẽ xuất hiện từ cuối cùng là xoắn ốc. Ý tôi là, tôi hy vọng họ sẽ làm vậy. Chúng tôi không có cách nào để biết.

Lý do chúng tôi đánh giá

Dù sao thì chúng tôi cũng biết triệu chứng của mình: đường ống bị tắc do có quá nhiều mã mới được đưa vào nó ở bước 1. Nhưng nguyên nhân gốc rễ của tình trạng tắc nghẽn là gì? Tại sao đường ống không đi nhanh hơn?

Tôi đã nói ở trên rằng đây không phải là bài viết về AI. Rõ ràng là tôi đang thất bại ở cho đến nay, nhưng hãy mang nó trở lại với con người. Nó quay trở lại quan sát đúng đến khó chịu mà tôi đã bắt đầu: mỗi lớp đánh giá là 10 lần chậm hơn. Là một xã hội, chúng tôi biết điều này. Có lẽ bây giờ bạn chưa từng nhìn thấy nó. Nhưng hãy tin tôi: những người thiết kế tổ chức để kiếm sống đều biết rằng các lớp đắt tiền...và họ vẫn làm điều đó.

Khi các công ty phát triển, tất cả họ đều có ngày càng nhiều lớp hợp tác, xem xét và quản lý. Tại sao? Bởi vì nếu không sẽ có sai lầm mắc phải và những sai lầm ngày càng tốn kém trên quy mô lớn. Giá trị trung bình được thêm vào bởi một tính năng mới cuối cùng sẽ trở nên thấp hơn giá trị trung bình bị mất thông qua các lỗi mới mà nó gây ra. Vì vậy, thiếu một cách để tạo ra các tính năng nhiều giá trị hơn (điều đó chẳng tốt đẹp gì sao!), ít nhất chúng tôi cũng cố gắng giảm thiểu thiệt hại.

Chúng ta càng thực hiện nhiều hoạt động kiểm tra và kiểm soát thì chúng ta càng tiến hành chậm hơn, nhưng càng nhiều chất lượng tăng lên một cách đơn điệu. Và đó chẳng phải là cơ sở của liên tục cải tiến?

Ờ, đại loại vậy. Chất lượng tăng lên một cách đơn điệu đang đi đúng hướng. Nhưng “kiểm tra và kiểm soát nhiều hơn” đã đi chệch hướng. Đó chỉ có một cách để cải thiện chất lượng và đó là một điều đầy khó khăn.

“Đảm bảo chất lượng” làm giảm chất lượng

Tôi đã viết cách đây vài năm về W. E. Deming và những triết lý “mới” xung quanh chất lượng mà ông đã phổ biến trong ngành sản xuất ô tô của Nhật Bản. (Cuối cùng Hoa Kỳ các nhà sản xuất ô tô ít nhiều đã có ý tưởng này. Cho đến nay ngành công nghiệp phần mềm chưa.)

Một trong những ảnh hưởng mà anh ấy nhấn mạnh là vấn đề về đường chuyền “QA” trong một nhà máy: xây dựng các vật dụng, có giai đoạn kiểm tra/QA, từ chối các vật dụng QA thất bại. Tất nhiên, người kiểm tra của bạn có thể bỏ sót một số sai sót, vì vậy khi nghi ngờ, hãy thêm giai đoạn QA thứ hai sau giai đoạn đầu tiên để nắm bắt phần còn lại những cái đó, v.v.

Trong một mô hình toán học đơn giản, điều này có vẻ hợp lý. (Ví dụ: nếu mỗi lượt QA phát hiện được 90% lỗi, sau đó sau hai lượt QA bạn đã giảm số lượng lỗi đi 100 lần. Điều đó tuyệt vời đến mức nào?)

Nhưng trong thực tế con người có tác nhân thì không đơn giản như vậy. Trước hết, khuyến khích trở nên kỳ lạ. Nhóm QA thứ hai về cơ bản phục vụ để đánh giá cách thức đội QA đầu tiên đang làm tốt; nếu đội QA đầu tiên tiếp tục mất tích khiếm khuyết, sa thải chúng. Bây giờ, nhóm QA thứ hai đó có rất ít động lực để tạo ra kết quả đó cho bạn bè của họ. Vì vậy có lẽ chúng trông không quá khó; dù sao thì đội QA đầu tiên đã bỏ sót lỗi, không phải vô lý mà chúng ta cũng có thể bỏ lỡ nó.

Hơn nữa, đội QA đầu tiên biết rằng có đội QA thứ hai sẽ bắt bất kỳ khiếm khuyết; nếu hôm nay tôi không làm việc chăm chỉ thì chắc chắn đội thứ hai sẽ bắt kịp sự lỏng lẻo. Đó là lý do tại sao họ ở đó!

Ngoài ra, nhóm tạo ra các vật dụng này ngay từ đầu đã không kiểm tra làm việc quá cẩn thận; đó chính là mục đích của nhóm QA! Tại sao tôi lại chậm lại việc sản xuất mọi vật dụng một cách cẩn thận, với chi phí cao hơn khoảng 20% có lúc chỉ có 10 lỗi trong 100 lỗi và tôi có thể loại bỏ chúng ở mức bước tiếp theo chỉ với 10% chi phí lãng phí? Nó chỉ có ý nghĩa. Cộng thêm họ sẽ sa thải tôi nếu tôi đi chậm hơn 20%.

Chưa nói gì đến toàn bộ kỹ thuật thiết kế lại để cải thiện chất lượng, điều đó sẽ rất tốn kém và chúng ta có thể thay vào đó hãy thiết kế tất cả các vật dụng mới.

Bạn có biết phòng kỹ thuật nào không?

Chà, đây không phải là thời điểm thích hợp để nhắc lại Deming, nhưng chỉ cần nói rằng, anh ấy đang làm gì đó. Và kỹ thuật của anh ấy đã phát huy tác dụng. Bạn nhận được những thứ như Hệ thống sản xuất Toyota nổi tiếng nơi họ đã loại bỏ hoàn toàn giai đoạn QA, nhưng lại nói với mọi người rằng "ôi chết tiệt, dừng dây lại, tôi phát hiện ra một khiếm khuyết!" nút.

Nổi tiếng là các nhà sản xuất ô tô của Mỹ đã cố gắng áp dụng hệ thống tương tự bằng cách cài đặt các nút “dừng dòng” tương tự. Tất nhiên, không ai nhấn những nút đó. Họ sợ bị sa thải.

Sự tin tưởng

Cơ sở hoạt động của hệ thống Nhật Bản và phần còn thiếu của Hệ thống của Mỹ không làm được điều đó là sự tin tưởng. Hãy tin tưởng giữa các cá nhân rằng bạn ông chủ Thực sự Thực sự Thực sự muốn biết về mọi khuyết điểm và muốn bạn để dừng dòng khi bạn tìm thấy một. Niềm tin của các nhà quản lý rằng các giám đốc điều hành nghiêm túc về chất lượng. Niềm tin của các giám đốc điều hành rằng các cá nhân, được trao một hệ thống có thể hoạt động và có động lực phù hợp sẽ tạo ra công việc có chất lượng và phát hiện những khuyết điểm của mình và nhấn nút dừng khi cần nhấn nó.

Tuy nhiên, còn một điều nữa: hãy tin tưởng rằng hệ thống thực sự hoạt động. Vì vậy trước tiên bạn cần một hệ thống có thể hoạt động được.

Tính có thể sai

Người lập trình AI rất dễ mắc sai lầm; họ thường xuyên viết mã xấu. Bằng cách này, họ giống như con người lập trình viên.

Phương pháp sản xuất của Deming không có bất kỳ viên đạn ma thuật nào. Than ôi, bạn không thể chỉ làm theo quy trình mười bước của anh ấy và ngay lập tức đạt được chất lượng cao hơn kỹ thuật. Bí mật là bạn phải nhờ các kỹ sư của mình thiết kế chất lượng cao hơn vào toàn bộ hệ thống, từ trên xuống dưới, lặp đi lặp lại. Liên tục.

Mỗi khi có sự cố xảy ra, bạn phải hỏi: "Việc này xảy ra như thế nào?" và sau đó thực hiện toàn bộ quá trình khám nghiệm tử thi và Năm lý do tại sao (hoặc cho dù có bao nhiêu lý do tại sao trong thời trang ngày nay) và khắc phục các Nguyên nhân cốt lõi để nó không lại xảy ra lần nữa. “Người lập trình đã làm sai” không bao giờ là nguyên nhân gốc rễ mà chỉ là một triệu chứng. Tại sao người lập trình có thể mắc lỗi?

Công việc của người đánh giá mã không phải là xem lại mã. Đó là tìm ra cách để nhận xét đánh giá mã của họ đã lỗi thời, toàn bộ lớp nhận xét đó, nói chung các trường hợp trong tương lai, cho đến khi bạn không cần đánh giá của họ nữa.

(Hãy nghĩ đến những người đầu tiên tạo ra "go fmt" và bao nhiêu người ngu ngốc nhận xét đánh giá mã về khoảng trắng sẽ biến mất vĩnh viễn. Bây giờ đó là kỹ thuật.)

Vào thời điểm đánh giá của bạn phát hiện ra lỗi thì lỗi đó đã xảy ra rồi thực hiện. Nguyên nhân sâu xa đã xảy ra rồi. Bạn đã quá muộn.

Tính mô đun

Tôi ước gì có thể nói với bạn rằng tôi đã có mọi câu trả lời. Thực ra tôi không có nhiều. Nếu làm vậy thì tôi sẽ là người đầu tiên đăng ký vào Đơn điểm vì nó nghe có vẻ giống tuyệt vời.

Tôi nghĩ chúng ta sẽ mắc kẹt với những vấn đề về đường ống của hệ thống này trong một thời gian nữa. lâu rồi. Đánh giá quy trình - các lớp QA - không hoạt động. Thay vào đó, họ làm bạn chậm hơn trong khi che giấu nguyên nhân gốc rễ. Việc che giấu nguyên nhân khiến chúng khó khắc phục hơn.

Tuy nhiên, tiếng gọi của mã hóa AI rất mạnh mẽ. Đó là bước đầu tiên, nhanh chóng trong quy trình nhanh quá! Thực sự có cảm giác như có siêu năng lực. tôi muốn nhiều hơn nữa siêu năng lực. Chúng ta sẽ làm gì với nó?

Có lẽ cuối cùng chúng ta cũng có một lý do đủ thuyết phục để sửa chữa 20 năm các vấn đề bị ẩn bởi văn hóa đánh giá mã và thay thế nó bằng văn hóa thực sự về chất lượng.

Tôi nghĩ những người lạc quan có một nửa ý kiến đúng. Giảm bớt các giai đoạn xem xét, thậm chí ở mức độ khó chịu, sẽ là cần thiết. Nhưng bạn không thể chỉ giảm bớt các giai đoạn xem xét mà không có thứ gì đó để thay thế chúng. Đường đó nằm Ford Pinto hoặc bất kỳ máy bay Boeing nào gần đây.

Gói hoàn chỉnh, cú lật bàn, là thứ mà Deming mang đến sản xuất. Bạn không thể áp dụng một nửa hệ thống “chất lượng tổng thể”. Bạn cần phải loại bỏ các bài đánh giá và chúng đã lỗi thời chỉ trong một bước.

Làm thế nào? Bạn hoàn toàn có thể áp dụng hệ thống mới, từng bước nhỏ. Điều gì sẽ xảy ra nếu một số các thành phần trong hệ thống của bạn có thể được xây dựng theo cách mới? Hãy tưởng tượng một trường học cũ Hoa Kỳ nhà sản xuất ô tô mua phụ tùng từ các nhà cung cấp Nhật Bản; ồ, những cái này các bộ phận được thực hiện rất tốt! Bây giờ tôi có thể bắt đầu loại bỏ các bước QA ở nơi khác vì Tôi chỉ có thể giả định rằng các bộ phận sẽ hoạt động tốt và công việc "lắp ráp một chiếc tiện ích lớn hơn từ các bộ phận" đã loại bỏ rất nhiều sự phức tạp.

Tôi thích góc nhìn này. Tôi luôn thích những thứ nhỏ xinh, đó là của riêng tôi thiên vị. Tuy nhiên, bạn có thể tập hợp những thứ lớn đẹp từ những thứ nhỏ xinh mọi thứ.

Việc xây dựng những thứ đẹp đẽ riêng lẻ đó trong các nhóm nhỏ sẽ dễ dàng hơn rất nhiều tin tưởng lẫn nhau, biết chất lượng đối với họ như thế nào. Họ giao hàng của họ cho nhóm khách hàng, những người có thể giải thích rõ ràng về chất lượng trông giống như đối với họ. Và chúng ta tiếp tục đi. Chất lượng bắt đầu từ dưới lên và lan tỏa.

Tôi nghĩ các công ty khởi nghiệp nhỏ sẽ hoạt động rất tốt trong thế giới mới này, có lẽ tốt hơn bao giờ hết. Các công ty khởi nghiệp đã có ít lớp đánh giá hơn vì họ có ít người hơn Một số công ty khởi nghiệp sẽ tìm ra cách sản xuất linh kiện chất lượng cao một cách nhanh chóng; những người khác sẽ không và sẽ thất bại. Chất lượng bởi chọn lọc tự nhiên?

Các công ty lớn hơn sẽ gặp khó khăn hơn vì sự chậm chạp của họ hệ thống đánh giá đã được tích hợp sẵn và việc xóa chúng sẽ gây ra sự hỗn loạn hoàn toàn.

Tuy nhiên, vấn đề không chỉ là quy mô công ty. Tôi nghĩ đội ngũ kỹ thuật ở bất kỳ thời điểm nào công ty có thể trở nên nhỏ hơn và có những giao diện được xác định rõ ràng hơn giữa chúng.

Có thể bạn có nhiều nhóm trong một công ty cạnh tranh để phân phối cùng một thành phần. Mỗi người chỉ có một vài người và một vài bot mã hóa. Hãy thử 100 cách và xem ai nghĩ ra cách tốt nhất. Một lần nữa, chất lượng bởi sự tiến hóa. Code rẻ nhưng ý tưởng hay thì không. Nhưng bây giờ bạn có thể thử cái mới ý tưởng nhanh hơn bao giờ hết.

Có thể chúng ta sẽ thấy một điểm tối ưu mới trên monoliths-microservices liên tục. Microservices bị mang tiếng xấu vì chúng quá vi mô; trong bản gốc thuật ngữ, dịch vụ “vi mô” chính xác có quy mô phù hợp cho “hai chiếc bánh pizza”. team” để tự xây dựng và vận hành. Với AI, có thể đó là một chiếc bánh pizza và một số token.

Điều thú vị là bạn cũng có thể sử dụng cách mã hóa mới, nhanh hơn này để thử nghiệm mô-đun khác nhau ranh giới nhanh hơn. Tính năng vẫn khó đối với nhiều người lý do, nhưng việc tái cấu trúc và thử nghiệm tích hợp tự động là những điều AI vượt trội về. Hãy thử tách một mô-đun mà bạn sợ phải tách ra trước đây. Có lẽ nó sẽ thêm một số dòng mã. Nhưng đột nhiên các dòng mã rẻ, so với chi phí điều phối của một nhóm lớn hơn để duy trì cả hai phần.

Mỗi đội đều có một số khối nguyên khối hơi lớn và có quá nhiều lớp của các đánh giá. Có lẽ chúng ta sẽ không thể tiến tới Đơn Điểm. Nhưng, chúng ta có thể tạo nên một thế giới tốt đẹp hơn nhiều. Vấn đề của chúng tôi có thể giải quyết được.

Chỉ cần có sự tin tưởng.