Có lẽ gần như không thể đo lường mức độ đóng góp một cách khách quan giữa việc sử dụng và kết quả đầu ra, nên trừ khi là các gói như enterprise thì liệu có khả thi không nhỉ;;
Anh Kim. Tôi mạo muội muốn góp một lời khuyên. Không có gì khác, chỉ là đừng dùng AI GTP? quá nhiều. Nếu có sự tiện lợi thì rủi ro cũng tăng lên. Để mổ trâu thì có lưỡi dao tương xứng, còn bắt gà thì có cần đến dao không? Có khi cách đơn giản mới là đáp án đúng.
Có GitHub, có Google, có những cách đơn giản. Không cần gắn sao, cũng không tốn thời gian, sau này còn có cả cách code chay nữa.
Giả sử anh Kim là một vị tướng ngoài chiến trường. Chẳng phải điều đương nhiên là phải thắng trận sao? Chiến lược phù hợp với tình huống ư? Chỉ áp chế bằng lục quân thôi sao? Không phải vậy. Ý kiến của tôi là tìm bằng Google có thể nhanh hơn, tất nhiên còn tùy từng người, và GPT cũng có thể tốt. Tôi góp ý như vậy vì thấy AI chẳng phải là con dao để mổ trâu hay sao.
Đó là một trong những nhu cầu chính của con người: được xã hội công nhận giá trị của bản thân.
Nhưng khi về sau phần lớn sẽ bị AI thay thế, tôi cũng tò mò không biết con người sẽ giải quyết nhu cầu về cảm giác hữu ích này như thế nào. Có thể là game chăng... Dù sao thì trong thế giới thực, cuối cùng con người cũng sẽ kém hiệu quả hơn máy móc.
Nghĩ theo một khía cạnh nào đó thì đây có lẽ là cuộc sống lý tưởng nhất. Làm việc bằng động lực nội tại, và nếu công việc đó còn có thể nuôi sống bản thân nữa thì càng tốt. Tối đa hóa ảnh hưởng/phần thưởng cũng là một lựa chọn, nhưng không phải đáp án đúng cho tất cả mọi người, và tôi nghĩ cuộc đời là quá trình mỗi người tự ghép nên bức tranh theo tiêu chuẩn của riêng mình.
Và rốt cuộc, quan hệ lao động là một mối quan hệ được trả công để bị “khai thác năng lực”. Tuy vậy, nếu bạn không thích cảm giác “mình vất vả thế này mà lại được đền đáp ít hơn người bên cạnh?”, thì khi đó tôi nghĩ đúng là nên chuyển hướng sang chiến lược tối đa hóa ảnh hưởng/phần thưởng.
Còn tôi thì có vẻ đã sống theo chiến lược “chỉ cần công việc đủ thú vị thì tôi sẽ bán mình với giá rẻ”. Cũng giống như khi mua đồ, tôi luôn thích những thứ có giá trị lớn hơn số tiền mình bỏ ra.
Cá nhân tôi thấy những điểm như áp dụng cấu trúc kiểu Cascading Replication hoặc vượt qua giới hạn kỹ thuật bằng vận hành là rất thú vị. Về phần này, tôi đã ghi lại suy nghĩ của mình dài hơn một chút trên Facebook. https://www.facebook.com/share/p/1Kp8V917bL/
Sức mạnh của một instance đơn lẻ: Có nhiều phản ứng cho rằng việc xử lý lưu lượng ở quy mô 800 triệu người dùng bằng một Postgres (ghi) duy nhất mà không cần sharding một lần nữa khẳng định rằng “máy chủ DB khổng lồ đúng là bạn của chúng ta (Big DB servers are your friend)” và cho thấy tính hiệu quả của vertical scaling.
Sự mỉa mai của sharding so với refactoring: Về đoạn trong bài viết nói rằng “họ không chọn sharding vì việc refactor ứng dụng hiện có quá phức tạp”, đã có những lời đùa châm biếm lẫn phê bình rằng “thật mỉa mai khi một công ty bán AI hỗ trợ lập trình lại nói họ không làm được vì refactor quá khó”. (Mặt khác, cũng có ý kiến bênh vực rằng đây là lựa chọn hợp lý nếu xét đến độ phức tạp vận hành và chi phí di chuyển mà sharding mang lại.)
Sự tiếc nuối về chiều sâu kỹ thuật: Vì bài viết chủ yếu xoay quanh những nội dung khá chung chung như caching, connection pooling, v.v., nên cũng có một số ý kiến phê bình cho rằng thiếu chi tiết kỹ thuật cụ thể và “giống một bài viết mang tính quảng bá hơn”.
Thảo luận liên quan đến Rust: Trong phần bình luận, ngoài nội dung chính của bài viết, còn có những trao đổi kỹ thuật đi sâu hơn khi mọi người chia sẻ cách tận dụng kiểm tra tại thời điểm biên dịch của Rust để ngăn chặn tận gốc vấn đề Idle Transaction.
Đã ra mắt được vài tuần, ban đầu không được chú ý nhiều nhưng giờ đột nhiên đang bùng nổ phản hồi; đây là một trợ lý AI. https://github.com/clawdbot/clawdbot cũng được công bố dưới dạng mã nguồn mở.
Hiểu đơn giản là bạn giao việc cho trợ lý Clawdbot như đang trò chuyện trong ứng dụng nhắn tin mình vẫn dùng, như Telegram hay Slack, và nó hoạt động theo kiểu điều khiển toàn bộ máy tính.
Có thể xem đây là phiên bản mở rộng hơn theo hướng rộng hơn của những gì Claude Code/Codex từng làm.
Tôi cũng thấy nó hoạt động rất kỳ lạ suốt một lúc vào hôm qua, nhưng giờ thì có vẻ đã ổn hơn một chút.
Nó kiểu như gắn nhãn spam cho cả những địa chỉ email vốn vẫn nhận bình thường, hoặc để thư rác lọt qua và hiển thị như bình thường.
OpenAI có vẻ kiểu gì cũng sẽ thất bại.
Ý là cứ đưa ra trước rồi xem người khác làm thế nào.
Có lẽ các nhà cung cấp dịch vụ đám mây lại sẽ không thích điều này.
Có lẽ gần như không thể đo lường mức độ đóng góp một cách khách quan giữa việc sử dụng và kết quả đầu ra, nên trừ khi là các gói như enterprise thì liệu có khả thi không nhỉ;;
Không rõ bài này viết cho ai; nếu phần thân là chủ đề chính thì nội dung cũng nên được triển khai theo đúng chủ đề với bố cục mở-thân-kết chứ?
Cái này hình như cũng dùng Claude Code qua OAuth.. chắc sẽ có nguy cơ bị ban nhỉ?
Tôi đồng ý. Và dù thích hay không thì nó đã là hiện thực rồi..
Vì rào cản đã thấp hơn, tôi lo rằng phần mềm chất lượng thấp cũng sẽ bị sản xuất hàng loạt tương ứng.
Vậy thì trước hết hãy công khai hồ sơ chứng minh rằng toàn bộ dữ liệu dùng để huấn luyện mô hình AI đều đã được thu thập một cách hợp pháp đi đã.
Anh Kim. Tôi mạo muội muốn góp một lời khuyên. Không có gì khác, chỉ là đừng dùng AI GTP? quá nhiều. Nếu có sự tiện lợi thì rủi ro cũng tăng lên. Để mổ trâu thì có lưỡi dao tương xứng, còn bắt gà thì có cần đến dao không? Có khi cách đơn giản mới là đáp án đúng.
Có GitHub, có Google, có những cách đơn giản. Không cần gắn sao, cũng không tốn thời gian, sau này còn có cả cách code chay nữa.
Giả sử anh Kim là một vị tướng ngoài chiến trường. Chẳng phải điều đương nhiên là phải thắng trận sao? Chiến lược phù hợp với tình huống ư? Chỉ áp chế bằng lục quân thôi sao? Không phải vậy. Ý kiến của tôi là tìm bằng Google có thể nhanh hơn, tất nhiên còn tùy từng người, và GPT cũng có thể tốt. Tôi góp ý như vậy vì thấy AI chẳng phải là con dao để mổ trâu hay sao.
Đó là một trong những nhu cầu chính của con người: được xã hội công nhận giá trị của bản thân. Nhưng khi về sau phần lớn sẽ bị AI thay thế, tôi cũng tò mò không biết con người sẽ giải quyết nhu cầu về cảm giác hữu ích này như thế nào. Có thể là game chăng... Dù sao thì trong thế giới thực, cuối cùng con người cũng sẽ kém hiệu quả hơn máy móc.
Chi phí vibe coding.. phải trả bao nhiêu đây
Đúng là các cao thủ port DOOM... quá đỉnh.
Người ta vẫn đánh giá GitLab có CI/CD tốt.
Nhưng vì giới hạn của tài khoản miễn phí nên dù có hỗ trợ tiếng Hàn thì tôi vẫn hay nghiêng về GitHub hơn.
Forgejo và Gitea, nền tảng gốc của nó, lại cho cảm giác như bản nhái GitHub nên tôi cũng không mấy muốn dùng.
Sẽ tốt hơn nếu có kèm theo phần giải thích SRE là gì.
Nghĩ theo một khía cạnh nào đó thì đây có lẽ là cuộc sống lý tưởng nhất. Làm việc bằng động lực nội tại, và nếu công việc đó còn có thể nuôi sống bản thân nữa thì càng tốt. Tối đa hóa ảnh hưởng/phần thưởng cũng là một lựa chọn, nhưng không phải đáp án đúng cho tất cả mọi người, và tôi nghĩ cuộc đời là quá trình mỗi người tự ghép nên bức tranh theo tiêu chuẩn của riêng mình.
Và rốt cuộc, quan hệ lao động là một mối quan hệ được trả công để bị “khai thác năng lực”. Tuy vậy, nếu bạn không thích cảm giác “mình vất vả thế này mà lại được đền đáp ít hơn người bên cạnh?”, thì khi đó tôi nghĩ đúng là nên chuyển hướng sang chiến lược tối đa hóa ảnh hưởng/phần thưởng.
Còn tôi thì có vẻ đã sống theo chiến lược “chỉ cần công việc đủ thú vị thì tôi sẽ bán mình với giá rẻ”. Cũng giống như khi mua đồ, tôi luôn thích những thứ có giá trị lớn hơn số tiền mình bỏ ra.
Trời ơi.
Cá nhân tôi thấy những điểm như áp dụng cấu trúc kiểu Cascading Replication hoặc vượt qua giới hạn kỹ thuật bằng vận hành là rất thú vị. Về phần này, tôi đã ghi lại suy nghĩ của mình dài hơn một chút trên Facebook. https://www.facebook.com/share/p/1Kp8V917bL/
Tóm tắt thảo luận trên Hacker News: https://news.ycombinator.com/item?id=46725300
Sức mạnh của một instance đơn lẻ: Có nhiều phản ứng cho rằng việc xử lý lưu lượng ở quy mô 800 triệu người dùng bằng một Postgres (ghi) duy nhất mà không cần sharding một lần nữa khẳng định rằng “máy chủ DB khổng lồ đúng là bạn của chúng ta (Big DB servers are your friend)” và cho thấy tính hiệu quả của vertical scaling.
Sự mỉa mai của sharding so với refactoring: Về đoạn trong bài viết nói rằng “họ không chọn sharding vì việc refactor ứng dụng hiện có quá phức tạp”, đã có những lời đùa châm biếm lẫn phê bình rằng “thật mỉa mai khi một công ty bán AI hỗ trợ lập trình lại nói họ không làm được vì refactor quá khó”. (Mặt khác, cũng có ý kiến bênh vực rằng đây là lựa chọn hợp lý nếu xét đến độ phức tạp vận hành và chi phí di chuyển mà sharding mang lại.)
Sự tiếc nuối về chiều sâu kỹ thuật: Vì bài viết chủ yếu xoay quanh những nội dung khá chung chung như caching, connection pooling, v.v., nên cũng có một số ý kiến phê bình cho rằng thiếu chi tiết kỹ thuật cụ thể và “giống một bài viết mang tính quảng bá hơn”.
Thảo luận liên quan đến Rust: Trong phần bình luận, ngoài nội dung chính của bài viết, còn có những trao đổi kỹ thuật đi sâu hơn khi mọi người chia sẻ cách tận dụng kiểm tra tại thời điểm biên dịch của Rust để ngăn chặn tận gốc vấn đề
Idle Transaction.Đã ra mắt được vài tuần, ban đầu không được chú ý nhiều nhưng giờ đột nhiên đang bùng nổ phản hồi; đây là một trợ lý AI.
https://github.com/clawdbot/clawdbot cũng được công bố dưới dạng mã nguồn mở.
Bài viết dưới đây của MacStories có giải thích chi tiết hơn một chút.
Clawdbot đã cho tôi thấy tương lai của trợ lý AI cá nhân sẽ trông như thế nào.
Nếu xem The Ultimate Clawdbot Posts on X do Robert Scoble tổng hợp,
bạn sẽ thấy khá nhiều nội dung đã được sắp xếp riêng ở đó.
Hiểu đơn giản là bạn giao việc cho trợ lý Clawdbot như đang trò chuyện trong ứng dụng nhắn tin mình vẫn dùng, như Telegram hay Slack, và nó hoạt động theo kiểu điều khiển toàn bộ máy tính.
Có thể xem đây là phiên bản mở rộng hơn theo hướng rộng hơn của những gì Claude Code/Codex từng làm.
Tôi cũng thấy nó hoạt động rất kỳ lạ suốt một lúc vào hôm qua, nhưng giờ thì có vẻ đã ổn hơn một chút.
Nó kiểu như gắn nhãn spam cho cả những địa chỉ email vốn vẫn nhận bình thường, hoặc để thư rác lọt qua và hiển thị như bình thường.
https://google.com/appsstatus/dashboard/…
Xem trạng thái bên tiếng Anh thì có vẻ sự cố đã kéo dài khoảng 20 giờ.