AI Không Thể Cứu Vớt Code Xấu: Tại Sao Lập Trình Viên Cao Cấp Lại Quan Trọng Hơn Bao Giờ

Mỗi vài tháng, lại có một tiêu đề giật gân tuyên bố rằng các kỹ sư phần mềm sắp lỗi thời. AI sẽ viết hết toàn bộ code. Lập trình viên xong việc. Đưa máy móc vào, sa thải con người.

Và mỗi vài tháng, thực tế lại đẩy lùi những nhận định này.

Dữ liệu thực tế cho thấy một câu chuyện tinh tế, thú vị hơn và thực tế hơn nhiều. Đó là câu chuyện nơi AI thực sự là một công cụ cộng sức mạnh mẽ, nhưng chỉ khi được vận hành bởi những người thực sự hiểu sâu sắc về những gì họ đang xây dựng. Bài viết này sẽ thảo luận về một phương pháp thực tế để lập trình nhanh cùng AI. Nhưng quan trọng hơn, đó là lý do tại sao phương pháp này lại đòi hỏi tư duy cấp cao (senior-level thinking) thay vì thay thế nó.

Nghịch lý mà không ai muốn nói đến

Vào tháng 7 năm 2025, METR (một tổ chức nghiên cứu AI tiên phong) đã công bố một thử nghiệm đối chứng ngẫu nhiên nghiêm ngặt. Họ tuyển dụng 16 nhà phát triển mã nguồn mở có kinh nghiệm, mỗi người có trung bình 5 năm làm việc trên các kho lưu trữ (repository) trưởng thành với hơn 22.000 sao. Các nhà phát triển đã hoàn thành 246 nhiệm vụ thực tế, được phân bổ ngẫu nhiên để cho phép hoặc không cho phép sử dụng các công cụ AI.

Kết quả? Các nhà phát triển sử dụng AI mất thời gian dài hơn 19% để hoàn thành nhiệm vụ.

Trước khi nghiên cứu bắt đầu, các nhà phát triển dự đoán AI sẽ giúp họ tiết kiệm 24% thời gian. Sau khi nghiên cứu kết thúc, họ vẫn tin rằng nó giúp họ tiết kiệm được 20%. Nhận thức về tốc độ hoàn toàn tách biệt khỏi thực tế.

Vào tháng 2 năm 2026, METR đã công bố một bản cập nhật thừa nhận rằng các công cụ đã phát triển nhanh chóng kể từ đầu năm 2025, và dữ liệu mới hơn của họ không đáng tin cậy do hiệu ứng lựa chọn: những nhà phát triển thấy AI có giá trị nhất từ chối làm việc nếu không có nó, và họ đang lọc bỏ các nhiệm vụ không muốn làm mà không có AI. Xu hướng khả năng đã được cải thiện, nhưng bài học cốt lõi vẫn đứng vững: cảm thấy nhanh và thực sự nhanh là hai chuyện hoàn toàn khác nhau.

Trong khi đó, Báo cáo Nghịch lý Năng suất AI của Faros AI (2025), dựa trên dữ liệu telemetry từ hơn 10.000 nhà phát triển trên 1.255 đội nhóm, đã xác nhận sự đứt gãy này ở cấp độ tổ chức: các nhà phát triển sử dụng AI viết nhiều code hơn và hoàn thành nhiều nhiệm vụ hơn, nhưng các công ty không thấy sự cải thiện đáng kể trong tốc độ giao ứng dụng hoặc kết quả kinh doanh.

Tại sao? Bởi vì tốc độ viết code chưa bao giờ là nút thắt cổ chai thực sự.

Vấn đề di chuyển nút thắt cổ chai

Khi AI tăng tốc độ tạo code, số lượng pull request tăng lên. Hàng đợi review (xem xét) dài thêm. Quy trình kiểm thử (QA) bị quá tải. Xác thực bảo mật bị tụt hậu. Nút thắt cổ chai không biến mất; nó di chuyển xuống hạ lưu (downstream).

