Nếu định vibe coding thì sao không làm bằng C luôn?
(stephenramsay.net)- Vibe coding thực sự hoạt động tốt, nhưng nó tạo ra mã mà chính tác giả cũng không tự hiểu hết, từ đó làm giảm đi niềm vui cốt lõi của việc lập trình
- Mọi ngôn ngữ lập trình đều là công cụ được thiết kế vì sự thuận tiện của con người chứ không phải của máy móc; những ưu điểm như an toàn, trừu tượng hóa và khả năng đọc hiểu rốt cuộc cũng chỉ là cấu trúc phục vụ tư duy của con người
- Vậy thì mã do AI viết có nhất thiết phải cần ngôn ngữ thân thiện với con người không?, bài viết đề xuất một ngôn ngữ mới thân thiện với máy và lấy AI làm trung tâm là VOPL(Vibe-Oriented Programming Language)
- Ngôn ngữ này có thể bao hàm nhiều khả năng khác nhau như giả mã có thể thực thi, phần mở rộng của lập trình văn chương, hoặc một dạng cú pháp cụ thể dựa trên ngôn ngữ tự nhiên
- Cũng như thời kỳ đầu của máy tính chương trình lưu trữ, sự kháng cự với các mô hình tính toán mới là lịch sử lặp lại nhiều lần; vibe coding cũng có thể là bước tiếp theo của dòng chảy đó
Sự căng thẳng giữa lập trình và vibe coding
- Với tôi, lập trình là niềm vui chứ không phải công việc, là đam mê kéo dài từ cuối những năm 1990
- Tôi đã dạy lập trình suốt 25 năm, và điều khiến tôi tự hào nhất là biến những người không học chuyên ngành thành lập trình viên
- Khi lập trình, tôi coi trọng niềm vui tự mình hiểu ra trong quá trình giải quyết vấn đề
- Ngược lại, vibe coding là quá trình AI viết mã thay cho con người, dẫn tới trạng thái mà người viết không hiểu trọn vẹn kết quả
- Nó có cảm giác như đang “gian lận” (dù không hẳn chỉ là vậy), và tạo ra một sự khó chịu rất khó diễn tả chính xác
- Có cảm giác nó lấy đi khá nhiều niềm vui của chính việc code
- Dù vậy, vibe coding hoạt động tốt đến mức có thể tạo ra các hệ thống thực tế với chất lượng cao
- Nó không chỉ dừng ở mức thay thế tìm kiếm, mà còn giải quyết chính xác cả những vấn đề mà ta lười tự xử lý
- AI thành thạo hơn con người trong việc lần vết lỗi và quản lý bộ nhớ, và mỗi lần ném một ý tưởng chương trình cho AI thì kết quả tạo ra lại khiến người ta ngạc nhiên
Ngôn ngữ vốn là công cụ dành cho con người
- Như trong Structure and Interpretation of Computer Programs của Abelson & Sussman, ngôn ngữ lập trình là phương tiện biểu đạt cho con người
- Mã là “thứ để con người đọc”, còn máy móc thì không cần khả năng đọc hiểu đó
- Mọi ngôn ngữ lập trình đều được thiết kế như một môi trường giúp con người tư duy và biểu đạt
- Tính an toàn của Rust, khả năng trừu tượng hóa của C++, hay tính đồng thời của Go đều là các tính năng vì sự thuận tiện của con người chứ không phải của máy
- Quản lý bộ nhớ, đồng thời, ổn định kiểu dữ liệu đều chỉ là những lớp trừu tượng để hỗ trợ cấu trúc tư duy của con người
- Vì vậy, trong thời đại AI viết mã, thiết kế ngôn ngữ lấy con người làm trung tâm có thể trở nên không còn cần thiết
Vậy AI có cần kiểu ngôn ngữ này không? : Ý nghĩa của đề xuất “hãy vibe coding bằng C”
- Khi vibe coding, con người đã viết chương trình trong trạng thái không thể hiểu trọn vẹn toàn bộ mã nguồn
- Trong tình huống đó, lý do để duy trì cú pháp thân thiện với con người trở nên yếu đi
- Thay vì ngôn ngữ thân thiện với con người, có thể hợp lý hơn khi viết trực tiếp bằng ngôn ngữ thân thiện với máy (C hoặc assembly)
- AI có thể quản lý tinh vi hơn con người các vấn đề như undefined behavior của C, giải phóng bộ nhớ hay off-by-one
- Cũng như compiler tối ưu hóa tốt hơn, AI thể hiện khả năng quản lý việc thực thi mã chính xác hơn con người
- Vậy câu hỏi đặt ra là: có cần một ngôn ngữ phù hợp hơn cho AI sử dụng không?
- Tại sao lại nhất thiết phải vibe coding bằng những ngôn ngữ “lấy con người làm trung tâm” như Python, Rust hay C++?
Đề xuất VOPL(Vibe-Oriented Programming Language)
- Nếu giả định một ngôn ngữ dành riêng cho vibe coding, có thể hình dung ra các khả năng như sau
- Một ngôn ngữ siêu cấp cao gần với giả mã có thể thực thi
- Giống như phiên bản hoàn chỉnh của lập trình văn chương, nơi con người chỉ mô tả còn AI sinh ra mã máy
- Một cấu trúc trông giống ngôn ngữ tự nhiên nhưng có những “thành ngữ” riêng
- Những khái niệm như cách diễn đạt đồng thời bằng tiếng lóng dựa trên từ ngữ đời thường thay cho “goroutine”
- Hướng đi là thiết kế một hệ biểu đạt lấy máy làm trung tâm để AI có thể hiểu chính xác vấn đề và nhanh chóng tạo ra mã thực thi
- Dù vẫn tồn tại bài toán phải huấn luyện AI với ngôn ngữ mới, nhưng hiện nay đã có rất nhiều lập trình viên ném giả mã cho AI và tạo mã theo kiểu đối thoại
nên cũng có khả năng một dạng VOPL nào đó đã và đang được học từ trước
Sự thay đổi của hành vi lập trình
- Việc “tự tay code” trong tương lai có thể bị xem như một dạng giáo dục nền tảng kiểu Montessori trong đào tạo vibe coder
- Cũng giống như luyện vẽ tay trước thời Photoshop, hay luyện giải phương trình trên giấy vẫn còn trong chương trình học dù đã có máy tính điện tử
- Sự kháng cự trước sự xuất hiện của những mô hình mới đã lặp lại nhiều lần trong lịch sử
- Ví dụ về sự phản đối thời kỳ đầu đưa máy tính chương trình lưu trữ vào sử dụng (ENIAC → EDVAC)
- Ngay cả Grace Hopper cũng từng phải đấu tranh với lời chỉ trích rằng “máy không thể viết lệnh cho máy”
Thông điệp kết luận
- Vibe coding đã là hiện thực, và tương lai phát triển phần mềm có thể sẽ đòi hỏi thiết kế lại chính ngôn ngữ
- Đã đến lúc nghiêm túc thảo luận về khả năng chuyển từ ngôn ngữ lấy con người làm trung tâm sang ngôn ngữ lấy AI làm trung tâm
“Same vibe, as the kids say.” — Nói theo cách của giới trẻ bây giờ thì đúng là cùng một vibe
4 bình luận
Nếu định coding kiểu vibe thì sao không làm bằng C đi?
Tin rằng khi code bằng mô hình ngôn ngữ thì nó sẽ tự hiểu và thần kỳ tạo ra những biểu đạt gần với máy móc, đúng là tâm lý của kẻ muốn ăn không ngồi rồi.
Càng bị ràng buộc thì lại càng làm việc tốt trong phạm vi những ràng buộc đó.
Dù AI có viết mã đi nữa, trách nhiệm đối với dịch vụ vẫn là của lập trình viên. Tôi không chắc liệu họ có thể chịu trách nhiệm với đoạn mã mà bản thân không thể hiểu được hay không.
"Ngay cả khi làm vibe coding, nếu muốn có thể rà soát kết quả thì nên làm bằng ngôn ngữ mình hiểu rõ."
Có một câu cực kỳ quan trọng trong phần bình luận.
Ý kiến trên Hacker News
Một lần nữa thấy rằng công việc phát triển phần mềm thật sự rất đa dạng
Tôi làm backend, đặc biệt là phát triển API, và nút thắt lớn nhất của năng suất là đa số mọi người không thể định nghĩa yêu cầu cho đúng
Hỏi PM thì họ né tránh, còn lập trình viên frontend thì chờ backend đưa API
Cuối cùng, phần khó nhất không phải là viết code mà là quá trình tư duy để khám phá và diễn giải yêu cầu
Lập trình thực sự là hành vi hiện thực hóa hệ thống do chính mình thiết kế và thổi sự sống vào nó
Nếu chỉ xem việc viết code trong công ty là ‘Programming’ thì sẽ nảy sinh hiểu lầm
Tuy nhiên có lẽ ông ấy không có nhiều kinh nghiệm phát triển phần mềm thương mại quy mô lớn
Dự đoán của ông về “tương lai của lập trình” rất hay, nhưng trong bối cảnh công nghiệp thì có thể hơi hạn chế
(tham khảo: Giới thiệu về Stephen Ramsay)
Cuối cùng điều quan trọng là mindset và mức độ tiếp xúc với công nghệ
LLM đã tăng năng suất của tôi rất nhiều — đặc biệt với người có tư duy kiến trúc như tôi
Những thứ trước đây mất vài tháng thì giờ làm trong vài tiếng
Dạo này tôi đang dùng LLM để dịch mã Shockwave Lingo cũ sang ngôn ngữ hiện đại nhằm khôi phục game legacy
Cuối cùng, nếu vibe coding là tương lai, thì điều đó mặc nhiên bao hàm tiền đề rằng AI chưa hoàn hảo
Khoảnh khắc ta tùy ý đặt ra năng lực và giới hạn cho AI trong tưởng tượng, bản thân cuộc thảo luận đã trở nên mơ hồ
Phải họp với các bên liên quan bốn năm lần mới làm rõ được
Tôi đã thử vibe coding bằng C, nhưng vẫn ghét C
AI quên giải phóng bộ nhớ như con người rồi sửa lại sau
Làm bằng Rust thì vui hơn nhiều, và hiểu được hệ sinh thái phụ thuộc của ngôn ngữ mới là năng lực thật sự
AI giúp tra cứu nhanh kiểu ‘kiến thức sách vở’ này
Với C thì phải kiểm tra từng chỗ xem đã giải phóng bộ nhớ chưa, còn Rust thì gần như không phải lo chuyện đó
Dù có vibe coding đi nữa, tôi vẫn nghĩ Rust tốt hơn hẳn vì có cơ chế an toàn của ngôn ngữ
Những tính năng thân thiện với con người của Python cũng giúp ích cho AI
Giờ nhờ AI mà việc tự làm UI hay utility mới trở nên dễ hơn,
và cũng đơn giản để chỉ hiện thực đoạn cần hiệu năng bằng C++
Nếu tự debug bằng GDB thì chắc đã mất nhiều thời gian hơn
Nó thay tôi xử lý những phần khó chịu như thao tác chuỗi hay quản lý con trỏ nên khá hài lòng
Mã do compiler tạo ra lúc nào cũng hiệu quả hơn, nhưng tôi đang dùng các lỗi của AI như cơ hội học tập
Ngay cả với LLM chạy cục bộ cũng có thể tự động hóa việc kiểm chứng như giải phóng bộ nhớ
Gần đây có một cuộc thảo luận tên là “Why AI Needs Hard Rules, Not Vibe Checks”
(liên kết)
Lý do Rust phù hợp với vibe coding là nhờ các tính năng kiểm chứng miễn phí như bảo đảm về kiểu và vòng đời
Nếu không có những kiểm chứng này, LLM rất dễ tạo ra mã không an toàn
Trừu tượng hóa là thứ không chỉ con người mà cả LLM cũng cần
Một ngôn ngữ mà mọi hàm, biến, kiểu và ngoại lệ đều phải được đặc tả nghiêm ngặt
Có thể bất tiện khi viết, nhưng sẽ là cấu trúc dễ đọc và dễ kiểm chứng
Nó bàn về khó khăn của việc dịch sao cho bảo toàn ý đồ chứ không chỉ đường đi khi thực thi của mã
Các công cụ như Shellcheck cũng có thể biến người mới thành chuyên gia
Muốn cải thiện bằng RL thì phải có khả năng tự động đánh giá tính nhất quán của mã
Cần nhìn lại các ngôn ngữ dựa trên logic như Prolog
Nếu LLM tạo ra mã đầy bug, thì đổi ngôn ngữ kết quả cũng tương tự
Ban đầu vibe coding rất ấn tượng, nhưng chẳng mấy chốc vòng lặp sửa liên tục làm đầu óc kiệt quệ
Nó cướp mất khả năng tập trung giống như lướt feed thuật toán
Giờ tôi tự code, chỉ giao phần nhàm chán cho ChatGPT
Với lại cũng chẳng học được gì
Làm vậy giúp làm rõ yêu cầu và cũng dễ chuyển sang AI khác hơn
Tôi nghi ngờ LLM có thể tạo ra mã C không rò rỉ bộ nhớ
Đây là lĩnh vực mà cả lập trình viên con người cũng hay sai, nên LLM với chất lượng dữ liệu huấn luyện thấp còn nguy hiểm hơn
Nếu tạo một chương trình bị segfault bằng vibe coding thì đó chỉ là lãng phí thời gian
Gần như không bị hỏng và luôn compile được
Con người thì mệt nhưng LLM thì không
Nếu huấn luyện lại bằng code C tốt thì vẫn có dư địa cải thiện
AI tránh được undefined behavior trong C ư? Khó mà tin nổi
Nếu mô hình được huấn luyện để mắc lỗi như con người thì khả năng cao cũng sẽ sinh ra những bug tương tự
Vì chúng dự đoán token có xác suất cao nhất nên ít mắc những lỗi phổ biến hơn
Nó cũng tìm rất tốt nguyên nhân gây crash
Những ngôn ngữ hiện đại như Zig hay Rust tốt hơn nhiều
Lý do vibe coding khiến tôi không thoải mái không chỉ vì nó giống như ‘gian lận’
Lập trình là một nghệ thuật có linh hồn
Cách mỗi người giải quyết vấn đề đều khác nhau, và đó chính là sự sáng tạo
Vibe coding tạo cảm giác như cỗ máy đang hấp thụ sự sáng tạo đó
Cuối cùng cả suy nghĩ, quyết định lẫn sai lầm đều do máy làm thay
Đã có đề xuất tạo ra “vibe-oriented programming language(VOP)”
Nhưng nếu là ngôn ngữ dành cho LLM thì ngược lại nó phải nghiêm ngặt và dài dòng
Nếu không ghi rõ mọi điều kiện và ngoại lệ thì không được phép compile
Bất tiện với con người, nhưng với LLM lại có ưu điểm là giảm bối rối
Cần một cấu trúc nơi con người giải thích khái niệm, rồi AI chuyển nó thành code
Một khi đã compile thì gần như lúc nào cũng chạy đúng
Dù có vibe coding thì cũng nên làm bằng ngôn ngữ mà mình hiểu rõ để còn review được kết quả
Nếu không thì có khi cứ thử nghiệm bằng brainfuck còn hơn
Với câu hỏi “Thế thử bằng assembly x86 xem?” thì,
tôi từ chối vì “tôi phải có khả năng tự review và mở rộng nó”
Vibe coding thuần túy chỉ là thí nghiệm tư duy, không phải mục tiêu thực tế
Có thể một ngày nào đó AI sẽ lo luôn cả QA, nhưng hiện tại ngôn ngữ an toàn và sự kiểm chứng của con người vẫn là bắt buộc
Chắc là tôi đã làm nghề đủ lâu để thấy những cuộc tranh luận kiểu này trở nên mệt mỏi