Vibe Engineering

• "Vibe Engineering" là tên gọi mới cho một phương thức phát triển chuyên nghiệp sử dụng công cụ lập trình AI; khác với "vibe coding" nhanh, tùy hứng và thiếu trách nhiệm, nó chỉ cách tiếp cận mà kỹ sư giàu kinh nghiệm tận dụng LLM nhưng vẫn duy trì chất lượng mã và trách nhiệm
• Sự xuất hiện của các tác tử lập trình như Claude Code, OpenAI Codex CLI và Gemini CLI đã khiến việc dùng LLM trong các dự án thực tế tăng mạnh; một số kỹ sư còn chạy nhiều tác tử cùng lúc để xử lý song song
• Để tận dụng LLM hiệu quả, vẫn cần những thực hành kỹ nghệ phần mềm đỉnh cao đã được xác lập như kiểm thử tự động, lập kế hoạch trước, tài liệu hóa toàn diện, quản lý phiên bản và văn hóa review code
• Công cụ AI có đặc tính khuếch đại chuyên môn sẵn có; kỹ sư càng nhiều kỹ năng và kinh nghiệm thì càng có thể đạt kết quả nhanh hơn và tốt hơn khi dùng LLM
• Thuật ngữ này nhấn mạnh đây là cách dùng AI khó hơn và tinh vi hơn cho phát triển phần mềm production, được phân biệt rõ với "vibe coding"; sự kết hợp tưởng như mâu thuẫn giữa engineering và vibe lại tạo lợi thế dễ nhớ hơn (nhấn mạnh sự thay đổi của quy trình phát triển cùng tầm quan trọng của chuyên môn khi công cụ AI tiến hóa)

---

Phân biệt giữa vibe coding và vibe engineering

• Vibe coding là cách phát triển phần mềm bằng AI theo kiểu nhanh, lỏng lẻo và thiếu trách nhiệm; hoàn toàn do prompt dẫn dắt và không chú ý đến cách mã thực sự hoạt động
• Ở đầu kia của phổ là cách những chuyên gia lành nghề tăng tốc công việc bằng LLM nhưng vẫn tự hào, tự tin và chịu trách nhiệm về phần mềm mình tạo ra, và điều đó được gọi là vibe engineering
• Một sự thật ít được nói đến là làm việc hiệu quả với LLM trong các dự án thực tế, chứ không phải project đồ chơi, với vai trò kỹ sư phần mềm là việc khó, đòi hỏi hiểu biết sâu về cách dùng công cụ và có rất nhiều cạm bẫy cần tránh

Sự xuất hiện và tác động của các tác tử lập trình

• Các công cụ tác tử lập trình như Claude Code phát hành vào tháng 2/2025, Codex CLI của OpenAI phát hành vào tháng 4, và Gemini CLI phát hành vào tháng 6 đã xuất hiện, làm tăng mạnh tính hữu dụng của LLM đối với các bài toán lập trình thực tế
  • Những công cụ này liên tục sửa mã và chủ động kiểm thử để tiếp tục làm việc cho đến khi đạt được mục tiêu đã chỉ định
• Những kỹ sư phần mềm giàu kinh nghiệm và đáng tin cậy đang chạy nhiều tác tử cùng lúc để xử lý nhiều vấn đề song song và mở rộng phạm vi công việc
  • Tác giả ban đầu hoài nghi, nhưng sau khi trực tiếp chạy các tác tử lập trình song song thì xác nhận rằng cách này mệt về mặt tinh thần nhưng hiệu quả đáng ngạc nhiên
• Phần lớn bộ sưu tập tools.simonwillison.net được xây dựng theo kiểu vibe coding cổ điển, nhưng việc lặp đi lặp lại cùng các tác tử lập trình để tạo ra mã đạt chất lượng production có thể bảo trì trong tương lai lại cho cảm giác là một quy trình hoàn toàn khác

Những thực hành kỹ nghệ phần mềm hiện có được LLM tăng cường

• Kiểm thử tự động: nếu có một bộ test mạnh, toàn diện và ổn định thì công cụ lập trình tác tử có thể hoạt động rất nhanh; nếu không có test, tác tử có thể khẳng định là mọi thứ chạy dù thực ra chưa test, hoặc thay đổi mới có thể làm hỏng các tính năng không liên quan
  • Phát triển ưu tiên kiểm thử đặc biệt hiệu quả với các tác tử có thể lặp trong loop
