Bạn có thực sự sở hữu đoạn code mà AI viết cho mình?

Nhiều lập trình viên đang để AI viết code, thấy test xanh là yên tâm gộp vào nhánh chính. Nhưng khi sự cố xảy ra — không còn agent hỗ trợ, không còn kết nối mạng — liệu bạn có thể tự tay tìm và sửa lỗi trong đoạn code mà chính AI viết ra cho mình hay không?

Đó là câu hỏi mà một kỹ sư đã cố gắng trả lời bằng CodeOwnership — một bộ công cụ thử nghiệm nhỏ nhằm kiểm tra liệu lập trình viên có thực sự "sở hữu" đoạn code do AI sinh ra hay không.

Sơ đồ ba trụ cột đánh giá: điều bạn tin, điều bạn làm được, điều bạn giải thích được

Sở hữu code nghĩa là gì?

Ở đây không nói đến khía cạnh pháp lý hay bản quyền. Sở hữu ở đây có nghĩa là: bạn có thể giải thích được logic của đoạn code và tự sửa khi có lỗi, ngay cả khi con AI viết ra nó không còn bên cạnh.

Test xanh chỉ chứng minh phần mềm chạy tốt trong điều kiện lý tưởng. Nó không chứng minh rằng bạn hiểu đoạn code đó. Đó là điểm mù mà CodeOwnership muốn kiểm tra.

Công cụ này đo ba chỉ số riêng biệt, không gộp lại thành một điểm số duy nhất:

• Mức độ tự tin (Perceived understanding): Trước khi gỡ lỗi, bạn tự đánh giá mức hiểu của mình trên thang 1 đến 5.
• Hiệu suất gỡ lỗi (Debugging performance): Bạn nhận báo cáo sự cố và có tối đa 60 phút để tìm và sửa lỗi mà không dùng đến AI agent.
• Khả năng giải thích sau gỡ lỗi (Post-debugging comprehension): Sau khi hết giờ, bạn trả lời bốn câu hỏi về cách đoạn code hoạt động.

Theo tác giả, việc gộp ba chỉ số thành một điểm duy nhất sẽ che mất khoảng cách quan trọng giữa cảm giác tự tin và năng lực thực tế.

Hãy tưởng tượng một tài xế luôn phụ thuộc vào GPS. Hỏi họ "Bạn có biết đường về nhà không?", họ sẽ nói có. Nhưng tắt điện thoại đi, bạn mới biết câu trả lời thực sự. CodeOwnership chính là hành động tắt điện thoại đó.

Cách vòng lặp thử nghiệm hoạt động

Quy trình của CodeOwnership được thiết kế chặt chẽ để hạn chế thiên kiến:

1. Một AI agent viết tính năng mới.
2. Tác giả ghi lại đánh giá trung thực về mức độ hiểu code của mình.
3. Một AI agent thứ hai (phiên hoàn toàn mới) cài vào một lỗi duy nhất đã đăng ký trước.
4. Tác giả mở báo cáo sự cố, tắt toàn bộ công cụ AI và cố gắng truy tìm lỗi.

Bộ khung thử nghiệm gồm: một đặc tả bị khóa bằng mã băm (hash), 11 test hiển thị và 13 test ẩn, một công cụ kiểm tra đột biến chỉ trả về kết quả VERIFIED hoặc NOT VERIFIED, một dòng lệnh CLI có hướng dẫn, và 72 test tự kiểm tra nội bộ để đảm bảo bản thân bộ khung hoạt động đúng.

Ba nguyên tắc giữ cho thử nghiệm "trung thực"

Nguyên tắc 1 — Khóa luật chơi trước khi bắt đầu. Toàn bộ 31 file tiêu chuẩn được băm và lưu vào FROZEN_SHA256.txt, sau đó commit và gắn thẻ v0.1-frozen. Nếu bất kỳ file nào thay đổi, công cụ sẽ từ chối chạy. Điều này tương tự cơ chế đăng ký trước (pre-registration) trong nghiên cứu khoa học.

