Tôi đồng ý rằng vibe coding phù hợp với khung tiêu dùng. Tôi thấy nó giống như phiên bản lập trình của trào lưu gần đây là Temu-kkang, Ali-kkang (https://www.asiae.co.kr/article/2024053117460950053).
Nhưng nếu nói rằng khung tiêu dùng là cách để không lặp lại thất bại của phong trào maker, thì tôi không thể đồng ý ở nhiều khía cạnh, giống như bình luận trên HN.
Vibe coding đang tiếp nối lịch sử của các nhà phát triển công dân.
Giờ đây, tôi cho rằng vibe coding đang tiến tới việc biến lập trình trở thành thứ dễ dàng, nhanh chóng và thiết yếu như điện.
Ngay lúc này, ngay cả những lập trình viên thiên tài ở vô số doanh nghiệp cũng đang tiếp tục lập trình bằng prompt và agent mà không cần viết dù chỉ một dòng code.
Dù cũng có những người cố hạ thấp điều này, nhưng tôi nghĩ rất khó để phản bác rằng vibe coding của Andrej Karpathy là một cột mốc ghi dấu trong lịch sử máy tính.
Câu hỏi rất hay. Thực ra, điều kiện “hybrid” trong thí nghiệm của chúng tôi chính xác là theo hướng đó — cấu hình cung cấp đồng thời phần tóm tắt đã được sắp xếp và nhật ký trải nghiệm thô.
Kết quả là hybrid cao nhất, đạt 4.95/5.0. Nếu chỉ đưa phần tóm tắt thì là 2.65, nhưng khi gắn thêm các ghi chép quá trình như “thất bại”, “không rõ nguyên nhân” thì điểm yếu của phần tóm tắt lại được bù đắp.
Vì vậy, kết luận là “không phải bản thân phần tóm tắt là xấu, mà là cần chứa cả quá trình và sự bất định cùng nhau”.
Tuy nhiên, vì N=1 nên vẫn cần nghiên cứu tiếp theo để xác định liệu nội dung này có thể được dùng một cách phổ quát cho nhiều nhóm người dùng khác nhau hay không.
Vậy nếu cấu hình để bộ nhớ tổng hợp chứa quy trình của những tác vụ đó, cùng với nội dung về thất bại và thành công, thì liệu kết quả có khác đi không?
Đúng vậy. Ban đầu tôi cũng nghĩ rằng ít nhất thì bộ nhớ tổng hợp sẽ tốt hơn mức cơ sở, nhưng khi thấy kết quả tôi đã rất ngạc nhiên.
Phân tích kỹ thì điểm mấu chốt là việc "bảo toàn tính bất định". Trong log thô vẫn còn lại những dấu vết như "đã thử cái này nhưng không được", "không rõ nguyên nhân", nên agent sẽ trả lời rằng điều gì không biết thì là không biết; còn bản tóm tắt thì lại xóa sạch toàn bộ ngữ cảnh đó, khiến agent ngược lại đưa ra câu trả lời sai với sự tự tin.
Thú vị đấy, nhưng cũng có cảm giác phải chăng họ chỉ tiến hóa theo hướng dùng thật nhiều token của mình để thu phí cao hơn; và thực ra cũng có cảm giác ở một mức độ nào đó, AI đã được huấn luyện trên các thư viện nên nó chỉ việc tạo ra như vậy thôi.
Nghĩ đến chuyện chỉ một số thư viện nhất định sẽ phát triển vì được agent ưa chuộng thì cũng thấy hơi kỳ lạ.
Rốt cuộc thì việc Bộ Quốc phòng Mỹ bỏ Anthropic và chọn OpenAI, nhưng cách diễn đạt thường thấy lại có sự khác biệt.
OpenAI cùng đề xuất cơ chế triển khai cụ thể như xây dựng các biện pháp an toàn kỹ thuật, đưa FDE (kỹ sư hiện trường) vào, và triển khai chuyên dụng trên đám mây
Anthropic thì yêu cầu điều khoản ngoại lệ ở mức điều khoản sử dụng
Từ góc nhìn của Bộ Quốc phòng Mỹ, điều đó bị xem là "một doanh nghiệp tư nhân thực hiện quyền phủ quyết đối với từng trường hợp sử dụng riêng lẻ", nên họ công bố theo kiểu như muốn dằn mặt.
Thỏa thuận này được công bố không lâu sau khi Anthropic bị chỉ định là rủi ro chuỗi cung ứng, nếu nhìn bài của Axios thì Bộ Quốc phòng đã tận dụng cuộc đối đầu với Anthropic để thiết lập tông giọng trong các cuộc đàm phán với những công ty AI khác,
và OpenAI, dưới áp lực đó, đã dẫn dắt được một thỏa thuận theo hình thức mà Bộ Quốc phòng có thể chấp nhận
Sự khác biệt trong cách diễn đạt lập trường chính thức cũng khá lớn.
Sam Altman nói rằng "Bộ Quốc phòng đã thể hiện sự tôn trọng sâu sắc đối với an toàn",
trong khi phía Anthropic đến cuối vẫn giữ tông "về mặt lương tâm, chúng tôi không thể đồng ý với yêu cầu của Bộ Quốc phòng"
Có vẻ như, dù cùng một nguyên tắc, khác biệt lớn nằm ở chỗ có giữ thể diện cho Bộ Quốc phòng hay không,
và kết quả là khi OpenAI chấp nhận thì cục diện trở nên hơi kỳ,
nên ở đoạn cuối Sam Altman đã thêm câu "hãy đề nghị các điều kiện này giống nhau với mọi công ty AI",
như một thông điệp gián tiếp rằng nên nới lỏng các biện pháp đối với Anthropic.
Là một lập trình viên solo đang vận hành 7 dự án, tôi thấy bài viết này thực sự chạm đúng nỗi đau.
Nhờ các công cụ AI coding, tốc độ phát triển ban đầu đã tăng nhanh đến mức điên rồ, nhưng rồi đống mã được chồng lên quá nhanh mà không có test cuối cùng lại biến thành địa ngục refactor. Đặc biệt, khi phải vận hành nhiều dịch vụ cùng lúc, với những dự án không có test, mỗi lần chạm vào một tính năng là lại sợ chỗ khác phát nổ, đến mức ngại không dám động vào.
Phép so sánh "test = hào lũy" thực sự rất chính xác. Đối thủ có thể sao chép code, nhưng rất khó để sao chép cả một test suite bao phủ hàng nghìn edge case. Nhất là khi AI làm rất tốt việc sinh code, nhưng để tạo ra các kịch bản test thực sự có ý nghĩa thì đó vẫn là lĩnh vực đòi hỏi kiến thức miền từ con người.
Mình có điều thắc mắc muốn hỏi các bạn lập trình viên: tại sao dạo gần đây phần lớn các dự án lại thường được phát triển bằng Rust hơn là Golang? Lý do lớn nhất có phải là có hay không có GC không?
Đây là một nghiên cứu thú vị. Đặc biệt, việc 12/20 hạng mục trong phần "Build vs Buy" là DIY để lại ấn tượng mạnh.
Bên mình cũng có quan sát tương tự khi xây dựng tiêu chuẩn persona cho AI agent (Soul Spec): nếu không chỉ rõ công cụ cho Claude Code bằng CLAUDE.md hoặc AGENTS.md, nó có xu hướng tự triển khai theo cách riêng của mình.
Điều mà "Recency Gradient" trong nghiên cứu này gợi ý là, để một công cụ mới được đưa vào stack mặc định của Claude, nó cần либо được phơi bày đủ nhiều trong dữ liệu huấn luyện, либо phải được chỉ định rõ ràng trong tệp ngữ cảnh của dự án. Cuối cùng thì Context Engineering thậm chí còn chi phối cả việc lựa chọn công cụ.
Các công cụ dành cho nhà phát triển giờ đây cần trở thành sản phẩm mà các agent ưu tiên lựa chọn.
Nếu agent còn không nhắc tới thì sẽ ngày càng bị bỏ xa
Ralph loop cũng mới được thêm cách đây không lâu, và nhìn việc Financial skill cũng đã được bổ sung thì có cảm giác là nếu cứ chờ thôi, những thứ vốn có ở các công cụ bên thứ ba sẽ nhanh chóng được đưa vào.
Tôi đồng ý rằng vibe coding phù hợp với khung tiêu dùng. Tôi thấy nó giống như phiên bản lập trình của trào lưu gần đây là Temu-kkang, Ali-kkang (https://www.asiae.co.kr/article/2024053117460950053).
Nhưng nếu nói rằng khung tiêu dùng là cách để không lặp lại thất bại của phong trào maker, thì tôi không thể đồng ý ở nhiều khía cạnh, giống như bình luận trên HN.
Vibe coding đang tiếp nối lịch sử của các nhà phát triển công dân.
Giờ đây, tôi cho rằng vibe coding đang tiến tới việc biến lập trình trở thành thứ dễ dàng, nhanh chóng và thiết yếu như điện.
Ngay lúc này, ngay cả những lập trình viên thiên tài ở vô số doanh nghiệp cũng đang tiếp tục lập trình bằng prompt và agent mà không cần viết dù chỉ một dòng code.
Dù cũng có những người cố hạ thấp điều này, nhưng tôi nghĩ rất khó để phản bác rằng vibe coding của Andrej Karpathy là một cột mốc ghi dấu trong lịch sử máy tính.
Câu hỏi rất hay. Thực ra, điều kiện “hybrid” trong thí nghiệm của chúng tôi chính xác là theo hướng đó — cấu hình cung cấp đồng thời phần tóm tắt đã được sắp xếp và nhật ký trải nghiệm thô.
Kết quả là hybrid cao nhất, đạt 4.95/5.0. Nếu chỉ đưa phần tóm tắt thì là 2.65, nhưng khi gắn thêm các ghi chép quá trình như “thất bại”, “không rõ nguyên nhân” thì điểm yếu của phần tóm tắt lại được bù đắp.
Vì vậy, kết luận là “không phải bản thân phần tóm tắt là xấu, mà là cần chứa cả quá trình và sự bất định cùng nhau”.
Tuy nhiên, vì N=1 nên vẫn cần nghiên cứu tiếp theo để xác định liệu nội dung này có thể được dùng một cách phổ quát cho nhiều nhóm người dùng khác nhau hay không.
Vậy nếu cấu hình để bộ nhớ tổng hợp chứa quy trình của những tác vụ đó, cùng với nội dung về thất bại và thành công, thì liệu kết quả có khác đi không?
Đúng vậy. Ban đầu tôi cũng nghĩ rằng ít nhất thì bộ nhớ tổng hợp sẽ tốt hơn mức cơ sở, nhưng khi thấy kết quả tôi đã rất ngạc nhiên.
Phân tích kỹ thì điểm mấu chốt là việc "bảo toàn tính bất định". Trong log thô vẫn còn lại những dấu vết như "đã thử cái này nhưng không được", "không rõ nguyên nhân", nên agent sẽ trả lời rằng điều gì không biết thì là không biết; còn bản tóm tắt thì lại xóa sạch toàn bộ ngữ cảnh đó, khiến agent ngược lại đưa ra câu trả lời sai với sự tự tin.
Cũng là điều tôi phần nào cảm nhận được từ trải nghiệm, nhưng bộ nhớ tổng hợp còn tệ hại hơn tôi nghĩ rất nhiều.
Tôi định thử dùng nhưng hiện chỉ hỗ trợ đến gemini 2.5 thôi... Danh sách model được hỗ trợ cũng là vibe coding làm đại luôn à
Thú vị đấy, nhưng cũng có cảm giác phải chăng họ chỉ tiến hóa theo hướng dùng thật nhiều token của mình để thu phí cao hơn; và thực ra cũng có cảm giác ở một mức độ nào đó, AI đã được huấn luyện trên các thư viện nên nó chỉ việc tạo ra như vậy thôi.
Nghĩ đến chuyện chỉ một số thư viện nhất định sẽ phát triển vì được agent ưa chuộng thì cũng thấy hơi kỳ lạ.
Rốt cuộc thì việc Bộ Quốc phòng Mỹ bỏ Anthropic và chọn OpenAI, nhưng cách diễn đạt thường thấy lại có sự khác biệt.
OpenAI cùng đề xuất cơ chế triển khai cụ thể như xây dựng các biện pháp an toàn kỹ thuật, đưa FDE (kỹ sư hiện trường) vào, và triển khai chuyên dụng trên đám mây
Anthropic thì yêu cầu điều khoản ngoại lệ ở mức điều khoản sử dụng
Từ góc nhìn của Bộ Quốc phòng Mỹ, điều đó bị xem là "một doanh nghiệp tư nhân thực hiện quyền phủ quyết đối với từng trường hợp sử dụng riêng lẻ", nên họ công bố theo kiểu như muốn dằn mặt.
Thỏa thuận này được công bố không lâu sau khi Anthropic bị chỉ định là rủi ro chuỗi cung ứng,
nếu nhìn bài của Axios thì Bộ Quốc phòng đã tận dụng cuộc đối đầu với Anthropic để thiết lập tông giọng trong các cuộc đàm phán với những công ty AI khác,
và OpenAI, dưới áp lực đó, đã dẫn dắt được một thỏa thuận theo hình thức mà Bộ Quốc phòng có thể chấp nhận
Sự khác biệt trong cách diễn đạt lập trường chính thức cũng khá lớn.
Sam Altman nói rằng "Bộ Quốc phòng đã thể hiện sự tôn trọng sâu sắc đối với an toàn",
trong khi phía Anthropic đến cuối vẫn giữ tông "về mặt lương tâm, chúng tôi không thể đồng ý với yêu cầu của Bộ Quốc phòng"
Có vẻ như, dù cùng một nguyên tắc, khác biệt lớn nằm ở chỗ có giữ thể diện cho Bộ Quốc phòng hay không,
và kết quả là khi OpenAI chấp nhận thì cục diện trở nên hơi kỳ,
nên ở đoạn cuối Sam Altman đã thêm câu "hãy đề nghị các điều kiện này giống nhau với mọi công ty AI",
như một thông điệp gián tiếp rằng nên nới lỏng các biện pháp đối với Anthropic.
Chỉ giữ theo hướng tối giản thôi không được sao...?
Hoặc nhân lúc WordPad đã bị khai tử thì ra một cái mới nhẹ hơn hẳn đi...
Là một lập trình viên solo đang vận hành 7 dự án, tôi thấy bài viết này thực sự chạm đúng nỗi đau.
Nhờ các công cụ AI coding, tốc độ phát triển ban đầu đã tăng nhanh đến mức điên rồ, nhưng rồi đống mã được chồng lên quá nhanh mà không có test cuối cùng lại biến thành địa ngục refactor. Đặc biệt, khi phải vận hành nhiều dịch vụ cùng lúc, với những dự án không có test, mỗi lần chạm vào một tính năng là lại sợ chỗ khác phát nổ, đến mức ngại không dám động vào.
Phép so sánh "test = hào lũy" thực sự rất chính xác. Đối thủ có thể sao chép code, nhưng rất khó để sao chép cả một test suite bao phủ hàng nghìn edge case. Nhất là khi AI làm rất tốt việc sinh code, nhưng để tạo ra các kịch bản test thực sự có ý nghĩa thì đó vẫn là lĩnh vực đòi hỏi kiến thức miền từ con người.
Mình có điều thắc mắc muốn hỏi các bạn lập trình viên: tại sao dạo gần đây phần lớn các dự án lại thường được phát triển bằng Rust hơn là Golang? Lý do lớn nhất có phải là có hay không có GC không?
Cái này khá ổn đấy.
Đây là một nghiên cứu thú vị. Đặc biệt, việc 12/20 hạng mục trong phần "Build vs Buy" là DIY để lại ấn tượng mạnh.
Bên mình cũng có quan sát tương tự khi xây dựng tiêu chuẩn persona cho AI agent (Soul Spec): nếu không chỉ rõ công cụ cho Claude Code bằng
CLAUDE.mdhoặcAGENTS.md, nó có xu hướng tự triển khai theo cách riêng của mình.Điều mà "Recency Gradient" trong nghiên cứu này gợi ý là, để một công cụ mới được đưa vào stack mặc định của Claude, nó cần либо được phơi bày đủ nhiều trong dữ liệu huấn luyện, либо phải được chỉ định rõ ràng trong tệp ngữ cảnh của dự án. Cuối cùng thì Context Engineering thậm chí còn chi phối cả việc lựa chọn công cụ.
Thật tốt khi bộ dữ liệu gốc cũng được công khai: https://github.com/amplifying-ai/claude-code-picks
Hoa Kỳ “Trung Quốc”
Người ta gọi đó là Assistive agent optimization (AAO).
Các công cụ dành cho nhà phát triển giờ đây cần trở thành sản phẩm mà các agent ưu tiên lựa chọn.
Nếu agent còn không nhắc tới thì sẽ ngày càng bị bỏ xa
Ralph loop cũng mới được thêm cách đây không lâu, và nhìn việc Financial skill cũng đã được bổ sung thì có cảm giác là nếu cứ chờ thôi, những thứ vốn có ở các công cụ bên thứ ba sẽ nhanh chóng được đưa vào.
Astro*
Có lẽ cũng có thể dịch bằng cá tính riêng.
👍👍👍