• Lập kế hoạch trước: khi bắt đầu ghép nhanh một thứ gì đó, nếu xuất phát từ một kế hoạch cấp cao thì mọi thứ sẽ diễn ra tốt hơn nhiều, và điều này còn quan trọng hơn khi làm việc với tác tử
  • Có thể lặp trước trên kế hoạch rồi mới giao cho tác tử viết mã
• Tài liệu hóa toàn diện: giống như lập trình viên con người, LLM cũng chỉ có thể giữ một phần codebase trong ngữ cảnh tại một thời điểm; nếu cung cấp tài liệu liên quan, nó có thể dùng API ở vùng khác mà không cần đọc mã trước
  • Nếu viết tài liệu tốt từ trước, mô hình có thể dựng nên phần triển khai khớp với đầu vào đó
• Thói quen quản lý phiên bản tốt: khi tác tử lập trình có thể đã thay đổi gì đó, việc hoàn tác sai sót và hiểu được cái gì thay đổi khi nào, bằng cách nào càng trở nên quan trọng hơn
  • LLM rất giỏi với Git, có thể tự dò lịch sử để truy vết nguồn gốc bug và thường dùng git bisect tốt hơn đa số lập trình viên
• Tự động hóa hiệu quả: tích hợp liên tục, format và lint tự động, triển khai liên tục lên môi trường preview đều giúp ích cho công cụ lập trình tác tử
  • LLM giúp viết nhanh các script tự động hóa, để lần sau có thể lặp lại công việc một cách chính xác và nhất quán
• Văn hóa review code: nếu bạn review code nhanh và hiệu quả thì trải nghiệm làm việc với LLM sẽ tốt hơn nhiều
  • Nếu bạn chỉ muốn tự viết mã hơn là ngồi review thứ do người khác (hoặc thứ gì đó) viết ra, thì sẽ thấy khó khăn
• Một dạng kỹ thuật quản lý rất kỳ lạ: để có kết quả tốt từ tác tử lập trình, cách làm lại giống với việc đạt kết quả tốt từ cộng tác viên con người đến mức hơi khó chịu
  • Cần đưa ra chỉ dẫn rõ ràng, đảm bảo đủ ngữ cảnh cần thiết và cung cấp phản hồi có thể hành động được về sản phẩm đầu ra
  • Điểm dễ hơn nhiều so với làm việc với người thật là không cần lo xúc phạm hay làm họ nản chí, nhưng kinh nghiệm quản lý sẵn có vẫn hữu ích một cách đáng ngạc nhiên
• QA thủ công thật sự tốt: ngoài kiểm thử tự động, còn phải rất giỏi trong việc kiểm thử phần mềm thủ công, bao gồm dự đoán và đào sâu vào các edge case
• Kỹ năng nghiên cứu mạnh: luôn có hàng chục cách để giải một bài toán lập trình cụ thể; việc xác định lựa chọn tốt nhất và chứng minh cách tiếp cận đó luôn quan trọng, và vẫn là rào cản trước khi thả tác tử đi viết mã thật
• Khả năng triển khai lên môi trường preview: khi tác tử xây xong tính năng, nếu có cách xem trước tính năng đó một cách an toàn mà không deploy thẳng lên production, quá trình review sẽ hiệu quả hơn nhiều và rủi ro phát hành thứ bị lỗi sẽ giảm mạnh
• Bản năng về thứ có thể outsource cho AI và thứ phải xử lý thủ công: điều này tiếp tục tiến hóa khi mô hình và công cụ ngày càng hiệu quả hơn
  • Một phần lớn của việc làm việc hiệu quả với LLM là duy trì trực giác mạnh về lúc nào nên áp dụng nó hiệu quả nhất
• Cảm quan ước lượng được cập nhật: ước lượng dự án sẽ mất bao lâu luôn là một trong những phần khó nhất nhưng quan trọng nhất của kỹ sư senior, đặc biệt trong các tổ chức nơi quyết định ngân sách và chiến lược dựa trên những ước lượng đó
  • Lập trình có hỗ trợ AI khiến việc này còn khó hơn; những thứ từng mất rất lâu nay có thể nhanh hơn nhiều, nhưng việc ước lượng giờ lại phụ thuộc vào những yếu tố mới mà tất cả chúng ta vẫn đang cố hiểu

