Khi ranh giới giữa "Vibe coding" và "Agentic engineering" dần bị xóa nhòa

Gần đây, tôi đã có cuộc trò chuyện với Joseph Ruscio trên podcast High Leverage của Heavybit về chủ đề các công cụ lập trình AI. Trong quá trình đó, tôi đã nhận ra một sự thật khá đáng báo động: hai khái niệm mà tôi từng cho là tách biệt hoàn toàn — "Vibe coding" (lập trình theo cảm hứng) và "Agentic engineering" (kỹ thuật tác nhân) — đang bắt đầu giao thoa trong công việc của chính mình.

Một điều thú vị khi tham gia podcast là nó đôi khi thúc đẩy tô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.

Sự khác biệt ban đầu

Khi thuật ngữ "vibe coding" mới xuất hiện, tôi đã viết bài khẳng định rằng đây là một khái niệm rất khác so với việc sử dụng AI có trách nhiệm để viết code — thứ mà tôi gọi là "agentic engineering".

Ban đầu, tôi vạch ra ranh giới rất rõ ràng:

• Vibe coding: Là khi bạn không hề nhìn vào mã nguồn. Bạn có thể không biết lập trình, chỉ cần yêu cầu một thứ gì đó và nhận lại kết quả. Nếu nó hoạt động, thì tuyệt vời; nếu không, bạn bảo nó sửa và hy vọng. Bạn không quan tâm đến chất lượng code hay các ràng buộc kỹ thuật. Đây là công cụ tuyệt vời cho mục đích cá nhân, nhưng cực kỳ vô trách nhiệm nếu dùng để xây dựng phần mềm cho người khác.
• Agentic engineering: Là khi 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 và hiệu suất. Bạn sử dụng các công cụ AI để tối đa hóa khả năng của mình, nhưng vẫn dựa trên kinh nghiệm và tiêu chuẩn kỹ thuật để xây dựng hệ thống sản xuất chất lượng cao.

Mục tiêu của tôi là xây dựng hệ thống chất lượng cao hơn với tốc độ nhanh hơn, chứ không phải tạo ra những thứ chất lượng thấp nhanh hơn.

Khi ranh giới bắt đầu bị xóa nhòa

Tuy nhiên, khi Joseph nhắc đến sự phân biệt này, tôi bỗng nhận ra rằng chúng không còn tách biệt rõ rệt như trước nữa đối với tôi. Điều này thực sự khá khó chịu.

Vấn đề nằm ở chỗ: khi các tác nhân AI (coding agents) trở nên đáng tin cậy hơn, tôi không còn xem xét từng dòng code chúng viết nữa, ngay cả đối với các công việc cấp độ sản xuất.

Tôi biết rất rõ rằng nếu tôi yêu cầu Claude Code xây dựng một điểm cuối API JSON để chạy truy vấn SQL và xuất kết quả, nó sẽ làm đúng ngay lập tức. Nó sẽ không mắc lỗi sai ngớ ngẩn. Nếu tôi yêu cầu thêm kiểm thử tự động và tài liệu, tôi biết nó sẽ làm tốt.

Nhưng tôi không còn xem xét đoạn code đó nữa. Và rồi cảm giác tội lỗi ập đến: nếu tôi không xem xét code, liệu có thực sự trách nhiệm khi đưa nó vào môi trường sản xuất (production) không?

Niềm tin vào "Black Box" và rủi ro tiềm ẩn

Để tự trấn an bản thân, tôi nghĩ lại về thời gian làm quản lý kỹ thuật tại các tổ chức lớn. Khi các đội nhóm khác xây dựng phần mềm mà đội của tôi phụ thuộc vào, tôi không bao giờ đọc từng dòng code của họ. Tôi chỉ xem tài liệu, sử dụng dịch vụ của họ và bắt đầu triển khai tính năng của riêng mình. Chỉ khi gặp lỗi hoặc hiệu năng kém, tôi mới mới đào sâu vào kho lưu trữ Git của họ.

