"Vibe Coder" so với Kỹ sư Phần mềm: Ranh giới giữa ý tưởng và trách nhiệm

Cách đây gần một thập kỷ, tôi từng viết về sự khác biệt giữa Java Developer và Software Engineer. Lúc đó, tôi chưa nhận ra rằng mọi người gắn liền bản sắc nghề nghiệp của mình với ngôn ngữ lập trình sâu sắc đến mức nào. Mục tiêu của tôi khi đó là phân biệt giữa người bị định nghĩa bởi một ngôn ngữ cụ thể và người tư duy rộng hơn về việc giải quyết vấn đề.

Toàn bộ cuộc thảo luận bắt đầu từ một tiền đề: Java đã trở thành "con đường duy nhất". Nhiều nhà phát triển bắt đầu tư duy từ Java hướng ra bên ngoài. Công cụ trở thành lăng kính để nhìn nhận mọi vấn đề. Và khi một vấn đề không vừa khít với lăng kính đó, họ bẻ cong vấn đề cho đến khi nó vừa vặn.

Tôi không muốn kéo dài sự so sánh này quá xa, bởi vì AI không chỉ là một ngôn ngữ lập trình hay framework khác. Nó thay đổi nền kinh tế của việc viết phần mềm. Tuy nhiên, mô hình cũ vẫn còn đó. Một công cụ trở nên mạnh mẽ, mọi người bao bọc bản sắc của mình xung quanh nó, và rồi nghề thủ công bị giảm thiểu xuống mức của công cụ.

Bây giờ, câu hỏi không phải là AI có thể viết code hay không. Nó làm được điều đó. Và mỗi ngày nó làm tốt hơn. Câu hỏi thực sự là loại công việc nào được tạo ra từ quá trình đó và điều gì sẽ xảy ra khi nó bước vào một codebase thực sự, với người dùng thực, dữ liệu thực, yêu cầu tuân thủ thực sự, các sự cố thực sự và những người thực sự phải bảo trì nó.

Đó chính là nơi tôi thấy sự khác biệt giữa một "Vibe Coder" (người lập trình theo cảm hứng) và một Kỹ sư Phần mềm. Vibe Coder là người muốn kiểm tra một ý tưởng bằng cách tạo ra phần mềm dưới dạng nguyên mẫu. Kỹ sư Phần mềm là người suy nghĩ về toàn bộ vòng đời phát triển phần mềm. Vì vậy, sự khác biệt không nằm ở công cụ. Sự khác biệt nằm ở nơi trách nhiệm bắt đầu và nơi nó kết thúc.

Yêu cầu merge code

Thước đo sai lầm

Rất nhiều cuộc thảo luận xung quanh vibe coding vẫn đo sai vấn đề. Mọi người chứng minh xem họ đi từ ý tưởng đến ứng dụng nhanh như thế nào. Điều đó có giá trị, đặc biệt khi mục tiêu là kiểm tra một ý tưởng. Nhưng trong một đội ngũ phát triển phần mềm, phải có người xem xét (review) nó. Phải có người hiểu ý định đằng sau nó. Phải có người quyết định xem dependency đó có thuộc về đó hay không. Phải có người kiểm tra xem test có xác minh hành vi đúng không. Phải có người áp dụng thay đổi schema. Phải có người điều phối thay đổi giữa các nhóm. Phải có người lên kế hoạch rollback. Phải có người viết runbook. Và phải có người chịu trách nhiệm khi nhận được thông báo báo lỗi (page).

Không một trong số này thuộc về dự án đồ chơi của bất kỳ ai. Vì vậy, tôi sẽ đo công việc do AI tạo ra bằng một thước đo khác: thời gian để merge an toàn (time to safe merge). Điều này bao gồm khả năng review, rủi ro, chất lượng test, quyền sở hữu, khả năng rollback và liệu tác giả có thể giải thích các quyết định có ý nghĩa trong thay đổi đó hay không. Nếu AI làm cho việc tạo code rẻ hơn nhưng làm cho việc merge an toàn tốn kém hơn, thì đội ngũ không thu được lợi ích nhiều như họ nghĩ.