Bản chất và ý nghĩa của vibe engineering

• Để thực sự khai thác được khả năng của các công cụ mới này, cần vận hành ở đẳng cấp cao nhất của cuộc chơi, bao gồm
  • không chỉ chịu trách nhiệm viết mã, mà còn
  • nghiên cứu cách tiếp cận,
  • quyết định kiến trúc cấp cao,
  • viết đặc tả,
  • định nghĩa tiêu chí thành công,
  • thiết kế loop tác tử,
  • lập kế hoạch QA,
  • quản lý một đội quân ngày càng đông những thực tập sinh số kỳ quặc luôn tìm cách lách nếu có cơ hội,
  • và dành rất nhiều thời gian cho review code
• Gần như tất cả những điều này vốn đã là đặc trưng của một kỹ sư phần mềm senior
• Công cụ AI khuếch đại chuyên môn sẵn có; với tư cách kỹ sư phần mềm, bạn càng có nhiều kỹ năng và kinh nghiệm thì càng có thể đạt kết quả nhanh hơn và tốt hơn khi làm việc với LLM và tác tử lập trình

“Vibe engineering”, thật vậy sao? : Suy ngẫm về việc chọn thuật ngữ

• Về việc cái tên "vibe engineering" có ngớ ngẩn không: có lẽ là có; khái niệm "vibe" trong AI ở thời điểm này có phần đã bị dùng đến mệt mỏi, và bản thân "vibe coding" đang bị nhiều lập trình viên dùng theo nghĩa miệt thị
  • Nhưng tôi sẵn sàng giành lại chữ vibe cho một điều gì đó mang tính xây dựng hơn
• Tôi chưa bao giờ thích sự phân biệt gượng ép giữa "coder" và "engineer" vì nó luôn giống một dạng rào cản gia nhập, nhưng trong trường hợp này thì một chút rào cản gia nhập lại chính xác là điều cần thiết
  • Vibe engineering thiết lập sự phân biệt rõ ràng với vibe coding, và báo hiệu rằng đây là một cách khác, khó hơn và tinh vi hơn để làm việc với công cụ AI nhằm xây dựng phần mềm production
• Tôi thích khả năng nó sẽ bị xem là ngạo mạn và gây tranh cãi; toàn bộ không gian này vẫn còn phi lý theo rất nhiều cách
  • Trong lúc tìm ra cách hiệu quả nhất để áp dụng những công cụ mới này, chúng ta không nên quá nghiêm trọng hóa bản thân
• Trước đây tôi từng cố gắng phổ biến những thuật ngữ như lập trình có hỗ trợ AI nhưng gần như không thành công, nên lần này thử cọ xát với chữ vibe xem chuyện gì xảy ra cũng không phải ý tệ
• Tôi thực sự thích sự lệch pha rõ ràng giữa "vibe" và "engineering", vì nó làm cho cụm từ kết hợp này trở nên vừa vui nhộn vừa (hy vọng là) dễ nhớ theo một cách tự mâu thuẫn

[m00nlygreat]

Tôi nhớ là trước đây cũng từng đặt tên kiểu “coding gì đó?” rồi thất bại, nên có vẻ AI pair programming là cách diễn đạt phù hợp nhất.

Đặt tên chỉ để khẳng định “cái tên đó là do tôi придумал”.

[m00nlygreat]

Đã từng có người gọi đó là "Augmented Coding", nhưng rồi cụm này nhanh chóng biến mất.

[GN⁺]

Ý kiến trên Hacker News

