Từ phản đối đến Vibe coding: Vì sao các nhà phát triển đang đổi ý về AI?

Từ phản đối đến Vibe coding: Vì sao các nhà phát triển đang đổi ý về AI?

[00:00] Có một điều thế này: tôi đã muốn làm video này từ lâu, nhưng cứ trì hoãn vì nghĩ mình sẽ nhận được rất nhiều phản ứng phản đối. Vì vậy, trước khi đi vào nội dung chính, hãy cho tôi nói rõ vài điều.

[00:00] Trước hết, tôi là người hoài nghi LLM, chủ yếu vì tôi ghét các chiến lược marketing gây hiểu lầm của Sam và Dario, cũng như những lời nói dối trắng trợn mà họ dùng để thúc đẩy sản phẩm. Ý tôi là, LLM hiện đã đủ tốt, nên chúng ta không cần giả vờ rằng chúng là một dạng siêu trí tuệ giống như thần thánh.

[00:00] Tôi cũng ghét hướng đi có vẻ như ngành công nghiệp đang theo đuổi, khi mọi người kiểm tra với Claude hoặc ChatGPT trước khi đưa ra bất kỳ quyết định cơ bản hay thực hiện hành động nhỏ nhặt nào. Cứ gọi tôi là điên, nhưng tôi thuộc kiểu người cổ điển cho rằng bạn phải có khả năng viết một email dài hai đoạn mà không cần nhờ Claw hoàn thành từng câu.

[00:00] Quan trọng hơn, khi nói đến code, tôi tin rằng quyền sở hữu vẫn rất quan trọng. Nói cách khác, bất kể bạn dùng phương pháp nào để viết code, bạn vẫn chịu trách nhiệm cho thứ mình phát hành. Bạn phải hiểu nó và có toàn quyền kiểm soát những gì mình đưa ra trước các khách hàng trả tiền.

[00:00] Vì vậy, tôi thực sự phát điên khi nghe mọi người nói rằng họ không còn đọc code nữa, hoặc họ đặt niềm tin vào một vòng lặp phức tạp nào đó vừa đóng vai trò nhà phát triển phần mềm, vừa đóng vai trò chuyên gia review phần mềm.

[00:00] Tuy nhiên, bất kể cảm xúc hay quan điểm cá nhân của tôi về AI là gì, thực tế là nhiều tên tuổi lớn trong ngành—những người từng khá thận trọng với AI-generated code—đang thay đổi lập trường. Và tôi nghĩ chúng ta thực sự nên bàn về chuyện này.

[00:00] Nếu đã theo dõi tôi một thời gian, có lẽ bạn biết rằng tôi không giả vờ biết ngành công nghiệp sẽ đi về đâu và luôn cố tránh các thái cực. Vì thế, tôi không chắc những người này có thực sự đúng hay không, nhưng họ có thành tích thành công, nên ít nhất chúng ta cũng nên lắng nghe họ.

Notch và sự thay đổi lập trường đáng kinh ngạc

[00:01] Người đầu tiên trong danh sách là Marcos Pson, được biết đến nhiều hơn với tên Notch, nhà sáng tạo Minecraft.

[00:01] Vào đầu năm, Notch gần như ở vị trí đối lập hoàn toàn với niềm tin vào AI coding. Ông lập luận rằng lập trình là về logic, không phải việc gõ phím, và nói rằng bất kỳ ai thúc đẩy AI-generated code либо là bất tài, либо là xấu xa.

[00:01] Vài tháng sau, vào tháng 7, ông đăng một thông điệp rất đơn giản: “Phản đối AI”. Nhưng chỉ một tuần sau, ông quyết định thử Vibe coding.

[00:01] Có vẻ như việc tìm lập trình viên giỏi cho trò chơi của mình đang trở nên khó khăn. Và như ông nói, ông sẽ cảm thấy đỡ áy náy hơn khi sa thải một chatbot.

[00:02] Chỉ vài tuần sau đó, ông chia sẻ các thử nghiệm với Cloud và thừa nhận rằng có thể mình đã sai. Sau thêm vài thử nghiệm, ông kết luận rằng mình đang tận hưởng Vibe coding và việc lập trình đã được giải quyết phần nào.

[00:02] Nếu thành thật mà nói, đó là một sự thay đổi quan điểm khá ngoạn mục chỉ trong một mùa hè.

[00:02] Tuy nhiên, cần lưu ý rằng ông vẫn tin nền tảng là quan trọng, các nhà phát triển vẫn nên học coding, và ông lo mình sẽ trở thành quản lý cấp trung thay vì một nhà phát triển.

[00:02] Đây là một nỗi lo chính đáng, và hầu hết chúng ta đều sợ rằng đó sẽ là kết quả của việc thêm LLM vào quy trình làm việc. Viết code là phần thú vị. Đọc hàng đống code rác thì không.