Đây là sự khác biệt đầu tiên. Một Vibe Coder đo lường thời gian để có phiên bản hoạt động đầu tiên. Một Kỹ sư Phần mềm đo lường thời gian để merge an toàn. Thời gian để có phiên bản hoạt động đầu tiên hữu ích khi công việc là khám phá. Thời gian để merge an toàn là cần thiết khi công việc bước vào một codebase dùng chung. Nó bao gồm chi phí review, chi phí test, chi phí triển khai, chi phí rollback, chi phí điều phối và chi phí bảo trì trong tương lai. Đó là lý do tại sao bản demo là vạch đích sai. Nó chỉ chứng minh rằng một cái gì đó có thể được trình diễn, không phải là nó có thể được đội ngũ tiếp nhận hay không.

Đầu ra không phải là tiến bộ

Code được hỗ trợ bởi AI nên tốt hơn, không phải lớn hơn. Nếu công cụ cho phép bạn tạo ra nhiều hơn, con người phải hạn chế nhiều hơn. Nếu không, bạn không tiết kiệm công việc. Bạn đang chuyển nó xuống hạ nguồn, nơi việc bảo trì trở thành công việc vặt của người khác. Code được hỗ trợ bởi AI không thể được giữ ở một tiêu chuẩn khác. Nó phải đáp ứng cùng một tiêu chuẩn như code viết tay. Vì vậy, nó nên hẹp. Nó nên có một lý do để tồn tại. Nó không nên bao gồm các dọn dẹp không liên quan. Nó không nên định dạng lại một nửa file chỉ vì mô hình thích thế. Nó không nên thêm một gói mà không có lời giải thích rõ ràng.

Nếu thay đổi lớn vì mô hình tạo ra quá nhiều, hãy chia nhỏ nó. Tôi đã trải nghiệm điều này rất nhiều. Nó vui vẻ tạo ra rất nhiều mã mẫu (boilerplate) cho một thứ mà bạn có thể viết trong mười dòng. Vì vậy, nếu tác giả không thể giải thích tại sao mỗi tệp có ý nghĩa thay đổi, nó chưa sẵn sàng. Đó là quyền sở hữu cơ bản.

Sự khác biệt thứ hai là đơn vị công việc. Một Vibe Coder coi đầu ra được tạo ra là tiến bộ. Một Kỹ sư Phần mềm coi mọi thay đổi là đơn vị trách nhiệm. Đầu ra được tạo ra có thể lớn, lộn xộn và tạm thời. Quản lý thay đổi thực sự không thể tùy tiện như vậy. Nó phải đủ hẹp để review, đủ dễ giải thích để tin tưởng, và đủ giới hạn để merge mà không kéo theo một nửa hệ thống. Đây là nơi tốc độ trở nên hữu ích hoặc biến thành nợ review.

AI không thể chịu trách nhiệm

Review code được tạo bởi AI không giống như review code bình thường. Khi con người viết code, thường có một dấu vết quyết định. Nó có thể khiếm khuyết, nhưng ít nhất có một người có thể giải thích con đường đó. Bạn có thể hỏi tại sao họ sử dụng sự trừu tượng đó, tại sao họ đặt quy tắc ở đó, tại sao họ chọn gói đó, tại sao họ làm cho test trông như thế đó.

Với code do AI tạo ra, một số quyết định đó không thực sự là quyết định. Chúng là sự hoàn tất (completions). Nếu tác giả chưa chuyển đổi đầu ra được tạo ra thành công việc sở hữu, người review đang làm hai việc: review và khôi phục quyền tác giả.

Quyền sở hữu là sự khác biệt thứ ba. Một Vibe Coder có thể nói là mô hình đã tạo ra nó. Một Kỹ sư Phần mềm phải nói: "Tôi sở hữu nó". Điều đó có nghĩa là tác giả phải chuyển đổi đầu ra được tạo ra thành một quyết định kỹ thuật trước khi yêu cầu review. Code có thể bắt đầu từ mô hình, nhưng trách nhiệm giải thích không thể ở lại đó.

