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.
[đã xóa liên kết] Có vẻ tác giả đã để ảnh chụp màn hình phiên bản Android ở đây. Càng dùng càng thấy đây là một công cụ kỳ lạ theo cách riêng. Cộng đồng cũng rất geek và có nhiều điều đáng ngạc nhiên.
Chỉ cần mỗi Emacs là có thể làm đủ thứ. Gần đây còn cài được trên Android nên thật tuyệt khi có thể tận dụng nguyên các tính năng trên desktop. Tôi đang đào sâu với chủ đề công cụ quản lý tri thức bằng Emacs. Đến khi con tôi hiện đang học mẫu giáo vào tiểu học, có lẽ lúc đó sẽ dùng Emacs để lifelogging nhỉ haha. Vì chỉ cần thành thạo một công cụ thôi, nên về lâu dài đây là cách giúp giảm bớt những băn khoăn.
Nhưng nếu chỉ cần nói rõ nguyên lý làm rối mã cho người dùng, và nhận được sự đồng ý với điều khoản miễn trừ rằng có thể bị một số mô hình cụ thể phá được, thì có lẽ cũng không nhất thiết phải hoàn tiền đâu, bạn thật sự rất chu đáo với người dùng haha
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ỉ
> Nói thẳng ra thì bây giờ phát triển Java cũng đâu nhất thiết phải dùng sản phẩm của JetBrains
Phần này thì... tôi hơi khó mà đồng ý được, huhu...
[đã xóa liên kết] Có vẻ tác giả đã để ảnh chụp màn hình phiên bản Android ở đây. Càng dùng càng thấy đây là một công cụ kỳ lạ theo cách riêng. Cộng đồng cũng rất geek và có nhiều điều đáng ngạc nhiên.
Chỉ cần mỗi Emacs là có thể làm đủ thứ. Gần đây còn cài được trên Android nên thật tuyệt khi có thể tận dụng nguyên các tính năng trên desktop. Tôi đang đào sâu với chủ đề công cụ quản lý tri thức bằng Emacs. Đến khi con tôi hiện đang học mẫu giáo vào tiểu học, có lẽ lúc đó sẽ dùng Emacs để lifelogging nhỉ haha. Vì chỉ cần thành thạo một công cụ thôi, nên về lâu dài đây là cách giúp giảm bớt những băn khoăn.
[đã xóa liên kết]
Nhưng nếu chỉ cần nói rõ nguyên lý làm rối mã cho người dùng, và nhận được sự đồng ý với điều khoản miễn trừ rằng có thể bị một số mô hình cụ thể phá được, thì có lẽ cũng không nhất thiết phải hoàn tiền đâu, bạn thật sự rất chu đáo với người dùng haha