Quản trị kỹ thuật thời kỳ 'chi phí viết code bằng 0': Góc nhìn từ một Giám đốc kỹ thuật

Tôi đã làm giám đốc kỹ thuật được hơn ba năm nay, và tôi vẫn nghe cũng như đọc thấy những điều mà tôi gọi là "các quy tắc cũ" được lặp đi lặp lại: giám đốc không nên dành thời gian viết code, công việc tốt cần có thời gian, hãy bảo vệ đội ngũ khỏi các yêu cầu từ phía kinh doanh, cần đạt được sự đồng thuận trước khi cam kết, v.v.

Một thời gian, tôi từng nghĩ những người lặp lại các câu nói này đã bị tụt hậu. Sau đó, chúng tôi đưa LLM vào tổ chức của mình và chi phí tạo ra code đã giảm xuống, tôi bắt đầu kiểm tra từng quy tắc dựa trên giả định nền tảng của nó. Nhận thức đáng ngạc nhiên là khoảng một nửa số quy tắc cũ dựa trên những giả định đã không còn đúng, nửa còn lại dựa trên những giả định vẫn còn hiệu lực, và một vài trong số đó hiện nay còn quan trọng hơn trước đây.

Những gì theo sau đây là phiên bản đã được tinh chỉnh từ các ghi chú tôi tích lũy trong năm qua. Gemini 4 đã hỗ trợ tôi trong việc biên tập.

Những gì chúng ta thực sự biết

Chi phí để tạo ra code có vẻ hợp lý đã sụp đổ và sẽ không quay trở lại mức cũ. Hầu như mọi tuyên bố vượt ra ngoài điều đó đều chưa được chứng minh hoặc là sai lầm.

Nếu bạn xây dựng lại các phương pháp quản lý dựa trên tuyên bố hẹp này, bạn sẽ đúng. Nếu bạn xây dựng chúng dựa trên những tuyên bố rộng hơn, bạn đang đánh cược với sự nghiệp của người khác và gọi đó là một kết luận.

Tập trung vào việc kiểm định các giả định

Mỗi phương pháp quản lý đều dựa trên một giả định nhất định. Theo dõi vận tốc (velocity) dựa trên giả định rằng đầu ra là đại diện hữu ích cho nỗ lực. Quy trình onboarding sáu tháng dựa trên giả định rằng cú pháp rất khó học. Kiến trúc dựa trên sự đồng thuận dựa trên giả định rằng thay đổi là đắt đỏ. Lập kế hoạch nhân sự dựa trên giả định rằng đầu ra tăng tỷ lệ thuận với số lượng người, v.v.

Câu hỏi cho mỗi phương pháp không phải là nó cũ bao nhiêu, mà là phương pháp đó thực sự dựa trên điều gì.

Nếu một phương pháp dựa trên chi phí viết code, hãy xem xét lại vì chi phí đó đã thay đổi. Nếu nó dựa trên cách con người phối hợp, xây dựng lòng tin, phân bổ sự chú ý hoặc xác minh tính đúng đắn, thì không có gì thay đổi cả, bất kể nghi thức đó có vẻ lỗi thời đến đâu.

Điều này nghe có vẻ hiển nhiên nhưng tôi nghĩ nhiều người đang phân loại theo cảm tính: cái gì có vẻ hiện đại thì giữ lại, cái gì có vẻ cũ thì loại bỏ. Điều đó tạo ra những đội ngũ từ bỏ các ma sát hữu ích nhưng lại giữ lại các quy trình vô dụng, bởi vì tuổi đời của một phương pháp và tính hiệu quả của nó là hai biến số không liên quan.

Bằng chứng ít hơn nhiều so với những lời đồn thổi

