Con người cũng không giỏi chọn ngẫu nhiên. Đáng ra không nên có quy luật, nhưng việc cố tình tránh quy luật tự nó cũng có thể được xem là một quy luật.
Không có kết quả đo mức sử dụng token thực tế cho một tác vụ đơn lẻ, nên đây chỉ là suy đoán rằng nếu dùng Magpie thì số lần thử lại sẽ giảm đến mức này.
Lĩnh vực tôi làm cũng không đến mức cực đoan như vậy, nhưng tôi đang nghiên cứu và phát triển trong lĩnh vực AI.
Ngoài các framework thường được dùng phổ biến, cũng có những trường hợp môi trường đích để triển khai mô hình thực tế khác với môi trường đã dùng khi huấn luyện.
Cũng có khi một số operation nhất định không được hỗ trợ, nên phải tạo custom operation theo từng nền tảng. Trong trường hợp này, nhiều khi cũng không thể kiểm thử ngay trên môi trường đã phát triển.
Đôi khi cũng có trường hợp tự thiết kế mô hình trực tiếp; tuy có thể viết mã kiểm thử bằng một số dữ liệu nhất định, nhưng tùy theo dataset mà các giá trị thay đổi theo xác suất, hoặc xuất hiện hiện tượng giá trị bùng nổ tại một thời điểm nào đó, nên rất khó bao quát bằng mã kiểm thử.
Có lẽ còn khá nhiều môi trường mà việc kiểm thử còn khó hơn cả trường hợp của tôi.
Cách tiếp cận của SQLite thực sự rất ấn tượng. Việc giữ kín bộ test có quy mô gấp 590 lần mã nguồn cuối cùng cho thấy rằng “giá trị thực sự của phần mềm nằm ở đặc tả hành vi”.
Thực tế, dạo gần đây khi thử xây dựng dự án bằng các công cụ AI coding, chỉ cần có README + tài liệu API + mã test của một dự án hiện có là đã có thể sao chép các tính năng cốt lõi với tốc độ đáng kinh ngạc. Đây là điều tôi cảm nhận được khi trực tiếp vận hành 7 dự án; trớ trêu thay, những dự án có test càng tốt thì lại càng dễ bị sao chép.
Tuy nhiên, có một điểm bị bỏ qua trong trường hợp Cloudflare vs Vercel, đó là “sao chép” và “vận hành” là hai vấn đề hoàn toàn khác nhau. Để tái hiện được cả các edge case của Next.js, hệ sinh thái plugin, lẫn mức độ phụ thuộc vào cộng đồng thì chỉ mã test thôi là không đủ. Cuối cùng, có lẽ hào lũy thực sự là sự kết hợp giữa mã test + cộng đồng + kinh nghiệm vận hành.
Dự án này có lẽ chưa đến mức GC trở thành vấn đề. Tôi nghĩ trong “phần lớn các dự án gần đây”, việc chọn ngôn ngữ lập trình trên thực tế thường thuộc phạm vi sở thích nhiều hơn là do ưu điểm hay giới hạn của một ngôn ngữ cụ thể; dù vậy, nếu hỏi Rust có ưu thế so sánh nào so với Go với tư cách là một ngôn ngữ lập trình đa dụng, thì tôi có lẽ sẽ trả lời rằng đó là mức độ trừu tượng mà Rust cung cấp và khả năng bắt được nhiều lỗi ngay tại thời điểm biên dịch. Tất nhiên, Go cũng có những ưu điểm so với Rust như lập trình bất đồng bộ dễ dàng, thời gian biên dịch nhanh và cú pháp ngắn gọn.
Chà, chỉ là suy đoán thôi, nhưng có lẽ là vì rào cản gia nhập với Rust đã biến mất.
Khó khăn lớn nhất là viết code xong mà biên dịch cứ liên tục thất bại, nhưng giờ thì AI làm thay rồi.
DIY, phong trào maker, indie, punk, mã nguồn mở đều là những phản biện đối với công nghiệp hóa, chủ nghĩa tư bản và chủ nghĩa tiêu dùng, vậy mà nói rằng để vượt qua giới hạn của chúng thì phải chấp nhận chủ nghĩa tiêu dùng.
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.
Con người cũng không giỏi chọn ngẫu nhiên. Đáng ra không nên có quy luật, nhưng việc cố tình tránh quy luật tự nó cũng có thể được xem là một quy luật.
Không có kết quả đo mức sử dụng token thực tế cho một tác vụ đơn lẻ, nên đây chỉ là suy đoán rằng nếu dùng Magpie thì số lần thử lại sẽ giảm đến mức này.
So sánh thời gian biên dịch có vẻ kỳ nhỉ. Tại sao lại so sánh ms/token?
Có lẽ cần sắp xếp lại mốc thời gian của nội dung liên quan. Cũng có ý kiến nói rằng OpenAI khi đó đang trong quá trình đàm phán hợp đồng, phải không?
Tôi luôn theo dõi rất kỹ, xin cảm ơn.
Có vẻ là có những trường hợp như vậy vì việc để x thu thập dữ liệu đã trở nên khá khó xử. Chúng tôi sẽ cố gắng cải thiện.
Đây là lần đầu tôi thấy lỗi tóm tắt thành “không có nội dung”..
Lĩnh vực tôi làm cũng không đến mức cực đoan như vậy, nhưng tôi đang nghiên cứu và phát triển trong lĩnh vực AI.
Ngoài các framework thường được dùng phổ biến, cũng có những trường hợp môi trường đích để triển khai mô hình thực tế khác với môi trường đã dùng khi huấn luyện.
Cũng có khi một số operation nhất định không được hỗ trợ, nên phải tạo custom operation theo từng nền tảng. Trong trường hợp này, nhiều khi cũng không thể kiểm thử ngay trên môi trường đã phát triển.
Đôi khi cũng có trường hợp tự thiết kế mô hình trực tiếp; tuy có thể viết mã kiểm thử bằng một số dữ liệu nhất định, nhưng tùy theo dataset mà các giá trị thay đổi theo xác suất, hoặc xuất hiện hiện tượng giá trị bùng nổ tại một thời điểm nào đó, nên rất khó bao quát bằng mã kiểm thử.
Có lẽ còn khá nhiều môi trường mà việc kiểm thử còn khó hơn cả trường hợp của tôi.
Cách tiếp cận của SQLite thực sự rất ấn tượng. Việc giữ kín bộ test có quy mô gấp 590 lần mã nguồn cuối cùng cho thấy rằng “giá trị thực sự của phần mềm nằm ở đặc tả hành vi”.
Thực tế, dạo gần đây khi thử xây dựng dự án bằng các công cụ AI coding, chỉ cần có README + tài liệu API + mã test của một dự án hiện có là đã có thể sao chép các tính năng cốt lõi với tốc độ đáng kinh ngạc. Đây là điều tôi cảm nhận được khi trực tiếp vận hành 7 dự án; trớ trêu thay, những dự án có test càng tốt thì lại càng dễ bị sao chép.
Tuy nhiên, có một điểm bị bỏ qua trong trường hợp Cloudflare vs Vercel, đó là “sao chép” và “vận hành” là hai vấn đề hoàn toàn khác nhau. Để tái hiện được cả các edge case của Next.js, hệ sinh thái plugin, lẫn mức độ phụ thuộc vào cộng đồng thì chỉ mã test thôi là không đủ. Cuối cùng, có lẽ hào lũy thực sự là sự kết hợp giữa mã test + cộng đồng + kinh nghiệm vận hành.
Wow
Dự án này có lẽ chưa đến mức GC trở thành vấn đề. Tôi nghĩ trong “phần lớn các dự án gần đây”, việc chọn ngôn ngữ lập trình trên thực tế thường thuộc phạm vi sở thích nhiều hơn là do ưu điểm hay giới hạn của một ngôn ngữ cụ thể; dù vậy, nếu hỏi Rust có ưu thế so sánh nào so với Go với tư cách là một ngôn ngữ lập trình đa dụng, thì tôi có lẽ sẽ trả lời rằng đó là mức độ trừu tượng mà Rust cung cấp và khả năng bắt được nhiều lỗi ngay tại thời điểm biên dịch. Tất nhiên, Go cũng có những ưu điểm so với Rust như lập trình bất đồng bộ dễ dàng, thời gian biên dịch nhanh và cú pháp ngắn gọn.
Dù là hợp đồng ở cùng một mức độ, cảm giác về độ tin cậy hay hình ảnh lại khác hẳn nhau.
Chắc tôi cũng nên hủy đăng ký gpt thôi.
Thật khó chịu, lỗi.
Wow, thật tuyệt. Có lẽ là nhờ RustPython nên bạn mới có thể nhận được điều này. Chúc bạn có kết quả tốt!
Mình có cảm giác Rust bắt được rất nhiều lỗi ngay từ lúc biên dịch, nên việc biên dịch thất bại đôi khi lại giúp AI đi đúng hướng hơn.
Tôi đã thử đăng ký.
Chà, chỉ là suy đoán thôi, nhưng có lẽ là vì rào cản gia nhập với Rust đã biến mất. Khó khăn lớn nhất là viết code xong mà biên dịch cứ liên tục thất bại, nhưng giờ thì AI làm thay rồi.
Có vẻ đó là một bài test mang tính đùa cợt.
DIY, phong trào maker, indie, punk, mã nguồn mở đều là những phản biện đối với công nghiệp hóa, chủ nghĩa tư bản và chủ nghĩa tiêu dùng, vậy mà nói rằng để vượt qua giới hạn của chúng thì phải chấp nhận chủ nghĩa tiêu dùng.
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.