Tôi đã bỏ vim để chuyển sang vscode vì AI,
nhưng cảm giác như đã đánh mất niềm vui khi lập trình nên tôi quay lại với vim.
Tôi đang dùng AI như một assistant, và đúng là có cảm giác như đã tìm lại được niềm vui phát triển phần mềm.
Viết thì có vẻ khó hiểu đấy, nhưng rốt cuộc điều muốn nói là nội dung này cũng áp dụng cho con người.
Vấn đề là liệu một bài do kẻ ngốc A viết ra, khi lại được chính kẻ ngốc A xem lại, có thực sự trở thành bài viết tốt hơn hay không.
Tất nhiên vẫn có một số ít trường hợp có thể tốt lên, cũng giống như vẫn có xác suất khoanh bừa hết mà đạt điểm tuyệt đối trong kỳ thi đại học, nhưng trong đa số trường hợp thì chỉ quay về mức trung bình sau N lần của kẻ ngốc A mà thôi.
(Chapter 2 thì tôi không thể hoàn toàn đồng ý.)
Tuy vậy, như bài luận văn nói, mong là mọi người hiểu rằng cái gọi là what-ever Scaling Law chỉ là một quy luật tăng trưởng mang tính tạm thời, chứ không phải thứ tồn tại vĩnh viễn.
Nếu đã đọc nghiêm túc bài luận văn của OpenAI thì hẳn cũng chẳng nói ra mấy lời như thế.
Thật ra còn hơn cả 100 bài luận văn kiểu đó, chỉ cần chứng minh rằng người khăng khăng nói "làm được" thực sự trở thành bằng chứng sống là xong.
Vấn đề là cứ mãi làm thứ giả kim thuật mang tên "làm được".
Cá nhân tôi cảm nhận rất sâu sắc rằng AI rất tệ trong đúng lĩnh vực chuyên môn của tôi. Tôi đoán có lẽ các chuyên gia ở những lĩnh vực khác cũng vậy. Tất nhiên nó vẫn giúp được rất nhiều. Dù phải viết cả đống tài liệu lải nhải suốt cả ngày, nhưng năng suất thì tuyệt đối không thể so với trước đây.
Sự chú ý được hình thành theo đa số.
Tác nhân kiểm chứng chỉ cần vượt qua hàm đánh giá.
Phần lớn mã công nghiệp xuất sắc đều không được công khai.
Mã nguồn mở là thứ mã được viết ra để trình diễn.
Theo kết quả thử nghiệm của viện nghiên cứu chúng tôi, đây là một mô hình do một “đội ngũ Qwen không còn là Qwen” vội vã tung ra chỉ để chạy theo benchmark nhằm xoa dịu bất ổn của thị trường. Nó bị ám ảnh quá mức với việc dùng công cụ. Chúng tôi xem đây là một bước thụt lùi so với 3.5.
Ngoài việc phát hành theo chu kỳ ngắn thì tôi không biết còn lại điều gì của Agile nữa.
Backlog hay sprint cũng đã tồn tại trước đó dưới những hình thức khác, còn việc giao tiếp với khách hàng thì có nhiều điểm không khớp với thực tế. Cuối cùng, tôi nghĩ rằng so với Agile, việc cải thiện DevOps đã mang lại nhiều tiến bộ hơn cho phát triển phần mềm.
Khi viết phần mềm, vấn đề không hẳn là tính trừu tượng mà là sự mơ hồ. Ngôn ngữ tự nhiên về bản chất là mơ hồ. Nó cũng có thể đa nghĩa nữa. Vì vậy có lẽ những nỗ lực viết code bằng ngôn ngữ tự nhiên không hoạt động tốt.
Trong tình huống như thế này, chuyện ngôn ngữ tự nhiên thay thế code lại càng là điều khó mà nghĩ tới.
Nội dung như vậy có vẻ là sự chấp niệm với cách làm việc trong quá khứ. Dù sao thì những phần đó rồi AI cũng sẽ làm tốt hơn. Điều quan trọng lúc này là trải nghiệm cải thiện những phần chưa vận hành tốt khi sử dụng AI. Nhưng tôi cũng cho rằng điều này chỉ mang tính tạm thời.
Mỗi người có thể khác nhau, nhưng tôi nghĩ việc học trong lĩnh vực máy tính thì chẳng phải ai cũng thường làm theo cách bạn nói sao. Dạo này cũng có thêm lựa chọn học bằng video, nên cứ chọn phương pháp học phù hợp với bản thân là được.
Vậy thì, bạn đã học ngôn ngữ lập trình hàm thuần như thế nào? Từ trước đến nay tôi học các ngôn ngữ lập trình (C, Go, Python, v.v.) bằng sách chuyên về phát triển phần mềm + dự án phụ, vậy với ngôn ngữ lập trình hàm thì đi theo hướng học như vậy cũng ổn chứ?
AI mang lại cảm giác như đang dùng máy khoan điện, cưa máy và máy xúc --. Sau khi dùng điện thoại di động, có rất nhiều người thậm chí không còn nhớ nổi số điện thoại của chính mình.
...Có thể xem những điều này là sự mai một, nhưng với tôi đó là hiệu quả. Từ kinh nghiệm từng làm nhà phát triển và đảm nhiệm nhiều vị trí khác nhau, tôi thấy công cụ AI là công cụ không chỉ dành riêng cho thế giới của lập trình viên mà còn là cơ hội và sự hỗ trợ để có được góc nhìn rộng hơn. Có thể ở một khía cạnh nào đó sẽ bị mai một, nhưng khoảng trống đó sẽ được lấp đầy bằng những thứ khác.
Theo trải nghiệm của tôi và kết luận của nhiều người, cách bài bản là nên học ngôn ngữ hàm bằng một ngôn ngữ hàm thuần túy.
Đó là câu chuyện được nhắc đến vào thời điểm ngôn ngữ hàm bắt đầu nổi lên và cả giai đoạn nó nhận được nhiều sự quan tâm, và tôi cũng đồng cảm với điều đó. Tôi đã học bằng Erlang vào giai đoạn đầu khi nó xuất hiện, và khi đó đó là một trải nghiệm khá gây sốc và đầy kinh ngạc.
Clojure ra đời đã khá lâu rồi, nên tôi thấy tò mò vì sao giờ lại có người nhắc đến Clojure một lần nữa.
Tôi từng có kinh nghiệm review một cuốn sách vào giai đoạn đầu khi Clojure mới xuất hiện. Sau đó tôi cũng thấy một vài công ty thử áp dụng nó, nhưng kết luận là không dễ để dùng trong môi trường doanh nghiệp. Rồi tưởng như nó đã chìm vào quên lãng, nên tôi lại càng thắc mắc vì sao bây giờ nó được nhắc đến trở lại.
Dù tôi đã dùng Java từ rất sớm và trong thời gian dài, JVM vẫn còn được dùng nhiều vì các tập đoàn lớn đã phát triển rất nhiều phần mềm bằng Java, (ở Mỹ) phần lớn nhân lực từ Ấn Độ đều dùng Java, và Java còn được dạy từ cấp phổ thông đến đại học, v.v. Tuy vậy, theo quan điểm cá nhân, tôi nghĩ nó không còn phù hợp với thời đại hiện nay nữa. Tôi thích Lisp, nhưng trong bài viết ở trên tôi không thấy được điểm gì khiến một ngôn ngữ khá ngách như vậy, lại còn chạy trên mô hình JVM đang dần đi xuống, lại được nhắc đến trở lại trong thời đại AI như bây giờ.
Quảng cáo và marketing vốn đã như vậy từ trước cả thời internet, nhưng giờ đây thứ mọi người nhìn thấy đã khác đi và cũng không còn cách nào để quản lý, nên các thủ pháp gần như lừa đảo đang tràn lan.
Mình chưa từng học bài bản về ngôn ngữ lập trình hàm, nên đang nghĩ hay là bắt đầu với Clojure. Mình nên học như thế nào? Rất mong nhận được nhiều lời khuyên từ các anh chị developer.
Có vẻ như Daniel Han, nhà sáng lập Unsloth, đúng là một thiên tài thực thụ. Mỗi khi có mô hình open-weight mới ra mắt, anh ấy đều phân tích và chia sẻ từ cấu trúc mô hình đến lỗi tokenization, lỗi quantization và cả lỗi template, thật sự rất đáng khâm phục.
Câu nói rằng "phần đáng kể của kỹ năng lập trình là trí nhớ thủ tục" thực sự khiến tôi thấy rất thấm.
Việc giải bài toán cũng là hành vi ghi nhớ quy trình và luyện tập để có thể tạo ra cùng một kết quả.
Dùng AI để lập trình thì cũng không sao, nhưng có vẻ vẫn cần tạo áp lực cho não để có thể lặp đi lặp lại việc tạo ra kết quả ở cùng mức độ trở lên.
Ít nhất khi chỉ dẫn cho AI, đừng chỉ ném ra vài câu ngắn gọn mà hãy diễn giải cụ thể nhất có thể suy nghĩ và tiến trình lập luận của mình; sau đó, trước khi bắt đầu công việc, nếu còn điều gì cần kiểm tra thêm thì hãy nhất định hỏi lại rồi mới tiến hành, như vậy có vẻ sẽ hữu ích.
Nhớ lại thời web còn hỗn loạn với quirk html, có thời người ta dùng trình kiểm tra tiêu chuẩn web để chấm điểm website. Việc tuân thủ tiêu chuẩn web không bảo đảm chất lượng cốt lõi của một site, nhưng ít nhất nó cũng có tác dụng khiến các site ý thức hơn về chuyện tuân thủ chuẩn. Và tôi nghĩ những công ty phải crawl web và machine reading như Google hẳn cũng đã được hưởng lợi ở mức gần như nằm không mà vẫn nâng được chất lượng tìm kiếm miễn phí.
Nếu đưa ra các guideline như vậy thì vào thời điểm không chỉ con người mà cả AI agent cũng đang trở thành chủ thể sử dụng Internet, có lẽ chúng ta sẽ có thể giảm bớt phần nào những cú trục trặc và nhanh chóng đạt được sự ổn định của hạ tầng. Theo thời gian, dù có vài thứ bị xem là rườm rà quá mức và thừa thãi, điều tôi muốn nói là bản thân việc nhanh chóng thiết lập kỷ cương(?) cũng có thể mang lại lợi thế cho các ngành liên quan.
Tắt tính năng AI của VSCode và dùng Claude Code thì đúng là thoải mái hơn hẳn.
Tôi đã bỏ
vimđể chuyển sangvscodevì AI,nhưng cảm giác như đã đánh mất niềm vui khi lập trình nên tôi quay lại với
vim.Tôi đang dùng AI như một assistant, và đúng là có cảm giác như đã tìm lại được niềm vui phát triển phần mềm.
Viết thì có vẻ khó hiểu đấy, nhưng rốt cuộc điều muốn nói là nội dung này cũng áp dụng cho con người.
Vấn đề là liệu một bài do kẻ ngốc A viết ra, khi lại được chính kẻ ngốc A xem lại, có thực sự trở thành bài viết tốt hơn hay không.
Tất nhiên vẫn có một số ít trường hợp có thể tốt lên, cũng giống như vẫn có xác suất khoanh bừa hết mà đạt điểm tuyệt đối trong kỳ thi đại học, nhưng trong đa số trường hợp thì chỉ quay về mức trung bình sau N lần của kẻ ngốc A mà thôi.
(
Chapter 2thì tôi không thể hoàn toàn đồng ý.)Tuy vậy, như bài luận văn nói, mong là mọi người hiểu rằng cái gọi là
what-ever Scaling Lawchỉ là một quy luật tăng trưởng mang tính tạm thời, chứ không phải thứ tồn tại vĩnh viễn.Nếu đã đọc nghiêm túc bài luận văn của OpenAI thì hẳn cũng chẳng nói ra mấy lời như thế.
Thật ra còn hơn cả 100 bài luận văn kiểu đó, chỉ cần chứng minh rằng người khăng khăng nói "làm được" thực sự trở thành bằng chứng sống là xong.
Vấn đề là cứ mãi làm thứ giả kim thuật mang tên "làm được".
Cá nhân tôi cảm nhận rất sâu sắc rằng AI rất tệ trong đúng lĩnh vực chuyên môn của tôi. Tôi đoán có lẽ các chuyên gia ở những lĩnh vực khác cũng vậy. Tất nhiên nó vẫn giúp được rất nhiều. Dù phải viết cả đống tài liệu lải nhải suốt cả ngày, nhưng năng suất thì tuyệt đối không thể so với trước đây.
Sự chú ý được hình thành theo đa số.
Tác nhân kiểm chứng chỉ cần vượt qua hàm đánh giá.
Phần lớn mã công nghiệp xuất sắc đều không được công khai.
Mã nguồn mở là thứ mã được viết ra để trình diễn.
Phải luôn ghi nhớ điều này khi sử dụng.
Theo kết quả thử nghiệm của viện nghiên cứu chúng tôi, đây là một mô hình do một “đội ngũ Qwen không còn là Qwen” vội vã tung ra chỉ để chạy theo benchmark nhằm xoa dịu bất ổn của thị trường. Nó bị ám ảnh quá mức với việc dùng công cụ. Chúng tôi xem đây là một bước thụt lùi so với 3.5.
Ngoài việc phát hành theo chu kỳ ngắn thì tôi không biết còn lại điều gì của Agile nữa.
Backlog hay sprint cũng đã tồn tại trước đó dưới những hình thức khác, còn việc giao tiếp với khách hàng thì có nhiều điểm không khớp với thực tế. Cuối cùng, tôi nghĩ rằng so với Agile, việc cải thiện DevOps đã mang lại nhiều tiến bộ hơn cho phát triển phần mềm.
Khi viết phần mềm, vấn đề không hẳn là tính trừu tượng mà là sự mơ hồ. Ngôn ngữ tự nhiên về bản chất là mơ hồ. Nó cũng có thể đa nghĩa nữa. Vì vậy có lẽ những nỗ lực viết code bằng ngôn ngữ tự nhiên không hoạt động tốt. Trong tình huống như thế này, chuyện ngôn ngữ tự nhiên thay thế code lại càng là điều khó mà nghĩ tới.
Nội dung như vậy có vẻ là sự chấp niệm với cách làm việc trong quá khứ. Dù sao thì những phần đó rồi AI cũng sẽ làm tốt hơn. Điều quan trọng lúc này là trải nghiệm cải thiện những phần chưa vận hành tốt khi sử dụng AI. Nhưng tôi cũng cho rằng điều này chỉ mang tính tạm thời.
Mỗi người có thể khác nhau, nhưng tôi nghĩ việc học trong lĩnh vực máy tính thì chẳng phải ai cũng thường làm theo cách bạn nói sao. Dạo này cũng có thêm lựa chọn học bằng video, nên cứ chọn phương pháp học phù hợp với bản thân là được.
Vậy thì, bạn đã học ngôn ngữ lập trình hàm thuần như thế nào? Từ trước đến nay tôi học các ngôn ngữ lập trình (C, Go, Python, v.v.) bằng sách chuyên về phát triển phần mềm + dự án phụ, vậy với ngôn ngữ lập trình hàm thì đi theo hướng học như vậy cũng ổn chứ?
AI mang lại cảm giác như đang dùng máy khoan điện, cưa máy và máy xúc --. Sau khi dùng điện thoại di động, có rất nhiều người thậm chí không còn nhớ nổi số điện thoại của chính mình.
...Có thể xem những điều này là sự mai một, nhưng với tôi đó là hiệu quả. Từ kinh nghiệm từng làm nhà phát triển và đảm nhiệm nhiều vị trí khác nhau, tôi thấy công cụ AI là công cụ không chỉ dành riêng cho thế giới của lập trình viên mà còn là cơ hội và sự hỗ trợ để có được góc nhìn rộng hơn. Có thể ở một khía cạnh nào đó sẽ bị mai một, nhưng khoảng trống đó sẽ được lấp đầy bằng những thứ khác.
Theo trải nghiệm của tôi và kết luận của nhiều người, cách bài bản là nên học ngôn ngữ hàm bằng một ngôn ngữ hàm thuần túy.
Đó là câu chuyện được nhắc đến vào thời điểm ngôn ngữ hàm bắt đầu nổi lên và cả giai đoạn nó nhận được nhiều sự quan tâm, và tôi cũng đồng cảm với điều đó. Tôi đã học bằng Erlang vào giai đoạn đầu khi nó xuất hiện, và khi đó đó là một trải nghiệm khá gây sốc và đầy kinh ngạc.
Clojure ra đời đã khá lâu rồi, nên tôi thấy tò mò vì sao giờ lại có người nhắc đến Clojure một lần nữa.
Tôi từng có kinh nghiệm review một cuốn sách vào giai đoạn đầu khi Clojure mới xuất hiện. Sau đó tôi cũng thấy một vài công ty thử áp dụng nó, nhưng kết luận là không dễ để dùng trong môi trường doanh nghiệp. Rồi tưởng như nó đã chìm vào quên lãng, nên tôi lại càng thắc mắc vì sao bây giờ nó được nhắc đến trở lại.
Dù tôi đã dùng Java từ rất sớm và trong thời gian dài, JVM vẫn còn được dùng nhiều vì các tập đoàn lớn đã phát triển rất nhiều phần mềm bằng Java, (ở Mỹ) phần lớn nhân lực từ Ấn Độ đều dùng Java, và Java còn được dạy từ cấp phổ thông đến đại học, v.v. Tuy vậy, theo quan điểm cá nhân, tôi nghĩ nó không còn phù hợp với thời đại hiện nay nữa. Tôi thích Lisp, nhưng trong bài viết ở trên tôi không thấy được điểm gì khiến một ngôn ngữ khá ngách như vậy, lại còn chạy trên mô hình JVM đang dần đi xuống, lại được nhắc đến trở lại trong thời đại AI như bây giờ.
Quảng cáo và marketing vốn đã như vậy từ trước cả thời internet, nhưng giờ đây thứ mọi người nhìn thấy đã khác đi và cũng không còn cách nào để quản lý, nên các thủ pháp gần như lừa đảo đang tràn lan.
Mình chưa từng học bài bản về ngôn ngữ lập trình hàm, nên đang nghĩ hay là bắt đầu với Clojure. Mình nên học như thế nào? Rất mong nhận được nhiều lời khuyên từ các anh chị developer.
Có vẻ như Daniel Han, nhà sáng lập Unsloth, đúng là một thiên tài thực thụ. Mỗi khi có mô hình open-weight mới ra mắt, anh ấy đều phân tích và chia sẻ từ cấu trúc mô hình đến lỗi tokenization, lỗi quantization và cả lỗi template, thật sự rất đáng khâm phục.
Câu nói rằng "phần đáng kể của kỹ năng lập trình là trí nhớ thủ tục" thực sự khiến tôi thấy rất thấm. Việc giải bài toán cũng là hành vi ghi nhớ quy trình và luyện tập để có thể tạo ra cùng một kết quả. Dùng AI để lập trình thì cũng không sao, nhưng có vẻ vẫn cần tạo áp lực cho não để có thể lặp đi lặp lại việc tạo ra kết quả ở cùng mức độ trở lên.
“Nếu bạn chẳng là gì nếu không có bộ giáp đó, thì bạn không nên sở hữu nó.” - Tony Stark
Ít nhất khi chỉ dẫn cho AI, đừng chỉ ném ra vài câu ngắn gọn mà hãy diễn giải cụ thể nhất có thể suy nghĩ và tiến trình lập luận của mình; sau đó, trước khi bắt đầu công việc, nếu còn điều gì cần kiểm tra thêm thì hãy nhất định hỏi lại rồi mới tiến hành, như vậy có vẻ sẽ hữu ích.
Nhớ lại thời web còn hỗn loạn với quirk html, có thời người ta dùng trình kiểm tra tiêu chuẩn web để chấm điểm website. Việc tuân thủ tiêu chuẩn web không bảo đảm chất lượng cốt lõi của một site, nhưng ít nhất nó cũng có tác dụng khiến các site ý thức hơn về chuyện tuân thủ chuẩn. Và tôi nghĩ những công ty phải crawl web và machine reading như Google hẳn cũng đã được hưởng lợi ở mức gần như nằm không mà vẫn nâng được chất lượng tìm kiếm miễn phí.
Nếu đưa ra các guideline như vậy thì vào thời điểm không chỉ con người mà cả AI agent cũng đang trở thành chủ thể sử dụng Internet, có lẽ chúng ta sẽ có thể giảm bớt phần nào những cú trục trặc và nhanh chóng đạt được sự ổn định của hạ tầng. Theo thời gian, dù có vài thứ bị xem là rườm rà quá mức và thừa thãi, điều tôi muốn nói là bản thân việc nhanh chóng thiết lập kỷ cương(?) cũng có thể mang lại lợi thế cho các ngành liên quan.