Có vẻ như bạn chưa hiểu rõ vì sao tôi nhắc đến lĩnh vực của tác giả và “miền chuyên môn của bản thân” nghĩa là gì.
Giao mọi quyết định cho AI mà không có suy nghĩ riêng thì có vẻ ngớ ngẩn,
nhưng tôi cũng không hiểu lắm những người đứng ở thái cực ngược lại.
Cuối cùng, điều tôi muốn hỏi là superscv đang nghĩ nên dùng LLM cho việc lập trình như thế nào thì tốt?
Hàn Quốc rồi cũng sẽ phải đều đặn (...) kéo dài tuổi nghỉ hưu vì vấn đề lương hưu thôi...
Điểm bùng phát có lẽ sẽ là thời điểm cứ tăng mãi tăng mãi rồi vượt cả tuổi thọ trung bình
(Có vẻ như Nga đã thành ra như vậy rồi thì phải..)
Thông điệp của tác giả có phần hơi mạnh, nhưng nếu đọc kỹ bài viết thì đó không phải là "đừng dùng AI". Bài viết có đưa ra gợi ý về việc nên tận dụng nó như thế nào, và ý chính là bản thân lập trình viên không được thiếu năng lực.
Nếu nhìn vào lý do vì sao thông điệp của tác giả lại tạo cảm giác mạnh như vậy, thì có thể thấy nó được xây dựng như một góc nhìn phản biện trước quan điểm cho rằng sẽ có thể phát triển phần mềm bằng copilot (mang sắc thái phụ thuộc nhiều vào copilot trong phát triển). Vì thế, tác giả đã dẫn dắt thông điệp theo hướng rằng các lập trình viên không nên tự đặt mình vào một lập trường làm tổn hại giá trị tồn tại của chính mình.
Tác giả cũng không hề nhắn nhủ rằng "đừng dùng AI", nên nếu nói đến việc tận dụng AI thì rốt cuộc cũng sẽ nằm đâu đó ở một điểm thỏa hiệp. Vì vậy, thông điệp tổng thể cũng có phần khá giống với điều bạn vừa trả lời trước đó.
Tuy nhiên, trong nội dung bạn viết ban đầu, tôi khó đồng ý với phần gọi đó là một "góc nhìn thiên lệch", nên mới trả lời trước như vậy.
Tạo ra chỉ là khởi đầu, và nếu vận hành một dịch vụ khoảng 10 năm thì sẽ phát sinh đủ thứ chuyện ở giữa chừng; muốn trụ vững qua những lúc đó thì phải có nền tảng cơ bản... cần phải học.
Trước hết, trong ý tôi nói về việc "ứng dụng AI trong phạm vi domain", thì chuyện con người đảm nhiệm thiết kế và điều phối là điều hiển nhiên...
Thực ra, có lẽ ngày xưa thì khác, nhưng bây giờ khi ai cũng biết giới hạn của LLM rồi thì đây là chuyện quá đương nhiên, đến mức chẳng cần phải nói ra nữa.
Tiếp theo là trường hợp những người bình thường không có kiến thức phát triển dùng LLM,
có vẻ như cả bài gốc, Hacker News lẫn tôi đều chưa từng nói về chuyện này, nhưng dù sao thì ngay cả trong trường hợp đó, chất lượng cũng đã đạt đến mức người dùng có thể hài lòng với kết quả.
Nếu không phải vậy thì Bolt.new, v0, hay cả Cursor chắc cũng không nhận được những đánh giá như bây giờ.
Điều khó là đưa ra quyết định nên tái phát minh đến đâu và nên dựa vào phụ thuộc bên ngoài đến mức nào.
Trong mọi trường hợp, việc chọn phụ thuộc đó để tiết kiệm thời gian dù bản thân mình có thể tự làm ra nó, và việc bị trói vào phụ thuộc vì nếu không có nó thì không thể tạo ra dịch vụ, là hai câu chuyện hoàn toàn khác nhau.
Có thể điều này không khả thi với mọi đoạn mã (chẳng hạn như hệ điều hành), nhưng sẽ rất hữu ích cho việc hiểu hệ thống nếu cố gắng tiến càng nhiều về phía trước càng tốt.
Tôi nghĩ có lẽ đang có một chút hiểu lầm trong việc nắm bắt ý nghĩa mà tác giả muốn truyền đạt.
Tác giả tập trung vào hiệu năng, độ ổn định và kiến trúc dễ bảo trì cùng tính nhất quán của mã trong dự án mình quản lý; mà tiêu biểu là kiến trúc và tính nhất quán của mã lại là một trong những lĩnh vực mà các LLM hiện nay thực sự làm rất kém.
Đặc biệt, mảng web là nơi có rất nhiều người đổ vào làm, và tư tưởng kiểu “miễn sao chạy được là được” cũng rất mạnh, nên có vô số đoạn mã chất lượng thấp đã được triển khai. Và vì LLM được huấn luyện dựa trên những thứ đó, chất lượng đầu ra rơi xuống mức khó tin.
Cứ thử yêu cầu GPT kiểu: "Tôi định đưa vào frontend web, hãy triển khai thuật toán quicksort bằng js giúp tôi" xem. Nếu bạn không tìm ra vấn đề trong đầu ra của nó, thì tôi nghĩ cuộc thảo luận này cũng không còn nhiều ý nghĩa.
Xem các bài viết trước đây của người viết thì có vẻ họ là một lập trình viên phát triển game.
Vì kiến thức và tài liệu về phát triển game không được LLM học với khối lượng lớn, nên khác với trường hợp ứng dụng CRUD, có vẻ tác giả bài viết cảm nhận rõ hơn các giới hạn của LLM.
Tôi đã đọc hết và cuối cùng nghĩ rằng chính vì điều này mà tác giả có góc nhìn hơi thiên lệch.
Dĩ nhiên, làm theo nội dung bài viết thì gần như là điều mang tính giáo khoa nên cũng đúng thôi,
nhưng tôi cho rằng AI đã làm đủ tốt ở mảng CRUD và frontend, nơi có rất nhiều tài liệu để học.
Có lẽ cần tận dụng nó tốt nhất có thể trong chính domain của mình.
Tôi đã nhờ bot AI của GN+ trích xuất kịch bản YouTube rồi tóm tắt, và hiệu năng khá tốt.
Xem video thì có quá nhiều nên rất mệt, nhưng có vẻ đây là một cách hay.
Tục ngữ vốn chứa đựng ý nghĩa của nó, nhưng ngày càng có nhiều người chỉ diễn giải theo mặt chữ
Nếu mấy kiểu chủ trương như vậy thành trào lưu thì lại chẳng mấy chốc phòng họp bị biến thành một mớ hỗn loạn
Đám nghiện giấy tờ lại hưng phấn quậy phá, rồi cùng một thất bại ấy năm nào cũng lặp lại
Việc này gắn khá nhiều với tiêu chuẩn luật lao động của từng quốc gia.. nhiều công ty ở Mỹ thường chỉ luân phiên nhau, nếu có giai đoạn không thể đảm nhận thì đổi thứ tự cho nhau. Đó là cách làm phổ biến. Vì đây là việc khá vất vả.. cũng có những công ty có đội ngũ chuyên trách on-call.
Ở châu Âu thì gần như sẽ có khoản bồi thường riêng vì tính chất công việc đã thay đổi hoặc vì đó là làm ngoài giờ.
Còn ở Hàn Quốc thì thường làm qua loa do ảnh hưởng của chế độ lương gộp. On-call rõ ràng cũng là làm việc, nhưng lại được tô vẽ như thể khoản phụ cấp cho khoảng thời gian đó là một phúc lợi.
Thực ra dùng hết tất cả các dịch vụ đó cũng đã khó rồi, nên việc có MCP là một lợi thế lớn.
Nếu sau này chỉ cần duy trì API tốt thì có vẻ sẽ khá hữu ích.
Phần cứng của Apple đúng là rất xuất sắc, nhưng phần mềm thì đầy rẫy ý đồ muốn trói buộc người dùng.
Ngay cả khi chỉ muốn chạy một ứng dụng do chính mình tạo và build trên đúng thiết bị của mình, bạn cũng cần một gói đăng ký 100 đô la.
Nếu là lập trình viên dùng các ứng dụng mã nguồn mở quy mô nhỏ đến vừa và tự build để dùng,
thì trên thiết bị Apple, thay vì phải lợi dụng lỗ hổng để jailbreak rồi sideload, cứ dùng Android còn thoải mái hơn.
Bên mình trả cho thời gian trực chờ bằng một nửa lương theo giờ, hỗ trợ chi phí viễn thông, còn thời gian thực sự hỗ trợ thì được tính là làm thêm giờ với hệ số 1,5.
Có vẻ như bạn chưa hiểu rõ vì sao tôi nhắc đến lĩnh vực của tác giả và “miền chuyên môn của bản thân” nghĩa là gì.
Giao mọi quyết định cho AI mà không có suy nghĩ riêng thì có vẻ ngớ ngẩn,
nhưng tôi cũng không hiểu lắm những người đứng ở thái cực ngược lại.
Cuối cùng, điều tôi muốn hỏi là superscv đang nghĩ nên dùng LLM cho việc lập trình như thế nào thì tốt?
Hàn Quốc rồi cũng sẽ phải đều đặn (...) kéo dài tuổi nghỉ hưu vì vấn đề lương hưu thôi...
Điểm bùng phát có lẽ sẽ là thời điểm cứ tăng mãi tăng mãi rồi vượt cả tuổi thọ trung bình
(Có vẻ như Nga đã thành ra như vậy rồi thì phải..)
Tóm tắt,
Tác giả: Nhà phát triển phải tự nâng cao và duy trì năng lực của mình. Thậm chí AI còn không hoạt động tốt đến vậy.
crawler: Ủa? Tôi thì dùng rất ổn mà?
superscv: Có nhiều vấn đề lắm...
crawler: Phải tinh chỉnh cho phù hợp rồi mới dùng chứ
superscv: Có vẻ ngay từ đầu đã đi quá xa khỏi thông điệp mà tác giả muốn truyền đạt..
Thông điệp của tác giả có phần hơi mạnh, nhưng nếu đọc kỹ bài viết thì đó không phải là "đừng dùng AI". Bài viết có đưa ra gợi ý về việc nên tận dụng nó như thế nào, và ý chính là bản thân lập trình viên không được thiếu năng lực.
Nếu nhìn vào lý do vì sao thông điệp của tác giả lại tạo cảm giác mạnh như vậy, thì có thể thấy nó được xây dựng như một góc nhìn phản biện trước quan điểm cho rằng sẽ có thể phát triển phần mềm bằng copilot (mang sắc thái phụ thuộc nhiều vào copilot trong phát triển). Vì thế, tác giả đã dẫn dắt thông điệp theo hướng rằng các lập trình viên không nên tự đặt mình vào một lập trường làm tổn hại giá trị tồn tại của chính mình.
Tác giả cũng không hề nhắn nhủ rằng "đừng dùng AI", nên nếu nói đến việc tận dụng AI thì rốt cuộc cũng sẽ nằm đâu đó ở một điểm thỏa hiệp. Vì vậy, thông điệp tổng thể cũng có phần khá giống với điều bạn vừa trả lời trước đó.
Tuy nhiên, trong nội dung bạn viết ban đầu, tôi khó đồng ý với phần gọi đó là một "góc nhìn thiên lệch", nên mới trả lời trước như vậy.
Tạo ra chỉ là khởi đầu, và nếu vận hành một dịch vụ khoảng 10 năm thì sẽ phát sinh đủ thứ chuyện ở giữa chừng; muốn trụ vững qua những lúc đó thì phải có nền tảng cơ bản... cần phải học.
Trước hết, trong ý tôi nói về việc "ứng dụng AI trong phạm vi domain", thì chuyện con người đảm nhiệm thiết kế và điều phối là điều hiển nhiên...
Thực ra, có lẽ ngày xưa thì khác, nhưng bây giờ khi ai cũng biết giới hạn của LLM rồi thì đây là chuyện quá đương nhiên, đến mức chẳng cần phải nói ra nữa.
Tiếp theo là trường hợp những người bình thường không có kiến thức phát triển dùng LLM,
có vẻ như cả bài gốc, Hacker News lẫn tôi đều chưa từng nói về chuyện này, nhưng dù sao thì ngay cả trong trường hợp đó, chất lượng cũng đã đạt đến mức người dùng có thể hài lòng với kết quả.
Nếu không phải vậy thì Bolt.new, v0, hay cả Cursor chắc cũng không nhận được những đánh giá như bây giờ.
Điều khó là đưa ra quyết định nên tái phát minh đến đâu và nên dựa vào phụ thuộc bên ngoài đến mức nào.
Trong mọi trường hợp, việc chọn phụ thuộc đó để tiết kiệm thời gian dù bản thân mình có thể tự làm ra nó, và việc bị trói vào phụ thuộc vì nếu không có nó thì không thể tạo ra dịch vụ, là hai câu chuyện hoàn toàn khác nhau.
Có thể điều này không khả thi với mọi đoạn mã (chẳng hạn như hệ điều hành), nhưng sẽ rất hữu ích cho việc hiểu hệ thống nếu cố gắng tiến càng nhiều về phía trước càng tốt.
Tôi nghĩ có lẽ đang có một chút hiểu lầm trong việc nắm bắt ý nghĩa mà tác giả muốn truyền đạt.
Tác giả tập trung vào hiệu năng, độ ổn định và kiến trúc dễ bảo trì cùng tính nhất quán của mã trong dự án mình quản lý; mà tiêu biểu là kiến trúc và tính nhất quán của mã lại là một trong những lĩnh vực mà các LLM hiện nay thực sự làm rất kém.
Đặc biệt, mảng web là nơi có rất nhiều người đổ vào làm, và tư tưởng kiểu “miễn sao chạy được là được” cũng rất mạnh, nên có vô số đoạn mã chất lượng thấp đã được triển khai. Và vì LLM được huấn luyện dựa trên những thứ đó, chất lượng đầu ra rơi xuống mức khó tin.
Cứ thử yêu cầu GPT kiểu: "Tôi định đưa vào frontend web, hãy triển khai thuật toán quicksort bằng js giúp tôi" xem. Nếu bạn không tìm ra vấn đề trong đầu ra của nó, thì tôi nghĩ cuộc thảo luận này cũng không còn nhiều ý nghĩa.
Tôi đã đọc hết và cuối cùng nghĩ rằng chính vì điều này mà tác giả có góc nhìn hơi thiên lệch.
Dĩ nhiên, làm theo nội dung bài viết thì gần như là điều mang tính giáo khoa nên cũng đúng thôi,
nhưng tôi cho rằng AI đã làm đủ tốt ở mảng CRUD và frontend, nơi có rất nhiều tài liệu để học.
Có lẽ cần tận dụng nó tốt nhất có thể trong chính domain của mình.
Công ty là nơi để học hỏi sao? Hay là nơi tái tạo giá trị bằng cách tận dụng những bánh xe do người khác làm ra?
https://vi.news.hada.io/topic?id=21091
Đọc xong bài này rồi đọc tiếp thì thấy có vẻ đúng thật.
Mục số 1 đúng là một thay đổi như cơn ác mộng, hoàn toàn không muốn chấp nhận. Cảnh việc lần vết lịch sử mã nguồn trở nên vô nghĩa.
Tôi đã nhờ bot AI của GN+ trích xuất kịch bản YouTube rồi tóm tắt, và hiệu năng khá tốt. Xem video thì có quá nhiều nên rất mệt, nhưng có vẻ đây là một cách hay.
Là vì bạn chưa từng gặp một nơi làm Electron thực sự giỏi thôi ~
... chắc kiểu đang nói vậy đó haha
Tục ngữ vốn chứa đựng ý nghĩa của nó, nhưng ngày càng có nhiều người chỉ diễn giải theo mặt chữ
Nếu mấy kiểu chủ trương như vậy thành trào lưu thì lại chẳng mấy chốc phòng họp bị biến thành một mớ hỗn loạn
Đám nghiện giấy tờ lại hưng phấn quậy phá, rồi cùng một thất bại ấy năm nào cũng lặp lại
Việc này gắn khá nhiều với tiêu chuẩn luật lao động của từng quốc gia.. nhiều công ty ở Mỹ thường chỉ luân phiên nhau, nếu có giai đoạn không thể đảm nhận thì đổi thứ tự cho nhau. Đó là cách làm phổ biến. Vì đây là việc khá vất vả.. cũng có những công ty có đội ngũ chuyên trách on-call.
Ở châu Âu thì gần như sẽ có khoản bồi thường riêng vì tính chất công việc đã thay đổi hoặc vì đó là làm ngoài giờ.
Còn ở Hàn Quốc thì thường làm qua loa do ảnh hưởng của chế độ lương gộp. On-call rõ ràng cũng là làm việc, nhưng lại được tô vẽ như thể khoản phụ cấp cho khoảng thời gian đó là một phúc lợi.
Thực ra dùng hết tất cả các dịch vụ đó cũng đã khó rồi, nên việc có MCP là một lợi thế lớn.
Nếu sau này chỉ cần duy trì API tốt thì có vẻ sẽ khá hữu ích.
Phần cứng của Apple đúng là rất xuất sắc, nhưng phần mềm thì đầy rẫy ý đồ muốn trói buộc người dùng.
Ngay cả khi chỉ muốn chạy một ứng dụng do chính mình tạo và build trên đúng thiết bị của mình, bạn cũng cần một gói đăng ký 100 đô la.
Nếu là lập trình viên dùng các ứng dụng mã nguồn mở quy mô nhỏ đến vừa và tự build để dùng,
thì trên thiết bị Apple, thay vì phải lợi dụng lỗ hổng để jailbreak rồi sideload, cứ dùng Android còn thoải mái hơn.
Bên mình trả cho thời gian trực chờ bằng một nửa lương theo giờ, hỗ trợ chi phí viễn thông, còn thời gian thực sự hỗ trợ thì được tính là làm thêm giờ với hệ số 1,5.
Có vẻ có phe C# đang ẩn mình ở giữa nhỉ