• Gần đây cứ đọc những chủ đề như thế này là tôi lại thấy hơi chán nản. Trước đây tôi có kỹ năng lập trình khó kiếm, nhu cầu cao và lương tốt, và dù ngôn ngữ hay framework thay đổi nhanh thì tôi vẫn cảm thấy mình đủ thông minh để theo kịp. Nhưng khi thấy những người như Simon Willison nói rằng kiểu viết mã mới dựa trên agent và luồng công việc đồng thời hàng loạt mới là tương lai, tôi thấy như sẽ phải bỏ ra một nỗ lực khổng lồ, nên rất mệt mỏi. Tôi đã thử dùng coding agent rồi, nhưng ngược lại còn phải chờ nhiều hơn, lại khó giữ được flow vì phải quản lý nhiều việc cùng lúc, nên thấy bớt vui. Vì thế tôi còn nghĩ hay là chuyển hẳn sang một lĩnh vực khác như sales.
  • Tôi thật sự đồng cảm với cảm giác đó. Thực ra một trong những mục tiêu của tôi là phản bác ý nghĩ rằng "kỹ năng lập trình sẽ trở nên vô dụng và ai cũng có thể viết code bằng LLM". Tôi tin rằng trên thực tế, người đã có kinh nghiệm phát triển từ trước sẽ có giá trị cao hơn rất nhiều khi làm việc cùng coding agent hay LLM. Bạn có thể tận dụng những gì đã học để tạo ra tác động lớn hơn với công cụ mới. Như bài viết cũng nói, công cụ AI có vai trò khuếch đại năng lực của chuyên gia sẵn có. Người mới có thể tạo ra một UI đẹp bằng ChatGPT, nhưng những việc như thiết kế kiến trúc, automated testing hay CI/CD, triển khai Kubernetes, vận hành đồng thời nhiều agent thì họ không làm được, nên vai trò của kỹ sư giàu kinh nghiệm lại càng quan trọng hơn.
  • Tôi cũng thấy việc "quản lý nhiều agent được song song hóa quy mô lớn" là một gánh nặng. Bề ngoài nó trông rất mạnh mẽ nên chắc nhiều lập trình viên đang quan tâm, nhưng thực ra tôi thấy nó là một nguồn stress khổng lồ và đầy việc quản trị. Khi mới đam mê phát triển, chính việc viết code là niềm vui, và tôi có thể code cả ngày để học được rất nhiều. Giờ khi đã có hơn 10 năm kinh nghiệm, tôi lại chuyển sang lối nghĩ mang tính kinh doanh kiểu "rốt cuộc tại sao phải code cái này?". Trong các cuộc họp, chỉ cần bộ phận khác hỏi "cái này làm được không?" thì câu trả lời gần như luôn là "YES". Về mặt kỹ thuật thì hầu như đều làm được. Nhưng câu hỏi thật sự quan trọng là "khó đến mức nào" hoặc "tại sao phải làm việc này". Tôi vẫn nghĩ điều quan trọng không phải là khả năng lặp lại và tung ra đủ thứ, mà là nhìn vào bản chất.
  • Bạn nói rất đúng tâm trạng của tôi. Bản thân tôi cũng thật sự không thích công việc đứng ra trông nom và quản lý AI. Hơn nữa, điều đáng sợ là kiểu lập trình dựa trên AI này đang dần coi như đương nhiên một thực tế nơi người ta không thể làm việc nếu không có tài khoản của một tập đoàn lớn, thiếu mọi kiểm chứng và đầy mơ hồ.
  • Không cần quá lo. Tôi cũng đang mentoring một kỹ sư mới trong nhóm, và bạn ấy cải thiện code rất vất vả, vì chỉ cần chạy được là đã thấy đủ. Cấu trúc không tốt, lại còn có các vấn đề nhỏ và lỗ hổng bảo mật ẩn khắp nơi. Chỉ với vỏn vẹn 3 file Python mà đã như vậy. Nhóm tôi có 10 dev, và khi cùng dùng LLM, chênh lệch chất lượng code sẽ còn lớn hơn theo đúng mức chênh lệch kinh nghiệm. Trong 6 tháng trước khi việc dùng LLM được chính thức hóa, cảm nhận của tôi là khoảng cách giữa junior và senior, giữa người ít và nhiều kinh nghiệm, thực tế còn nới rộng hơn. Quan điểm này khá giống với Simon.
  • Về bản chất, chỉ cần nhớ rằng người có kiến thức sẽ được công cụ trao thêm sức mạnh lớn hơn, chứ không phải ngược lại.
