Đo năng suất · thời AI

Số dòng code tăng,
giá trị có tăng?

Số dòng code dễ đếm nhất và dễ hiểu lầm nhất, nhất là khi AI viết cả nghìn dòng trong vài giây. Một kỹ sư từng ghi âm 2000 dòng vào mẫu báo cáo. Vì sao, và nên đo gì thay thế?

Chuyện âm 2000 dòngLuật GoodhartDORA và SPACEBảng chỉ số khởi đầu

LOC: -2000

tốt hơn, không phải tệ hơn

Ba ý chính

Đừng đo bằng số dòng, nói gọn

1Dòng code đo chữ viết ra, không đo giá trị giao ra. Giải pháp tốt thường ngắn hơn, xóa code thừa cũng là đóng góp.

2Thành mục tiêu là bị bóp méo. Đó là luật Goodhart. Thời AI nó còn sai hơn vì code ra gần như miễn phí.

3Hãy đo nhóm và kết quả. Thời gian giao hàng, tỷ lệ lỗi, chờ duyệt, làm lại, hài lòng. Theo xu hướng, không xếp hạng người.

Tóm lại: đếm ít thứ hơn, nhưng đúng thứ.
Lưu ý: chuyện âm 2000 dòng là giai thoại kể qua nhiều nguồn. Số liệu Faros AI do hãng công cụ đo lường công bố. Nhân vật là ví dụ minh họa.

Giai thoại

Chuyện âm 2000 dòng

1982, nhóm Lisa của AppleQuản lý muốn đo năng suất bằng số dòng code mỗi tuần. Ai cũng phải điền mẫu.

Bill AtkinsonThay phần xử lý vùng của QuickDraw bằng thuật toán đơn giản, nhanh hơn khoảng sáu lần, bớt khoảng 2000 dòng.

-2000

Số ông ghi vào mẫu. Theo lời kể, ít tuần sau người ta thôi yêu cầu ông điền.

Giai thoại kể qua nhiều nguồn, đừng coi từng chi tiết là chính xác. Ý của nó vẫn đúng.

Vì sao sai

Ba lý do đơn giản

Đo chữ, không đo kết quả

Người dùng không trả tiền cho dòng code. Họ trả cho vấn đề được giải quyết.

Ít hơn thường tốt hơn

Ít code là ít chỗ lỗi, ít thứ phải đọc, ít thứ phải bảo trì.

Dễ bị chơi

Muốn số đẹp thì viết dài, tách vô nghĩa, chép dán.

Luật Goodhart

Khi thước đo thành mục tiêu

Nói dễ hiểu

Khi một con số trở thành mục tiêu, nó thôi là thước đo tốt, vì người ta sẽ làm cho con số đẹp lên.

Ví dụ kinh điển

Số dòng code
Số commit
Điểm story

Không thước đo nào thoát hoàn toàn. Chỉ có thước khó chơi hơn và được dùng đúng cách.

Ví dụ minh họa

Nhóm Mận và bảng xếp hạng dòng code

1Tuần 1: Hùng 900 dòng, Lan 120 dòngLan dành cả tuần gỡ một lỗi khó mà khách phàn nàn.

2Tuần 3: Lan ở cuối bảngCô bỏ việc dọn code cũ, quay sang thêm tính năng nhỏ.

3Tuần 6: Hùng dùng AI sinh 3000 dòngNhiều đoạn chép lại nhau. Bảng đẹp, duyệt chậm gấp đôi.

4Tuần 6: hai lỗi lọt vào phát hànhKhông ai kịp đọc hết.

5Tuần 8: nhóm hiểu bảng sai, nhưng hành vi đã đổiVí dụ minh họa, nhân vật dựng lại.

Thời AI

Số hoạt động và số giao hàng tách nhau

Faros AI, 7/2025

+98%

Thay đổi được gộp ở nhóm dùng AI nhiều.

Cũng báo cáo đó

+154%

Kích thước mỗi thay đổi.

Cũng báo cáo đó

+91%

Thời gian duyệt mỗi thay đổi.

Cách đọc

Dữ liệu của hãng bán công cụ đo lường, là tương quan. Mình mới đọc bản tóm tắt.

METR, 7/2025

16 lập trình viên chậm hơn khoảng 19% với AI, dù tin mình nhanh hơn khoảng 20%.

Ý nghĩa