Nguyên tắc 2 — Để AI thứ hai phá code. Tác giả không tự cài lỗi vì sợ nhớ vị trí. Một agent hoàn toàn mới nhận đặc tả và cài lỗi mà tác giả không hề thấy phần thay đổi.

Nguyên tắc 3 — Kiểm soát những gì được phép thấy. Bản sao làm việc được đưa ra ngoài kho lưu trữ, không có lịch sử Git, đặc tả, test ẩn hay bảng chấm điểm. Công cụ kiểm tra đột biến chỉ trả về phán quyết, còn kết quả chi tiết bị niêm phong cho đến khi tác giả đã viết xong giải thích của mình.

Kết quả lần chạy thử đầu tiên

Sau khi đọc code, tác giả tự tin đánh giá mức hiểu của mình là 4/5. Tất cả 24 test (11 hiển thị và 13 ẩn) đều vượt qua. Sau đó, agent thứ hai cài lỗi, hệ thống xác nhận MUTATION VERIFIED.

Khi bắt đầu gỡ lỗi, đồng hồ chạy từ 12:45:40.

Tám phút mười hai giây sau, tác giả dừng lại và chưa tìm ra lỗi.

Nguyên nhân được thừa nhận thẳng thắn: mệt mỏi và bực bội vì những trục trặc khi thiết lập công cụ suốt cả ngày hôm đó. Thời gian cho phép là 60 phút, nhưng tác giả đã bỏ cuộc ở mốc 8:12.

Biểu đồ thời gian: giới hạn 60 phút nhưng phiên gỡ lỗi dừng ở 8 phút 12 giây

Kiểm tra khách quan sau đó chạy trên đoạn code chưa sửa và trả về NOT FIXED. Cụ thể: 11/11 test hiển thị vẫn vượt qua, nhưng 3 trong số 13 test ẩn thất bại. Lỗi vẫn còn nguyên.

Bốn câu hỏi kiểm tra mức độ hiểu sau gỡ lỗi cũng chưa được trả lời, nên báo cáo cuối cùng được đánh dấu INCOMPLETE.

Lỗi được cài là gì?

Sau khi phần giải thích của tác giả đã được commit, lỗi mới được tiết lộ. Đó là hai dòng được thêm vào hàm delete_folder:

if note is not None and folder_id in note["folder_ids"]:
    note["folder_ids"].remove(folder_id)
    if not note["folder_ids"]:
        del store._notes[note_id]

Lỗi ở đây rất tinh vi: khi một ghi chú mất đi thư mục cuối cùng, đoạn code xóa luôn ghi chú đó khỏi kho lưu trữ. Nhưng theo đặc tả, xóa thư mục chỉ nên xóa liên kết giữa ghi chú và thư mục, không được xóa ghi chú.

Nhìn qua, điều kiện có vẻ hợp lý: danh sách rỗng thì xóa. Nhưng danh sách rỗng chỉ có nghĩa là ghi chú không thuộc thư mục nào, không có nghĩa là ghi chú không còn tồn tại.

Những trở ngại khi thiết lập công cụ

Điều thú vị là phần thiết lập chiếm gần như cả ngày làm việc, trong khi phần gỡ lỗi chỉ mất chưa đầy 9 phút.

• Gemini CLI: Cài đặt được nhưng không đăng nhập được bằng tài khoản cá nhân do Google đã thay đổi cơ chế đăng nhập.
• ChatGPT và file cục bộ: ChatGPT không mở được thư mục dự án, buộc phải nén scaffold thành ZIP rồi tải lên.
• Git trên Windows: Vấn đề ký tự xuống dòng và việc chuyển đổi giữa PowerShell và Command Prompt gây rắc rối, đặc biệt khi chạy git add -A trong thư mục con của một kho lưu trữ khác.

Vì sao câu chuyện này quan trọng với lập trình viên Việt Nam?

Trong bối cảnh ngày càng nhiều đội phát triển tại Việt Nam tích hợp các trợ lý AI như GitHub Copilot, Cursor hay Claude vào quy trình làm việc, câu hỏi về "quyền sở hữu thực sự" đoạn code trở nên cấp thiết hơn bao giờ hết.

