Blackbox AI: dùng trợ lý viết mã không sinh nợ kỹ thuật

Blackbox AI là cái tên hay xuất hiện khi một lập trình viên đi tìm trợ lý viết mã cho công việc hàng ngày. Bài này không mô tả tính năng hay gói dịch vụ của bất kỳ sản phẩm nào, vì nhóm công cụ này đổi rất nhanh và bạn nên xem trực tiếp ở trang chính thức của nhà cung cấp. Thứ đáng bàn hơn và cũng ổn định hơn là chuyện này: một trợ lý viết mã làm năng suất của bạn tăng lên hay làm khối nợ kỹ thuật phình ra, phụ thuộc gần như hoàn toàn vào người ngồi dùng nó.

Blackbox AI và nhóm công cụ mà nó thuộc về

Trợ lý viết mã giỏi ở những việc nào

Điểm mạnh của nhóm công cụ này khá dễ thấy sau vài tuần dùng thật. Nó viết rất nhanh những đoạn mã khuôn mẫu mà ai cũng phải gõ lại hàng chục lần trong đời: khung một lớp, phần đọc cấu hình, vòng lặp duyệt danh sách, đoạn bắt lỗi quanh một lời gọi ra bên ngoài. Nó cũng khá tin cậy khi chuyển một đoạn từ cú pháp này sang cú pháp khác, khi dựng khung cho những ca kiểm thử đầu tiên, và khi diễn giải hộ một hàm dài do người khác viết từ lâu. Gợi ý tên biến của nó thường hợp lý, bởi đặt tên vốn là bài toán ngôn ngữ nhiều hơn là bài toán logic.

Và dở ở những việc nào

Ranh giới lộ ra khi bài toán đòi hỏi thứ nằm ngoài đoạn văn bản bạn đưa vào. Thiết kế kiến trúc là ví dụ rõ nhất: chia thành phần thế nào, đặt ranh giới ở đâu, chọn mô hình dữ liệu ra sao đều phụ thuộc vào hướng đi của sản phẩm, năng lực của đội và chi phí vận hành về sau, những thứ không ai viết trong mã. Ràng buộc nghiệp vụ cũng vậy. Một quy tắc tính toán đặc thù của ngành, nếu không có trong ngữ cảnh, sẽ được điền vào bằng giả định nghe rất chuẩn mực mà sai hoàn toàn.

Hai vùng còn lại đáng cảnh giác hơn cả. Với lỗi có nguyên nhân sâu, thứ nằm ở tương tranh hoặc ở một giả định sai từ tầng dưới, Blackbox AI cũng như các công cụ cùng loại thường đề xuất bản vá làm triệu chứng biến mất trong khi nguyên nhân còn nguyên. Với bảo mật thì nặng hơn: mã sinh ra hay theo lối viết phổ biến nhất trong dữ liệu huấn luyện, mà phổ biến nhất chưa bao giờ đồng nghĩa với an toàn nhất. Đây là chỗ nợ kỹ thuật hình thành nhanh nhất mà không ai kịp nhận ra.

Loại công việc	Nên giao đến mức nào
Đoạn lặp lại, có khuôn sẵn	Giao thoải mái, vẫn đọc lại
Chuyển đổi giữa hai cú pháp	Giao được, kiểm thử phần biên
Diễn giải đoạn mã lạ	Coi là giả thuyết, không phải tài liệu
Thiết kế kiến trúc	Chỉ để gợi mở, quyết định là của bạn
Xác thực, phân quyền, mã hóa	Rà từng dòng, không dùng nguyên trạng

Vì sao mã do máy sinh ra trông đúng mà vẫn có thể sai

Nó tối ưu cho vẻ hợp lý chứ không cho việc chạy đúng

Muốn dùng nhóm công cụ này một cách tỉnh táo thì phải hiểu nó tối ưu cho cái gì. Bên dưới ô gợi ý là một mô hình dự đoán phần văn bản tiếp theo sao cho giống nhất với khối mã nguồn khổng lồ mà nó từng học. Mục tiêu đó là trông hợp lý, không phải chạy đúng. Hai thứ này trùng nhau trong phần lớn trường hợp, đủ để tạo cảm giác tin cậy, rồi lệch nhau đúng vào tình huống hiếm gặp, mà tình huống hiếm gặp lại chính là nơi sự cố sinh ra.