• Vào đầu năm 2023, quanh thời điểm GPT-4 ra mắt, ngành dịch thuật cũng có một thay đổi tương tự. Trong dịch Anh-Nhật, lĩnh vực tôi từng làm, machine translation lần đầu tiên tiến rất sát trình độ con người. Khi đó tôi đã tranh luận đủ kiểu với nhiều dịch giả chuyên nghiệp, và giống như ở đây, ai cũng bày tỏ sự thất vọng vì sợ rằng kỹ năng dịch thuật khó nhọc sẽ trở nên vô nghĩa. Phản ứng phổ biến là nếu dùng LLM như trợ lý, thì ngay cả niềm vui thử thách trong quá trình làm việc giờ cũng biến mất. Hầu hết các dịch giả tôi gặp đều làm freelance và thuộc kiểu cẩn trọng dịch từng câu một. Họ không mấy hứng thú với việc trở thành người quản lý các dự án dịch quy mô lớn, và dù có thể vận dụng năng lực giao tiếp văn hóa/ngữ cảnh ở mức cao, họ vẫn thiếu động lực. Hiện giờ tôi không còn làm dịch nhiều nữa, nhưng vẫn liên tục theo dõi tiến triển của AI và thỉnh thoảng dùng các bài dịch để test so sánh model. Dạo này tôi thử nghiệm một hệ thống dịch dựa trên multi-LLM, cho nhiều LLM chạy chồng lên nhau để đối chiếu và cải thiện bản dịch của nhau. Với một số tài liệu, kết quả cho ra thực sự gần như giống hệt bản dịch tốt nhất của con người. Phí API không hề rẻ, nhưng với những bản dịch quan trọng thì hoàn toàn đáng để đầu tư. Khi thiết kế một hệ thống "vibe translation" như vậy, kinh nghiệm làm dịch giả của tôi rõ ràng đã giúp ích rất nhiều. Nó khá giống với vibe engineering mà Simon nói tới. Ở tuổi hiện tại của tôi (68), điều này vẫn ổn, nhưng nếu LLM và những thứ tương tự xuất hiện vào đầu sự nghiệp của tôi, lúc mới có 5~10 năm kinh nghiệm, có lẽ tôi đã bỏ nghề dịch giả rồi.
  • Câu chuyện dịch thuật thực sự là một chất liệu rất hay cho các cuộc thảo luận về LLM, cảm ơn vì đã chia sẻ kinh nghiệm. Mặt khác, đa số mọi người vốn không đánh giá dịch giả là một giá trị sâu sắc. Ví dụ, gần như chẳng ai nhớ ai là người dịch một cuốn sách. Bây giờ mọi người cũng không còn đọc sách nhiều như trước, nên điều đó càng đúng hơn. Và cũng vì vậy, dịch thuật từ xưa đã luôn có xu hướng được ký hợp đồng/thanh toán theo số từ hoặc số dòng. Nó bị đối xử như một bước kiểm tra cuối cùng, giống như software security. Các mảng dịch thuật thực sự có thể còn sức cạnh tranh trong tương lai có lẽ chỉ là pháp lý, vì con người phải ra tòa hay chịu trách nhiệm, hoặc phiên dịch đồng thời/phiên dịch hiện trường, vì cần gặp mặt trực tiếp và có sự hiện diện thật.
