Gần đây, tôi đã có buổi trò chuyện với Joseph Ruscio về các công cụ lập trình AI cho podcast High Leverage của Heavybit: Tập #9, "Sự thay đổi bước ngoặt trong lập trình bằng AI với Simon Willison". Dưới đây là một số điểm nhấn của tôi, bao gồm cả một nhận thức khá "đáng ngại" rằng: vibe coding và kỹ nghệ tác nhân (agentic engineering) đã bắt đầu giao thoa ngay trong chính công việc của tôi.

Một điều tôi thực sự thích ở các buổi podcast là đôi khi chúng thúc đẩy tôi phải suy nghĩ thành lời, từ đó làm lộ ra những ý tưởng mà trước đây tôi chưa thể diễn đạt rõ ràng.

Vibe coding và kỹ nghệ tác nhân đang bắt đầu chồng lấp lên nhau

Vài tuần sau khi thuật ngữ "vibe coding" lần đầu xuất hiện, tôi đã xuất bản bài viết "Không phải mọi hoạt động lập trình có AI hỗ trợ đều là vibe coding (nhưng vibe coding thực sự rất đỉnh)". Trong đó, tôi đã khẳng định chắc chắn niềm tin của mình rằng "vibe coding" là một thứ rất khác biệt so với việc sử dụng AI một cách có trách nhiệm để viết mã — thứ mà kể từ đó tôi bắt đầu gọi là "kỹ nghệ tác nhân" (agentic engineering).

Tuy nhiên, khi Joseph đề cập đến sự khác biệt giữa hai khái niệm này, tôi chợt nhận ra rằng đối với bản thân mình, chúng không còn tách biệt rõ rệt như trước đây nữa:

Tôi từng nghĩ chúng ta đã có một ranh giới cực kỳ rõ ràng: vibe coding là khi bạn hoàn toàn không thèm ngó ngàng gì đến code. Bạn thậm chí có thể chẳng biết lập trình là gì. Bạn có thể là một người ngoại đạo yêu cầu một thứ gì đó, nhận lại kết quả, và nếu nó chạy được thì tuyệt vời! Còn nếu không, bạn chỉ việc bảo nó là "không chạy được đâu" và cầu may.

Trong suốt quá trình đó, bạn chẳng mảy may bận tâm đến chất lượng mã nguồn hay bất kỳ ràng buộc kỹ thuật nào khác. Quan điểm của tôi về vibe coding là: nó rất tuyệt vời, miễn là bạn hiểu rõ khi nào nên dùng và khi nào không. Nếu đó là một công cụ cá nhân cho riêng bạn, nơi mà nếu có lỗi thì chỉ mình bạn chịu thiệt, thì cứ việc!

Nhưng nếu bạn đang xây dựng phần mềm cho người khác, thì vibe coding là một sự thiếu trách nhiệm trầm trọng, bởi đó là thông tin của người dùng. Những lỗi ngớ ngẩn của bạn sẽ gây hại cho họ. Bạn cần một tiêu chuẩn cao hơn thế.

Điều này tương phản hoàn toàn với kỹ nghệ tác nhân (agentic engineering) — nơi bạn là một kỹ sư phần mềm chuyên nghiệp. Bạn hiểu về bảo mật, khả năng bảo trì, vận hành, hiệu suất và vân vân. Bạn đang sử dụng những công cụ này bằng tất cả năng lực trình độ cao nhất của mình. Tôi nhận thấy phạm vi thử thách mà mình có thể đảm nhận đã tăng lên đáng kể vì tôi có sự hỗ trợ của các công cụ này.

Dù vậy, tôi vẫn đang dựa trên 25 năm kinh nghiệm làm kỹ sư phần mềm của mình. Mục tiêu là xây dựng các hệ thống vận hành (production) chất lượng cao: nếu bạn tạo ra những thứ kém chất lượng với tốc độ nhanh hơn, tôi nghĩ đó là điều tồi tệ. Tôi muốn xây dựng những thứ chất lượng cao hơn với tốc độ nhanh hơn. Tôi muốn mọi thứ mình làm ra phải tốt hơn về mọi mặt so với trước đây.

