Lập trình dựa trên AI (Agentic Coding) thực chất là một cái bẫy

Lập trình dựa trên AI (Agentic Coding) thực chất là một cái bẫy

Giữ vững sự cảnh giác trước "nợ nhận thức" và sự suy giảm kỹ năng trong kỷ nguyên AI.

"AI sẽ viết code, còn con người trong vòng lặp sẽ là người điều phối."

Đây là tâm điểm đang được ngành công nghệ kỹ thuật hype lên mạnh mẽ hiện nay: lập trình truyền thống đã chết, và Phát triển dựa trên đặc tả (Spec Driven Development - SDD) mới là tương lai. Bạn tạo ra một kế hoạch, rồi rời xa việc viết bất kỳ dòng code nào. Các tác nhân AI biết hơn và sẽ xử lý toàn bộ khâu triển khai. Nhiệm vụ của bạn là trở thành chuyên gia, cung cấp "gu thẩm mỹ tốt", xem xét kết quả đầu ra, và liên tục điều hướng tác nhân để thực hiện kế hoạch mà bạn đã vạch ra.

Quy trình làm việc này hiện nay có nhiều hình thức khác nhau, nhưng nhìn chung, đó là quá trình wherein một người xác định yêu cầu dự án (cả ở vi mô và vĩ mô), tạo kế hoạch, rồi liên tục kéo cần máy đánh bạc, lặp đi lặp lại với nhiều phiên bản tác nhân cho đến khi hoàn thành. Trong suốt quá trình đó, khoảng cách giữa "người điều phối" và dòng code đang được tạo ra ngày càng lớn hơn.

Kỹ năng lập trình

Các tác nhân lập trình (Coding Agents) hữu ích và mạnh mẽ, nhưng đã có những sự đánh đổi có thể đo lường được cần được thảo luận:

• Tăng độ phức tạp của các hệ thống xung quanh để giảm thiểu tính mơ hồ không xác định của AI.
• Kỹ năng bị teo đi đối với một bộ phận lớn dân số lập trình viên.
• Bị phụ thuộc vào nhà cung cấp (Vendor lock-in) cho cá nhân và cả đội ngũ (những sự cố như mất kết nối Claude Code đã khiến cả đội ngũ phải đứng hình).
• Chi phí dao động và gia tăng để tiếp cận các công cụ. Chi phí nhân viên là cố định; nhưng token (đơn vị tính của AI) là một mục tiêu di động liên tục.

Để thành công với cách tiếp cận này, nó dựa vào một yếu tố cực kỳ quan trọng: chỉ có những nhà phát triển lành nghề, tư duy phản biện và thoải mái làm việc ở cấp độ kiến trúc mới có thể phát hiện ra vấn đề trong hàng ngàn dòng code được tạo ra trước khi chúng trở thành rắc rối.

Tuy nhiên, một cách đầy trớ trêu, chính kỹ năng tư duy phản biện và sự minh mẫn về nhận thức của cá nhân lại là những thứ mà công cụ AI đã được chứng minh là tác động tiêu cực.

Không chỉ là một "Lớp trừu tượng" (Abstraction) khác

Một luận điểm phổ biến chúng ta thường nghe từ cộng đồng là các lập trình viên chỉ đang "di chuyển lên trên cùng của stack" và vào một loại trừu tượng hóa khác. Liệu các công cụ này có thực sự là một lớp trừu tượng hay không vẫn là một vấn đề chưa được giải quyết; một mức độ mơ hồ cao hơn không phải là một mức độ trừu tượng cao hơn.