Hãy cảnh giác với bất kỳ ai, kể cả đội ngũ của chính bạn, khi họ chỉ báo cáo về sự tăng tốc vượt bậc. Những lợi ích mà tôi biết đến xuất hiện rõ ràng trong các dự án mới (greenfield), các đoạn code mẫu (boilerplate) và các lĩnh vực xa lạ. Chúng mờ nhạt hoặc đảo ngược trong công việc chuyên sâu trên các hệ thống mà kỹ sư đã hiểu rõ. Tôi rất mong chờ dữ liệu và các nghiên cứu được thực hiện sau quý 4 năm 2025, khi một thế hệ mô hình mới được ra mắt, hoàn toàn làm lu mờ khả năng của những mô hình mà các báo cáo và nghiên cứu cũ dựa vào.

Tuy nhiên, khoảng cách giữa tốc độ cảm nhận và tốc độ đo lường tự nó đã là một vấn đề quản lý. Nếu các kỹ sư của bạn cảm thấy nhanh hơn và bàn giao cùng một khối lượng công việc nhưng với nhiều lỗi hơn, bạn sẽ bố trí nhân sự sai, lập kế hoạch sai và đặt ra những kỳ vọng với phía kinh doanh mà bạn không thể đáp ứng. Công việc đầu tiên trong một tổ chức áp dụng AI là thiết lập hệ thống đo lường đủ trung thực để cho bạn biết liệu mình có thực sự tăng tốc hay không.

Các đại diện yếu cho một thứ rẻ tiền

Vận tốc, số lượng pull request và số ticket đã đóng luôn là những thước đo không hoàn hảo. Chúng tồn tại được vì thứ mà chúng đại diện, tức là nỗ lực viết code, vốn thực sự khan hiếm, nên các sai số vẫn nằm trong giới hạn chấp nhận được.

Bây giờ, thứ được đại diện đó đã trở nên rẻ tiền. Điều đó không chỉ khiến các chỉ số trở nên không hoàn hảo mà thực sự còn gây hiểu lầm, bởi vì cách rẻ nhất để tăng các chỉ số này là tạo ra khối lượng công việc, và khối lượng chính là thứ mà tổ chức của bạn không còn thiếu nữa.

Các chỉ số dành riêng cho AI giải quyết sai vấn đề. Tôi nghĩ tỷ lệ chấp nhận (acceptance rates) và số lượng prompt cũng là một sai lầm tương tự dưới hình thức mới. Bước đi bền vững hơn là điều cũ kỹ và khó khăn hơn: hãy đo lường kết quả kinh doanh và sức khỏe của hệ thống, đồng thời coi khối lượng code là một chi phí cần được biện minh thay vì là đầu ra cần được tán dương. Các kỹ sư giỏi đã nói điều này trước cả khi có LLM. Điều đó đúng vào lúc đó. Và bây giờ nó có thể thực thi theo cách mà trước đây không thể, vì không ai có thể tranh cãi rằng viết nhiều code hơn là phần khó nhất.

"Làm đúng" vẫn cần thời gian (hiện tại là vậy)

Quy tắc cho rằng công việc tốt cần thời gian được chia tách rõ ràng làm hai phần.

Thời gian cho các công việc nền tảng (plumbing) đã sụp đổ. Dựng khung dịch vụ, tạo các bài kiểm thử, chuyển đổi giữa các framework, viết bản nháp đầu tiên cho một quá trình di chuyển dữ liệu: tất cả những việc này giờ đây đều nhanh chóng, và bất kỳ tiến độ nào dựa trên các chi phí đó đều xứng đáng được rút ngắn.

Thời gian cho tính đúng đắn (correctness) được chia làm hai.