• Dạo này trong cộng đồng công nghệ, tôi thấy người ta đang đẩy quá đà luận điệu rằng "viết code nhanh hơn và năng suất cao hơn" nên cũng hơi khó chịu. Không khí hiện tại quá coi trọng việc cứ ra kết quả thật nhanh. Trong trải nghiệm thực tế của tôi, LLM thường tạo ra code dài dòng, lộn xộn. Tất nhiên nó có thể nhanh hơn tôi, nhưng tôi lại thấy code do mình viết chậm rãi còn tốt hơn nhiều. Cái không khí bây giờ kiểu gì cũng phải chat thật nhanh, ra kết quả thật nhanh, rồi lên production thật nhanh, vốn từng là nguyên nhân khiến các sản phẩm web cẩu thả thời xưa bị tung ra tràn lan. Thay vì chỉ chơi chữ bằng các thuật ngữ nghe kêu như vibe coding/engineering, chúng ta nên nghiêm túc bàn xem tại sao lại cần tốc độ nhanh đến mức chấp nhận chất lượng thấp như vậy, và tại sao bản thân automation/quy trình lại không thể được cải thiện hơn nữa. Ví dụ, có thể tạo unit test rất nhanh, nhưng tôi nghĩ nên hỏi ngược lại rằng ngay từ đầu tại sao lại cần nhiều unit test đến thế. Rõ ràng là chúng cần thiết, nhưng tôi có cảm giác abstraction ở tầng trên đang tiến bộ còn công cụ ở tầng dưới, tức các công cụ chi tiết, lại tiến rất chậm.
  • Vấn đề cốt lõi trong các cuộc tranh luận về software engineering là, dù công cụ và ngôn ngữ có vẻ giống nhau, trên thực tế tồn tại khoảng cách cực lớn về tolerance, security, compliance và tiêu chuẩn maintainability. Có người chỉ cần làm nhanh một prototype đơn giản, nhưng cũng có người xử lý roadmap 10 năm hoặc dữ liệu nhạy cảm. Khi hai góc nhìn này bị trộn lẫn, sẽ đồng thời xuất hiện quan điểm rằng làm ra thật nhanh là năng lực và nỗi lo rằng như vậy sẽ dẫn tới hậu quả kinh khủng. Cả hai phía đều không sai, nhưng tôi thấy bối cảnh công việc thực tế và mức độ rủi ro gần như luôn bị bỏ qua trong các cuộc thảo luận.
  • Thực tế mà nói, LLM đúng là giúp tăng tốc phát triển rất mạnh. Tôi đã code từ năm lớp 5, tức hơn 20 năm rồi, và xung quanh cũng công nhận tốc độ của tôi, nhưng từ khi đưa LLM vào thì quy mô tôi xử lý được đã tăng vọt. Cuộc chơi đã thay đổi hẳn rồi, giờ chỉ còn là chuyện bạn thích nghi được hay không. Tôi cũng có rất nhiều bất mãn với sự bất định của tương lai, nhưng nếu là kỹ sư ở hoàn cảnh tương tự thì tôi hoàn toàn đồng cảm.
  • Tôi muốn thử trình bày lập luận vì sao tốc độ lại quan trọng đến vậy trong phát triển phần mềm. Không phải là tôi chắc chắn đúng hay có dữ liệu thực nghiệm gì, và cách định nghĩa thuật ngữ cũng có thể chưa rõ ràng. Trước hết, có thể xem "phần mềm tầm thường" là loại mà mọi người đều biết rõ giá trị và lời giải của nó, có thể kiểm chứng tự động, hoặc chỉ tồn tại đúng một cách triển khai. Nhưng phần lớn phần mềm ngoài đời là không tầm thường. Ở đó luôn xuất hiện bug, yêu cầu bị thiếu, abstraction bị rò rỉ, tính năng vô dụng, vấn đề tích hợp, hiệu năng, bảo mật, độ phức tạp, và những cơn đau đầu về bảo trì. Dù là dev giỏi cỡ nào, dù code tốt đến đâu, những vấn đề này cũng khó tránh khỏi. Chúng chỉ lộ ra và dần được cải thiện thông qua feedback lặp đi lặp lại, sử dụng thực tế, bảo trì và vô số thử nghiệm. Nói cách khác, không thể làm code hoàn hảo ngay một lần, mà chất lượng chỉ tăng dần qua nhiều vòng lặp. Chất lượng tổng thể của phần mềm bị chi phối bởi số lượng của "vòng lặp phản hồi" này. Thời gian cần để đi hết một vòng sẽ giới hạn tổng số lần lặp có thể thực hiện. Cuối cùng, tôi nghĩ tốc độ sản xuất càng cao thì càng có thể trải qua nhiều feedback loop hơn, và nhờ đó phần mềm tiến hóa thành tốt hơn. Code chậm nhưng chất lượng cao mà chỉ lặp được 1 lần thì cũng có giới hạn; ngược lại, kết quả chất lượng thấp nhưng lặp gần như vô hạn thì có thể đi tới thành quả tốt hơn.
  • 5 năm nữa có lẽ đây sẽ trở thành ví dụ hay nhất thế giới về ngụy biện sunk cost.