Vì thế mã do Blackbox AI hay bất kỳ trợ lý nào cùng loại đưa ra thường sai theo kiểu khó chịu: đúng cấu trúc, đúng phong cách đặt tên, đúng thứ tự các bước, nhưng nhầm một điều kiện biên, bỏ qua trạng thái rỗng, hoặc dùng một phương thức có thật mà không làm đúng việc bạn tưởng. Lỗi cú pháp thì trình biên dịch bắt ngay. Loại lỗi này thì không; nó đi thẳng vào nhánh hiếm và nằm im cho tới ngày dữ liệu thật chạm vào.

Đọc lướt là mắt xích yếu nhất

Phần đáng lo không nằm ở công cụ mà nằm ở phản xạ của người ngồi trước màn hình. Khi một đoạn mã hiện ra đã thụt lề gọn gàng, tên biến nghe chuyên nghiệp, bố cục giống hệt thứ bạn vẫn viết, đầu óc chuyển từ chế độ thẩm định sang chế độ xác nhận. Bạn không còn đọc để tìm lỗi nữa mà đọc để thấy rằng nó ổn. Cảm giác này mạnh hơn hẳn lúc tự gõ, bởi khi tự gõ thì từng dòng đều đi qua phần suy nghĩ có ý thức.

Cái giá nghề nghiệp mà người mới dễ phải trả

Phần học nằm trong lúc vật lộn

Đây là phần nên nói thẳng, và nói không phải để trách ai. Kỹ năng lập trình phần lớn không hình thành lúc bạn đọc lời giải, mà hình thành trong quãng khó chịu trước đó: lúc đọc thông báo lỗi lần thứ ba, lúc chèn một dòng in ra để xem biến đang mang giá trị gì, lúc nhận ra giả định ban đầu của mình sai ở chỗ nào. Chính quãng đó xây nên trực giác gỡ lỗi và khả năng đọc hiểu hệ thống.

Khi người mới dùng trợ lý để đi vòng qua đúng quãng đó, bài tập vẫn xong và phần việc vẫn được nộp, nhưng phần học đã bị bỏ lại. Hệ quả không hiện ra ngay mà đến sau vài tháng, vào cái ngày gặp một lỗi mà không công cụ nào gợi ý nổi vì nó nằm trong ngữ cảnh riêng của hệ thống. Lúc ấy khoảng cách giữa người từng vật lộn và người chưa từng vật lộn lộ ra rất rõ.

Ranh giới giữa đi nhanh và đi vòng

Vậy khi nào dùng Blackbox AI hay các trợ lý cùng nhóm là hợp lý? Cách phân biệt đơn giản mà tôi thấy dùng được: nếu bạn đã biết cách làm và chỉ muốn khỏi gõ lại, đó là đi nhanh; nếu bạn chưa hiểu bài toán và mong công cụ hiểu hộ, đó là đi vòng. Người đã có nghề dùng trợ lý như một cái máy đánh chữ thông minh, vì họ có sẵn tiêu chuẩn để chấm bài nó. Người chưa có nghề thì thiếu đúng tiêu chuẩn ấy.

Kỷ luật tối thiểu khi đưa Blackbox AI vào dự án thật

Không đưa vào dự án dòng mã mình chưa hiểu

Quy tắc đầu tiên đơn giản đến mức nghe như thừa, nhưng bị vi phạm nhiều nhất: không dán vào dự án bất kỳ dòng nào bạn không giải thích được cho người khác nghe. Không phải hiểu mang máng rằng đoạn này để làm việc kia, mà hiểu từng dòng đang làm gì và bỏ nó đi thì hỏng chỗ nào. Nếu đọc xong vẫn còn một dòng chưa nắm, hãy hỏi lại cho tới khi nắm, hoặc tự viết lại theo cách mình hiểu.

Kiểm thử là điều kiện, không phải tùy chọn

Quy tắc thứ hai: mọi đoạn được sinh ra đều phải có ca kiểm thử đi kèm, và tốt nhất là bạn tự nghĩ ra các ca đó trước khi nhìn vào mã. Lý do rất thực tế. Nếu để công cụ vừa viết mã vừa viết kiểm thử, nó có xu hướng viết kiểm thử khớp với những gì mã đang làm, kể cả khi mã đang làm sai. Hình thức rà soát mã hiệu quả nhất vẫn là chạy thử với dữ liệu cố tình xấu.

