Diễn giả từ Netflix, Meta và IBM: AI sẽ biến bất kỳ ai thành lập trình viên 10x, nhưng cũng kèm theo 10x công việc dọn dẹp

Tại hội nghị All Things AI vừa diễn ra tại Durham, Bắc Carolina, các diễn giả đến từ những gã khổng lồ công nghệ như IBM, Meta và Netflix đã cùng thảo luận về tương lai của AI trong lập trình. Mặc dù AI ngày càng dễ tiếp cận, nhưng nó chưa thể đơn giản đến mức bạn chỉ cần hét lên: "Alexa! làm cho tôi một trang web thương mại điện tử". Và dĩ nhiên, việc thêm dòng chữ "ĐỪNG ẢO TƯỞNG" vào vòng lặp lệnh cũng chẳng giúp ích gì cả.

Điểm mấu chốt được nhiều chuyên gia nhấn mạnh là kết quả tối ưu từ AI sẽ dành cho những ai biết chuẩn bị kỹ lưỡng. Bạn càng muốn AI làm nhiều việc giúp bạn, bạn càng phải làm nhiều việc nhà chuẩn bị trước đó.

Nghịch lý Jevons và gánh năng suất

Nhiều bài phát biểu tại hội nghị đã đề cập đến Nghịch lý Jevons – hiện tượng khi một nguồn lực trở nên hiệu quả hơn, nó lại càng được sử dụng nhiều hơn. Nghịch lý này thường được dùng để giải thích tại sao AI sẽ không cướp mất việc làm của tất cả mọi người. Thực tế, lập luận cho rằng AI sẽ tạo ra nhiều việc làm mới hơn.

Tuy nhiên, hiện tại, AI chắc chắn đang tạo ra nhiều công việc hơn cho người dùng, đòi hỏi thời gian để chuẩn bị ngữ cảnh và kiểm tra kết quả đầu ra. Claude có thể biến bất kỳ ai thành một lập trình viên năng suất gấp 10 lần, nhưng họ sẽ cần phải dọn dẹp gấp 10 lần kết quả đó. Trước khi AI có thể thống trị con người như trong bộ phim The Matrix, nó vẫn sẽ cần sự giúp đỡ của chúng ta để vượt qua các rào cản.

Netflix và "kiểm tra mã đối nghịch"

Làm thế nào để AI khiến các kỹ sư tại Netflix bận rộn? Trong bài thuyết trình của mình, Ben Ilegbodu, Kiến trúc sư giao diện người dùng (UI Architect) tại Netflix, giải thích rằng ngay khi bạn tạo ra một tác nhân AI để tự động hóa một nhiệm vụ nào đó, bạn sẽ cần một tác nhân thứ hai để đánh giá công việc đó.

Ilegbodu đôi khi còn chia nhỏ công việc thành nhiều tác nhân chuyên biệt vào các phần khác nhau của quy trình xem xét mã nguồn. Ông gọi cách tiếp cận này là "kiểm tra mã đối nghịch" (adversarial code review).

Thậm chí, bạn còn cần một tác nhân thứ ba để điều phối hành động giữa hai tác nhân đầu tiên. Ilegbodu mô tả ngày làm việc của chính mình là hiện thân của Nghịch lý Jevons. Khi ông kích hoạt một tác nhân để triển khai tính năng mới, ông sẽ giao cho một tác nhân khác làm công việc chuẩn bị cho nhiệm vụ tiếp theo mà ông đang nghĩ đến. Về mặt hiệu quả, ông đang "song song hóa chính mình để công việc luôn diễn ra".

AI đã cho phép Ilegbodu lập trình bằng những ngôn ngữ ông chưa từng biết, như Python, Bash và Groovy. Tuy nhiên, sự chuyển đổi ngữ cảnh liên tục này có thể gây mệt mỏi. "Cuối ngày, tôi thực sự cảm thấy khá mệt, vì thực chất tôi đã dành cả ngày để nói chuyện với một cái gì đó", ông thừa nhận.

Meta và "người thực tập sinh không biết no"

Justin Jeffress, Nhà vận động phát triển (Developer Advocate) tại Meta, so sánh AI như một lập trình viên trẻ nhiệt huyết nhưng ngây thơ trong nhóm. Tuy nhiên, khác với nhân viên trẻ, AI sẽ không bao giờ bị "quá tải".

Bạn có thể liên tục đổ thêm thông tin cho AI, và nó sẽ tiếp nhận tất cả (miễn là bạn đủ tiền chi trả cho token). Nhưng cơn đói không đáy này dẫn đến tình trạng Jeffress gọi là "nguồn thối" (context rot).

"Theo thời gian, khi bạn tương tác với tác nhân AI, càng nhiều thứ nó phải tính toán để đưa ra câu trả lời, càng nhiều yếu tố cạnh tranh sự chú ý của nó và khả năng cao nó sẽ không làm đúng việc" ông nói.

