GitHub Podcast: Giải mã các tranh cãi AI về RAG, MCP và vai trò của lập trình viên

Chúng tôi đi sâu vào những câu hỏi này và các quan điểm gây tranh cãi (hot take) khác về AI trong tập mới nhất của GitHub Podcast.

18 tháng 9, 2026

6 phút

Các "hot take" biến những chủ đề phức tạp thành một câu khẳng định đầy tự tin. Điều đó khiến chúng rất thu hút sự tương tác, nhưng không nhất thiết giúp người nghe hiểu rõ vấn đề.

Ở bề nổi, chúng không quá quan trọng. Bạn đồng ý, phản đối, chia sẻ lại, tranh luận vài phút rồi thôi. Đôi khi quan điểm đó đúng hướng. Đôi khi nó hoàn toàn vô nghĩa.

Giá trị của các "hot take" nằm ở những gì xảy ra khi bạn ngừng phản ứng và bắt đầu phân tích chúng. Trong điều kiện nào thì điều này đúng? Bối cảnh nào đang bị thiếu? Nó dựa trên những giả định gì? Điều gì thay đổi khi bạn áp dụng nó vào công việc thực tế?

Đó mới là nơi chứa đựng chiều sâu. Một "hot take" hay sẽ cung cấp cho bạn thứ gì đó đủ sắc bén để đặt câu hỏi. Những câu hỏi chính là nơi bạn tìm thấy các ý tưởng hữu ích.

Chúng tôi khám phá tất cả những điều này và hơn thế nữa trong tập mới nhất của GitHub Podcast!

Bạn chưa sẵn sàng để bắt đầu? Dưới đây là một vài "hot take" phổ biến về AI mà chúng tôi đã thảo luận và những gì chúng ta có thể rút ra từ đó.

Hot take #1: “Bạn không cần phải đọc code do AI tạo ra”

Có, bạn cần phải đọc. Bạn vẫn là người chịu trách nhiệm về đoạn code đó.

Nhưng điều đó không có nghĩa là mọi dòng code được tạo ra đều cần mức độ chú ý như nhau.

Việc tái cấu trúc (refactor) xác thực trong môi trường production xứng đáng có quy trình đánh giá khác với một thử nghiệm CSS. Một codebase mà bạn đã duy trì suốt 10 năm sẽ điều hướng bản năng của bạn khác với một codebase bạn vừa mở ra sáng nay. Giả vờ rằng mọi thay đổi đều mang rủi ro như nhau không phải là sự nghiêm túc. Đó chỉ là cách sử dụng thời gian tồi tệ.

Một quy tắc đơn giản: hãy đánh giá cho đến khi bạn có thể giải thích và làm chủ được kết quả.

Đôi khi công việc đó bắt đầu trước cả khi agent viết bất cứ thứ gì. Bạn đọc cách triển khai hiện tại, lập bản đồ các phụ thuộc, xác định các trường hợp biên (edge cases) và lập kế hoạch. Đến khi bản triển khai đầu tiên xuất hiện, bạn đã hiểu nó nên làm gì và nó có thể sai ở đâu.

Những lúc khác, chính đoạn code được tạo ra mới cần phần lớn sự chú ý của bạn. Bạn kiểm tra việc xử lý lỗi, quyền truy cập, truy cập dữ liệu, hiệu suất, khả năng truy cập và các bài kiểm thử (tests).

AI chỉ chuyển dịch nỗ lực sang chỗ khác. Nó không làm cho công việc biến mất.

Kỹ năng thực sự là biết rủi ro nằm ở đâu.

Hot take #2: “Các công ty sẽ không thuê bạn nếu bạn không sử dụng AI”

Thực tế thì sắc thái hơn một chút. Ngày càng nhiều đội ngũ hỏi ứng viên về cách họ sử dụng AI. Điều đó hợp lý. Những công cụ này đang trở thành một phần của quá trình phát triển phần mềm.

Nhưng không ai nghĩ rằng mọi lập trình viên đều cần cùng một quy trình làm việc, cùng một công cụ hay cùng một mức độ nhiệt tình như nhau.