GitClear đã phân tích 153 triệu dòng code bị thay đổi và tìm thấy một xu hướng đáng báo động mà họ gọi là "nợ kỹ thuật do AI gây ra". Theo nhà sáng lập Bill Harding, việc thêm code nhanh là điều đáng mong muốn nếu bạn làm việc đơn độc, nhưng code được thêm vội vã là độc hại đối với các đội nhóm phải duy trì nó sau đó.

Đây là vấn đề cơ bản khi coi AI là sự thay thế cho phán đoán kỹ thuật. AI xuất sắc trong việc tạo code. Nhưng nó rất tệ trong việc hiểu tại sao code đó tồn tại, sự đánh đổi (trade-offs) mà nó mang lại, và điều gì sẽ bị hỏng khi yêu cầu thay đổi sáu tháng sau.

Đây chính là nơi các lập trình viên cấp cao (Senior developers) trở nên không chỉ hữu ích, mà là không thể thay thế.

Những gì các huyền thoại đang nói

Grady Booch, người đồng sáng tạo UML, IBM Fellow và một trong những nhân vật có ảnh hưởng nhất trong lịch sử kỹ thuật phần mềm, mô tả thời điểm hiện tại là "thời kỳ vàng thứ ba của kỹ thuật phần mềm". Trong một cuộc trò chuyện vào tháng 2 năm 2026 trên The Pragmatic Engineer, ông đã thẳng thắn phát biểu: khi được hỏi về dự báo rằng kỹ thuật phần mềm sẽ hoàn toàn có thể tự động hóa trong vòng 12 tháng, Booch gọi đó là "hoàn toàn vô lý" và lập luận rằng nó phản ánh sự hiểu sai căn bản về bản chất của kỹ thuật phần mềm.

Điểm của ông rất chính xác: Các công cụ AI giảm ma sát và giải phóng các nhà phát triển khỏi sự nhàm chán của việc triển khai, nhưng công việc cốt lõi của kỹ thuật phần mềm (cân bằng các lực lượng kỹ thuật, đưa ra quyết định thiết kế trong sự không chắc chắn, chịu trách nhiệm cho các hệ thống quy mô lớn) vẫn mang tính con người cơ bản. Ông lập luận rằng kiến trúc quan trọng hơn bao giờ hết.

Kent Beck, người sáng tạo Extreme Programming, đồng tác giả Tuyên ngôn Agile và người tiên phong của Phát triển Hướng dẫn Kiểm thử (TDD), đưa ra sự phân biệt quan trọng giữa hai chế độ làm việc với AI:

• Vibe coding (Lập trình theo cảm tính): Bạn mô tả những gì bạn muốn, đưa lỗi trả lại cho AI và hy vọng có một đoạn code hoạt động. Bạn chỉ quan tâm đến hành vi, không quan tâm đến chất lượng.
• Augmented coding (Lập trình tăng cường): Bạn duy trì các tiêu chuẩn kỹ thuật phần mềm truyền thống (code sạch, độ bao phủ kiểm thử, tính dễ bảo trì) trong khi tận dụng AI để gõ ít hơn và di chuyển nhanh hơn.

Beck đã viết code hơn 50 năm. Thay vì cảm thấy bị đe dọa bởi AI, ông mô tả cảm thấy được tiếp thêm năng lượng từ nó, cuối cùng có thể giải quyết các tham vọng dự án mà ông đã trì hoãn trong nhiều năm. Nhưng cách tiếp cận của ông rất kỷ luật: AI là người thực thi, nhà phát triển vẫn là kiến trúc sư của chất lượng.

Beck cũng quan sát thấy một điều quan trọng về các nhà phát triển trẻ: những người sử dụng AI tốt không đang làm "vibe coding". Họ sử dụng AI để tăng tốc độ học hỏi trong khi duy trì các tiêu chuẩn chất lượng. Công cụ khuếch đại bất kỳ kỷ luật (hoặc sự thiếu kỷ luật) nào đã tồn tại.

Phương pháp: Phát triển cấp cao được tăng cường bởi AI

Dựa trên nghiên cứu và các mô hình đang nổi lên từ các đội nhóm hoạt động hiệu quả cao, dưới đây là một khuôn khổ thực tế để lập trình nhanh cùng AI mà không hy sinh chất lượng.