Nếu tạm gác chuyện đó sang một bên, thì đúng là các lập trình viên thường nghi ngờ những ngôn ngữ mới và cách lập trình mới. Khi FORTRAN ra mắt, các lập trình viên cũng hoài nghi về nó. Họ có những tuyên bố tương tự: nó có khả năng gây ra nhiều lỗi và bất ổn hơn, và viết assembly trực tiếp thì hiệu quả hơn. Sau đó, lại có những tranh luận xung quanh việc tích hợp các trình biên dịch (compiler) đưa quá nhiều "phép thuật" vào quy trình. Những luận điểm này mang tính quy chuẩn, xuất phát từ nỗi sợ hãi về những gì có thể bị mất đi nếu những công nghệ mới này được đón nhận.

Sự khác biệt với những gì đang diễn ra ngày nay là những nỗi sợ hãi trước đây chỉ mang tính suy đoán và lý thuyết. Chỉ trong vài năm ngắn ngủi tồn tại của các công cụ AI, chúng ta đã thấy những tác động đáng kể. Không chỉ là các lập trình viên junior, mà ngay cả những người có hơn một thập kỷ kinh nghiệm:

• Các lập trình viên Junior đối mặt với con đường dốc hơn, khi chúng ta cắt giảm khả năng làm việc trực tiếp với code và thay thế bằng việc xem xét code được tạo ra. Xem xét code (code review) là quan trọng, nhưng nó chỉ chiếm 50% quá trình học hỏi, nhiều nhất là vậy. Nếu không có ma sát và thử thách đến từ việc làm việc trực tiếp với code, khả năng học hỏi của họ bị giảm sút nghiêm trọng.

Nghiên cứu hiện tượng này mất thời gian, nên bằng chứng giai thoại là rất quan trọng để có cái nhìn thời gian thực về tình hình. Nhưng nó cũng đã được nghiên cứu, và có nhiều báo cáo khẳng định đây là một hiện tượng thực sự.

Lần này thực sự khác biệt.

Khi một nhà phát triển C++ chuyển sang Java hoặc Python, họ không phàn nàn về việc "sương mù não" (brain fog). Khi một sysadmin chuyển sang AWS, họ không cảm thấy mình đang mất khả năng hiểu về mạng.

Một Kỹ sư Cao cấp mất đi sự sắc bén trong lập trình và trở nên "gỉ sét" theo thời gian khi chuyển sang các vai trò quản lý và thực hành viết code ít hơn không phải là hiện tượng mới. Đây là sự tiến hóa tự nhiên của chuyên môn: một kỹ sư đã có hàng thập kỷ viết code, ma sát và kinh nghiệm tích lũy sẽ có thời gian và kinh nghiệm để củng cố những kỹ năng và trí tuệ đó. Và họ có thể áp dụng trí tuệ đó khi công việc của họ bớt đi về cú pháp và tập trung hơn vào các quyết định kiến trúc cấp cao hơn. Những cá nhân đó không chỉ cực kỳ hiếm, mà bạn sẽ không có được làn sóng kỹ sư cao cấp tiếp theo nếu chúng ta tất cả đều từ bỏ sự ma sát của việc viết, giải quyết vấn đề và gỡ lỗi (debug).

Vấn đề về kỹ năng

Điều đang xảy ra ngay bây giờ là một xu hướng mà các nhà phát triển, những người chưa bao giờ có sự trường tồn đó hay 30+ năm ma sát dẫn đến sự hiểu biết sâu sắc, đang được chuyển sang các quy trình cấp cao hơn đòi hỏi cùng những kỹ năng để quản lý các tác nhân AI mà kỹ sư cao cấp đã mất hàng thập kỷ để có được.

Tuy nhiên, các Kỹ sư Cao cấp cũng không miễn nhiễm. Simon Willison, một nhà phát triển với gần 30 năm kinh nghiệm, đã báo cáo rằng ông không còn "mô hình tinh thần vững chắc về những gì ứng dụng có thể làm và cách chúng hoạt động, điều này có nghĩa là mỗi tính năng bổ sung trở nên khó lý luận hơn".

Vấn đề của "Người điều phối" có kỹ năng