Bối cảnh không chỉ là tệp tin

Một mô hình có thể đọc rất nhiều code bây giờ. Điều đó không có nghĩa là nó hiểu hệ thống. Một số bối cảnh sống trong code, nhưng rất nhiều bối cảnh kỹ thuật sống ở nơi khác. Nó sống trong các sự cố, các lần di chuyển (migration) cũ, hành vi của khách hàng, nỗi đau vận hành, quy ước đội ngũ, yêu cầu bảo mật, quy tắc tuân thủ và những quyết định kỳ lạ trong quá khứ.

Mô hình không có những thứ đó trừ khi bạn đưa cho nó. Ngay cả khi bạn đưa cho nó, nó không mang bối cảnh đó theo cách mà một kỹ sư làm. Nó hoạt động trong cửa sổ ngữ cảnh (context window) của chính nó. Nhiệm vụ càng lớn, mô hình càng dễ tối ưu hóa cục bộ và làm hỏng điều gì đó ở mức toàn cầu.

Đó là lý do tại sao "chỉ cần yêu cầu nó sửa toàn bộ" là một thói quen xấu nhưng cũng chưa hoạt động hiệu quả. Tôi đã lười biếng đủ để làm điều đó nhiều lần. Một mô hình tốt hơn là giảm không gian quyết định trước khi yêu cầu code. Khi tôi áp đặt hơn, nó làm việc tốt hơn cho tôi. Nhưng việc áp đặt đòi hỏi điều gì? Rằng tôi hiểu mình đang cố gắng làm cái quái gì. Tôi nghĩ đây là nơi các kỹ sư có kinh nghiệm sẽ nhận được nhiều giá trị nhất từ AI. Không phải bằng cách đưa mô hình nhiều tự do hơn, mà bằng cách cho nó ít tự do hơn. Tự do hữu ích cho việc hack cuối tuần. Sản xuất cần sự ràng buộc.

Đây là sự khác biệt thứ tư. Một Vibe Coder đưa mô hình một mục tiêu, nhưng một Kỹ sư Phần mềm đưa mô hình một nhiệm vụ có giới hạn. Nhiệm vụ có giới hạn là nơi kỹ thuật xảy ra. Sử dụng giao diện này. Không chạm vào lớp này. Vân vân. Một câu lệnh (prompt) tốt ở đây không phải là phép thuật. Nó thường là bằng chứng cho thấy kỹ sư đã hiểu ranh giới.

Vibe Coding thuộc về quy trình giao hàng, nhưng không phải ở mọi nơi

Trong một cuộc phỏng vấn gần đây mà tôi rất khuyên bạn nên xem, Andrew Kelley - người tạo ra Zig - nói rằng dự án cấm các đóng góp của AI và gọi chúng là rác rưởi không thể tránh khỏi. Tôi hiểu họ. Những người bảo trì đang thấy các pull request (PR) khổng lồ do AI tạo ra với các thay đổi không liên quan, hành vi kế thừa bị hỏng, các phụ thuộc lạ và những người đóng góp không thể giải thích code họ gửi.

Nhưng sự lộn xộn họ mô tả không phải là một phán quyết về AI. Đó là những gì vibe coding tạo ra khi nó rơi xuống sai phía của một đường ranh giới. Vì vậy, tôi sẽ không cấm nó. Tôi sẽ định vị nó.

Đường ranh giới đó là sự khác biệt thứ năm: khám phá (discovery) so với giao hàng (delivery). Cùng một pull request mà mất cả buổi chiều của người bảo trì thì vô hại khi bạn đang tạo một nguyên mẫu (spike). Không ai sở hữu code bỏ đi đó. Khám phá có thể chịu đựng sự lộn xộn vì mục tiêu là học hỏi hoặc lặp lại nhanh chóng trên một ý tưởng. Giao hàng không thể chịu đựng sự lộn xộn không giải thích được vì mục tiêu là một kết quả kinh doanh thực sự. Bạn không thể nói chúng tôi đúng 99,9%. Đôi khi nó chỉ cần phải đúng. Đó là đường ranh giới thực tế.

