Đây là bài "kỷ luật", phần ít người viết nhưng tôi nghĩ quan trọng nhất khi dùng AI lâu dài cho một dự án. Vấn đề thực tế rất quen thuộc: nhờ AI sửa một lỗi, AI vô tình gây ra một lỗi khác ở chỗ không ai ngờ tới. Nếu bạn không biết code, càng không biết đâu mà lần, chỉ thấy ứng dụng "tự nhiên hỏng" sau một lần sửa tưởng chừng vô hại.
Phân loại rủi ro trước khi để AI sửa
Trước khi để AI đụng vào code, tôi tự phân loại thay đổi sắp làm theo 3 mức:
- 🟢 An toàn: sửa giao diện, đổi chữ, không đụng tới logic hay dữ liệu.
- 🟡 Cẩn thận: đụng tới logic tính toán, luồng xử lý dữ liệu.
- 🔴 Nguy hiểm: đụng tới dữ liệu người dùng, thanh toán, bảo mật (đúng những phần đã nói ở bài 6).
Mức rủi ro càng cao, càng cần verify (kiểm tra lại) kỹ trước khi chấp nhận bản sửa, đúng tinh thần "mức tự kiểm tra phải tăng theo độ phức tạp" đã nói ở bài 6. Một thay đổi màu chữ thì chạy thử nhìn qua là đủ; một thay đổi liên quan tới tính tiền thì phải kiểm tra kỹ hơn nhiều.
Sửa từng phần nhỏ, verify ngay, không viết lại toàn bộ
Nối lại nguyên tắc "chia nhỏ việc" ở bài 2: luôn bắt đầu từ file gốc đang chạy tốt, sửa từng phần nhỏ, verify ngay trước khi sang phần tiếp theo. Không để AI viết lại toàn bộ một file hay một tính năng trong một lần, vì khi đó lỗi mới sinh ra ở đâu gần như không thể biết được, phải dò lại từ đầu.
Một thói quen nhỏ nhưng hữu ích: trước khi chấp nhận một bản sửa, nên xem kỹ diff (phần chênh lệch giữa bản cũ và bản mới) xem chính xác dòng nào đã đổi, thay vì chỉ chạy thử thấy có vẻ ổn là đồng ý ngay. Nhiều khi AI sửa đúng chỗ mình yêu cầu, nhưng tiện tay đổi thêm một dòng khác mà mình không để ý.
Quy tắc vàng: fix sinh bug mới thì revert ngay
💡 Quy tắc vàng: Nếu một bản sửa lỗi (fix) vô tình sinh ra một lỗi mới, revert (quay lại đúng bản trước khi sửa) ngay lập tức, không vá chồng thêm một lớp sửa nữa lên trên trong khi chưa chắc lỗi cũ đã hết. Vá chồng nhiều lớp như vậy là con đường ngắn nhất dẫn tới nợ kỹ thuật, tới lúc không ai còn nhớ lớp nào sửa gì, lỗi nào chồng lên lỗi nào.
Versioning kỷ luật: lưới an toàn khi debug
Tôi luôn giữ một biến đánh số phiên bản trong code (gọi là APP_VERSION) cùng một file version.json đi kèm, và đảm bảo hai thứ này luôn khớp nhau mỗi lần có thay đổi. Khi có lỗi xảy ra, việc đầu tiên cần biết chắc là mình đang thực sự chạy đúng bản nào, tránh trường hợp ngồi debug trên một bản cũ trong khi tưởng mình đã sửa xong ở bản mới. Nghe đơn giản, nhưng đây chính là lưới an toàn giúp tiết kiệm rất nhiều thời gian mỗi lần có sự cố.
Chạy được trên máy mình không có nghĩa là đúng ở mọi nơi, mọi lúc
Một bản sửa cần được test vượt ra ngoài phạm vi máy và điều kiện bạn đang dùng để sửa: khác môi trường (thiết bị, hệ điều hành, kết nối mạng), khác thời điểm (dùng lâu dài, hay tới một mốc thời gian cụ thể), và đặc biệt là các luồng quan trọng nhất của ứng dụng như đăng nhập, thanh toán.
Vài ví dụ thực tế tôi từng gặp, chia làm hai nhánh:
Khác môi trường, khác luồng. Một lần sửa lỗi vô tình khiến màn hình trắng trống trên iOS 12 (phiên bản hệ điều hành cũ), dù chạy hoàn toàn bình thường trên máy tôi dùng để test. Một lần khác, một ứng dụng đăng nhập bằng Google (dùng Firebase, dịch vụ backend của Google) sau một lần sửa bị treo, load mãi không vào được, đúng vào luồng quan trọng nhất của app là đăng nhập, mà lúc test qua loa lại không lộ ra ngay.
Khác thời điểm, khác hoàn cảnh. App học từ vựng của tôi có cơ chế ôn tập đếm số bài kiểm tra đã làm, dùng một thời gian dài mới phát hiện số liệu hiển thị sai mà không ai để ý, vì lỗi chỉ lộ ra sau nhiều lần lặp lại, không phải ngay lần đầu dùng. Một ứng dụng khác tôi mô tả với AI là "vẫn hoạt động khi mất mạng", nhưng chưa từng thử thật, tới khi thực sự mất mạng mới phát hiện tính năng đó sai, phải đi sửa lại hàng loạt ứng dụng cùng lỗi tương tự. Và một tính năng liên quan tới giấy tờ hết hạn, thiết kế xong nhưng chưa test, tới đúng ngày hết hạn thực sự xảy ra mới lộ lỗi giao diện: tràn dòng, thiếu thông tin cần thiết.
Bài học chung cho cả 4 ví dụ: những tình huống "hiếm khi kiểm tra nhưng chắc chắn sẽ xảy ra", như dùng lâu dài, mất mạng, tới hạn, thiết bị cũ, cần được chủ động test giả lập ngay từ lúc code xong, không đợi nó tự xảy ra ngoài đời thật rồi mới biết.
Chốt lại
Kỷ luật khi sửa code không phải để làm chậm mọi thứ cho vui, mà là cách duy nhất giữ được một dự án chạy tốt lâu dài khi bạn liên tục nhờ AI sửa và thêm tính năng. Phân loại rủi ro trước khi sửa, sửa từng phần nhỏ, revert ngay khi cần thay vì vá chồng, giữ versioning kỷ luật, và test rộng ra ngoài điều kiện quen thuộc, đó là những gì tôi thấy hiệu quả nhất sau nhiều lần tự mình vấp phải.
3 mức độ rủi ro khi thay đổi: mức càng cao, càng cần verify kỹ
Bài tiếp theo tôi sẽ nói về một chủ đề ít người để ý khi dùng AI: vấn đề bản quyền với nội dung và hình ảnh AI tạo ra.