Cảm giác nhanh và tốc độ thật có thể lệch nhau. Đo hoạt động dễ đánh lừa.

Thay bằng gì · DORA

Bốn chỉ số về giao hàng

Chỉ số	Câu hỏi nó trả lời
Tần suất triển khai	Nhóm phát hành bao lâu một lần?
Thời gian giao hàng	Từ commit đến người dùng mất bao lâu?
Tỷ lệ thay đổi gây lỗi	Bao nhiêu lần phát hành gây sự cố?
Thời gian khôi phục	Khi hỏng, mất bao lâu để sửa?

Dùng để nhìn nhóm và hệ thống, không để chấm điểm từng người.

Thay bằng gì · SPACE

Năm chiều của năng suất (2021)

Hài lòng và sức khỏe

Nhóm có thấy công việc đáng làm không?

Hiệu quả

Kết quả cho người dùng và kinh doanh.

Hoạt động

Số việc làm ra. Dùng cẩn thận.

Giao tiếp, hợp tác

Thông tin và công việc chảy giữa người với người ra sao.

Hiệu suất, dòng chảy

Ít bị ngắt quãng, ít chờ đợi.

Lập luận cốt lõi

Không chỉ số đơn lẻ nào đủ. Tối ưu một chiều thường làm tụt chiều khác.

Bảng khởi đầu

Năm chỉ số cho nhóm nhỏ

Chỉ số	Cách đo	Cảnh báo khi
Thời gian giao hàng	Ngày từ mở việc đến chạy thật	Dài ra liên tục
Tỷ lệ thay đổi gây lỗi	Sửa gấp trên số lần phát hành	Tăng khi tốc độ tăng
Thời gian chờ duyệt	Giờ từ mở PR đến được duyệt	Tăng khi dùng AI nhiều
Công việc làm lại	Code sửa lại trong 2 tuần	Tăng cùng số dòng
Sự hài lòng của nhóm	Khảo sát 3 câu mỗi tháng	Giảm dần

Ghép đôi

Mỗi chỉ số tốc độ cần một chỉ số chất lượng

Tốc độThời gian giao hàng ngắn lại

Chất lượngTỷ lệ lỗi sau phát hành

Tiến bộ thậtCả hai cùng tốt lên

Thời gian giao hàng ngắn mà tỷ lệ lỗi tăng không phải tiến bộ. Chỉ là chuyển chi phí sang người dùng.

Cách dùng

Năm nguyên tắc để số liệu không gây hại

1Đo nhóm, không xếp hạng ngườiHỏi "hệ thống vướng ở đâu", không hỏi "ai kém nhất".

2Xem xu hướng, không đặt chỉ tiêu cứngChỉ tiêu cứng sinh ra trò chơi.

3Công khai cách đo và lý doNhóm cần biết số liệu để làm gì.

4Hỏi người trước khi tin sốMười lăm phút trò chuyện thường rõ hơn bảng số.

5Xem lại thước đo mỗi quýThước đo cũng cần bảo trì như code.

Nói với quản lý

Bắt đầu từ nhu cầu, không từ phản bác

BạnAnh muốn biết nhóm có giao hàng đều và an toàn, phải không?

BạnEm đề nghị hai chỉ số: thời gian giao hàng và tỷ lệ lỗi sau phát hành. Ta theo xu hướng ba tháng.

BạnEm có một chuyện ngắn về kỹ sư viết âm 2000 dòng. Anh nghĩ nó nói điều gì?

Mục tiêu là đổi câu hỏi, không đổi người.

Cân bằng

Số dòng code không hoàn toàn vô dụng

Dùng để cảnh báo

Cho biết quy mô thay đổi
3000 dòng thì yêu cầu chia nhỏ

Đừng quên

Chỉ số khác cũng bị chơi
Không đo gì cũng là lựa chọn tồi

Dữ liệu còn hạn chế: phần lớn bài về đo năng suất là của hãng công cụ hoặc blog. Mình chưa thấy dữ liệu độc lập cho thấy một chỉ số đơn lẻ dự đoán tốt năng suất.

Kết luận

Đo kết quả của nhóm: giao nhanh, giao an toàn, ít làm lại, vẫn muốn làm cùng nhau.

Làm ngay: chọn hai chỉ số kết quả, ghi bốn tuần qua, trình bày xu hướng ở buổi họp tới.

Số dòng code tăng,giá trị có tăng?