Chôn sâu trong một nghiên cứu gần đây của Anthropic là một khoảnh khắc trung thực đáng ngạc nhiên khi nói về rủi ro của việc tương tác thường xuyên với các tác nhân lập trình:

Một lý do khiến sự teo đi của kỹ năng lập trình đáng lo ngại là "nghịch lý giám sát"... sử dụng Claude hiệu quả đòi hỏi sự giám sát, và giám sát Claude đòi hỏi chính những kỹ năng lập trình có thể bị teo đi do lạm dụng AI quá mức.

Sandor Nyako, Giám đốc Kỹ thuật Phần mềm tại LinkedIn, người giám sát 50 kỹ sư, đã nhận thấy điều này lan rộng khắp tổ chức và đã yêu cầu đội ngũ của mình không sử dụng chúng cho "các nhiệm vụ đòi hỏi tư duy phản biện hoặc giải quyết vấn đề."

"Để phát triển kỹ năng, mọi người cần phải trải qua khó khăn. Họ cần phát triển cơ bắp để suy nghĩ qua các vấn đề," ông nói. "Làm thế nào một người có thể đặt câu hỏi liệu AI có chính xác hay không nếu họ không có tư duy phản biện?"

Cũng có câu hỏi về việc cấu thành "lạm dụng quá mức" là gì. Chúng ta đã có bằng chứng, cả dựa trên dữ liệu và giai thoại, rằng những kỹ năng này có thể teo đi và tiêu tan khá nhanh (trong vài tháng trong một số trường hợp).

Đây là mâu thuẫn khiến nhiều người ủng hộ AI nói chuyện "hai mồm": Việc sử dụng các tác nhân lập trình đang chủ động làm giảm đi chính những kỹ năng cần thiết để quản lý hiệu quả các tác nhân lập trình đó.

LLM tăng tốc những phần sai

Trái ngược với câu chuyện hiện tại đang được tung ra, chúng ta không nhất thiết cần phải viết code nhanh hơn. Đặc biệt là code mà chúng ta không hiểu đầy đủ, và đặc biệt là với số lượng lớn mà chúng ta không thể xem xét trong khung thời gian hợp lý.

Trước khi có AI, danh sách ưu tiên của một nhà phát triển (tốt) có thể trông như sau:

1. Hiểu về code và mối liên hệ của nó với codebase.
2. Code có được căn chỉnh với các tiêu chuẩn đã ghi chép và hiệu quả hay không.
3. Càng ít dòng code càng tốt để hoàn thành mục tiêu (duy trì tính dễ đọc).
4. Thời gian hoàn thành.

Lập trình tác nhân (Agentic coding), và LLM nói chung, hoàn toàn đảo ngược danh sách này.

Khả năng và cách sử dụng của chúng có xu hướng tập trung vào tốc độ bằng cách tăng lượng code có thể được tạo ra trong một khung thời gian nhất định. Tốc độ là sản phẩm phụ tự nhiên của năng lực cao. Khi nó bị ép buộc, nó luôn dẫn đến độ chính xác thấp hơn. Việc tích hợp các công cụ này không có xu hướng tập trung nhiều vào sự hiểu biết sâu sắc hoặc sự súc tích.

Chúng có thể được sử dụng theo cách đó không? Có, với sự quyết tâm, chúng chắc chắn có thể.

Nhưng chúng có đang được dùng như vậy không? Không, thực sự là không; các mệnh lệnh ép buộc và sự hype xung quanh việc sử dụng token trên các tổ chức đang chứng minh điều đó.

Lập trình === Quy hoạch (Planning)

Có một sự phân chia giữa các nhà phát triển không được làm nổi bật nhiều lắm: Một số chúng ta quy hoạch và suy nghĩ tốt hơn khi dùng code. Tư duy và làm việc với code không chỉ là sự nhàm chán vô nghĩa; nó buộc bạn phải suy nghĩ về mọi thứ ở cấp độ kỹ thuật liên quan đến mọi thứ từ bảo mật đến hiệu suất, trải nghiệm người dùng và khả năng bảo trì.

