Những lời khuyên phổ biến về AI hiện nay thường tập trung vào công cụ và “prompt thần kỳ”. Với tôi, điều này giống như việc đưa ra lời khuyên về kỹ thuật phần mềm mà chỉ xoay quanh việc nhớ các lệnh của vim – tuy có ích, nhưng không đi vào cốt lõi của kỹ năng thực sự.
Khác với nhiều lời khuyên thông thường, bài viết này dành cho những người đã là kỹ sư phần mềm có năng lực, chứ không phải những người thiếu nền tảng kỹ thuật đang tìm cách “viết code bằng vibe”. Đây là các kỹ thuật mà tôi sử dụng hàng ngày với vai trò là kỹ sư cấp cao tại GitHub. Tôi dùng Copilot cho phần lớn các tình huống dưới đây, nhưng các kỹ thuật này không phụ thuộc vào công cụ – bạn có thể dùng bất kỳ AI nào có giao diện trò chuyện.
Kỹ thuật “Xin ý kiến thứ hai” (Second opinion)
Một vấn đề khi tin vào đầu ra của AI trong các lĩnh vực bạn chưa quen là AI thường trả lời sai. Giống như các kỹ sư yếu, AI có thể trả lời đúng về mặt kỹ thuật nhưng phức tạp hoặc không đúng chuẩn. Tuy nhiên, nếu bạn đã có một giải pháp đang hoạt động, không mất gì nếu bạn gửi nó cho AI để xem liệu nó có thể đề xuất cách làm đơn giản hơn hoặc đúng chuẩn hơn không.
Ngay cả những kỹ sư giỏi cũng đôi khi bỏ lỡ các giải pháp tốt hơn. Nhưng họ có thể nhận ra một giải pháp tốt hơn nếu được gợi ý (dù từ người hay AI). Bạn chỉ cần sao chép diff của nhánh code và gửi vào AI chat với lời nhắn đơn giản như “code này ổn không nhỉ?”. Nếu phản hồi không hữu ích, hãy lướt qua và bỏ qua. Nhưng đôi khi bạn sẽ có khoảnh khắc “à, mình quên mất cái này” và cải thiện được chất lượng thay đổi.
Điểm quan trọng là chỉ dành vài phút cho bước này. Nếu không có khoảnh khắc Eureka ngay lập tức, hãy dừng lại. Nếu không, bạn sẽ bắt đầu thiết kế giải pháp cùng AI – điều này cũng có ích, nhưng đó là một kỹ thuật hoàn toàn khác.
Tôi không khuyên dùng các công cụ code review sẵn có cho việc này. Chúng thường để phát hiện lỗi tinh vi hoặc đề xuất thay đổi dòng code, trong khi ở đây bạn cần một kiểm tra cảm tính ở mức cao. Bạn có thể áp dụng kỹ thuật này không chỉ cho code mà còn cho bản thiết kế kiến trúc, ghi chú debug, hoặc bất kỳ sản phẩm kỹ thuật nào.
Kỹ thuật “Viết script debug dùng một lần” (Throwaway debugging scripts)
Khi làm việc với hệ thống lớn, AI hiện nay không mạnh bằng kỹ sư giỏi trong việc thay đổi code phức tạp. Nhưng AI lại vượt trội trong việc viết chương trình ngắn: nó có thể viết ra 10–30 dòng code đơn giản gần như hoạt động ngay nhanh hơn bất kỳ ai.
Cách tận dụng điều này? Bình thường, lập trình viên không cần nhiều chương trình kiểu này vì hầu hết phải chỉnh sửa hệ thống lớn hoặc viết script quan trọng trong production (nơi mà độ chính xác quan trọng hơn tốc độ). Nhưng việc viết code ngắn dễ dàng mở ra nhiều ứng dụng mới – giống như sự phát triển phần mềm mạnh mẽ nhờ máy tính giá rẻ thời 90s và 2000s.
Ứng dụng chính mới ở đây là debug. Nhiều kỹ sư không nhận ra việc này dễ đến mức nào. Ví dụ, tôi từng thiết lập một index mới cho Elasticsearch và không hiểu vì sao query phức tạp không trả về kết quả. GPT-4o lập tức tạo ra một script dài giúp tôi chạy từng phần nhỏ của query để xác định điều kiện nào loại bỏ kết quả. Về cơ bản thì tôi cũng sẽ làm như vậy, nhưng thay vì mất 10 phút gõ lệnh thủ công, tôi mất 30 giây copy-paste script.
Điều kiện tiên quyết là bạn phải hiểu sơ bộ vấn đề. Nếu bạn hoàn toàn mù mờ, bạn sẽ không biết cần script gì và không hiểu kết quả. Kỹ thuật này hiệu quả nhất khi bạn đã biết mình cần debug bước nào, AI sẽ giúp bạn tự động hóa nó.
Một số kỹ thuật khác
Dưới đây là vài kỹ thuật phụ tôi thường dùng – không quan trọng bằng hai kỹ thuật chính, nhưng cũng đáng đề cập:
- Tìm bằng chứng cho điều bạn đã biết: Kỹ sư giỏi thường cần dẫn chứng để bảo vệ quan điểm trong các cuộc thảo luận nội bộ. AI có chức năng tìm kiếm (đặc biệt là loại “deep research”) giúp bạn tìm tài liệu nhanh hơn cả Google.
- Lấp đầy kiến thức ngoài chuyên môn: Trong dự án lớn, bạn sẽ phải viết thứ gì đó không phải sở trường (ví dụ một đoạn cấu hình nginx). AI có thể đưa bạn từ “zero đến trình độ junior mạnh” ngay lập tức. Tất nhiên, bạn vẫn nên nhờ người có chuyên môn review kỹ thay đổi đó.
Tóm tắt
Bài viết này bổ sung cho bài viết trước của tôi về cách tôi dùng LLM mỗi ngày. Ở đây, tôi cố gắng hệ thống lại thành các kỹ thuật có thể tái sử dụng. Bạn cũng có thể xem thêm bài viết của tôi về lập trình với AI và khía cạnh bảo mật, hoặc các bài viết về AI nói chung.
- Xin ý kiến thứ hai từ LLM là một kỹ thuật tốt với kỹ sư có kinh nghiệm. Vì bạn đã tự giải quyết vấn đề, nên bạn có khả năng đánh giá chất lượng đầu ra của AI và đôi khi nó thực sự cải thiện giải pháp đáng kể.
- Viết script debug tạm thời là một điểm mạnh lớn của LLM. Vì code này không cần merge vào hệ thống, nên việc nó có đúng chuẩn codebase hay không không quan trọng. Nếu bạn biết mình định debug bước nào, AI có thể tiết kiệm cho bạn cả chục phút gõ lệnh thủ công.
- Ngoài ra, LLM cũng hữu ích khi bạn cần tìm dẫn chứng cho lập luận hoặc tạm thời lấp đầy kiến thức ngoài chuyên môn, nhưng tôi xem đó là các “trường hợp hữu ích” hơn là “kỹ thuật”.
Trần Ngọc Minh 