Các chỉ dẫn mơ hồ dẫn đến kết quả phân tán. Việc suy nghĩ rõ ràng về thông tin bạn cung cấp cho tác nhân là công việc của kỹ thuật ngữ cảnh (context engineering). Với AI tác nhân, điều này đã trở thành một dạng nghệ thuật. Jeffress đề xuất sử dụng "chuỗi lệnh" (prompt chaining), hoặc liệt kê các nhiệm vụ cụ thể từng bước một. Làm nhiều việc ở đầu vào có nghĩa là bớt lo lắng trong quá trình chạy, cho phép nhà phát triển rảnh tay hơn. Nhưng thực tế là nó dành thời gian để họ tinh chỉnh quy trình thêm nữa bằng cách chạy nhiều tác nhân song song.

Jeffress lưu ý rằng AI thường có thể làm 80% một công việc nhất định, để lại 20% cuối cùng cho con người hoàn thiện. Tuy nhiên, khi ông giải quyết phần 20% đó, ông lại thấy rằng 80% trong số đó có thể do các bot thực hiện. Quy trình này tiếp diễn lặp lại như một nguyên tắc Pareto fractal của những nhiệm vụ dọn dẹp vô tận.

IBM và nghệ thuật phân rã

Thực tế là AI không làm chính xác những gì bạn muốn không phải là lỗi của AI. Đó là vấn đề ở kỹ năng "phân rã" (decomposition) của bạn, theo Luis Lastras, Giám đốc công nghệ ngôn ngữ và đa phương tiện của IBM.

Ông phê phán việc "viết câu lệnh theo kiểu ước muốn" (wishful prompting) – chỉ đơn giản là gõ "Tôi yêu cầu, đừng ảo tưởng. Sự nghiệp của tôi phụ thuộc vào nó, làm ơn, làm ơn, làm ơn". Điều này giống như bùa chú và hy vọng nó có hiệu quả.

Thay vào đó, các nhà phát triển nên suy nghĩ về cách chia nhỏ công việc thành các phần dễ quản lý hơn cho tác nhân. Loại "phân rã" này thực chất là Cơ bản Kỹ thuật 101. Đó là "nghệ thuật lấy một hệ thống rất phức tạp, xác định các phần chính, mô-đun hóa chúng, rồi thiết kế những thứ đó, và thậm chí giao cho các chuyên gia thiết kế từng mảnh".

Khi xây dựng tác nhân, đừng ném thông tin ngẫu nhiên vào LLM, mà hãy xác định các chức năng cụ thể để giúp tác nhân thực thi nhiệm vụ. IBM gần đây đã phát hành thư viện mã nguồn mở mellea.ai với các mẫu chính (key patterns) – các chức năng cung cấp cho LLM các hướng dẫn được mã hóa bằng Python cụ thể. Chúng có thể được dùng để thêm yêu cầu vào lệnh gọi LLM, phát hiện đầu ra độc hại, cấu trúc đầu ra theo lược đồ, v.v.

IBM cũng đang nghiên cứu khả năng cho phép tác nhân chuyển đổi LLM cho các nhiệm vụ chuyên biệt, hoặc "chuyển đổi não bộ". Nghiên cứu của họ cho thấy một mô hình nhỏ hơn, chuyên biệt cho một lĩnh vực cụ thể, nếu được dành nhiều thời gian suy luận, sẽ hoạt động tốt hơn các mô hình lớn hơn.

Học cách áp đặt ràng buộc

"Các giả định ngầm định là nợ kỹ thuật", Justin Chau, nhà phát triển cao cấp tại Intuit, giải thích thêm. Điều rõ ràng với chúng ta có thể không rõ ràng với máy móc. "Chúng ta phải rất, rất cụ thể về kết quả mà mình mong muốn".

Một lời khuyên từ Chau: Hãy đưa ra các ràng buộc cho tác nhân của bạn, thay vì chỉ đưa ra chỉ dẫn. Một LLM sẽ bỏ qua một chỉ dẫn nếu nó tìm thấy cách mà nó cho là tốt hơn để hoàn thành nhiệm vụ. Các ràng buộc là những câu trả lời cứng và khó bị bỏ qua hơn bởi bộ não AI. Nếu bạn bảo tác nhân rằng trong mọi trường hợp không được dùng HTML, nó sẽ tôn trọng yêu cầu đó.

Nhưng mạnh hơn cả ràng buộc là sự thiếu quyền hạn. "Nếu tôi không cho nó quyền truy cập vào GitHub, tôi biết chắc chắn nó sẽ bao giờ không đụng đến GitHub", Chau nói.

Có lẽ, với AI, chúng ta đang thấy mình bước vào thế giới của Douglas Adams. Xa rời việc làm tất cả công việc thay cho chúng ta, AI đặt chúng ta lên một con đường chuẩn bị không bao giờ kết thúc. Giống như siêu máy tính Deep Thought trong The Hitchhiker's Guide to the Galaxy, AI đưa ra câu trả lời, nhưng con người lại là người phải đau đầu tìm ra câu hỏi đúng.