Hai cách xây dựng với AI
Hiện nay, ở mọi đội ngũ đang xây dựng với AI đều có một cuộc tranh luận âm thầm chạy xuyên suốt—thường nó xuất hiện như một cảm giác hơn là một cuộc tranh cãi. Có người hoàn thiện và phát hành một ứng dụng hoạt động chỉ trong một buổi chiều bằng cách mô tả họ muốn gì và chấp nhận mọi thứ mà mô hình tạo ra. Người khác lại khăng khăng đọc từng dòng, viết test, và hiểu xem thứ đó thực sự hoạt động như thế nào. Cả hai đều dùng chung những công cụ ấy. Họ chỉ đang chơi những trò chơi rất khác nhau.
Hai trò chơi này giờ đã có tên. Cách làm nhanh, thoải mái, kiểu mô tả rồi chấp nhận được gọi là vibe coding (lập trình theo “cảm hứng”). Còn lối xây dựng cẩn thận, có hệ thống để tạo ra các hệ thống đáng tin cậy xoay quanh một mô hình—lại gần với điều mà người ta muốn nói khi gọi đó là agentic engineering (kỹ thuật theo tác nhân). Thật hấp dẫn khi biến điều này thành một cuộc chiến: một bên đại diện cho tốc độ, bên kia cho tính chặt chẽ, rồi chọn phe. Cách đóng khung đó lại bỏ lỡ vấn đề. Chúng không phải đối thủ. Chúng là những công cụ cho những thời điểm khác nhau, và kỹ năng thật sự nằm ở việc biết bạn đang cầm công cụ nào.
Sự nhầm lẫn này đáng được làm rõ, vì rủi ro đang tăng rất nhanh. Ngày càng nhiều phần mềm được viết với sự trợ giúp nặng tay từ các mô hình, và những thói quen con người hình thành ngay bây giờ sẽ quyết định phần mềm đó có thể trở thành thứ ta xây tiếp được, hay chỉ là một đống mã mà không ai hiểu. Làm đúng sự phân biệt thì AI sẽ làm bạn nhanh hơn trong mọi thứ—từ những thử nghiệm vứt đi cho đến các hệ thống nghiêm túc. Làm sai thì bạn hoặc bò lê qua những bản prototype chẳng đáng được chăm chút, hoặc phát hành các hệ thống production được ghép lại bằng những phỏng đoán.
Bài viết này đi qua toàn bộ vấn đề: mỗi chế độ thực sự là gì, vì sao vibe coding lại quyến rũ đến vậy, mỗi chế độ phù hợp ở đâu, cách phân biệt chúng ngay trong khoảnh khắc, và cách dùng cả hai mà không tự lừa mình về việc một tác vụ cụ thể đang đòi hỏi chế độ nào. Trên đường đi sẽ có một bảng so sánh, một checklist quyết định nhanh, vài tình huống thực tế, và hai bộ checklist bạn có thể giữ lại.
Vibe coding là gì
Thuật ngữ vibe coding bắt nguồn từ Andrej Karpathy, người đã mô tả một cách làm việc mới: bạn đi “all-in” với mô hình, nói chuyện với nó bằng ngôn ngữ tự nhiên, chấp nhận các gợi ý mà không quá bận tâm đến chi tiết, và gần như quên rằng mã nguồn đó tồn tại. Bạn không đọc diff. Bạn đang cưỡi theo “vibe”.
Nó giúp hình dung một phiên làm việc thực sự trông sẽ ra sao. Bạn mở một chat hoặc một agent, mô tả thứ bạn muốn, rồi mã xuất hiện. Bạn chạy nó. Có gì đó không ổn, nên bạn dán lại lỗi và xin sửa, và mã mới lại xuất hiện. Bạn không đọc kỹ—thậm chí có thể chẳng đọc gì. Bạn chạy lại. Nó chạy được, hoặc chạy được đủ, rồi bạn chuyển sang tính năng tiếp theo và làm y như vậy. Vòng lặp này nhanh và gần như mang tính trò chuyện, và không lúc nào bạn dừng lại để xây dựng một mô hình tinh thần xem mọi thứ khớp với nhau ra sao. Mô hình đó được giữ lại—hoặc đúng hơn, chẳng ai giữ nó.
Bất kỳ ai từng làm kiểu này cũng hiểu vì sao nó bùng nổ. Nó thực sự rất thú vị. Bạn di chuyển nhanh ngang tốc độ suy nghĩ, lực cản giữa một ý tưởng và một prototype đang chạy gần như biến mất, và bạn có thể tạo ra những thứ mà bằng tay bạn sẽ không bao giờ đủ kiên nhẫn để làm. Một người gần như không thể viết nổi một đoạn script giờ có thể dựng lên một ứng dụng web hoạt động. Một kỹ sư giàu kinh nghiệm có thể thử nghiệm năm hướng tiếp cận trong thời gian trước đây chỉ đủ để thiết lập một cái. Với một dự án cuối tuần, một thử nghiệm nhanh, hoặc một công cụ mà chỉ bạn dùng—nó có thể giống như một siêu năng lực, và thực tế thì phần nào đúng như vậy.
Nhưng điểm đặc trưng không phải tốc độ. Mà là sự buông tay. Trong vibe coding, bạn trao đi không chỉ việc gõ phím mà cả sự hiểu biết. Bạn tin rằng mã chạy được vì trông có vẻ chạy được, và bạn không đặc biệt quan tâm nó vận hành thế nào. Đổi chác đó chính xác là thứ khiến nó nhanh, và cũng chính xác là nơi rắc rối bắt đầu. Giữ chặt từ “buông tay” này, vì gần như mọi điều tốt và xấu về vibe coding đều bắt nguồn từ nó.
Vì sao nó cảm thấy tuyệt đến vậy
Trước khi nói về nơi vibe coding đi sai, đáng để nghiêm túc xem xét vì sao rất nhiều người giỏi lại rơi vào nó, vì lực hút đó là có thật và việc giả vờ rằng nó không tồn tại là vô ích.
Lý do đầu tiên đơn giản là tốc độ, và tốc độ thì gây nghiện. Có một niềm vui đặc biệt khi mô tả một thứ rồi thấy nó xuất hiện chỉ ngay khoảnh khắc sau, và nó gãi đúng vào cùng một nỗi ngứa đã khiến công việc trở nên thú vị ngay từ đầu. Viết mã bằng tay trước giờ luôn có những chặng dài ma sát: boilerplate, cấu hình, việc tra cứu một interface mà bạn đã dùng cả trăm lần. Vibe coding nén ma sát đó lại gần như bằng không, và cảm giác không còn ma sát giống như được bay.
Lý do thứ hai là vòng lặp phản hồi. Mỗi yêu cầu nhỏ tạo ra kết quả nhìn thấy được rất nhanh, và kết quả nhìn thấy được nhanh là thứ củng cố mạnh mẽ nhất đối với não. Đây là cùng một vòng lặp khiến trò chơi trở nên cuốn hút và nuôi dưỡng sự cưỡng chế. Bạn hỏi, bạn nhận, rồi bạn hỏi lại—và chỉ trong một giờ là trôi mất. Vòng lặp thỏa mãn đến mức dừng lại để đọc mã dường như là một sự gián đoạn, giống như dừng một lượt chạy tốt để kiểm tra dáng đi của bạn.
Lý do thứ ba là bản demo. Hầu hết áp lực trong phần mềm là phải cho thấy tiến độ, và một prototype vibe coded cho thấy tiến độ cực kỳ đẹp. Nó trông như đã xong. Nó hoạt động, bấm vào là phản hồi và làm người ta ấn tượng trong cuộc họp. Khoảng cách giữa “trông có vẻ đã xong” và “thực sự đã xong” đối với người ngoài là vô hình, và những vấn đề vô hình sẽ không tạo ra sự khẩn cấp. Vì vậy, phần thưởng ngầm lặng lẽ ưu đãi thứ trông như đã hoàn thành hơn là thứ vận hành đúng. Và các đội ngũ dạt dần về vibe coding mà không bao giờ phải quyết định rõ ràng.
Không có gì trong số này là một lỗi tính cách. Đó là phản ứng hợp lý trước các động lực thật và là một trải nghiệm tốt hơn một cách chân thực. Việc gọi tên ra không nhằm cảm thấy mình vượt trội so với nó. Mục đích là nhận ra lực kéo này để bạn quyết định khi nào cần chống lại, thay vì bị cuốn theo một cảm giác mà bạn chưa từng xem xét.
Agentic engineering là gì
Agentic engineering là tư thế còn lại. Nó cũng dựa nặng vào AI—thậm chí thường nhiều hơn vibe coding—vì nó đưa mô hình vào bên trong những hệ thống thực, nơi mô hình tự thực hiện các hành động. Điểm khác không nằm ở việc bạn dùng nhiều AI hay ít. Điểm khác là mức độ bạn giữ quyền kiểm soát với những gì AI tạo ra.
Một kỹ sư coi output của mô hình giống như một reviewer cẩn thận coi bản pull request tự tin của một kỹ sư junior. Công việc có thể rất xuất sắc, nhưng đó vẫn là bản nháp cần được kiểm tra, chứ không phải là một chân lý để chấp nhận. Trên thực tế, điều đó biến thành một vài thói quen cụ thể. Có test, để hành vi bạn quan tâm được “neo” lại và một thay đổi trong tương lai không thể âm thầm làm nó gãy. Có cách nhìn xem hệ thống đã làm gì và vì sao, để khi có chuyện sai bạn có thể lần ra thay vì đoán. Có giới hạn những thứ hệ thống có thể chạm vào, và các điểm rõ ràng nơi con người xác nhận trước khi bất cứ thứ gì tốn kém hoặc không thể đảo ngược xảy ra. Và khi công việc liên quan đến một autonomous agent, sẽ có evals—các bài test lặp lại để xem toàn bộ thứ đó có thật sự làm đúng việc của nó trong những tình huống quan trọng hay không—vì một agent chạy được một lần trong demo cho bạn gần như không biết gì về việc nó chạy đúng hay không.
Trên hết là sự hiểu biết. Có người hiểu thứ đó vận hành như thế nào và có thể sửa nó khi nó hỏng, có thể suy luận về các “biên” của nó, có thể giải thích cho đồng nghiệp vì sao nó được xây như vậy. Sự hiểu biết được coi như một “deliverable” (sản phẩm bàn giao) theo đúng nghĩa, như một phần của công việc—không kém gì mã chạy—bởi một hệ thống không ai hiểu là một hệ thống đang thất bại, chỉ là chưa ai để ý ra.
Nếu vibe coding là về việc buông theo “vibe”, thì engineering là về việc từ chối. Nó giữ lại đúng một thói quen mà vibe coding ném đi: thói quen xác minh và hiểu trước khi tin tưởng. Chỉ riêng thói quen đó đã là toàn bộ khác biệt, và đáng để nhìn trực tiếp vào nó.
Đó là một phổ, không phải nhị phân
Trước khi đi xa hơn, sẽ giúp nếu bỏ ý nghĩ rằng chỉ có hai lựa chọn. Vibe coding và full engineering là hai đầu của một dải, còn phần lớn công việc thực tế nằm đâu đó dọc theo dải đó.
Ở tận cùng bên trái là vibe coding thuần túy: bạn chấp nhận những gì mô hình đưa và không bao giờ đọc nó. Tiến vào một chút từ đó là điều mà hầu hết mọi người thực sự làm phần lớn thời gian—AI-assisted coding, nơi mô hình viết và bạn duyệt diff trước khi chấp nhận, giống như cách bạn duyệt công việc của một đồng nghiệp. Xa hơn nữa là một kiểu có kỷ luật hơn, theo đặc tả: bạn ghi rõ mã phải làm gì, để mô hình hiện thực hóa, rồi kiểm tra phần hiện thực dựa trên đặc tả bằng các test. Ở tận cùng bên phải là agentic engineering đầy đủ: mô hình được “dệt” vào một hệ thống kèm evals, quan sát (observability) và guardrails, và toàn bộ thứ đó được xem như phần mềm production—dù thực tế nó đã được viết với sự trợ giúp nặng từ AI.
Khi bạn di chuyển từ trái sang phải, bạn đổi tốc độ thô lấy quyền kiểm soát, sự hiểu biết, và độ bền. Không điểm nào trong số này là câu trả lời đúng nói chung. Sai lầm mà mọi người hay gặp không phải là chọn nhầm điểm. Mà là không nhận ra rằng có một núm vặn, rồi để nó mắc kẹt ở vị trí mà thói quen hoặc tâm trạng đã vô tình đặt. Một người xây dựng giỏi sẽ xoay núm một cách có chủ đích: trượt sang trái để khám phá và sang phải để gia cố. Phần còn lại của bài viết này thực sự là để giúp bạn học cảm giác núm đó nên nằm ở đâu.
Khác biệt cốt lõi: xác minh và hiểu biết
Dù bạn đang đứng ở đâu trong dải đó, thứ thay đổi khi bạn trượt dọc theo nó là một bước cụ thể. Đặt vibe coding thuần túy và engineering thực sự cạnh nhau, sự tương phản gần như “xấu hổ” vì nó quá đơn giản. Cả hai đều bắt đầu bằng việc mô tả mục tiêu và để mô hình tạo ra mã. Rồi lộ trình tách ra. Vibe coding đi thẳng từ mã được sinh ra đến việc phát hành nó. Engineering chèn một bước vào giữa: bước bạn đọc, test, và đảm bảo mình hiểu trước khi nó đi đến bất kỳ đâu.
