Ứng dụng LLMgiáo trình tự học
Chương 156 phút đọcMở rộng

15Lập trình với công cụ AI#

Chặng cuối của roadmap là các công cụ phát triển phần mềm dùng LLM. Kỹ sư AI vừa dùng chúng để làm việc, vừa cần hiểu chúng, vì đây là một trong những loại ứng dụng agent thành công nhất hiện nay. Chương này ngắn, nhưng nó cho thấy gần như mọi khái niệm của giáo trình trong một sản phẩm cụ thể: ngữ cảnh, tool, vòng lặp agent, kiểm tra và thử lại, và cả câu hỏi đo hiệu quả.

15.1Các loại công cụ#

Các công cụ lập trình dựa trên LLM khác nhau chủ yếu ở mức độ tự chủ. Ở mức thấp nhất là gợi ý mã trong trình soạn thảo, hoàn thành dòng hoặc khối mã đang gõ. Cao hơn một bậc là trợ lý trong IDE như Cursor, cho phép trò chuyện về mã và sửa nhiều tệp theo yêu cầu. Agent lập trình như Claude Code, Codex hay Gemini CLI chạy trong terminal hoặc IDE, tự đọc mã, sửa tệp, chạy lệnh và chạy kiểm thử theo đúng vòng lặp của Chương 9. Xa hơn nữa là agent tự chủ trên môi trường riêng như Devin, nhận một nhiệm vụ, làm việc trong môi trường đám mây riêng và trả về một thay đổi hoàn chỉnh; và các nền tảng như Replit sinh và triển khai cả ứng dụng từ một mô tả bằng lời.

Agent lập trình là minh hoạ rõ nhất cho các nguyên tắc của Chương 9. Nhiệm vụ lập trình có kết quả kiểm tra được, vì mã phải biên dịch được và kiểm thử phải chạy qua, nên agent tự phát hiện và sửa lỗi của chính nó, đúng cơ chế kiểm tra và thử lại ở Mục 9.7. Với tỉ lệ phát hiện lỗi cc cao nhờ kiểm thử tự động, phép tính ở Mục 9.7 cho thấy một chuỗi dài các bước vẫn có thể hoàn thành với xác suất cao.

15.2Bằng chứng về hiệu quả#

Bằng chứng về hiệu quả của các công cụ này phụ thuộc mạnh vào bối cảnh. Trong một thí nghiệm có đối chứng ngẫu nhiên, Peng và cộng sự (2023) cho thấy lập trình viên dùng GitHub Copilot hoàn thành nhiệm vụ viết một máy chủ HTTP bằng JavaScript nhanh hơn 55,8% so với nhóm đối chứng. Ngược lại, một thí nghiệm có đối chứng ngẫu nhiên của METR (Becker và cộng sự, 2025) với các lập trình viên mã nguồn mở giàu kinh nghiệm, làm việc trên chính kho mã quen thuộc của họ, cho thấy khi được phép dùng các công cụ AI đầu năm 2025 họ mất thời gian nhiều hơn 19%, dù chính họ ước tính rằng mình nhanh hơn khoảng 20%.

Hai kết quả không mâu thuẫn nhau. Công cụ AI giúp nhiều với nhiệm vụ mới, độc lập, dùng công nghệ phổ biến; nó giúp ít hoặc thậm chí làm chậm với nhiệm vụ trong một kho mã lớn có nhiều quy ước ngầm mà người làm đã thuộc lòng. Kết quả thứ hai còn cho thấy cảm nhận chủ quan về năng suất không đáng tin: người tham gia cảm thấy mình nhanh hơn trong khi thực tế chậm hơn. Kết quả này khớp với tinh thần của Chương 12: một thay đổi chỉ được coi là tốt hơn khi đo được, không phải khi cảm thấy.

15.3Cách dùng an toàn#

Cách dùng hiệu quả bắt đầu từ ngữ cảnh. Quy ước của dự án, cách chạy kiểm thử và cấu trúc thư mục thường được viết thành một tệp hướng dẫn mà công cụ tự đọc ở mỗi phiên làm việc; đó chính là quản lý ngữ cảnh ở Chương 5, áp dụng cho lập trình. Việc giao cho công cụ nên nhỏ và kiểm tra được: một thay đổi có kiểm thử đi kèm dễ xem xét hơn nhiều so với một thay đổi lớn. Mọi thay đổi cần được đọc lại trước khi chấp nhận, như khi xem xét mã của đồng nghiệp, vì mã chạy được chưa chắc đúng, an toàn hay dễ bảo trì.

Có hai rủi ro an toàn cần biết. Mô hình đôi khi gợi ý tên gói thư viện không tồn tại, và kẻ xấu có thể đăng ký một gói trùng tên đó để phát tán mã độc (Spracklen và cộng sự, 2025); vì vậy cần kiểm tra gói trước khi cài. Rủi ro thứ hai là bí mật lọt vào ngữ cảnh: khoá API, mật khẩu hay dữ liệu khách hàng không nên nằm trong những gì công cụ đọc, và quyền của agent lập trình trên máy và trên kho mã cần được giới hạn theo nguyên tắc quyền tối thiểu (Mục 9.7).

15.4Tóm tắt#

Công cụ lập trình dựa trên LLM trải từ gợi ý mã tới agent tự chủ, và agent lập trình thành công vì nhiệm vụ của nó có kết quả kiểm tra được. Bằng chứng về hiệu quả phụ thuộc vào bối cảnh: nhanh hơn 55,8% với một nhiệm vụ mới và độc lập, nhưng chậm hơn 19% với lập trình viên giàu kinh nghiệm trên kho mã quen thuộc, dù họ cảm thấy mình nhanh hơn. Dùng hiệu quả nghĩa là cung cấp ngữ cảnh tốt, giao việc nhỏ và đọc lại mọi thay đổi; dùng an toàn nghĩa là kiểm tra gói được gợi ý và không đưa bí mật vào ngữ cảnh.

Nhìn lại toàn bộ giáo trình, ta đã đi một vòng quanh sơ đồ ở Hình 1: mô hình ở giữa, rồi lần lượt prompt, ngữ cảnh, truy xuất, tool, an toàn, đánh giá và quan sát bao quanh nó. Ở mỗi thành phần, các thí nghiệm đều dẫn tới cùng một kết luận: những gì nghe hợp lý, như embedding thắng từ khoá, RAG luôn giúp, hay lời dặn trong prompt chống được tấn công, đều phải được đo trên dữ liệu của chính ứng dụng. Chương 16 gồm các bài tập để tự làm những phép đo đó, Chương 17 gom các câu hỏi phỏng vấn thường gặp. Hai giáo trình tiếp theo của lộ trình đi sâu vào hai phần mà giáo trình này chỉ chạm tới: Quantization làm cho mô hình rẻ hơn khi chạy, và MLOps vận hành cả hệ thống trong thời gian dài.


Tự kiểm tra

2 câu. Chọn đáp án để xem ngay lời giải thích.

  1. 1Thí nghiệm có đối chứng của METR (2025) với lập trình viên mã nguồn mở giàu kinh nghiệm cho kết quả gì?

  2. 2Vì sao cần kiểm tra các gói thư viện do trợ lý lập trình gợi ý?

Đã trả lời 0/2