Số dòng code đã có một người làm PR giỏi hơn
(curlewis.co.nz)- Việc đánh giá năng suất của lập trình viên nên dựa trên chỉ số đầu ra như giá trị cho khách hàng, doanh thu và độ tin cậy, thay vì lượng code
- Các con số quảng bá AI coding gần đây từ Google, Anthropic, OpenAI và Cursor đều tập trung vào các tuyên bố mang tính định lượng như tỷ lệ code được tạo ra hoặc số dòng code
- Tuyên bố trước đây của GitHub Copilot về việc tăng tốc công việc 55% là một kết quả có thể kiểm chứng, nhưng “tỷ lệ code do AI viết” có thể tăng lên dù có cải thiện hay không
- Nghiên cứu thực tế cho kết quả trái chiều, từ mức +26% số việc hoàn thành của Cui et al. đến kết quả “chậm hơn 19%” của METR rồi bị đảo ngược sau đó, và khảo sát cho thấy 90% doanh nghiệp không đo được hiệu quả; tác động ở cấp tổ chức vào khoảng 10%
- Việc áp dụng AI là cần thiết, nhưng đo lường hiệu quả phải dựa trên các tiêu chuẩn đã được kiểm chứng như chỉ số DORA, độ tin cậy, tốc độ tạo ra thay đổi có ý nghĩa, doanh thu và giá trị khách hàng
Sự trở lại của chỉ số số dòng code
- Chỉ vì một trong hai lập trình viên senior tại một công ty SaaS cách đây 15 năm viết nhiều code hơn 40% so với người còn lại không có nghĩa người đó là lập trình viên giỏi hơn
- Điều thực sự quan trọng là cái gì đã được phát hành (ship) và nó đóng góp ra sao cho khách hàng, doanh thu và độ ổn định; số dòng code và số lượng PR từ lâu đã được xem là cách đo tệ suốt hàng chục năm
- Các chỉ số tiêu biểu mà ngành đưa ra trong năm 2026 đều tập trung vào tỷ lệ code do AI viết
- Google: 75% code mới được AI tạo ra
- Anthropic: khoảng 80% code production được merge là do Claude viết, và kỹ sư triển khai “nhiều code hơn gấp 8 lần” mỗi quý
- OpenAI: tương tự, khoảng 80%
- Cursor: “viết hơn 100 triệu dòng code doanh nghiệp mỗi ngày”
- Tất cả các con số này đều là các tuyên bố về khối lượng (volume), và “tỷ lệ code do AI viết” thực chất chỉ là số dòng code với câu chữ quảng bá tinh vi hơn
- Việc tất cả các công ty này đều là nhà cung cấp AI cũng khiến động cơ thổi phồng mức độ chấp nhận trở nên rất rõ ràng
Trước đây họ từng nói về kết quả
- Vài năm trước, chỉ số cốt lõi không chỉ khác về quy mô mà còn khác về bản chất
- Tuyên bố tiêu biểu của GitHub là khi dùng Copilot, công việc được hoàn thành nhanh hơn 55%
- Dù bị chỉ trích nhiều, đây vẫn là một tuyên bố về kết quả (outcome): táo bạo, có thể phản bác và nói về giá trị — nếu sai thì có thể chứng minh là sai
- Các tuyên bố của năm 2026 được cấu trúc theo cách gần như không thể thất bại
- “75% code do AI viết” vẫn có thể là sự thật và tiếp tục tăng lên, bất kể việc triển khai có nhanh hơn, sự cố có giảm hay khách hàng có hài lòng hơn hay không
- Các con số về khối lượng chỉ gây thất vọng khi mức độ chấp nhận bị chững lại, và đa số đều đồng ý rằng việc chấp nhận là có thật
- Tuyên bố thì lớn hơn, nhưng ý nghĩa thực sự lại ít đi
Phần không lên bảng quảng cáo
- Điều đã xảy ra trong thời gian đó là bằng chứng về kết quả trở nên phức tạp hơn
-
Các kết quả ủng hộ việc áp dụng
- Cui et al.: với khoảng 5.000 lập trình viên, số việc hoàn thành +26%, đặc biệt cải thiện mạnh nhất ở lập trình viên junior — gần như không có nhiều tranh cãi
-
Bằng chứng theo hướng ngược lại
-
METR đảo ngược lập trường
- Tháng 2/2026, METR về thực chất đã rút lại lập trường trước đó — ước tính tiếp theo đảo chiều sang tăng tốc (speedup), dù biên độ sai số rất rộng
- Vì giờ đây các lập trình viên từ chối làm việc nếu không có AI và cũng không thể tự báo cáo đáng tin cậy thời gian cho các tác vụ có agent hỗ trợ, nên bản thân thiết kế nghiên cứu đã bị loại bỏ
- Lập trường mới nhất là: trong năm 2026, AI nhiều khả năng giúp tăng tốc cho lập trình viên, nhưng mức độ bao nhiêu thì không thể đo gọn gàng được
-
Tác động ở cấp doanh nghiệp
- Khảo sát khoảng 6.000 lãnh đạo của NBER: 69% doanh nghiệp đang dùng AI, nhưng khoảng 9 trên 10 báo cáo rằng không có tác động năng suất nào đo được
- Đồng thuận xuyên suốt các nghiên cứu là mức cải thiện khoảng 10% ở cấp tổ chức — hữu ích, nhưng chưa đến mức “không cần lập trình viên nữa”
- Những người hoài nghi vẫn chỉ trích dẫn “chậm hơn 19%” thì cũng là chọn lọc số liệu có lợi; nghiên cứu vẫn đang được cập nhật còn ngành thì chỉ đổi đối tượng đo lường
Phiên bản vanity metric của AI
- Đây không chỉ là vấn đề trong các tuyên bố của nhà cung cấp AI
-
Mô hình trưởng thành và những cái thang
- Carnegie Mellon SEI và Accenture vài ngày trước đã ra mắt AI Adoption Maturity Model — 5 cấp độ, 8 chiều, và dùng thống kê “95% tổ chức không có lợi nhuận” cho mục đích marketing
- “8 levels of AI-assisted development” của Steve Yegge xếp hạng dựa trên việc dùng công cụ nào và giám sát ở mức nào
- Mọi nhà cung cấp công cụ đều tung ra các thang đo trưởng thành, và bậc cao nhất thường là “dùng sản phẩm của họ nhiều hơn”
- Các thang này thực chất đo cường độ áp dụng, rồi gọi đó là trưởng thành — cùng một sự thay thế, chỉ khác bao bì
-
Sự hỗn loạn trong định nghĩa
- Khi Augment hỏi 219 lãnh đạo kỹ thuật định nghĩa “AI-native engineering”, họ nhận được 219 câu trả lời khác nhau
-
Hai mặt của Anthropic
- Vừa đưa ra tuyên bố “phát hành nhiều code hơn gấp 8 lần”, vừa công bố một trong những nghiên cứu chặt chẽ nhất năm nay
- Kết quả RCT cho thấy các lập trình viên có AI hỗ trợ đạt điểm thấp hơn 17% về mức độ hiểu đoạn code vừa phát hành, và không có mức tăng năng suất có ý nghĩa thống kê
- Nghĩa là hai điều cùng đúng một lúc: bộ phận nghiên cứu thì cập nhật, còn bộ phận marketing thì đếm khối lượng
Vì sao cần chú ý đến vấn đề này
- Những con số này không chỉ để trang trí mà còn tác động đến ngân sách, kỳ vọng hiệu suất và kế hoạch nhân sự
-
Cắt giảm nhân sự dưới danh nghĩa AI
- Tháng 2, Jack Dorsey cắt giảm hơn 40% nhân sự của Block (4.000+ người), và nêu AI là lập luận trọng tâm một cách công khai — “đội ngũ nhỏ hơn có thể làm nhiều hơn và tốt hơn với các công cụ chúng ta đang xây dựng”
- Vài tuần sau, Atlassian cắt giảm 10% (khoảng 1.600 người), thừa nhận rằng “giả vờ AI không làm thay đổi cấu trúc kỹ năng hoặc số lượng vai trò cần thiết là không trung thực”
- Trong cùng thông báo đó, Dorsey cũng nói rằng hoạt động kinh doanh vẫn vững và lợi nhuận gộp đang tăng
-
Nghi vấn với các tuyên bố năng suất
- Nếu “AI làm mọi người năng suất hơn nên cần ít nhân sự hơn”, thì tôi muốn thấy bằng chứng cho điều đó, nhưng hiện tại dường như chưa có
- Cần chứng minh rằng một phần nhân sự thực sự đang nhàn rỗi hoặc bị tận dụng kém; trong khi các công ty sản phẩm/SaaS luôn có roadmap bất tận, nên năng lực tăng thêm lẽ ra phải được dùng cho giá trị khách hàng và tốc độ — và phải thể hiện qua MAU, tỷ lệ chuyển đổi, doanh thu
- Việc chọn sa thải là dấu hiệu cho thấy tuyên bố về năng suất đang đóng vai trò PR cho một quyết định đã được đưa ra vì lý do khác như tuyển quá tay hoặc áp lực từ nhà đầu tư
- Có những trường hợp cắt giảm dựa trên hiệu quả là hợp lý, nhưng khi đó phải dùng hệ thống đánh giá hiệu suất cá nhân vốn đã vận hành, chứ không phải số token, “tỷ lệ code do AI viết” hay hạng trên thang trưởng thành
- Nếu cơ sở sàng lọc là vanity metric, thì việc sàng lọc đó chẳng khác gì “một cuộc xổ số được tô son điểm phấn”
Kết luận
- Đây không phải quan điểm chống AI; ngược lại, lập trường là mọi kỹ sư nên dùng AI mỗi ngày
- Dù gọi là AI-first hay AI-proficient, điều cần thiết là luôn tò mò thử nghiệm công cụ mới và model mới nhất
- Ngành này đã hấp thụ ngôn ngữ bậc cao, IDE, tự động hoàn thành, agile, devops; lúc nào cũng có người kháng cự và hoài niệm quá khứ, nhưng rồi cuối cùng họ cũng tham gia
- Điểm khác lần này là tốc độ — việc áp dụng “cloud” có thể trì hoãn vài năm mà vẫn sống sót, còn với AI thì có thể chỉ vài tháng
- Việc áp dụng AI là vạch xuất phát chứ không phải bảng điểm
- Cách đo hiệu quả kỹ thuật vốn đã được biết rõ — chỉ số DORA, độ tin cậy, tỷ lệ thay đổi có ý nghĩa, và cuối cùng là doanh thu cùng giá trị khách hàng
- Không có lý do gì để bỏ các phương pháp đã được kiểm chứng mà chuyển sang các điểm số vanity của AI
- Câu hỏi nên ném ra trong các buổi vendor pitch, review của lãnh đạo hay trên LinkedIn feed là: “Đó là kết quả hay chỉ là khối lượng?”
- Cách làm việc nên là AI-first, còn cách đo lường phải là những phương pháp đã được kiểm chứng qua thực chiến (battle-tested)
1 bình luận
Ý kiến trên Hacker News
Dòng chảy kỳ lạ này dường như đạt đỉnh trong bài blog của OpenAI vào tháng 2 năm 2026 [1]. Đây là bài mới lên trang chủ gần đây [2], nói về quá trình tạo ra một thứ được agent viết 100%
Nhưng lại không hề giải thích rốt cuộc thứ đó là gì, hay mang lại giá trị gì cho người dùng. Mô tả gần nhất chỉ là: “Sản phẩm này đã được hàng trăm người dùng nội bộ sử dụng, và còn có những power user nội bộ dùng nó hằng ngày”
Trong khi đó, việc nó có 1 triệu dòng code lại được lặp lại đến hai lần chỉ trong vài trăm từ đầu tiên
[1] https://openai.com/index/harness-engineering/
[2] https://news.ycombinator.com/item?id=48416264
Nếu lại còn “1 triệu dòng code” và “được agent viết 100%” thì càng có vẻ đúng hơn. Hoặc cũng có thể là một menu JS cho wiki nội bộ, mà thực chất là viết lại jquery bằng MS JScript rồi biên dịch xuống JS 5
Dù LLM có mạnh đến đâu thì khả năng bảo trì của nó có lẽ cũng gần như không có
https://github.com/openai/symphony
Trong một buổi phỏng vấn podcast, họ nói đó là một ứng dụng Electron để người dùng tải xuống, nên họ tạo bản build mới theo chu kỳ. Xem mục “Autonomous Merging Flow” ở đây: https://www.latent.space/p/harness-eng
Tôi cứ nhớ mãi chuyện một người bên Microsoft từng đăng kiểu như “muốn 1 triệu dòng code mỗi kỹ sư mỗi tháng”. Với hầu hết kỹ sư mà tôi đã kể chuyện này, nó nghe như châm biếm, nhưng hóa ra hoàn toàn không phải châm biếm, và dường như phản ánh khá đúng thái độ của nhiều CEO đối với việc sinh code bằng LLM
Tuy vậy, trong vài tháng gần đây, cảm giác như cơn sốt tạo ra lượng dòng code không thể bảo trì được đã hạ nhiệt đôi chút. Những góc nhìn thực tế và hữu dụng hơn đang được chia sẻ công khai nhiều hơn, và có vẻ cũng dần chạm tới một phần tầng lãnh đạo cao nhất ở vài công ty công nghệ. Có lẽ mọi thứ vẫn chưa hoàn toàn tiêu đời
Thực tế thì phần lớn code vẫn không hề được test
1 triệu dòng mỗi tháng / 25 ngày mỗi tháng / 8 giờ mỗi ngày / 60 phút mỗi giờ
Với người làm code review thì đây có vẻ là một vấn đề khá lớn
Việc bắt mỗi kỹ sư tạo ra 1 triệu dòng code mỗi tháng mà không nghĩ xem những dòng đó sẽ kiếm tiền cho công ty bằng cách nào, hay bao nhiêu token sẽ bị đốt với chi phí ra sao, rõ ràng không phải là một kế hoạch được cân nhắc kỹ lưỡng cho lắm
Trong khi đó, nợ kỹ thuật lại không níu được giới quản lý theo cách tương tự. Nợ nói chung có thể là vấn đề, nhưng thường bị xem là thứ chưa cần tránh hay xử lý cho đến khi nó thực sự trở thành vấn đề, nên cứ liên tục bị đẩy lùi
Tôi đã thấy điều này ở cả hai công ty nhỏ nơi tôi làm. Vài tháng trước ai cũng rất phấn khích khi được cấp Claude Cowork, và đến giờ vẫn dùng mỗi ngày, nhưng nếu so với thứ phép màu họ mong đợi thì khá là thất vọng
Kết quả thì tầm thường và dài dòng, sai cả những thứ rất cơ bản, liên tục đụng giới hạn token, rồi cuối cùng lại than rằng tự làm còn nhanh hơn nên quay về làm thủ công
Có thể lúc đầu cũng do dùng công cụ chưa đúng cách, nhưng mọi người đang nhận ra rằng vẫn còn một khoảng cách giữa những gì các CEO AI, dân buôn trên LinkedIn, và mấy người bán thực phẩm bổ sung AI trên YouTube nói với thực tế
Nếu một công ty nói rằng “AI đã làm mọi người năng suất hơn nên cần ít người hơn”, tôi muốn thấy bằng chứng. Hiện giờ tôi không tin là có bằng chứng như vậy
Thực tế thì họ đang nói nhảm, và dùng AI làm cái cớ để đảo ngược việc tuyển dụng quá mức thời COVID. Đồng thời, điều đó cũng khiến nhà đầu tư cảm thấy họ đã đón nhận công nghệ hợp mốt mới nhất và trở thành một tổ chức gọn nhẹ, hiệu quả chi phí hơn
Tôi cứ nghĩ nhà đầu tư quan tâm đến lợi nhuận hơn là chuyện tiếp nhận công nghệ hợp mốt mới nhất
Và một công ty nói kiểu “Chúng tôi cũng dùng công nghệ hào nhoáng mà bất kỳ thằng ngốc nào trong phòng ngủ cũng dùng được!” thì cũng là một công ty hoàn toàn không có sức cạnh tranh
Điều vô tận buồn cười là trong nhiều thập kỷ, ngành của chúng ta vẫn giải thích rằng “công việc chúng ta làm phức tạp và mất thời gian nên không thể dễ dàng đo năng suất”, nhưng khi AI xuất hiện thì đột nhiên số dòng code, hệ số nhân N lần, số ticket mỗi tuần lại được tung hô như thể đó là các chỉ số hữu ích hay khách quan
Những lý do từng dùng để bác bỏ các chỉ số như số dòng code vẫn không thay đổi. Điều cốt lõi không phải là lượng code tạo ra mà là chất lượng đầu ra. AI cũng giữ nguyên những vấn đề con người vốn có. Thế mà vì lý do nào đó chúng ta lại vứt bỏ những gì đã học được, khá là đáng xấu hổ
Bởi vì luôn tồn tại những ông sếp chỉ tham gia hời hợt nhưng lại hung hăng và đòi hỏi. Thật đáng buồn, những người mà công việc chính là vắt kiệt thêm nỗ lực từ nhân viên và không đóng góp gì cho phối hợp hay điều phối vẫn có giá trị kinh tế
Vì vậy luôn tồn tại hai đám mây chồng lấn: một bên là thành quả thực tế, bên kia là những phép đo như số dòng code
AI cung cấp đầy đủ công cụ để làm hài lòng kiểu sếp chỉ tham gia hời hợt nhưng đòi hỏi đủ thứ đó. Vì vậy giờ sẽ có nhiều người thích lấy số dòng code và số tính năng bổ sung làm thước đo hơn. Vì giờ việc đó đã dễ hơn
Nếu một lập trình viên senior hạng A+ làm tính năng trong 8 tháng mà cuối cùng không phát hành hoặc MVP bị hủy, thì tức là đã lãng phí lập trình viên senior A+ đó, và năng suất của họ sẽ ngang với hai kỹ sư hạng B+ tham gia cùng dự án
Đây thật ra là một vấn đề rất phổ biến, nhưng thường bị bỏ qua trong tuyển dụng hoặc phân bổ nguồn lực dự án. AI sẽ không thể thay đổi điều này theo cách có ý nghĩa
Đội ngũ có thể hoàn thành công việc nhanh hơn nhiều, nhưng tầng lớp quan liêu ở phía trên rất có thể vẫn y nguyên, và khi đó lợi ích từ AI coding sẽ trở nên không đáng kể. Muốn phù hợp với AI thì phải xây lại công ty từ trên xuống dưới, mà chuyện đó gần như sẽ không xảy ra
Phần cuối ép đẩy AI kỳ lạ đến mức gần như không có căn cứ. Không có lý do, không có mục tiêu, cũng không có lập luận về lợi ích, chỉ là kiểu “cứ dùng AI đi, developer phải đón nhận cái mới”
Gần đây tôi cũng đã đọc một bài viết khác giả vờ chỉ trích AI bằng vài ngữ cảnh ngắn ngủi rồi cuối cùng lại kết thúc bằng quảng cáo AI, và không hề có nội dung nào nối hai phần đó lại
Nhà đầu tư và khách hàng lớn cũng sẽ phải nghĩ lại trước khi ký các hợp đồng quan trọng
Vì thế phải dùng AI. Đừng tính toán vụn vặt chi phí và lợi ích. Thế giới đang đi theo hướng này, và nếu bạn muốn sống bằng nghề phát triển phần mềm thì bạn cũng phải ở trong hướng đó
Đoạn “Lần này khác biệt là tốc độ. Với cloud, chậm vài năm vẫn có thể sống sót. Với AI, có thể chỉ là vài tháng” nghe rất kỳ
Có vẻ tác giả hiểu rằng những tuyên bố ủng hộ AI của các công ty AI về tính thiết yếu của sản phẩm là không thể phản chứng, nhưng rồi ngay sau đó lại lùi thành kiểu “khoan, đừng nghĩ tôi là người chống AI”
Tuyên bố trên nghiêm ngặt hơn ở chỗ nào so với các tuyên bố về năng suất mà phần còn lại của bài viết đang chỉ trích? Cái ý rằng nếu không chấp nhận AI trong vài tháng thì sẽ không thể “sống sót”?
Dù CEO AI có nói thì cũng không thành sự thật, và việc một người chỉ ra CEO AI nói nhảm rồi vì lý do nào đó lại nói y hệt như vậy cũng không làm nó thành sự thật
Việc nói rằng sa thải người vì AI có biên độ diễn giải quá rộng và chuyển trách nhiệm từ bản thân sang AI. Thực tế thì không nên đổ những gì CEO làm cho AI. Họ hoàn toàn có thể đào tạo lại nhân viên để phù hợp với AI mà đã không làm. Tại sao? Có lẽ vì nguyên nhân không phải là AI
Tôi thực sự tự viết, chứ không làm bằng “AI slop” như tôi vẫn nói ở chỗ khác, nên có lẽ phần cuối đã trở nên “sloppy theo kiểu con người”
Đúng là tôi đã không hỗ trợ được cho đoạn “khoan”, nhưng tôi vẫn giữ quan điểm rằng mọi người nên thử dùng AI. Hãy thử nghiệm và tìm cách nó hữu ích với bản thân. Ngay cả giữa những kỹ sư tương đồng nhau thì phổ giá trị họ nhận được cũng rất rộng
Chi phí để thật sự thử công cụ một cách nghiêm túc gần như bằng 0, và lập trường “hãy áp dụng có chủ đích và đo lường bằng phương pháp nhàm chán đã được kiểm chứng” không giống với “không áp dụng thì sẽ chết” chút nào
Khi công ty nói rằng “AI đã khiến mọi người năng suất hơn nên cần ít nhân sự hơn”, thì ngầm hiểu là công ty đang nói rằng họ không muốn trở nên năng suất hơn
Ý họ là muốn trả ít tiền hơn cho một nhóm ít người hơn nhưng vẫn có cùng mức năng suất
Tại sao lại có sự mất cân đối giữa số tiền người sử dụng lao động nhận được trên mỗi đơn vị năng suất và số tiền nhân viên nhận được?
Nếu đạt cùng đầu ra với ít người hơn thì năng suất của công ty hay quốc gia đã được cải thiện
Nếu cùng mức năng suất với ít người hơn thì đầu ra cũng sẽ giảm tương ứng, nên công ty không được lợi gì, và nếu có chi phí cố định thì thậm chí còn có thể tệ hơn
https://www.mckinsey.com/featured-insights/mckinsey-explaine...
Tôi cho rằng số dòng code thực ra cũng không khác mấy so với số giờ có mặt ở văn phòng. Trước đại dịch, người ta luôn nói “nếu họ không ở văn phòng thì làm sao biết họ có đang làm việc không?”
Rất đơn giản. Hãy xem họ đóng góp gì cho doanh nghiệp bằng các chỉ số đầu ra được dùng để đánh giá mọi nhân viên
Tôi nghĩ chính các kỹ sư chúng ta cũng phải chịu phần lớn trách nhiệm cho việc số dòng code vẫn được xem như tài sản chứ không phải nợ. Chúng ta tự hào về những gì mình tạo ra, nhưng để giải thích một thứ “lớn” đến mức nào thì cần chỉ số, và rồi lại quay về chỉ số dễ đếm nhất
Cần đổi cách dùng từ. Đặc biệt là nên thường xuyên nói kiểu “...và cái giá của nó là N dòng code”. Cũng cần nói rõ những dòng code đó đã được dùng vào đâu
“Tôi đã triển khai tính năng mới X mà chỉ tốn có 200 dòng”
“Lỗi đó cực kỳ khó tìm, nhưng rốt cuộc chỉ tốn 6 dòng code”
“Trong trường hợp X thì chúng tôi làm việc đó, còn trong trường hợp Y thì không, nhưng rồi hóa ra bản thân sự phân biệt đó là không cần thiết. Vì vậy khi sửa vấn đề, chúng tôi đồng thời tiết kiệm được 20 dòng code”
Số dòng code là cái giá chúng ta phải trả. Chúng ta không khoe đã tiêu 200 đô mà không nói mình mua gì. Vậy tại sao với số dòng code thì lại làm thế?
“Tôi đăng ký muộn nên phải trả thêm 200 đô” và “Tôi mua được một chiếc giá treo đèn bằng gốm thủ công sơn tay với giá chỉ 200 đô. Hàng sản xuất công nghiệp trên Amazon còn hơn 1.200 đô” là hai câu hoàn toàn khác nhau, và trong code cũng có đúng sự khác biệt tương ứng như vậy