• Tôi nghĩ cái tên phù hợp hơn "vibe coding" phải là "agentic coding" hoặc "agentic software engineering". Luồng phát triển của tôi bắt đầu từ code plan của Claude, rồi bước đầu tiên luôn là tạo một spec rõ ràng. Tôi dùng TDD và còn dùng công cụ tự động để cưỡng chế các quy tắc chất lượng code ngầm do mình đặt ra. Ví dụ, nếu lệch khỏi design system thì không thể commit code, và việc tách lớp sao cho HTTP handler bắt buộc phải đi qua service layer cũng được kiểm tra tự động. Tôi cũng thường xuyên nhắc model phải tuân thủ TDD, và Claude 4.5 nhớ điều đó tốt hơn nhiều so với 4.1. Nhờ nền tảng TDD nên việc review code trong PR cũng cực kỳ dễ. Tôi còn tạo một công cụ đơn giản đưa PR và spec cho Gemini để tự động chỉ ra chỗ không khớp, thiếu sót hay lỗi. Nó là một công cụ backup rất tốt. Nhưng rốt cuộc điều quan trọng nhất vẫn là năng lực tự phán đoán kết quả mình muốn là gì và agent đang lệch ở đâu. Cuối cùng vẫn là "garbage in, garbage out; đầu vào chất lượng cao thì đầu ra mới chất lượng cao".
  • Bạn nói là nhắc model về TDD, vậy trong vibe coding thì trên thực tế agent có thật sự lặp đi lặp lại vòng red-green-refactor của TDD không? Hay là nó cứ tạo ra một kết quả hoàn chỉnh trong một mạch?
  • Tôi thấy thay vì gọi là vibe based thì nên gọi là "slop-coding" hơn.
• Tôi nghi ngờ liệu cái tên "vibe engineering" có thật sự phù hợp không. Trên thực tế đây là cách làm đặt lên agent đủ loại ràng buộc như automated testing, lập kế hoạch trước, tài liệu hóa chi tiết, code formatting/lint, manual QA, v.v. Tôi cũng đọc bài của Karpathy rồi bắt đầu vibe coding, ban đầu còn trải nghiệm cái flow cứ tin vào toàn bộ quy trình, kể cả khi code bị kẹt thì chạy lại nhiều lần. Nhưng càng có kinh nghiệm tôi càng nhận ra cuối cùng vẫn phải kiểm soát model. Vận hành agent giống như đua go-kart, cần có nhiều ràng buộc như các hàng lốp quanh đường đua. Constraint Harness mới là cốt lõi, còn bản thân code thì ngày càng dễ tạo và tái tạo. Sau này điều quan trọng sẽ là xây dựng tốt các bài test và các điều kiện ràng buộc cho sản phẩm do AI tạo ra.
  • Cái tên "vibe engineering" nghe quá nhẹ nhàng và không nghiêm túc. Một thuật ngữ trung tính và phản ánh đúng chức năng như "LLM-assisted programming" có phải sẽ tốt hơn không? Dù đúng là kém ấn tượng hơn.
• "Lập kế hoạch trước" cũng có thể gọi là spec-driven development. Thực ra nói ngắn gọn thì mọi phát triển phần mềm đều có thể xem là dựa trên đặc tả từ trước. Tuy nhiên, cốt lõi thật sự là một kiểu "quản lý cực kỳ kỳ lạ", tức đưa ra chỉ thị rõ ràng, đủ ngữ cảnh và phản hồi có thể hành động được. Nếu chỉ nhìn qua văn bản thì nó còn giống waterfall hơn agile.
• Giờ có vẻ như ý nghĩa của vibe-coding đã bị mở rộng thành một thuật ngữ bao trùm toàn bộ việc code dựa trên AI. Trên thực tế, khi làm việc với AI tôi cũng thấy nó giống pair programming hơn và có cảm giác đúng là đang "vibe-ing". Tuy vậy, kiểu vibe-coding nguyên bản như "Take the wheel, LLama of God" tức giao bừa toàn bộ cho nó, chắc vẫn sẽ tiếp tục được dùng rất thường xuyên, nên tôi nghĩ cần một từ mới riêng cho trường hợp đó. Tôi muốn đề xuất “Yolo-Coding”. Nó cũng rất hợp với mạch no-code, low-code, yolo-code.
  • Tôi nghĩ cứ để vibe coder giữ hình ảnh tiêu cực kiểu no-code thì tốt hơn. Tôi cũng không thích cụm vibe engineer, nhưng dù sao về sau cái tên engineer/developer bản thân nó có thể sẽ mặc định bao gồm việc dùng agent, còn kiểu phát triển "thủ công" mới là ngoại lệ.
  • Ở $enterprise, trong lúc cố tìm một cách gọi mới để phân biệt "responsible vibing" với "YOLO vibe coding", cuối cùng chúng tôi đi đến thuật ngữ "agent assisted coding". Vì nhất định phải có một chữ viết tắt 3 ký tự.
  • Ý nghĩa gốc của "vibe coding", đúng như Ilya Sutskever từng đăng trên Twitter, là chỉ đơn giản nhập prompt, rồi copy-paste kết quả ra chạy mà không review gì cả. Không phân tích, không kiểm chứng.
  • Cá nhân tôi xem AI-assisted coding là mức hỗ trợ như autocomplete hoặc giúp đọc tài liệu khó hiểu, còn vibe coding là
  • Dev hoàn toàn không hiểu đoạn code do LLM viết
  • Nợ kỹ thuật phát sinh ngay lập tức vì không có code review
  • Về pháp lý thì cực kỳ mong manh ở EU/US do các vấn đề bảo hộ bản quyền Tôi nghĩ điểm chí mạng lớn nhất của vibe coding là code do LLM tạo ra về bản chất không thể được bảo hộ/đăng ký bản quyền. Dù có vài ngoại lệ như Anh, ở phần lớn quốc gia gần như không có lối thoát.
  • Tôi cũng từng tạo slash command kiểu /yolo cho claude để cứ thế chạy mà không cần hướng dẫn gì đặc biệt.