1. Xác định trước khi bạn tạo mã (Define Before You Generate)

Trước khi chạm vào bất kỳ công cụ AI nào, hãy viết xuống ba điều:

• Cái gì bạn đang xây dựng (hợp đồng, không phải cách triển khai).
• Tại sao nó quan trọng (ngữ cảnh kinh doanh hoặc hệ thống).
• "Hoàn thành trông như thế nào" (tiêu chí chấp nhận, các trường hợp ngoại lệ, các chế độ thất bại).

Việc này mất 5 đến 15 phút. Nó tiết kiệm hàng giờ đồng hồ. AI xuất sắc trong việc tạo giải pháp cho các vấn đề được xác định rõ ràng. Nó rất tệ trong việc định nghĩa vấn đề. Đó là công việc của bạn.

2. Kiến trúc trước, Code sau (Architecture First, Code Second)

Quyết định ranh giới của bạn trước khi tạo ra một dòng code nào. Nó thuộc module nào? Các giao diện (interface) là gì? Các phụ thuộc là gì? Chế độ thất bại là gì?

AI không hiểu lịch sử hệ thống của bạn, quy ước của đội nhóm, hay sự cố sản xuất vào thứ Ba tuần trước. Một lập trình viên Senior thì hiểu. Hãy tự đưa ra các quyết định cấu trúc, sau đó để AI lấp đầy các chi tiết triển khai.

3. Các đơn vị nhỏ, có thể kiểm thử (Small, Testable Units)

Chia công việc của bạn thành các đơn vị đủ nhỏ để bạn có thể xác minh từng đơn vị trong vòng dưới 5 phút. Tạo code cho từng đơn vị riêng lẻ. Xem xét, kiểm thử và cam kết (commit) trước khi chuyển sang cái tiếp theo.

Về cơ bản, đây là TDD được áp dụng cho phát triển được hỗ trợ bởi AI. Sự hiểu biết của Kent Beck áp dụng trực tiếp: chu trình TDD (Red, Green, Refactor) là một cơ chế quản trị tự nhiên cho code do AI tạo ra. Hãy tự viết bài kiểm tra (test). Để AI viết phần triển khai. Tái cấu trúc (refactor) cùng nhau.

4. Review như thể đó là code của người khác (Vì nó đúng là như vậy)

Code do AI tạo ra, theo định nghĩa, là code bạn không viết. Hãy đối xử với nó bằng sự soi xét giống như bạn áp dụng cho một pull request từ một thành viên mới trong nhóm: một người đóng góp tài năng nhưng "mù" ngữ cảnh, người không biết môi trường sản xuất của bạn.

Khảo sát State of Developer Ecosystem 2025 của JetBrains thấy rằng 85% nhà phát triển thường xuyên sử dụng công cụ AI, nhưng chỉ từ 29% đến 46% tin tưởng vào kết quả. Sự hoài nghi lành mạnh đó là hoàn toàn đúng đắn. "Tin tưởng nhưng kiểm tra" không chỉ là phương châm. Đó là phương pháp.

5. Nắm quyền ngân sách độ phức tạp (Own the Complexity Budget)

Mọi hệ thống đều có ngân sách độ phức tạp. AI không biết ngân sách của bạn. Nó sẽ vui vẻ tạo ra một giải pháp sang trọng thêm ba phụ thuộc, giới thiệu một mẫu mới không nhất quán với codebase của bạn, và làm tăng gấp bề mặt cấu hình.

Các lập trình viên cấp cao duy trì mô hình tinh thần về độ phức tạp của hệ thống. Hãy bảo vệ nó. Từ chối code được tạo ra giải quyết vấn đề ngay lập tức nhưng làm tăng entropy (sự hỗn loạn) của hệ thống.

6. Đầu tư vào Prompt như một kỹ năng

Sự khác biệt giữa một prompt mơ hồ và một prompt chính xác thường là sự khác biệt giữa 30 phút gỡ lỗi đầu ra AI và 30 giây sao chép một triển khai chính xác. Hãy đối xử với các prompt của bạn giống như bạn đối xử với code của mình: cụ thể, có cấu trúc và có chủ đích.