Các hệ thống AI hiện nay kiểm tra và sửa code nhanh hơn bất kỳ người đánh giá nào, và việc giả vờ ngược lại sẽ làm mất uy tín. Một mặt, việc xác minh cơ học đang sụp đổ. Bất cứ thứ gì mà tính đúng đắn có thể được biểu diễn dưới dạng một cấu trúc máy có thể kiểm tra được: kiểu dữ liệu, bài kiểm thử, hợp đồng, quy tắc lint, bất biến, chỉ số canary. Các tác nhân (agents) chạy vòng lặp kiểm thử, đọc lỗi, sửa diff và chạy lại với tốc độ mà không người đánh giá nào theo kịp. Nếu tính đúng đắn của bạn nằm ở lớp này, thời gian kiểm tra của bạn thực sự đang giảm xuống, và nó sẽ tiếp tục giảm.

Nhưng hãy chú ý điều gì làm cho lớp này nhanh. Nó nhanh vì ai đó đã viết ra "đúng" nghĩa là gì, dưới dạng máy có thể đánh giá được. Đặc tả kỹ thuật đã thực hiện công việc và trình kiểm tra chỉ việc đọc nó.

Xác minh ngữ nghĩa là một vấn đề khác. Liệu code có thực hiện đúng chính sách mà doanh nghiệp thực sự cần không? Sự đánh đổi này có phù hợp với các quy định pháp lý của bạn không? Ở đây, tính đúng đắn nằm trong đầu con người và lịch sử tổ chức. AI kiểm tra AI có một vấn đề cấu trúc: trình kiểm tra chia sẻ dữ liệu huấn luyện, định kiến và điểm mù với trình tạo. Cả hai lớp đều thất bại ở cùng những nơi vì cùng những lý do. Tự đánh giá có thể bắt được lỗi chính tả, nhưng không bắt được sự hiểu lầm chung.

Tôi tin rằng có ba hệ quả theo sau, và đây cũng là cốt lõi của bài viết này:

Vì vậy, việc xác minh vẫn quyết định thông lượng. Điều đã thay đổi là vị trí của nút thắt cổ chai: từ tốc độ kiểm tra sang chất lượng đặc tả, và sự sẵn lòng của một cá nhân cụ thể trong việc chịu trách nhiệm về kết quả.

Quy trình đào tạo nhân sự cấp thấp là một vấn đề chưa có lời giải.

Không ai biết cách đào tạo kỹ sư cho môi trường này.

Khả năng phán đoán mà bạn muốn ở một kỹ sư cấp cao trước đây được xây dựng bằng cách thực hiện những công việc mà AI hiện nay đang đảm nhận: sửa các lỗi nhỏ, viết code mẫu, bị mắc kẹt rồi tự tìm cách thoát ra: đây không chỉ là các nhiệm vụ mà thực sự là quá trình rèn luyện tạo nên khả năng phán đoán. Nếu máy móc đảm nhận quá trình đó, quy trình đào tạo kỹ sư cấp cao sẽ bị phá vỡ, và nó sẽ bị phá vỡ với một độ trễ nhất định, vì vậy bạn sẽ không nhận ra trong ba đến năm năm tới.

Có những phản ứng hợp lý. Đánh giá có cấu trúc đối với code được tạo ra, các bài tập tự thực hiện có chủ đích, luân chuyển qua công việc kiểm thử và xác minh, tiếp xúc sớm với các hệ thống thực tế dưới sự giám sát chặt chẽ của cấp trên. Tôi đang thực hiện các phiên bản của một số phương pháp này. Tôi không thể nói với bạn rằng chúng hiệu quả, bởi vì biến kết quả là chất lượng của một kỹ sư cấp cao sau nửa thập kỷ nữa.

Điều tôi có thể nói với bạn là bất kỳ ai tuyên bố đã giải quyết được vấn đề này, dù là nhà cung cấp, người viết tiểu luận hay diễn giả hội thảo, đều đang bán một thứ gì đó. Hãy coi quy trình đào tạo là một vấn đề mở mà chính bạn phải chịu trách nhiệm. Nó có độ trễ dài nhất giữa hành động và bằng chứng, và ít cơ hội nhất để điều chỉnh hướng đi.

Quan điểm của tôi về các quy tắc cũ