Vấn đề nằm ở chỗ: khi các tác nhân lập trình (coding agents) ngày càng trở nên đáng tin cậy, tôi không còn xem lại (review) từng dòng code mà chúng viết nữa, kể cả đối với những dự án ở cấp độ vận hành thực tế.

Tôi thừa biết rằng nếu yêu cầu Claude Code xây dựng một endpoint JSON API thực hiện truy vấn SQL và xuất kết quả dưới dạng JSON, nó chắc chắn sẽ làm đúng. Nó sẽ không làm hỏng việc đó đâu. Bạn bảo nó viết thêm test tự động, viết thêm tài liệu, và bạn biết chắc kết quả sẽ ổn.

Nhưng tôi lại không hề review đoạn code đó. Và giờ tôi có cảm giác tội lỗi: nếu tôi chưa xem qua code, liệu có thực sự trách nhiệm khi đưa nó vào vận hành thực tế hay không?

Thứ thực sự giúp ích cho tôi là nhớ lại khoảng thời gian làm quản lý kỹ thuật tại các tổ chức lớn. Các đội nhóm khác xây dựng phần mềm mà đội của tôi phải phụ thuộc vào. Nếu một đội khác bàn giao thứ gì đó và nói: "Này, đây là dịch vụ thay đổi kích thước ảnh, đây là cách dùng nó"... tôi sẽ không đi đọc từng dòng code mà họ đã viết.

Tôi sẽ xem tài liệu của họ và dùng nó để xử lý ảnh. Sau đó, tôi bắt đầu triển khai các tính năng của riêng mình. Chỉ khi gặp vấn đề—như dịch vụ đó có vẻ có bug hoặc hiệu suất kém—thì lúc đó tôi mới đào sâu vào kho lưu trữ Git của họ để xem chuyện gì đang xảy ra. Còn lại, phần lớn thời gian tôi coi đó như một "hộp bán đen" (semi-black box) mà tôi không cần ngó tới cho đến khi cần thiết.

Tôi đang bắt đầu đối xử với các tác nhân AI theo cách tương tự. Cảm giác vẫn không mấy dễ chịu, bởi con người phải chịu trách nhiệm về những gì họ làm. Một đội ngũ có thể xây dựng nên uy tín. Tôi có thể nói: "Tôi tin tưởng đội đó. Họ đã làm ra những phần mềm tốt trong quá khứ. Họ sẽ không tạo ra thứ rác rưởi vì điều đó ảnh hưởng đến uy tín nghề nghiệp của họ."

Claude Code thì không có uy tín nghề nghiệp! Nó không thể chịu trách nhiệm cho những gì nó đã làm. Nhưng dù sao thì nó vẫn đang tự chứng minh năng lực của mình—hết lần này đến lần khác, nó tạo ra những thứ mạch lạc và thực hiện chúng một cách chính xác theo đúng phong cách mà tôi ưa thích.

Trước đây, nếu bạn tìm thấy một kho lưu trữ (repository) trên GitHub với hàng trăm lượt commit, một bản hướng dẫn (readme) chỉn chu và các bài kiểm tra tự động (automated tests), bạn có thể khá chắc chắn rằng người viết đã dành rất nhiều tâm huyết và sự chú ý vào dự án đó.

Nhưng giờ đây, tôi có thể tạo ra một kho lưu trữ với hàng trăm commit, một bản readme đẹp đẽ và các bài test bao phủ từng dòng code chỉ trong vòng nửa giờ! Nó trông giống hệt những dự án từng tốn bao công sức. Có thể nó cũng tốt tương đương, tôi không biết nữa. Tôi không thể phân biệt được chỉ bằng cách nhìn vào nó. Ngay cả với dự án của chính mình, tôi cũng không thể khẳng định.