Code review và gánh nặng của code do AI tạo ra

[00:02] Trong một cuộc phỏng vấn gần đây, Martin Odersky, người tạo ra Scala, cho rằng yêu cầu các kỹ sư review hàng núi code do AI tạo ra là một nhiệm vụ bất khả thi.

[00:02] Việc phải đọc và chịu trách nhiệm với hàng đống code được tạo ra có lẽ là thay đổi lớn nhất trong công việc của chúng ta hiện nay. Và đó thực sự là một việc vắt kiệt tinh thần.

[00:03] Đó là lý do mọi người nghĩ ra những vòng lặp code review điên rồ, hoặc đơn giản là hoàn toàn bỏ cuộc, không đọc code nữa.

[00:03] Câu trả lời của Odersky là chú trọng hơn vào các interface và type, đồng thời cung cấp cho AI một contract mà con người có thể hiểu và review, sau đó để ngôn ngữ thực thi contract đó.

[00:03] Nhưng ông cũng nói rằng type system hiện nay vẫn để lại quá nhiều lối thoát, bởi một phép cast hoặc truy cập bộ nhớ không an toàn có thể phá hoại sự bảo đảm đó. Vì vậy, chỉ riêng type mạnh hơn sẽ không giải quyết được vấn đề.

[00:03] Odersky muốn các lập trình viên định nghĩa yêu cầu chính xác hơn và sử dụng capabilities để giới hạn những gì code được tạo ra có thể truy cập, bao gồm file và secret. Ông cũng nói rõ rằng chúng ta vẫn chưa đạt đến mức đó.

[00:03] Vì vậy, với một số tiếng nói hàng đầu trong ngành, công việc kỹ sư phần mềm đang biến thành một công việc quản lý cấp trung vô hồn, nơi bạn dành cả ngày viết documentation và đọc code quá phức tạp. Thật vui biết bao.

DHH và việc giao bàn phím cho AI

[00:03] Nhưng một số người có lập trường cực đoan hơn nhiều về LLM coding.

[00:03] Năm ngoái, DHH viết rằng ông yêu thích việc viết Ruby và thà nghỉ hưu còn hơn vĩnh viễn giao bàn phím cho AI. Khi đó, ông đã dùng LLM để tra cứu và thảo luận ý tưởng, nhưng việc thực sự viết code là phần công việc ông muốn giữ lại.

[00:04] Sau đó, vài ngày trước, ông bước lên sân khấu tại Rails World và thông báo rằng 37signals đã “pencils down”. Giờ đây, ông nói việc viết code bằng tay là một trạng thái đặc biệt tại công ty, và nếu một agent không tạo ra được thứ họ cần, mục tiêu là sửa quy trình để agent có thể làm được vào lần sau.

[00:04] Nói cách khác, nếu agent thất bại thì chắc chắn đó là vấn đề về kỹ năng của con người.

[00:04] Ông cũng mô tả kế hoạch xây dựng lại Hey bằng các ứng dụng native và tất nhiên là một back end Rust.

[00:04] Làm ơn, vì tình yêu của Chúa, ai đó có thể giải thích cho tôi tại sao mọi bản rewrite do LLM dẫn dắt cuối cùng đều chuyển sang Rust không?

[00:04] Điều đáng lo và cũng buồn cười ở thời điểm này là DHH nói ông ghét nhìn vào Rust, không biết ngôn ngữ này, và xem đó là một lợi thế thực sự.

[00:04] Vì vậy, trong tương lai, lựa chọn thông minh là xây dựng sản phẩm bằng một tech stack mà bạn không thực sự biết, tốt nhất là còn ghét nó. Đây được xem là lời khuyên hợp lý, sáng suốt vào năm 2026.

[00:04] Nhân tiện, David nói rằng vì bạn không quen với tech stack, bạn có thể nói cho agent biết mình muốn gì và đánh giá kết quả từ bên ngoài.

[00:05] Như vậy, việc xây dựng phần mềm vào năm 2026 dựa trên câu “nhìn bên ngoài thì có vẻ ổn” và “cứ tin tôi đi” ở bên trong.

Bài học từ Basecamp 5

[00:05] Ngoài toàn bộ tiếng ồn xung quanh LLM, có một chi tiết nhỏ trong bài keynote của ông đáng được chú ý hơn.

[00:05] DHH nói rằng đầu năm nay, các designer tại 37signals đã sử dụng AI để xây dựng các tính năng cho Basecamp 5. Từng pull request riêng lẻ trông có vẻ hợp lý, nhưng khi ghép toàn bộ code lại, họ nhận được một architecture tệ đến mức đội ngũ buộc phải quay lại review thủ công toàn bộ công việc.

[00:05] Tạo ra code ban đầu trông có vẻ ổn nhưng cuối cùng lại trở thành một nỗi đau là trải nghiệm khá phổ biến với hầu hết chúng ta.