Tín hiệu quan trọng hơn chính là khả năng phán đoán.

Bạn có thể giải thích khi nào bạn dùng AI và khi nào bạn làm thủ công không? Bạn có thể mô tả cách bạn đánh giá code do AI tạo ra không? Bạn có thể nói chuyện một cách trung thực về tốc độ, chất lượng, bảo mật và khả năng bảo trì không? Bạn có thể thay đổi quy trình của mình khi các công cụ thay đổi không?

Nếu một công ty đang xây dựng các sản phẩm AI hoặc sử dụng AI nhiều trong quy trình kỹ thuật của họ, việc từ chối đụng đến AI có thể khiến bạn trở thành người không phù hợp. Điều đó không có gì gây tranh cãi cả. Nhưng sự phụ thuộc hoàn toàn hay từ chối hoàn toàn hiếm khi là câu trả lời tốt.

Câu trả lời tốt hơn là một lời giải thích rõ ràng về cách bạn làm việc, những gì bạn tin tưởng giao cho công cụ thực hiện và những khâu nào bạn vẫn giữ quyền kiểm soát.

Sự thành thạo đó đang dần trở thành một phần của nghề nghiệp.

Hot take #3: “Skills đã giết chết MCP”

Không. Chúng giải quyết các vấn đề khác nhau.

Model Context Protocol (MCP) cung cấp cho các agent một cách tiêu chuẩn để kết nối với các công cụ và dữ liệu. Tiêu chuẩn đó rất quan trọng khi bạn muốn các hệ thống hoạt động cùng nhau một cách đáng tin cậy. Các agent cần những cách có cấu trúc để gọi công cụ, lấy ngữ cảnh và thực hiện hành động.

Skills (kỹ năng) gần giống với các gói chuyên môn được đóng gói sẵn. Một skill có thể giải thích cách một nhóm làm việc, cách một dự án nên được thay đổi, cách một công cụ nên được sử dụng hoặc những quy ước nào là quan trọng. Vì các skill thường được viết bằng Markdown, con người cũng có thể đọc được chúng. Khả năng đọc hiểu đó là một phần giá trị của chúng.

MCP có thể cung cấp quyền truy cập. Skills có thể giải thích cách sử dụng quyền truy cập đó một cách hiệu quả.

Bạn không cần phải chọn ra người chiến thắng. Hãy sử dụng các tiêu chuẩn cho các giao diện dùng chung. Sử dụng các skill cho ngữ cảnh, quy trình và các phương pháp tốt nhất (best practices).

Sự kết hợp giữa chúng thú vị hơn nhiều so với việc tranh cãi.

Hot take #4: “RAG đã chết”

RAG không chết. Nó chỉ không còn là thứ mới mẻ nhất mà mọi người muốn đăng bài về nó nữa.

Retrieval-augmented generation (RAG) cung cấp cho hệ thống AI thông tin liên quan nằm ngoài dữ liệu huấn luyện của mô hình. Điều đó có thể bao gồm tài liệu, lịch sử hỗ trợ, chi tiết sản phẩm, kiến thức nội bộ hoặc ngữ cảnh của codebase.

Nếu không có khả năng truy xuất (retrieval) tốt, mô hình phải dựa vào những gì nó đã biết hoặc mất thêm thời gian để tìm kiếm ngữ cảnh. Điều đó gây lãng phí token, làm chậm công việc và khiến các câu trả lời không đầy đủ dễ xảy ra hơn.

Khả năng truy xuất tốt giúp mô hình bắt đầu gần hơn với câu trả lời. Nó thu hẹp không gian tìm kiếm và củng cố phản hồi bằng thông tin thực sự quan trọng.

Agents, skills, MCP và RAG đều có thể cùng tồn tại trong một quy trình làm việc. Một agent có thể sử dụng MCP để truy cập công cụ, tuân theo một skill để có các hướng dẫn cụ thể cho dự án và sử dụng truy xuất để tìm ngữ cảnh hỗ trợ phù hợp.