Vì vậy, tôi nhận ra điều mình coi trọng hơn cả chất lượng của các bài test hay tài liệu là: đã có ai thực sự sử dụng nó chưa. Nếu bạn có một sản phẩm làm theo kiểu "vibe coding" nhưng bạn đã dùng nó hàng ngày trong suốt hai tuần qua, điều đó đối với tôi giá trị hơn nhiều so với một thứ bạn vừa "khạc" ra mà hầu như chưa hề chạy thử.

Nếu bạn có thể tăng năng suất từ 200 dòng code một ngày lên 2.000 dòng, điều gì khác sẽ đổ vỡ? Hóa ra, toàn bộ chu kỳ phát triển phần mềm (SDLC) vốn được thiết kế xoay quanh ý tưởng rằng phải mất một ngày để tạo ra vài trăm dòng code. Và giờ thì không còn như vậy nữa.

Nó không chỉ ảnh hưởng đến các khâu phía sau (downstream) mà cả các khâu phía trước (upstream). Tôi đã xem một bài diễn thuyết tuyệt vời của Jenny Wen, trưởng nhóm thiết kế tại Anthropic; cô ấy nói rằng chúng ta có tất cả các quy trình thiết kế dựa trên ý tưởng là bạn phải làm thiết kế thật chuẩn xác—bởi vì nếu bạn bàn giao nó cho các kỹ sư và họ mất ba tháng để xây dựng sai thứ, đó sẽ là một thảm họa.

Chúng ta thiết lập một quy trình thiết kế cực kỳ sâu sát vì kết quả của thiết kế đó dẫn đến những công đoạn thực thi đắt đỏ. Nhưng nếu việc xây dựng không còn mất tới ba tháng, có lẽ quy trình thiết kế có thể chấp nhận rủi ro cao hơn nhiều, vì chi phí nếu làm sai đã được giảm đi đáng kể.

Khi nhìn lại các cuộc hội thoại của mình với các tác nhân AI, tôi thấy rõ ràng rằng đây vẫn là "ngôn ngữ của người ngoài hành tinh" đối với đại đa số mọi người.

Có hàng tá lý do khiến tôi không sợ sự nghiệp kỹ sư phần mềm của mình sẽ kết thúc khi máy tính có thể tự viết code, một phần vì những công cụ này là bộ khuếch đại cho kinh nghiệm sẵn có. Nếu bạn biết mình đang làm gì, bạn có thể chạy nhanh hơn rất nhiều khi có chúng. [...]

Trong khi làm việc với các công cụ này, tôi liên tục được nhắc nhở rằng công việc chúng ta làm khó đến mức nào. Tạo ra phần mềm là một việc cực kỳ gian nan. Dù bạn có đưa cho tôi tất cả các công cụ AI trên thế giới này, thì những gì chúng ta đang cố gắng đạt được vẫn thực sự rất khó khăn. [...]

Matthew Yglesias, một nhà bình luận chính trị, hôm qua đã đăng tweet: "Sau năm tháng, tôi nghĩ mình đã quyết định rằng mình không muốn 'vibecode' — tôi muốn các công ty phần mềm được quản lý chuyên nghiệp sử dụng AI hỗ trợ lập trình để tạo ra nhiều sản phẩm phần mềm tốt hơn, rẻ hơn và bán chúng cho tôi." Và điều đó nghe có vẻ rất đúng với tôi. Tôi có thể tự sửa ống nước nếu xem đủ video trên YouTube, nhưng tôi thà thuê một thợ sửa ống nước chuyên nghiệp còn hơn.

Tôi chợt nhận ra nó giống như điều tôi đã nói lúc trước: tôi chỉ muốn dùng dự án cá nhân của bạn nếu bạn đã thực tế sử dụng nó được vài tuần. Phiên bản doanh nghiệp của câu chuyện đó là: tôi không muốn dùng một hệ thống quản trị khách hàng (CRM) trừ khi có ít nhất hai doanh nghiệp khổng lồ khác đã sử dụng thành công hệ thống đó trong sáu tháng. [...] Bạn luôn muốn những giải pháp đã được chứng minh là hiệu quả trước khi chấp nhận rủi ro với chúng.

Nguồn bài viết từ Tác giả Simonwillison