AI giúp tạo mã nhanh hơn, nhưng phần việc tiết kiệm được chuyển sang khâu xác minh. Khi sản lượng mã tăng nhanh hơn năng lực rà soát, các kỹ sư giàu kinh nghiệm phải dành nhiều thời gian hơn để truy ngược ý định, kiểm tra giả định và ngăn mã không phù hợp đi vào vận hành.
Doanh nghiệp có thể giảm áp lực này bằng ba thay đổi. Họ cần biến phản hồi lặp lại thành quy tắc tự động và giữ lại chuỗi lập luận tạo ra mã. Hệ thống đo lường cũng cần ghi nhận công việc xác minh. Nếu quy trình vẫn chỉ khen thưởng sản lượng, những người bảo vệ chất lượng sẽ tiếp tục gánh phần việc khó thấy nhất.
The New Stack đặt tên trực tiếp cho vấn đề này: “Code review is burning out your best engineers”.
Bài viết của The New Stack mô tả một tình huống lặp lại ở nhiều đội phát triển. Những người quan tâm nhất đến chất lượng mã đang chìm trong hàng đợi rà soát. Họ không thể xử lý kịp và cũng không còn hứng thú xử lý. Đây không phải số liệu riêng về thị trường Việt Nam. Tuy vậy, tình huống có thể quen thuộc với các đội trong nước đang tăng tốc ứng dụng tác tử AI viết mã mà chưa thay đổi quy trình kiểm soát chất lượng.
Một nghiên cứu của Annie Vella được The New Stack dẫn lại cho biết 77% kỹ sư dành ít thời gian viết mã hơn trước. Phần thời gian đó chuyển sang kiểm tra đầu ra do AI tạo ra. Công việc không mất đi. Nó đổi từ tạo tác phẩm sang xác minh kết quả.
Công việc chuyển từ viết mã sang xác minh
AI làm tăng số lượng thay đổi mã mà một đội có thể tạo và hợp nhất, nhưng không làm tăng tương ứng năng lực đọc, hiểu và xác nhận mã. Kết quả là thời gian được tiết kiệm ở khâu viết mã xuất hiện trở lại dưới dạng hàng đợi rà soát và công việc xác minh.
Theo phân tích của Faros AI được The New Stack trích dẫn, các đội áp dụng AI ở mức cao hợp nhất nhiều hơn 98% yêu cầu thay đổi mã. Thời gian rà soát tăng 91%.
Những kỹ sư chịu áp lực lớn nhất không phải nhóm chống lại AI. Họ thường là người dùng AI sớm, đặt tiêu chuẩn cao cho chất lượng và từng xây dựng văn hóa rà soát của đội. Một người có thể phải xử lý 15 yêu cầu thay đổi mã mỗi ngày, mỗi yêu cầu dài 400 dòng.
Điều này làm thay đổi cách nhìn về năng suất. Một đội có thể tạo và hợp nhất nhiều mã hơn. Tuy nhiên, số dòng mã không phản ánh thời gian mà kỹ sư cấp cao dành để truy ngược ý định, phát hiện giả định sai hoặc sửa cấu trúc không phù hợp. Nghiên cứu khác về đầu ra mã do AI hỗ trợ cũng cho thấy sản lượng chỉ là một phần của bài toán chất lượng.
Vì sao mã do AI tạo khó rà soát hơn
Mã do AI tạo thường thiếu phần giải thích về mục đích, các phương án đã loại bỏ và những giới hạn đã được cân nhắc. Người rà soát phải tái dựng bối cảnh đó từ phần mã khác biệt. Việc này vẫn cần thiết ngay cả khi cú pháp, tên biến và luồng chính đều có vẻ hợp lý.
Khi một đồng nghiệp viết mã, người đó có thể giải thích mục đích và trả lời câu hỏi về quyết định triển khai. Khi AI viết mã, chuỗi lập luận thường không đi cùng phần thay đổi. Người rà soát phải suy ngược ý định từ chính đoạn mã.
Trông hợp lý nhưng vẫn sai
Mã có thể xử lý được trường hợp thông thường nhưng dựa trên giả định lệch với yêu cầu thật. Lỗi nằm ở các trường hợp biên, nên người đọc phải đối chiếu hành vi với mục đích ban đầu thay vì chỉ kiểm tra đoạn mã có chạy hay không.
Phức tạp hơn mức cần thiết
The New Stack nêu ví dụ một bài toán chỉ cần 15 dòng có thể được mô hình biến thành lớp trừu tượng dài 200 dòng. Mô hình đã học từ nhiều kiến trúc cấp doanh nghiệp. Vì vậy, nó có thể đưa vào khả năng mở rộng mà không ai yêu cầu. Người rà soát phải chứng minh phần phức tạp ấy là cần thiết hoặc dành thời gian loại bỏ nó.
Không hiểu quy ước của kho mã
Mô hình có thể tạo mã tốt theo nghĩa chung nhưng không phù hợp với hệ thống cụ thể. Mỗi kho mã có quy ước riêng về đặt tên, ghi nhật ký, xử lý lỗi và ranh giới giữa các mô đun. AI thường bỏ qua các quy ước không được biểu đạt thành chỉ dẫn hoặc quy tắc có thể kiểm tra.
Bịa ra chi tiết với giọng chắc chắn
Mã có thể gọi giao diện không tồn tại, dùng phương thức đã lỗi thời hoặc tạo tùy chọn cấu hình không có thật. Một số lỗi bị phát hiện ngay khi chạy. Số khác chỉ xuất hiện sau khi mã đã đi vào môi trường vận hành.
Sao chép khuôn mẫu mà không hiểu lý do
AI có thể thêm cơ chế thử lại ở nơi không nên thử lại, đặt bộ ngắt mạch cho lời gọi luôn đồng bộ hoặc viết phần xử lý lỗi không tương ứng với chế độ hỏng thực tế. Cấu trúc có vẻ chuyên nghiệp nhưng không giải quyết rủi ro của hệ thống đang được xây dựng.
Điểm chung của năm dạng lỗi là vẻ ngoài thuyết phục. Khi sản lượng tăng nhanh, người rà soát không thể chỉ đọc lướt để tìm lỗi hiển nhiên. Tranh luận về việc AI đang làm thay đổi hoạt động rà soát mã vì thế còn liên quan đến cách đội kỹ thuật phân bổ trách nhiệm.
Không thể giải quyết bằng cách rà soát nhiều hơn
Yêu cầu kỹ sư rà soát nhiều hơn không khắc phục được chênh lệch giữa tốc độ tạo mã và tốc độ xác minh. Dùng thêm một mô hình ngôn ngữ để kiểm tra cũng chưa đủ, vì mô hình viết mã và mô hình rà soát có thể chia sẻ cùng điểm mù.
Nếu tiếp tục bổ sung tác tử đối kháng và nhiều tầng lọc, quy trình có nguy cơ biến kỹ sư thành người trông coi hệ thống tự động. Thời gian từng dành để xây sản phẩm sẽ chuyển sang cấu hình bộ lọc, điều chỉnh chỉ dẫn và kiểm tra xem các tác tử có thực sự kiểm tra lẫn nhau hay không.
Giải pháp được bài gốc đề xuất là chuyển bớt gánh nặng khỏi người rà soát ở ba điểm. Đội kỹ thuật cần biến phản hồi lặp lại thành quy tắc và giữ lại chuỗi lập luận tạo ra mã. Hệ thống đo lường cũng cần ghi nhận công việc xác minh.
Biến phản hồi lặp lại thành quy tắc
Đội kỹ thuật có thể giảm khối lượng rà soát thủ công bằng cách phân loại các nhận xét gần đây thành ba nhóm: lỗi xác định được bằng quy tắc, lỗi kiểm tra được khi chạy mã và vấn đề thực sự cần phán đoán của con người.
Nhóm tác giả đề xuất lấy 100 nhận xét gần nhất trong các yêu cầu thay đổi mã để thực hiện việc phân loại. Theo kết quả mà The New Stack dẫn từ các đội đã áp dụng bài tập này, khoảng 45% có thể kiểm tra bằng quy tắc. Khoảng 30% có thể kiểm tra khi thực thi và 25% cần phán đoán.
Như vậy, ba phần tư phản hồi rà soát có thể được mã hóa thay vì lặp lại bằng nhận xét thủ công. Ví dụ, yêu cầu mọi điểm cuối mới phải có nhịp theo dõi OTel có thể được kiểm tra trên cây cú pháp trừu tượng. Nếu cùng một nhận xét xuất hiện nhiều lần, đội kỹ thuật nên cân nhắc biến nó thành quy tắc tự động.
Giữ lại chuỗi lập luận tạo ra mã
Chỉ dẫn và phiên làm việc với tác tử chứa mục đích của phần mã được tạo ra. Lưu lại dữ liệu này giúp người rà soát đánh giá thay đổi theo tiêu chí chấp nhận, phạm vi và quyết định kiến trúc thay vì tự dựng lại toàn bộ bối cảnh từ đoạn mã khác biệt.
Xóa hoặc bỏ quên chuỗi lập luận giống như xóa thông điệp ghi nhận thay đổi và phần mô tả yêu cầu, sau đó buộc người rà soát đoán lý do đằng sau từng quyết định.
Aviator xây dựng Verify để ghi nhận ý định từ chỉ dẫn và phiên làm việc với tác tử. Công cụ sau đó sắp xếp dữ liệu thành tiêu chí chấp nhận. Nội dung cần nêu rõ thay đổi làm gì, phần nào nằm ngoài phạm vi và dấu hiệu nào chứng minh kết quả hoạt động đúng. Các quyết định về kiến trúc, phạm vi và đánh đổi hành vi nhờ đó trở thành dữ liệu có thể rà soát.
Kỹ sư cấp cao khi ấy có thể tập trung vào câu hỏi có giá trị hơn: đội đang giải đúng vấn đề với đúng giới hạn hay chưa. Họ không phải bắt đầu bằng việc đọc một đoạn thay đổi 400 dòng vào cuối ngày rồi đoán mục đích của người hoặc tác tử đã tạo ra nó.
Chia sẻ kiến thức phải diễn ra sớm hơn
Rà soát mã chỉ truyền đạt kiến thức hiệu quả khi kỹ sư có thể đọc quyết định, tranh luận về đánh đổi và hiểu những giới hạn đã định hình phương án. Quét qua cú pháp sau khi một lượng lớn mã đã được tạo ra không thay thế được việc chia sẻ bối cảnh từ đầu.
Nếu hoạt động rà soát được chuyển về trước thời điểm viết mã, việc chia sẻ kiến thức cũng phải diễn ra sớm hơn. Đặc tả và tiêu chí chấp nhận cần đủ rõ để người rà soát hiểu hệ thống đang thay đổi theo hướng nào trước khi mã được sinh ra.
Đo lường và ghi nhận công việc xác minh
Hệ thống đo lường cần ghi nhận thời gian xây quy tắc, thiết kế rào chắn và phát hiện lỗi trước khi vận hành. Bảng điều khiển chỉ theo dõi tỷ lệ dùng AI, số dòng mã, thông lượng và thời gian hoàn thành sẽ bỏ qua phần lớn công sức của người bảo vệ chất lượng.
Theo nghiên cứu về kỹ thuật phần mềm AI của Faros AI được The New Stack dẫn lại, số yêu cầu thay đổi mã được hợp nhất mà không qua bất kỳ lượt rà soát nào tăng 31%. Con số này cho thấy bước rà soát đang bị bỏ qua thường xuyên hơn, nhưng nghiên cứu không xác định nguyên nhân. Dữ liệu cũng không cho biết đây là phản ứng có chủ ý trước hàng đợi hay hệ quả của yếu tố nào khác.
Theo theo dõi của Annie Vella với 158 kỹ sư tại 28 quốc gia, một số người đang nghỉ việc với hy vọng tìm lại vai trò cũ. Số khác rời hẳn nghề kỹ thuật phần mềm. Đây là quan sát quốc tế, không phải khảo sát riêng tại Việt Nam. Tuy vậy, nó chỉ ra rủi ro khi công việc chuyển quá mạnh sang xác minh mà doanh nghiệp vẫn chỉ khen thưởng sản lượng.
Những người mang gánh nặng rà soát không phải lúc nào cũng tiếp tục phàn nàn. Một số chuyển sang đội có công cụ tốt hơn. Số khác rời nghề vì công việc không còn giống vai trò họ đã chọn. Bảng điều khiển vẫn có thể cho thấy thông lượng cao cho đến khi những người giữ chuẩn chất lượng lần lượt rời đi.
Nội dung quy trình cần thay đổi trước khi kỹ sư kiệt sức
Mã do AI tạo có thể trông hợp lý nhưng vẫn đòi hỏi nhiều công sức xác minh vì người rà soát phải kiểm tra giả định và tái dựng bối cảnh. Doanh nghiệp cần tự động hóa nhận xét lặp lại, giữ lại ý định từ phiên làm việc với tác tử và đo lường công sức ngăn lỗi thay vì chỉ đếm đầu ra.
Đội kỹ thuật có thể bắt đầu bằng cách xem lại các nhận xét rà soát gần nhất và chọn một quy tắc lặp lại để tự động hóa.