[00:05] Và tôi nghĩ bất kỳ người hợp lý nào cũng sẽ tránh đưa ra lập trường cực đoan về coding trong bối cảnh này. Tuy nhiên, DHH cho rằng như vậy là đủ tốt để đặt tương lai các công ty của mình vào LLM.

Linus Torvalds và quan điểm thực dụng

[00:05] Linus Torvalds là một ví dụ nổi tiếng khác, dù lập trường của ông có nhiều sắc thái hơn.

[00:05] Ông bắt đầu thử nghiệm việc tạo code bằng LLM từ tháng 1 và các thử nghiệm ban đầu khá thành công. Ông cũng nói khá tích cực về Vibe coding như một cách để mọi người học hỏi và tạo ra những thứ mà nếu không có nó, họ sẽ không thể làm được.

[00:06] Nhưng ông cũng gọi đó là một ý tưởng khủng khiếp xét từ góc độ bảo trì nếu bạn đang xây dựng một sản phẩm thực sự.

[00:06] Đến tháng 7, tranh luận xuất hiện trên mailing list của Linux kernel, nơi một số người muốn dự án từ chối các công cụ AI. Linus không chấp nhận điều đó. Ông nói Linux không phải là một dự án chống AI; nếu ai đó có vấn đề với chuyện này, họ có thể fork dự án hoặc rời đi.

[00:06] Nói rõ hơn, điều đó không có nghĩa Linus đang để các agent Vibe code kernel. Cuộc thảo luận một phần xoay quanh các công cụ AI review code và báo cáo bug. Ông nói việc sử dụng chúng nên được đánh giá dựa trên giá trị kỹ thuật.

[00:06] Suy cho cùng, có sự khác biệt giữa việc dùng AI cho một Python script mà bạn hầu như không quan tâm và bảo vệ vị trí của AI trong quá trình phát triển Linux.

Salvatore Sanfilippo và giới hạn của việc tự động hóa

[00:06] Nhưng một số người còn muốn tiến xa hơn Linus. Chẳng hạn, Salvatore Sanfilippo, người tạo ra Radius, đã viết về coding với LLM từ năm 2024 và là một người thực sự tin tưởng công nghệ này.

[00:06] Vì vậy, đúng như dự đoán, ông cho rằng các nhà phát triển có thể lãng phí rất nhiều thời gian khi đọc code được tạo ra từng dòng một. Theo quan điểm của ông, thứ các nhà phát triển cần kiểm soát là thiết kế.

[00:07] Nói cách khác, chúng ta nên tập trung vào phần mềm làm gì, nó hoạt động ra sao và nó có chính xác hay không.

[00:07] Nếu bạn đang sử dụng Radius trong production, có lẽ bạn hy vọng ông ấy vẫn thực sự đọc code trước khi phát hành phiên bản mới. Suy cho cùng, thật điên rồ khi biết rằng cuối tuần của bạn có thể bị phá hỏng bởi một sự cố production do một LLM agent làm hỏng công cụ bên thứ ba mà bạn đang phụ thuộc vào.

[00:07] Và đây mới là phần buồn cười. Khi thực sự cần xây dựng một kiểu array mới cho Radius vào đầu năm nay, Sanfilippo đã dành khoảng bốn tháng cho công việc đó.

[00:07] Ông viết một specification chi tiết, trao đổi về thiết kế với các LLM, sau đó đọc code được tạo ra từng dòng một. Ông phát hiện những điểm kém hiệu quả và các lựa chọn thiết kế mình không thích, thay đổi chúng rồi stress test kết quả.

[00:07] Kết luận của ông khi đó là: với system programming chất lượng cao, bạn vẫn phải tham gia đầy đủ.

Kết luận: Quyền sở hữu vẫn thuộc về con người

[00:07] Vì vậy, tôi lại đi đến kết luận cũ mà mình đã nhắc đến trong vài tháng qua.

[00:07] Nếu bạn không quan tâm đến kết quả cuối cùng, bạn có thể Vibe code, bởi khả năng cao là sẽ chẳng có ai sử dụng nó. Tuy nhiên, nếu sinh kế của bạn phụ thuộc vào nó, ít nhất là ở thời điểm hiện tại, bạn cần tham gia và sở hữu kết quả.

[00:08] Tuy nhiên, tôi sẵn sàng trở thành một người hoàn toàn tin tưởng AI và công khai tuyên bố rằng coding đã được giải quyết, việc sử dụng máy tính đã được giải quyết, thậm chí cuộc sống đã được giải quyết, ngay khi một công ty AI lớn nào đó rót một ít tiền về phía tôi.

[00:08] Cho đến lúc đó, đừng quên thích và đăng ký vì điều đó giúp ích rất nhiều. Hẹn gặp lại lần sau, cảm ơn bạn đã xem.