Trong một cuộc phỏng vấn gần đây thảo luận về "Phát triển dựa trên đặc tả" (Spec Driven Development), Dax, người tạo ra OpenCode (một tác nhân lập trình mã nguồn mở không kém), đã được trích dẫn nói:

"Khi làm việc trên một cái gì đó mới hoặc một cái gì đó đầy thách thức, việc tôi gõ ra code chính là quá trình mà tôi tìm ra chúng ta thậm chí nên làm gì.

Tôi thực sự gặp khó khăn khi chỉ ngồi đó, viết ra một đặc tả khổng lồ về chính xác cách tính năng nên hoạt động. Tôi thích viết ra các kiểu (types). Tôi thích viết ra cách một số hàm có thể hoạt động cùng nhau. Tôi thích chơi với cấu trúc thư mục để xem các khái niệm khác nhau nên là gì. Và đây là tất cả những thứ mà tôi nghĩ hầu hết mọi người—hầu hết các lập trình viên—đã luôn làm. Tôi thực sự không thấy lý do tốt nào để tôi dừng việc đó cá nhân, vì đó là cách tôi tìm ra việc cần làm."

Những gì bạn nói thường không phải là những gì bạn có ý nghĩa, và LLMs lấp đầy sự mơ hồ bằng các giả định (hoặc ảo giác), điều này dẫn đến: nhiều xem xét hơn, nhiều sửa đổi tác nhân hơn, nhiều token bị đốt cháy hơn, và sự ngắt kết nối nhiều hơn với những gì đang được tạo ra. Ngược lại, Bạn có thể ngạc nhiên trước lời nhắc (prompt) đẹp nhất, không mơ hồ, cấu trúc hoàn hảo mà bạn từng viết, và LLM vẫn có thể xuất ra một phương thức ảo giác vì về cơ bản nó là một động cơ dự đoán token tiếp theo, không phải là một trình biên dịch. Bạn không thể thay thế một hệ thống xác định (deterministic) bằng một hệ thống xác suất (probabilistic) và mong đợi sự không mơ hồ bằng không.

Ngay cả những nhà phát triển cao cấp nhiệt tình nhất với AI cũng bắt đầu thấy sự ngắt kết nối này là một vấn đề đang hiện hữu và ngày càng lớn.

Bị khóa bởi nhà cung cấp (Vendor Lock-In)

Khi tôi đang duyệt LinkedIn trong thời gian sự cố ngừng hoạt động của Claude xảy ra một thời gian trước, tôi nhận thấy nhiều bài đăng nhấn mạnh rằng một số nhà phát triển và đội ngũ kỹ thuật đã bị đứng hình. Quy trình làm việc của họ, khả năng lập trình của chính họ, đã đạt đến điểm mà họ phần lớn phụ thuộc vào các nhà cung cấp này. Điều từng là một kỹ năng mà họ có thể thực hiện chỉ với bàn phím và trình soạn thảo văn bản bỗng nhiên đòi hỏi một thuê bao cho nhà cung cấp mô hình AI.

Bạn không thể dự đoán chi phí token của mình.

Các nhà cung cấp mô hình được trợ giá nặng nề, và các mô hình bản thân được xây dựng trên nền cát dịch chuyển. Mỗi lần phát hành mô hình mới đều tuân theo cùng một mẫu: điểm chuẩn cao, sau đó là sự hype, sau đó là thực tế sử dụng và mọi người phàn nàn về việc chúng bị "làm yếu" (nerfed) và đốt cháy 2-3 lần token nhiều hơn để hoàn thành cùng một công việc.