"Giám đốc không nên viết code." Người giám đốc chỉ làm hời hợt, xem xét pull request để cảm thấy mình hữu ích và trở thành nút thắt cổ chai là có thật. Cũng như người giám đốc có tư duy về công việc đã lỗi thời năm năm, không thể phân biệt được đâu là đội ngũ thực sự nhanh hơn và đâu là đội ngũ đang tạo ra đầu ra tự tin nhưng sai lệch với số lượng lớn (những "cỗ máy rác"). Giải pháp là hiệu chuẩn. Bạn không cần phải bàn giao sản phẩm. Bạn cần đủ sự tiếp xúc trực tiếp với các công cụ và đầu ra để không bị đánh lừa theo bất kỳ hướng nào, bởi sự thổi phồng hay bởi sự coi thường.

"Bảo vệ đội ngũ khỏi phía kinh doanh." Giả định đằng sau điều này là sự chú ý có hạn và việc chuyển đổi ngữ cảnh rất tốn kém. Giả định đó vẫn còn nguyên vẹn. Điều thay đổi là cái giá của việc bỏ đói đội ngũ về mặt ngữ cảnh. Các kỹ sư sử dụng công cụ AI mà không có ngữ cảnh kinh doanh chỉ tạo ra những công việc trôi chảy, hợp lý nhưng sai lệch trên quy mô lớn. Sự điều chỉnh không phải là làm ngập lụt mọi người với mọi thứ, mà là ngừng lọc thông tin theo mặc định và bắt đầu chọn lọc có chủ đích: ngữ cảnh nào, cho ai, ở mức độ chi tiết nào.

"Chúng ta cần sự đồng thuận trước khi cam kết." Sự đồng thuận luôn là về cam kết và phối hợp, và chi phí để tồn tại qua các lần xoay trục (pivot) giá rẻ. Điều mà các lần xoay trục giá rẻ thay đổi là những quyết định nào thực sự cần sự đồng thuận. Các quyết định có thể đảo ngược, hay "cánh cửa hai chiều", nên được thực hiện bởi nhóm nhỏ nhất có thể, một cách nhanh chóng, vì một quyết định sai lầm có thể đảo ngược giờ đây rất rẻ để sửa chữa. Các quyết định không thể đảo ngược vẫn xứng đáng với quy trình chậm rãi. Kỹ năng thực sự là phân loại, và hầu hết các tổ chức phân loại sai liên tục, coi các lựa chọn kỹ thuật có thể đảo ngược là vĩnh viễn và các lựa chọn tổ chức vĩnh viễn là tùy tiện.

"Chúng ta cần thêm nhân sự." Kinh tế học đơn vị của đầu ra đã thay đổi, vì vậy mọi yêu cầu đều xứng đáng nhận được một câu hỏi khó hơn so với ba năm trước: phần nào của công việc này là khả năng phán đoán, và phần nào là sản xuất mà chúng ta vẫn tiếp tục thuê người làm? Nhưng đừng điều chỉnh quá mức. Thêm người vào một dự án đang chậm tiến độ chỉ làm nó chậm hơn. Chi phí phối hợp, gánh nặng onboarding và chi phí truyền thông không thay đổi theo giá của cú pháp. Hãy xem xét kỹ lưỡng nhân sự vì đầu ra trên mỗi người đã thay đổi, không phải vì con người không còn là phần đắt đỏ nữa.

Tại sao các câu nói sáo rỗng vẫn tồn tại

Sau ba năm, đây là những gì tôi tin về sự tồn tại của chúng. Các phương pháp tồn tại đều có lý do, và các lý do luôn đan xen: một số đã lỗi thời, một số vẫn còn hiệu lực, một số mang tính chính trị. Khi bạn nghe một quy tắc cũ được lặp lại, bạn thường nghe một người bảo vệ phần hợp lệ bằng lập luận sai hoặc bảo vệ phần lỗi thời bằng lập luận từng có hiệu quả trong quá khứ.