Bao gồm các ràng buộc. Chỉ định phiên bản ngôn ngữ, quy ước framework, mẫu xử lý lỗi bạn mong đợi. Càng nhiều ngữ cảnh bạn cung cấp, càng ít công việc bạn phải xem xét lại.

Tại sao chúng ta cần nhiều Lập trình viên Senior hơn, không phải ít hơn

Đây là sự thật khó nghe mà ngành công nghiệp cần lắng nghe.

AI đang làm cho khoảng cách giữa các lập trình viên giỏi và lập trình viên bình thường rộng ra, không phải hẹp lại. Báo cáo của Faros AI nhận thấy việc áp dụng AI nghiêng về các kỹ sư ít thâm niên hơn, trong khi các kỹ sư cấp cao áp dụng nó ít thường xuyên hơn. Điều này không phải là technophobia (sợ công nghệ). Đó là bởi vì các kỹ sư cấp cao nhận ra rằng hầu hết việc sử dụng AI vẫn ở mức bề mặt: tự động hoàn thành và tạo code mẫu (boilerplate). Các khả năng nâng cao (review có ngữ cảnh, lập luận kiến trúc, thực thi nhiệm vụ theo tác nhân) phần lớn vẫn chưa được khai thác.

Những nhà phát triển khai thác nhiều giá trị nhất từ AI là những người đã biết thế nào là tốt. Họ có thể phát hiện khi code được tạo ra tinh vi nhưng sai. Họ hiểu tại sao một mẫu cụ thể không phù hợp với ngữ cảnh của họ. Họ có thể phân giải một vấn đề phức tạp thành các đơn vị có thể xử lý được bằng AI.

Nghiên cứu nhất quán cho thấy các lập trình viên trẻ thấy lợi ích tốc độ thô lớn nhất từ AI, nhưng cũng đòi hỏi sự giám sát cao nhất. Lợi ích ròng phụ thuộc vào độ chín của quản trị, mà là một cách khác để nói nó phụ thuộc vào việc có các lập trình viên cấp cao có thể thiết lập tiêu chuẩn, xem xét đầu ra và duy trì tính toàn vẹn của hệ thống.

Mối quan tâm chính của Grady Booch về kỷ nguyên AI không phải là các kỹ sư sẽ bị thay thế. Đó là sự giảm kỹ năng (deskilling): khi AI xử lý các nhiệm vụ nhập môn, thế hệ tiếp theo có thể thiếu cơ hội để phát triển các kỹ năng cơ bản làm cho các kỹ sư cấp cao trở nên giá trị. Nếu chúng ta không tạo ra các lộ trình có chủ đích để các nhà phát triển xây dựng chuyên môn sâu, chúng ta sẽ kết thúc với một ngành công nghiệp đầy những người vận hành AI có thể tạo code nhưng không thể thiết kế hệ thống.

Kết luận

AI là công cụ lập trình mạnh mẽ nhất mà chúng ta từng có. Nó cũng là công cụ nguy hiểm nhất trong tay người không hiểu những gì họ đang xây dựng.

Phương pháp rất đơn giản: tư duy cấp cao, thực thi cấp AI. Xác định vấn đề một cách chính xác. Đưa ra các quyết định kiến trúc. Tạo code trong các đơn vị nhỏ, có thể xác minh. Xem xét mọi thứ. Nắm quyền kiểm soát độ phức tạp.

Những nhà phát triển sẽ phát đạt không phải là những người gõ nhanh nhất hoặc tạo ra nhiều dòng code nhất. Họ là những người hiểu hệ thống, đưa ra các đánh đổi âm thanh và chịu trách nhiệm cho những gì được xuất xưởng.

Chúng ta không cần ít lập trình viên cấp cao hơn. Chúng ta cần nhiều hơn thế. Và chúng ta cần họ giỏi hơn bao giờ hết.

Rodrigo Caetano là nhà sáng lập và CEO của SULTS, một nền tảng quản lý vận hành tất cả trong một phục vụ hơn 1.500 công ty và 600.000 người dùng. Ông đã viết code từ năm 2006 và vẫn viết code sản xuất bằng Java.