Bạn biết nhân viên của mình tốn bao nhiêu; bạn không có ý niệm chi phí token sẽ là bao nhiêu ngày qua ngày, tháng qua tháng, năm qua năm. Nếu toàn bộ đội ngũ của bạn sử dụng lập trình tác nhân làm mặc định, tài khoản chi tiêu của bạn sẽ cần phải cực kỳ linh hoạt. Như Primeagen nói gần đây: "khi bạn sử dụng các quy trình tác nhân hoàn toàn này, các nhà cung cấp mô hình về cơ bản sở hữu bạn".

Không phải là vô lý khi diễn biến mô hình này, nơi chúng ta có thể tạo ra một ngành công nghiệp mà bạn cần phải trả tiền cho việc tiêu thụ token để hoàn thành một cái gì đó từng là sản phẩm của tư duy phản biện và khả năng giải quyết vấn đề của chính bạn. Điều này sẽ giống như một loại "bị khóa bởi nhà cung cấp", nhưng cho một bộ kỹ năng của toàn ngành công nghiệp (và tôi chắc chắn các nhà cung cấp mô hình đang xoa tay vui mừng trong sự mong đợi cho điều đó). Sự "kéo thảm" về tài chính và trí tuệ có thể đến bất cứ lúc nào, và các LLM cục bộ (local LLMs) hiện không sẵn sàng để mở rộng quy trình hấp thụ mức độ sử dụng đó.

Đây không phải là suy đoán lý thuyết; nó đang được báo cáo ngay bây giờ. Ngay cả các nhà cung cấp mô hình bản thân họ cũng đang làm sáng tỏ điều đó. Một nghiên cứu khác của Anthropic cho thấy sự sụt giảm 47% đáng báo động về kỹ năng gỡ lỗi (debugging):

"Tích hợp AI một cách mạnh mẽ vào nơi làm việc—đặc biệt là trong kỹ thuật phần mềm—certainly đi kèm với những đánh đổi... các nhà phát triển có thể dựa vào AI để cung cấp kết quả nhanh chóng cái giá của việc xây dựng các kỹ năng quan trọng—đáng chú ý nhất là khả năng gỡ lỗi khi mọi thứ đi sai."

Có một cách để tránh tất cả những điều này, tất nhiên. LLMs là một bước tiến công nghệ mạnh mẽ, và khi được sử dụng có trách nhiệm, chúng có thể là một công cụ tuyệt vời để học hỏi và nâng cao kỹ năng. Chúng cho phép tôi đi sâu và rộng hơn vào các khái niệm và kỹ thuật, mở rộng sự hiểu biết và cho phép khám phá các ý tưởng mới mà trước đây tốn nhiều công sức và thời gian hơn để thử nghiệm. Đây là nơi tôi nghĩ chúng sẽ mang lại giá trị dài hạn lớn nhất cho ngành.

Cách tiếp cận của tôi: Hạ thấp vai trò của AI

Tôi chắc chắn không đang cổ vũ việc gõ code thủ công. Các lập trình viên luôn tìm cách tạo ra code mà không phải viết code. Đó là lý do chúng ta thậm chí có Emmet, tự động hoàn thành và các đoạn mã (snippets). Ngay cả COBOL cũng được thiết kế để đóng gói nhiều hướng dẫn hơn với ít chữ viết hơn bằng cách sử dụng các từ "giống tiếng Anh" như MOVE và WRITE. Khẩu hiệu của jQuery là "viết ít hơn, làm nhiều hơn". LLMs là một sự bổ sung khác cho mảng các công cụ tạo code này.

Những gì tôi đang cổ vũ, tuy nhiên, là tận dụng LLMs và các tác nhân lập trình như các quy trình thứ cấp. Một cách không hy sinh kỹ năng của cá nhân trên bàn thờ năng suất. Bạn có thể lật kịch bản và dựa vào chúng để lên ý tưởng cho các phần quy hoạch trong khi vẫn chủ động tham gia trong suốt quá trình triển khai, ủy quyền cho chúng khi cần thiết. Bạn có thể tận dụng lợi ích về năng suất, và giảm thiểu nợ hiểu biết.

