Nội dung: ba vòng xác minh mã do AI tạo ra
AI tăng tốc viết mã, nhưng sản lượng cao hơn không tự động tạo ra phần mềm tốt hơn. Các nhóm kỹ thuật cần xác minh mã ngay khi tác tử tạo ra. Họ cũng cần kiểm tra toàn bộ thay đổi trước khi hợp nhất và duy trì một kho mã đủ khỏe cho những vòng phát triển tiếp theo. Ba vòng này giúp kiểm soát chất lượng, bảo mật, độ tin cậy và nợ kỹ thuật mà không loại bỏ trách nhiệm của con người.
Một nghiên cứu của Đại học Carnegie Mellon về các kho mã công khai sử dụng Cursor ghi nhận số dòng mã được thêm vào tăng từ 3 đến 5 lần trong tháng đầu tiên. Mức tăng này suy giảm sau khoảng 2 tháng. Nghiên cứu dùng SonarQube để đánh giá chất lượng và phát hiện số cảnh báo từ phân tích tĩnh tăng 30%, còn độ phức tạp của mã tăng 41%.
Các kết quả này cho thấy đợt tăng năng suất có thể ngắn hơn ảnh hưởng của nợ kỹ thuật. Theo bài viết gốc của The New Stack, thách thức với các nhóm kỹ thuật không chỉ nằm ở khả năng tạo mã. Họ còn phải xác minh rằng mã thực hiện đúng mục tiêu, đáp ứng tiêu chuẩn nội bộ và không làm nợ kỹ thuật phình to.
Tom Howlett, Giám đốc phụ trách kết nối kỹ thuật AI tại Sonar, cảnh báo không nên dùng số dòng mã làm thước đo. Ông nói: “Nếu chỉ số đó tăng quá mạnh thì nhóm đang có vấn đề.” Với doanh nghiệp Việt Nam đang đưa AI vào quy trình phát triển phần mềm, khả năng kiểm tra và bảo trì phản ánh kết quả đầy đủ hơn. Khả năng đưa mã vào vận hành cũng có ý nghĩa hơn sản lượng mã.
Tốc độ tạo mã đang vượt khả năng xác minh
Tốc độ viết mã bằng AI có thể tăng nhanh hơn năng lực rà soát của nhóm. Nếu quy trình xác minh vẫn phụ thuộc chủ yếu vào việc con người đọc từng dòng, khối lượng thay đổi lớn hơn sẽ biến khâu kiểm tra thành điểm nghẽn.
Howlett nhận định với The New Stack rằng tốc độ viết mã đã tăng nhưng hoạt động xác minh chưa theo kịp. Nhiều nhóm vẫn phụ thuộc vào việc con người đọc và rà soát mã thủ công.
Theo ví dụ của Howlett, nếu lập trình viên tạo ra lượng mã lớn gấp 50 lần nhưng vẫn dùng quy trình rà soát cũ, thời gian dành cho việc kiểm tra sẽ tăng. Áp lực càng rõ khi các yêu cầu hợp nhất mã xuất hiện thường xuyên hơn và chứa nhiều thay đổi hơn. Người rà soát có thể không còn đủ thời gian xem kỹ từng dòng trước khi chấp thuận.
Tác tử AI cũng không phải lúc nào cũng biết đâu là thay đổi nhỏ nhất cần thiết để hoàn thành một tính năng. Khi thiếu bối cảnh về kiến trúc, tệp liên quan và quy ước của dự án, tác tử có thể đưa ra giả định, sửa quá nhiều tệp hoặc tạo thêm mã không cần thiết. Mã dài và phức tạp hơn khiến bước xác minh sau đó tốn nhiều công sức hơn.
Đây là lý do tranh luận về việc AI đang thay đổi hoạt động rà soát mã không thể chỉ tập trung vào tốc độ. Quy trình kiểm tra phải được thiết kế để xử lý khối lượng thay đổi do tác tử tạo ra.
Niềm tin vào mã cần đủ bốn thành phần
Sonar mô tả niềm tin vào mã bằng bốn thành phần: ý định, rào chắn, xác minh và bằng chứng. Howlett cho biết các thành phần được liên kết bằng phép nhân có chủ ý, vì thiếu một thành phần sẽ làm suy giảm độ tin cậy của toàn bộ kết quả.
Ý định xác định thay đổi cần đạt được điều gì. Rào chắn đặt ra giới hạn về chất lượng, bảo mật, độ tin cậy và khả năng bảo trì. Xác minh kiểm tra mã theo những giới hạn đó. Bằng chứng giúp con người biết vì sao thay đổi có thể được chấp nhận.
Việc để chính mô hình vừa tạo mã tự đánh giá kết quả của mình không đáp ứng đầy đủ công thức này. Howlett ví cách làm đó với việc để học sinh tự chấm bài tập. Tác tử viết mã có thể làm việc tốt, nhưng đầu ra mang tính xác suất nên không thể bảo đảm luôn nhất quán hoặc luôn phát hiện đúng phần bị bỏ sót.
Anirban Chatterjee, Giám đốc tiếp thị sản phẩm và giải pháp của Sonar, nói với The New Stack rằng nếu chờ đến yêu cầu hợp nhất mã mới xác minh, tác tử có thể đã lặp lại cùng một lỗi 3, 4 hoặc 5 lần. Mục tiêu là ngăn lỗi lọt vào yêu cầu hợp nhất và ngăn lỗi tiếp tục xuất hiện.
Vòng thứ nhất: xác minh ngay khi tác tử tạo mã
Vòng xác minh thứ nhất đưa hướng dẫn, tạo mã, kiểm tra và khắc phục vào cùng một quy trình. Hệ thống cung cấp bối cảnh, tác tử thực hiện thay đổi, công cụ kiểm tra kết quả và tác tử sửa vấn đề trước khi chuyển sang bước tiếp theo.
Trong vòng tác tử do Sonar mô tả, bối cảnh giúp tác tử hiểu tiêu chuẩn dự án và phạm vi thay đổi. Tác tử không bắt đầu với hiểu biết sâu về kho mã như một lập trình viên giàu kinh nghiệm. Người đã làm việc lâu với hệ thống thường biết kiến trúc, tệp cần sửa và cách viết mã đang được áp dụng. Tác tử phải tìm kiếm những thông tin đó, khiến quá trình khám phá tốn kém hơn khi kho mã phức tạp.
Chatterjee cho rằng việc cung cấp đúng thông tin vào đúng thời điểm có thể giảm công việc dò tìm. Thông tin đó gồm tiêu chuẩn dự án và các vấn đề từng xuất hiện, đồng thời giúp mã mới phù hợp hơn với hệ thống hiện có. Cách tiếp cận này đặc biệt đáng chú ý khi doanh nghiệp triển khai tác tử AI viết mã trên những dự án đã tồn tại nhiều năm.
Phân tích tự động sau mỗi thay đổi giúp phát hiện vấn đề khi phạm vi công việc vẫn nhỏ. Theo Chatterjee, vấn đề được tìm thấy càng sớm thì chi phí sửa trong mã càng thấp. SonarQube thực hiện phân tích bằng tính toán, nên nhóm không phải yêu cầu một mô hình tạo sinh tự xem lại đầu ra và tiêu thụ thêm tài nguyên xử lý. Tác tử có thể dành phần tài nguyên đó để sửa các vấn đề đã được xác nhận.
Vòng thứ hai: kiểm tra toàn bộ thay đổi trước khi hợp nhất
Vòng xác minh thứ hai đánh giá toàn bộ thay đổi trước khi mã đi vào kho dùng chung hoặc tiến gần hơn đến môi trường vận hành. Đây là điểm kiểm tra độc lập nằm ngoài tác tử đã tạo ra mã.
Vòng tích hợp liên tục kiểm tra chất lượng, bảo mật, thành phần phụ thuộc, kiến trúc và khả năng bảo trì. Các tiêu chuẩn của tổ chức được áp dụng qua một cổng chất lượng rõ ràng. Nếu vòng đầu hoạt động tốt, số vấn đề đi tới bước tích hợp liên tục sẽ giảm, nhưng vòng thứ hai vẫn cần thiết để kiểm tra toàn bộ thay đổi.
Mục tiêu không phải loại bỏ trách nhiệm của con người. Howlett cho rằng lập trình viên vẫn chịu trách nhiệm về chất lượng, nhưng nên dành sự chú ý cho những quyết định cần phán đoán của con người. Khi khối lượng mã tăng mạnh, việc rà soát mọi dòng với cùng một mức độ chi tiết như trước không còn thực tế. Kiểm tra tự động có thể thu hẹp phạm vi để lập trình viên tập trung vào thiết kế, tác động kinh doanh và rủi ro quan trọng.
Điều chỉnh mức xác minh theo rủi ro
Mức độ giám sát cần tương xứng với hậu quả nếu phần mềm gặp lỗi. Một ứng dụng nội bộ ít rủi ro có thể dùng quy trình nhẹ hơn. Hệ thống ngân hàng xử lý lượng giao dịch lớn mỗi ngày cần nhiều lớp xác minh và sự tham gia sâu hơn của con người. Không một phép kiểm tra riêng lẻ nào, kể cả mô hình tạo ra mã, đủ sức bảo vệ toàn bộ quy trình.
The New Stack cho biết SonarQube phân tích mã tự động để nhận diện lỗi, lỗ hổng, vấn đề kiến trúc và độ phức tạp. Gitar bổ sung hoạt động rà soát bằng AI, gồm nhận xét trên yêu cầu hợp nhất, bản tóm tắt, phần diễn giải từng bước và sơ đồ. Theo The New Stack, Sonar mua lại Gitar vào tháng 5 năm 2026.
Vòng thứ ba: giữ kho mã đủ khỏe để AI tiếp tục làm việc
Vòng xác minh thứ ba duy trì chất lượng của kho mã vì mã được tạo hôm nay sẽ trở thành bối cảnh cho các tác tử sau này. Lỗi cũ, quy ước thiếu nhất quán và nợ kỹ thuật có thể làm tăng chi phí khám phá và khiến những thay đổi mới khó xác minh hơn.
Công cụ AI không làm việc trên một kho mã đứng yên. Mã được tạo hôm nay sẽ được các tác tử sau này đọc, học và chỉnh sửa. Mã kém chất lượng, quy ước thiếu nhất quán và nợ kỹ thuật vì thế có thể tự khuếch đại qua nhiều vòng phát triển.
Chatterjee khuyến nghị các tổ chức muốn mở rộng sử dụng AI phải bảo đảm kho mã có chất lượng tốt, được cập nhật và không chứa lỗi hoặc lỗ hổng đã biết. Ông cũng đề xuất thử một số công cụ AI cùng lúc để xác định lựa chọn phù hợp với nhóm.
Phân tích nền và hoạt động khắc phục có thể phát hiện lỗi cũ, lỗ hổng bảo mật và nợ kỹ thuật tích lũy trước khi chúng cản trở công việc mới. Nếu bỏ qua khâu này, tác tử phải dành nhiều thời gian hơn để tìm đường trong hệ thống phức tạp, tiêu thụ thêm tài nguyên xử lý và tạo ra thay đổi khó xác minh hơn.
Ba vòng liên kết trực tiếp với nhau. Kho mã khỏe giúp tác tử tạo thay đổi phù hợp hơn. Xác minh sớm giảm số lỗi đi đến bước tích hợp. Kiểm tra trước khi hợp nhất ngăn vấn đề lọt vào kho mã dùng chung. Hoạt động bảo trì sau phát hành cải thiện nền tảng cho lần phát triển tiếp theo.
Cách theo đuổi tốc độ do AI tạo ra
Nhóm kỹ thuật nên thống nhất tiêu chuẩn phần mềm trước khi mở rộng sử dụng AI, sau đó đưa hoạt động xác minh vào từng giai đoạn. Cách tiếp cận này chuyển trọng tâm từ số lượng mã sang chất lượng của thay đổi và mức độ tự tin khi đưa mã vào sử dụng.
Các bước đưa xác minh vào quy trình
- Xác định rõ ý định và tiêu chuẩn chung, gồm mục tiêu của thay đổi cùng yêu cầu về chất lượng, bảo mật, độ tin cậy và khả năng bảo trì.
- Ưu tiên sửa lỗi hiện có, lỗ hổng, quy ước thiếu nhất quán và vấn đề kiến trúc để tác tử có nền tảng tốt hơn. Việc chuẩn bị kho mã phải được duy trì liên tục, không phải một đợt dọn dẹp duy nhất.
- Thử nghiệm trong phạm vi kiểm soát, đồng thời đánh giá các công cụ và quy trình AI bằng cùng một bộ tiêu chuẩn độc lập.
- Kết nối xác minh tự động với quy trình của tác tử để lỗi được phát hiện và sửa trong lúc mã đang được tạo.
- Quản trị theo mức độ rủi ro, bằng cách cung cấp đúng bối cảnh, giới hạn rõ ràng và điều kiện chuyển vấn đề cho con người. Những thay đổi có hậu quả nghiêm trọng cần thêm lớp xác minh và phê duyệt.
Howlett khuyến nghị theo dõi khả năng hoàn thành các yêu cầu hợp nhất có quy mô dễ quản lý, tần suất phát hành và thời gian của một chu kỳ phát triển. Ông cảnh báo không nên dùng số dòng mã làm thước đo. Sản lượng chỉ có ý nghĩa khi chất lượng giữ nguyên hoặc được cải thiện.
Giá trị của AI trong phát triển phần mềm nằm ở mức độ tự tin của nhóm khi đưa mã vào sử dụng, không phải lượng mã tác tử có thể tạo ra. Ba vòng xác minh chuyển tốc độ tạo mã thành tốc độ có thể tin cậy, đồng thời giữ trách nhiệm của con người đối với những quyết định quan trọng.
Hãy tiếp tục theo dõi Sine để cập nhật cách các nhóm kỹ thuật đưa AI vào phát triển phần mềm mà không đánh đổi chất lượng.