Giữ nó ra xa phần xác thực và phân quyền

Quy tắc thứ ba liên quan tới vùng mà một sai sót nhỏ có hậu quả lớn. Phần xác thực và phân quyền, phần lưu trữ mật khẩu, phần kiểm tra quyền trước mỗi thao tác nhạy cảm đều không nên nhận mã sinh tự động rồi dùng nguyên trạng. Nó có thể bỏ sót một lần kiểm tra quyền ở nhánh phụ, dùng cách so sánh chuỗi không an toàn, hoặc để lộ thông tin qua thông báo lỗi. Nếu buộc phải dùng, hãy coi đoạn mã đó như bản nháp của người lạ và rà lại cùng một đồng nghiệp.

Cảnh giác với thư viện được gợi ý

Quy tắc cuối ít người biết cho tới khi vấp phải. Các trợ lý đôi khi đề xuất một gói nghe rất hợp lý, tên đúng quy ước của hệ sinh thái, mô tả trôi chảy, mà thực tế là thư viện không tồn tại, hoặc có tồn tại nhưng đã lâu không ai bảo trì. Trường hợp đầu chỉ làm bạn mất thời gian; trường hợp sau nguy hiểm hơn, vì một gói bị bỏ hoang là nơi lỗ hổng nằm lại mà không ai vá. Hãy tự xác minh trước khi thêm bất cứ phụ thuộc nào.

Bảo mật dữ liệu và câu chuyện giấy phép

Những gì không nên dán vào công cụ bên ngoài

Có một ranh giới mà nhiều đội chỉ vẽ ra sau khi đã lỡ vượt qua. Đừng dán mã nguồn nội bộ, khóa bí mật, chuỗi kết nối cơ sở dữ liệu, thông tin đăng nhập hay dữ liệu khách hàng vào bất kỳ dịch vụ bên ngoài nào, kể cả khi chỉ định nhờ giải thích một hàm. Dữ liệu rời khỏi máy bạn là dữ liệu bạn không còn kiểm soát, còn nghĩa vụ bảo mật với khách hàng thì không chuyển giao theo. Trước khi dùng Blackbox AI trong môi trường có dữ liệu thật, hãy hỏi người phụ trách an toàn thông tin của đơn vị.

Vấn đề giấy phép của mã được sinh ra

Phần này chưa có câu trả lời gọn và tôi cũng không định đưa ra kết luận pháp lý. Vấn đề nằm ở chỗ mô hình học từ lượng mã nguồn công khai rất lớn, trong đó có những phần mang giấy phép mã nguồn ràng buộc, và đôi khi đầu ra giống đáng kể một đoạn đã có sẵn ở đâu đó. Ai sở hữu đoạn mã sinh ra, nó có kế thừa ràng buộc của nguồn gốc hay không, đó là những câu hỏi giới luật và giới kỹ thuật vẫn đang tranh luận. Với dự án thương mại, cách thận trọng là nêu vấn đề trong nội quy của đội và hỏi bộ phận pháp chế trước.

Kết luận

Nhìn lại thì Blackbox AI và cả nhóm trợ lý viết mã không tự nó làm bạn giỏi lên hay kém đi. Nó khuếch đại thói quen sẵn có: người quen đọc kỹ và viết kiểm thử sẽ đi nhanh hơn mà chất lượng không giảm; người quen dán trước sửa sau sẽ tích nợ nhanh hơn và tích một cách êm ái, vì mã trông rất tử tế cho tới ngày nó vỡ. Ranh giới giữa hai lối dùng không nằm trong công cụ mà nằm trong kỷ luật của người dùng cùng khiphach.vn.

Nếu chỉ giữ lại vài điều, tôi chọn ba: đọc hiểu từng dòng trước khi đưa vào dự án, tự nghĩ ca kiểm thử trước khi nhìn mã, và không bao giờ đưa dữ liệu nhạy cảm ra ngoài. Ba thói quen đó còn giá trị bất kể công cụ nào đang thịnh hành. Còn những gì thuộc về một sản phẩm cụ thể, từ điều khoản sử dụng tới cách dữ liệu của bạn được xử lý, hãy xác nhận tại nguồn chính thức vào đúng lúc bạn cần đến nó.