Quy trình làm việc hàng ngày của tôi:

• Tôi sử dụng LLMs để giúp tạo đặc tả và kế hoạch, trong khi tôi điều phối việc triển khai. Đây là sự đảo ngược của quy trình "điều phối"; tôi vẫn đang viết code thủ công bất cứ đâu từ 20% đến 100%, tùy thuộc vào nhiệm vụ.
• Tôi rất thường xuyên viết pseudo-code khi tôi tương tác với các mô hình, thu hẹp khoảng cách giữa yêu cầu và code được tạo ra.
• Tôi sử dụng các mô hình như các tiện ích ủy quyền để tạo code đặc thù và tài liệu tương tác, cũng như các công cụ nghiên cứu để tôi có thể liên tục đặt câu hỏi, lặp lại, tái cấu trúc và đạt được sự rõ ràng xung quanh các cách tiếp cận của mình.
• Tôi không bao giờ tạo ra nhiều hơn những gì tôi có thể xem xét trong một lần ngồi. Nếu quá nhiều để xem xét, tôi sẽ chậm lại và chia nhỏ nhiệm vụ, tái cấu trúc thủ công khi cần thiết để đảm bảo sự hiểu biết toàn diện về kết quả cuối cùng.
• Tôi không bao giờ yêu cầu LLM hoặc tác nhân triển khai một cái gì đó mà tôi chưa bao giờ làm trước đây hoặc không thể tự làm, ngoại trừ có lẽ chỉ cho mục đích giáo dục hoặc hướng dẫn (và thường bị loại bỏ sau đó).

Nếu tôi phải tóm tắt danh sách này, nó sẽ là: Sử dụng chúng như Máy tính của Con tàu (Ship's Computer), không phải Data. (bất kỳ người hâm mộ Star Trek nào cũng nên hiểu tham chiếu này).

Tôi không đi nhanh hơn, nhưng tôi đang làm công việc chất lượng tốt hơn.

Lợi ích về năng suất từ các mô hình này là có thật, và sự ma sát cũng như sự hiểu biết đến từ việc tham gia vào công việc một cách hữu hình và thường xuyên cũng vậy.

Mặc dù có vô số nỗ lực thất bại trong việc dân chủ hóa lập trình trong khi không hiểu lập trình, chúng ta phải đối mặt với thực tế là bạn không thể hiểu code nếu không tương tác với nó. Và đã trở nên rõ ràng rằng nếu bạn không tiếp tục tương tác và viết nó, bạn có thể mất đi sự hiểu biết đó, điều này sẽ lần lượt khiến bạn trở thành một người điều phối kém năng lực hơn ngay từ đầu, khiến giai đoạn lập trình AI này trở thành một giai đoạn ngắt quãng kỳ lạ và gây căng thẳng không cần thiết.

Có lẽ tôi đang lo lắng quá nhiều, nhưng lịch sử chứa đựng những bài học.

Tất cả những điều này cảm thấy tương tự, giống như một thí nghiệm lớn khác mà chúng ta đang thực hiện trên chính mình. Chúng ta đã trải qua một giai đoạn tương tự với sự ra đời của mạng xã hội mà không hiểu các tác động dài hạn, và bây giờ chúng ta phải đối mặt với sự thiếu tập trung (cùng với nhiều vấn đề khác) trên quy mô lớn.

Lần này, chúng ta đang đánh cược với một thứ gì đó rủi ro hơn nhiều.

"Những người đặt tất cả vào các tác nhân AI ngay bây giờ đang đảm bảo sự lỗi thời của chính họ. Nếu bạn thuê ngoài tất cả tư duy của mình cho máy tính, bạn ngừng nâng cao kỹ năng, học hỏi và trở nên năng lực hơn." – Jeremy Howard, người tạo ra fast.ai