Lời cảnh báo trung thực là đường ranh giới này liên tục dịch chuyển. Khi các công cụ tốt hơn trong việc test, rollback và review, một số chi phí merge an toàn sẽ giảm bớt. Giảm bớt không có nghĩa là biến mất. Miễn là ai đó phải sở hữu kết quả, phải có một mức độ kỷ luật nhất định. Hãy sử dụng vibe coding nơi chi phí của việc sai là thấp, và sử dụng kỷ luật kỹ thuật nơi chi phí của việc sai thuộc về khách hàng, đội ngũ hoặc doanh nghiệp.

Vấn đề học việc

Các kỹ sư trẻ sẽ sử dụng AI. Họ nên thế. Nếu sử dụng tốt, nó có thể giải thích code, so sánh các cách tiếp cận, tạo ví dụ và làm cho việc học nhanh hơn. Nhưng có một phiên bản xấu của điều này.

Nếu một kỹ sư trẻ sử dụng AI để tránh hiểu hệ thống, họ có thể giao nhiều hơn nhưng học ít hơn. Đó là một sự đánh đổi kém. Những năm đầu tiên của kỹ thuật là nơi mọi người xây dựng mô hình tinh thần. Họ cần xây dựng mô hình đó trong đầu riêng của họ, không phải mượn nó từ máy móc.

Bạn không xây dựng sự phán xét đó bằng cách ở bên ngoài hệ thống và yêu cầu mô hình liên tục sửa chữa nó. Đây là một trong những phần khó khăn nhất đối với các quản lý. AI có thể khiến các kỹ sư trẻ trông năng suất hơn trong ngắn hạn trong khi làm suy yếu vòng lặp học tập biến họ thành những kỹ sư giỏi. Lý do sâu xa hơn của Kelley cho việc cấm AI ở Zig liên quan đến đây. Ông gọi review code là "poker của người đóng góp", cách một dự án tìm thấy những người đáng được phát triển thành đội ngũ cốt lõi. Các bài gửi AI phá vỡ điều này vì người đóng góp không học codebase hay tiếp nhận phản hồi.

Và đây là điểm cuối cùng. Kỹ thuật đòi hỏi một mức độ học việc. Vibe coding cám dỗ bạn làm việc một mình. Mọi người làm việc và học hỏi trong các nhóm. Kỹ sư phần mềm cải thiện nghề thủ công của mình bằng cách làm việc với người khác. Công việc không chỉ là code. Công việc là sự phán xét, không phải đầu ra. Một kỹ sư phần mềm có sự phán xét về điều gì rủi ro và điều gì không. Sự phán xét đó được xây dựng thông qua tiếp xúc với hệ thống và con người.

Sự khác biệt

Một Vibe Coder hữu ích khi đầu ra chính là ý tưởng. Họ có thể rút ngắn khoảng cách giữa một ý tưởng và một cái gì đó có thể nhấp vào. Nhiều ý tưởng xứng đáng được đối xử như vậy trước khi bất kỳ ai dành năng lượng kỹ thuật thực sự cho chúng.

Một Kỹ sư Phần mềm cần thiết khi chi phí chính là quyền sở hữu. Họ kiểm soát những gì bước vào hệ thống, cách nó được review, cách nó được bảo mật, cách nó được test, cách nó được vận hành và cách nó sẽ được thay đổi sau này. Sự khác biệt mang tính vận hành. Nó cũng không phải là một bản sắc cố định. Cùng một người nên vibe coding trong giai đoạn khám phá và chuyển sang kỹ thuật trong giai đoạn giao hàng. Kỹ năng là biết bạn đang ở chế độ nào, và không để thói quen của chế độ này rò rỉ sang chế độ kia. Vibe coding có thể giúp bạn học nhanh hơn. Kỹ thuật phần mềm giúp bạn tránh phải trả giá cho việc học đó mãi mãi.