• Có một thí nghiệm nơi chim bồ câu tương tác với một thiết bị có thể nhả thức ăn ngẫu nhiên; chúng tưởng rằng phần thưởng đến từ hành động của mình nên cứ lặp đi lặp lại đủ kiểu điệu nhảy và động tác buồn cười.
  • Biết đâu mấy điệu nhảy vui nhộn đó lại chính là thứ rất giống với "viết test" hay "lập kế hoạch".
  • Có ai có bài báo hay nghiên cứu nào làm căn cứ không? Tôi thử tìm kiểu "chim bồ câu biểu diễn trò" thì chỉ ra toàn video mạng xã hội nên khó tìm quá.
• Tôi thấy cái tên "Augmented Engineering" (AE) hay hơn. Vì nhờ sức mạnh của AI mà năng lực có thể được mở rộng và tạo ra kết quả tốt nhất, nên gọi là "kỹ thuật tăng cường". AE cũng có thể hiểu là "Advanced Engineering". Vì AI cho phép ngay lập tức tiếp cận tri thức công nghệ mới nhất, nên đương nhiên đó cũng là một dạng engineering tiên tiến hơn. Còn vibe thì không ổn lắm.
  • Không cần quá bận tâm về thuật ngữ, vì nếu đặt tên riêng thì ngược lại sẽ làm người ta cảm thấy code bằng AI chỉ áp dụng cho một bộ phận dev. Sau này kiểu code truyền thống mới là trường hợp ngoại lệ, và từ vibe hiện tại cũng sẽ sớm biến mất.
  • Tôi phản đối câu cuối. AI không chỉ giúp tiếp cận ngay lập tức kiến thức engineering mới nhất, mà còn có nguy cơ "hấp thụ ngay lập tức" cả những sai lầm, lỗi, hiểu nhầm và thiết kế tệ lặp đi lặp lại suốt 1~10 năm gần đây. Tức là tuyệt đối không được tin thông tin do AI cung cấp một cách thiếu phê phán; luôn phải kiểm tra nguồn, và thậm chí còn phải kiểm tra xem chính nguồn đó có phải do AI tạo ra hay không. Dataset đang ngày càng bị ô nhiễm nên càng phải cẩn thận hơn.
  • Tôi muốn hỏi liệu "Augmented Engineering" có nhất thiết phải là một cái tên riêng không. Thực ra nó cứ là "engineering" thôi, cũng như không ai gọi việc làm cùng sách tham khảo là "book-assisted engineering". Vibe cũng vậy. Thậm chí có thể gọi là "Yolo engineering", hay "Machine Outsourced Irresponsible LMAO Engineering" cũng được. Còn cái "Advanced Engineering" cuối cùng nghe cũng hơi phóng đại.
• Simon lúc nào cũng nắm trúng trọng tâm. Nhưng vấn đề thật sự là từ "vibe" chứ không phải "coding". Dù đổi thành vibe engineering thì nó vẫn mang sắc thái là "cứ lao vào làm mà chẳng hiểu mình đang làm gì". Xét như vậy thì một thuật ngữ như "AI-assisted software engineering", vốn phân biệt rõ hai đầu của phổ, có lẽ vẫn tốt hơn.

[kimjoin2]

Tạo ra những cách gọi vô nghĩa;