Tôi bắt đầu đối xử với các tác nhân AI theo cách tương tự. Tuy nhiên, điều này vẫn tạo cảm giác khó chịu vì con người phải chịu trách nhiệm về những gì họ làm. Một đội nhóm có thể xây dựng danh tiếng uy tín. Tôi có thể nói: "Tôi tin tưởng đội nhóm kia vì họ từng làm tốt trong quá khứ".

Claude Code không có danh tiếng chuyên nghiệp! Nó không thể chịu trách nhiệm về những gì nó đã làm. Nhưng nó vẫn chứng minh năng lực lặp đi lặp lại, tạo ra những thứ đơn giản và chính xác theo phong cách tôi thích.

Ở đây có yếu tố của "sự bình thường hóa của sự lệch lạc" (normalization of deviance). Mỗi lần mô hình viết đúng code mà không cần tôi giám sát chặt chẽ, rủi ro là tôi sẽ tin tưởng nó vào sai thời điểm trong tương lai và phải trả giá.

Tác động đến vòng đời phát triển phần mềm

Trước đây, nếu bạn thấy một kho GitHub với hàng trăm lần commit, readme tốt và kiểm thử tự động, bạn có thể chắc chắn rằng người viết đã dành nhiều tâm huyết. Bây giờ, tôi có thể tạo ra một kho như vậy trong nửa giờ đồng hồ! Nó trông giống hệt những dự án được chăm chút kỹ lưỡng. Có thể nó tốt bằng họ, tôi không biết. Ngay cả với dự án của chính tôi, tôi cũng không thể phân biệt được.

Tôi nhận ra những gì tôi trân trọng hơn cả chất lượng kiểm thử hay tài liệu là việc ai đó đã thực sự sử dụng nó. Một sản phẩm được "vibe code" nhưng bạn dùng hàng ngày trong hai tuần qua có giá trị hơn nhiều so với thứ vừa được tạo ra và chưa bao giờ chạy thử.

Nếu năng suất tăng từ 200 dòng code mỗi ngày lên 2.000 dòng, điều gì sẽ bị gãy? Toàn bộ vòng đời phát triển phần mềm (SDLC) được thiết kế quanh ý tưởng rằng mất cả ngày để viết vài trăm dòng code. Giờ thì không còn như vậy nữa.

Không chỉ là khâu hậu kỳ (downstream), mà cả khâu thiết kế (upstream) cũng thay đổi. Nếu việc xây dựng tính năng sai không còn tốn ba tháng nữa, thì quy trình thiết kế có thể rủi ro hơn vì chi phí sửa sai đã giảm đi rất nhiều.

Kết luận: AI là bộ khuếch đại kinh nghiệm

Khi nhìn vào các cuộc hội thoại với các tác nhân AI, rõ ràng đây là ngôn ngữ của mặt trăng với đại đa số mọi người. Tôi không sợ nghề kỹ sư phần mềm của mình kết thúc, bởi vì những công cụ này là bộ khuếch đại cho kinh nghiệm hiệ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.

Việc tạo ra phần mềm là một công việc cực kỳ khó khăn. Dù có tất cả công cụ AI, mục tiêu chúng tôi cố gắng đạt được vẫn thực sự thách thức.

Matthew Yglesias từng tweet: "Năm tháng qua, tôi nghĩ tôi đã quyết định là tôi 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 hỗ trợ lập trình AI để tạo ra nhiều sản phẩm hơn/tốt hơn/rẻ hơn để bán cho tôi."

Điều đó nghe rất đúng. Tôi có thể tự sửa ống nước nhà mình nếu xem đủ video YouTube, nhưng tôi thà thuê một thợ sửa ống nước chuyên nghiệp.

Điều này cũng áp dụng cho các nhà cung cấp SaaS. Tôi không muốn sử dụng CRM của bạn trừ khi ít nhất hai doanh nghiệp lớn khác đã sử dụng thành công nó trong sáu tháng. Chúng ta muốn những giải pháp đã được chứng minh hiệu quả trước khi mạo hiểm thử nghiệm.

Đây là thực tế của lập trình trong kỷ nguyên AI: ranh giới giữa việc tạo nhanh theo cảm hứng và kỹ thuật chuyên nghiệp đang mờ đi, đòi hỏi chúng ta phải thiết lập lại các tiêu chuẩn về niềm tin và chất lượng.