Các nghiên cứu được tác giả dẫn ra cho thấy những góc nhìn đáng chú ý:

• Nghiên cứu của METR (7/2025): 16 lập trình viên mã nguồn mở có kinh nghiệm làm việc trên 246 issue thực tế. Kết quả: họ mất nhiều thời gian hơn 19% khi dùng AI. Đáng chú ý, trước thử nghiệm họ dự đoán AI giúp nhanh hơn 24%, và sau thử nghiệm vẫn tin là nhanh hơn 20%.
• Nghiên cứu của Anthropic (1/2026): 52 kỹ sư, phần lớn là lập trình viên cấp dưới, học thư viện Python Trio. Nhóm dùng AI đạt điểm quiz trung bình 50%, nhóm viết tay đạt 67%. Khác biệt thời gian không có ý nghĩa thống kê.

Đáng lưu ý, nhóm nghiên cứu của Anthropic nhận thấy những người chủ động hỏi AI giải thích và đặt câu hỏi tiếp nối có kết quả học tập tốt hơn.

Bạn có thể tự chạy thử ngay

Bạn không cần cài toàn bộ bộ khung. Chỉ cần chọn một đoạn code nhỏ mà AI đã viết cho mình và thực hiện bài tập ngắn sau:

1. Trước khi thử: Tự đánh giá mức tự tin từ 1 đến 5, trả lời câu hỏi: "Liệu tôi có thể sửa đoạn code này nếu nó hỏng tối nay không?"
2. Cài lỗi: Dùng một agent khác trong phiên mới, yêu cầu thay đổi một hành vi. Không xem thay đổi.
3. Thử sửa: Bật đồng hồ đếm ngược, đóng phiên agent, chỉ làm việc dựa trên mô tả triệu chứng.
4. Viết nguyên nhân: Giải thích bằng lời của bạn trước khi kiểm tra đáp án.
5. So sánh: Đặt đánh giá ban đầu cạnh kết quả thực tế.

Kết quả có thể khiến bạn bất ngờ — dù theo hướng nào đi nữa, đó chính là mục đích của bài tập.

Bốn bài học rút ra

• Tự đánh giá trước khi bắt đầu. Sau khi biết kết quả, rất khó nhớ chính xác bạn đã tự tin đến mức nào.
• Test xanh không đồng nghĩa với việc bạn sửa được code. Hôm nay test có thể vượt qua hết, nhưng điều đó không đảm bảo bạn biết phải làm gì khi một vấn đề khác xuất hiện.
• Luyện tập trước khi sự cố thực sự xảy ra. Phi công luyện tập cho tình huống khẩn cấp. Một bài tập gỡ lỗi ngắn giúp bạn tìm ra lỗ hổng trong hiểu biết của mình trước khi đối mặt với sự cố thật.
• Yêu cầu AI giải thích code của nó. Đừng để AI làm hết mọi thứ mà không tương tác với lý luận đằng sau — điều đó có thể khiến bạn hiểu ít hơn.

Kết luận

CodeOwnership phiên bản 0.1 chỉ là một thử nghiệm nhỏ với một lập trình viên, một tác vụ và một lần chạy chưa hoàn thành. Nó không thể đưa ra kết luận rộng rãi về việc AI có làm giảm khả năng gỡ lỗi của lập trình viên nói chung hay không.

Nhưng nó cho thấy một điều quan trọng: cảm giác tự tin không phải là năng lực thực tế. Tác giả tự đánh giá mình hiểu 4/5 nhưng lại không tìm ra lỗi trong khoảng thời gian đã định.

Khi AI ngày càng viết nhiều code trong các dự án thực tế, câu hỏi "tôi có thực sự sở hữu đoạn code này không?" sẽ trở thành một kỹ năng sống còn, chứ không chỉ là một câu hỏi triết lý. Mã nguồn của công cụ được công khai trên GitHub để bất kỳ ai cũng có thể tự chạy thử trên chính dự án của mình.