Có ai biết emacs nghĩa là gì không? Dù đúng là nó có ý nghĩa, nhưng mấy cái tên viết tắt thì nhìn qua cũng chẳng thể biết được, mà đã là tên thì… Với lại giờ chỉ đặt tên theo chức năng thôi thì cũng đã có quá nhiều dự án rồi.
Người trao quyền cho AI rốt cuộc vẫn là con người, nhưng xét thực tế thì tôi nghĩ AI rất có khả năng sẽ được giao quyền hạn và mức độ tự chủ lớn hơn hiện nay.
Nhìn vào xu hướng hiện tại, phạm vi giao cho AI làm thay con người đang dần mở rộng. Không chỉ viết báo cáo hay vibe coding, mà còn có xu hướng muốn để AI tác động đến thế giới bên ngoài giao diện chat thông qua trình duyệt web hay thậm chí là robot.
Nếu vậy, ban điều hành rốt cuộc sẽ muốn AI thay thế hoàn toàn con người trong một số công việc hay lĩnh vực nhất định, và nếu điều đó trở nên khả thi thì ít nhất trong phạm vi đó AI sẽ có quyền hạn và mức độ tự chủ tương đương con người.
Vì thế, tôi nghĩ cần xem khả năng một ngày nào đó trong tương lai AI được trao quyền ở mức ngang con người là khá cao.
Khi đó, việc AI sẽ hành xử thế nào khi được trao nhiều quyền hạn và tự chủ như vậy đương nhiên sẽ trở nên rất quan trọng.
Về mặt cấu trúc thì nên làm thế nào cho tốt và hợp lý, phần này được tổng hợp khá rõ trong các câu trả lời của dòng GPT. Họ nói cần có việc xác định phạm vi một cách minh thị, tách biệt quyền hạn, nhiều lớp giám sát trước/sau, và nhiều phương thức để con người có thể can thiệp vào AI. Từ lúc đã liên quan đến các khu vực có thể can thiệp vật lý thì ngay từ đầu việc trao cho AI quyền tự chủ hoàn toàn đã là không phù hợp. Nhưng ngay cả trong trường hợp đó, việc giữ con người ở trong vòng lặp cũng có thể sẽ dần suy yếu vào một ngày nào đó.
Tham khảo thêm thì hiện tôi đang dùng AI chủ yếu ở 3 mảng trong công việc: viết tài liệu hoặc email, phân tích mã nguồn hiện có và các issue hiện tại, tạo và chỉnh sửa mã theo issue.
Trong đó, với tài liệu hay email thì tôi chỉ cần tự đọc lại kết quả rồi dùng nguyên xi hoặc sửa sơ qua là được, nhưng khi có dính đến việc sinh mã hay sửa mã thì tôi dùng thận trọng hơn rất nhiều. Chỉ cần nói kiểu đại khái "sửa cái này giúp tôi" là AI có lúc diễn giải chỉ thị của tôi một cách mơ hồ, thậm chí tự ý đụng vào cả những phần tôi còn chưa hề nhắc đến.
Vì vậy trước khi sửa mã, tôi luôn bắt AI đưa ra tài liệu đặc tả theo STICC trước để được phê duyệt một cách minh thị, và tôi đã đóng điều này thành prompt toàn cục. Công việc chỉnh sửa thực tế thì buộc phải làm đúng y những gì có trong đặc tả, còn sau khi sửa xong thì toàn bộ diff tôi đều tự kiểm tra. Cả việc chạy các lệnh như build cũng luôn phải có sự chấp thuận của tôi, hoặc đơn giản là tôi tự tay chạy trong terminal.
Làm vậy thì có nhược điểm là những thứ nhỏ nhặt đôi khi tự tôi sửa tay còn nhanh hơn, nhưng vẫn tốt hơn là để AI tự tiện đụng vào những thứ linh tinh rồi gây nổ tung. Rốt cuộc nếu nó nổ trong môi trường production thì trách nhiệm vẫn là của tôi mà.
Một câu trích dẫn phản bác định luật Goodhart khiến tôi nghĩ đến câu nói thường được cho là của Peter Drucker: “Nếu không thể đo lường, thì không thể quản lý (If you can't measure it, you can't manage it)”.
Tìm hiểu thêm thì ngay cả Drucker Institute cũng nói rằng Drucker chưa từng nói như vậy.
Ngược lại, tôi lại tìm thấy một câu nói theo hướng đối lập.
Cho rằng nếu không thể đo lường thì không thể quản lý là sai lầm — đó là một huyền thoại đắt giá. (It is wrong to suppose that if you can't measure it, you can't manage it—a costly myth) - Edwards Deming
Việc đặt cho AI câu hỏi như “bạn nghĩ nên trao cho AI bao nhiêu mức tự chủ, quyền hạn?” quả là khá gợi nhiều suy nghĩ.
Nếu CEO hỏi một nhân viên rằng “tôi nên trao cho bạn bao nhiêu quyền hạn?”, thì cảm giác sẽ giống như người đó trả lời “tôi muốn được trao toàn quyền điều hành công ty” vậy. CEO sẽ xem đó là một câu trả lời hay, hay là nghĩ đó là một nhân viên chưa được xã hội hóa đủ tốt, thì còn tùy gu của người đó...
Tuy vậy, tôi nghĩ câu hỏi nên trao cho AI bao nhiêu quyền hạn có lẽ không phải nên hỏi AI, mà nên hỏi các nhà phát triển dùng AI, ban lãnh đạo và những con người sử dụng nó.
Thỉnh thoảng tôi có chỉnh sửa frontend chạy trên intranet nội bộ của công ty, và từng bị mắng vì đưa mấy biểu tượng như ☰ ⋮ ⋯ + vào dashboard mà ban lãnh đạo xem. Họ hỏi chức năng nọ kia biến đâu mất rồi, tôi bảo là bấm nút này là được, thì họ lại nói là không nhìn thấy, cứ viết thẳng bằng văn bản đi, rồi phàn nàn đủ thứ... Cuối cùng có lần tôi phải đưa nó quay lại giao diện kiểu những năm 2000 như trước. Có lẽ chuyện gì cũng vậy, nhưng frontend đúng là khó thật.
Có vẻ như cả Tesla lẫn Rivian đều đang đi theo hướng tự làm chip riêng. Tất nhiên sau thông báo này, giá cổ phiếu đã giảm tới 10%.
Tôi chưa có dịp lái thử Rivian, chỉ mới ngồi bên trong thôi, nhưng chất lượng hoàn thiện thực sự rất tốt.
Họ cũng đã đăng ký thương hiệu và bằng sáng chế ở Hàn Quốc từ năm 2021 rồi, nhưng vẫn chưa nghe tin ra mắt.
Nếu có ai đó nói họ có một con ngỗng đẻ trứng vàng, thì chẳng phải chúng ta cần có khả năng kiểm chứng xem quả trứng đó có thật sự là vàng không, có đúng là con ngỗng đó đẻ ra không, và họ lấy đi điều gì như cái giá của những quả trứng vàng ấy sao.
Tôi đọc lập luận của Stallman rằng để có được điện toán đáng tin cậy thì phải có quyền truy cập vào mã nguồn theo sắc thái như vậy.
Gần đây có một trường hợp phát hiện micro trong sản phẩm tên là nanokvm do sipeed, một nhà sản xuất nền tảng nhúng của Trung Quốc, phát hành.
Tôi biết là có một cảm giác bất an rằng các sản phẩm nhúng của Trung Quốc yếu về bảo mật, thậm chí có thể bị lợi dụng cho các chiến dịch an ninh của chính phủ.
Vì thế, có lẽ do định kiến đó được phản chiếu, nên gần đây cũng đã có bài như thế này về sản phẩm đó. 중국산 NanoKVM에서 숨겨진 마이크를 발견한 과정
Nhưng tôi nghĩ sipeed đã có thể thoát khỏi hiểu lầm như một sự cố ngoài ý muốn vì từ phần cứng đến phát triển phần mềm đều được họ tiến hành theo hướng mã nguồn mở: https://x.com/lexifdev/status/1999340940805439775
Vào thời của Stallman, trong những cuộc thảo luận kiểu này, thay vì chính phủ Trung Quốc thì ở vị trí đó là chính phủ Mỹ thời vẫn còn ảnh hưởng của chủ nghĩa McCarthy và NSA.
Cũng từng có những trường hợp backdoor của NSA mà ban đầu tưởng là thuyết âm mưu nhưng sau đó được chứng minh là có thật, và cả những thứ như printer tracking dots (https://en.wikipedia.org/wiki/Printer_tracking_dots) nữa.
Dạo này, thay vì các thuyết âm mưu có chính phủ can dự, câu chuyện nóng hơn lại là các công ty sống nhờ quảng cáo nghe lén micro trên smartphone để phục vụ quảng cáo nhắm mục tiêu.
Và trong các công ty công nghệ phần mềm, mã nguồn tất nhiên đóng vai trò lớn, nhưng tôi nghĩ sự tiện lợi tổng thể, năng lực vận hành dịch vụ và độ tin cậy còn đóng vai trò lớn hơn.
Dù có lấy được toàn bộ mã nguồn của OpenAI đi nữa, những kẻ đến sau cũng đâu dễ dàng đảm bảo và vận hành ổn định hạ tầng có thể gánh được vô số người dùng, rồi đuổi kịp độ tin cậy thương hiệu của họ.
Có khá nhiều trường hợp vận hành sản phẩm chủ lực theo mô hình mã nguồn mở, có vô số bản fork, nhưng vẫn không đánh mất quyền chủ đạo.
Chỉ cần kể những ví dụ hiện ra ngay lúc này thì cũng có Chrome hay VS Code.
Tất nhiên cũng có những trường hợp đánh mất quyền chủ đạo, như vụ Elastic hay Redis liên quan đến giấy phép mã nguồn mở vì AWS, nhưng tương tự, tôi cho rằng đó cũng là vì hai công ty này tương đối thua kém AWS ở sự tiện lợi, năng lực vận hành dịch vụ và độ tin cậy.
Nói thế nào thì những câu chuyện này suy cho cùng cũng là chuyện mang tính chính trị và ý thức hệ. Nên tôi xin thêm một chút chia sẻ cá nhân.
Với tư cách là người làm phát triển phần mềm là nghề chính, và nghịch phần cứng nhúng như sở thích, thì khi phải đối mặt với các black box không có mã nguồn hay sơ đồ mạch, thực sự là... cực kỳ khó để phát triển và bảo trì.
Khi định phát triển bằng cách dùng một thư viện phần mềm hay phần cứng nào đó, nếu có thể tiếp cận được mã nguồn hay bản thiết kế, hoặc ít nhất là tài liệu đặc tả được sắp xếp tử tế, thì việc phát triển thật sự dễ dàng hơn rất nhiều; còn nếu không thì thực sự rất đau đầu.
Gần đây ở nước ngoài cũng có khá nhiều câu chuyện về quyền được sửa chữa, và một điều khiến tôi ấn tượng là ngày xưa khi mở nắp các thiết bị điện tử ra thì bên trong có vẽ sơ đồ dây để người ta tham khảo lúc sửa chữa. (Gần đây Apple cũng được nói là cung cấp sơ đồ mạch cho các thợ sửa chữa.)
Những trải nghiệm như vậy ảnh hưởng rất lớn đến việc hình thành độ tin cậy với các sản phẩm đó. Dạo này khi chọn công nghệ nào đó hay mua một sản phẩm, điều đầu tiên tôi cân nhắc là nếu nó hỏng hoặc phát sinh vấn đề thì liệu tôi có thể dễ dàng hiểu nó, tự sửa để tiếp tục dùng, hoặc lách qua mà dùng tiếp được hay không.
Nếu định coding kiểu vibe thì sao không làm bằng C đi?
Tin rằng khi code bằng mô hình ngôn ngữ thì nó sẽ tự hiểu và thần kỳ tạo ra những biểu đạt gần với máy móc, đúng là tâm lý của kẻ muốn ăn không ngồi rồi.
Càng bị ràng buộc thì lại càng làm việc tốt trong phạm vi những ràng buộc đó.
Dạo này có vẻ để bản thân bài thuyết trình thật sự có ý nghĩa thì chủ yếu phải xoay quanh các mẹo xử lý AI, nhưng thật tiếc khi cảm giác bản chất của việc thuyết trình ngày càng trở nên dễ dãi và phai nhạt đi.
Tác giả: Thấy chưa
Biểu đồ cân nặng của tôi đang đi lên.
Có ai biết
emacsnghĩa là gì không? Dù đúng là nó có ý nghĩa, nhưng mấy cái tên viết tắt thì nhìn qua cũng chẳng thể biết được, mà đã là tên thì… Với lại giờ chỉ đặt tên theo chức năng thôi thì cũng đã có quá nhiều dự án rồi.Chỉ cần tích lũy đủ tín chỉ OMSCS là có thể tốt nghiệp. Không cần viết luận văn.
Người trao quyền cho AI rốt cuộc vẫn là con người, nhưng xét thực tế thì tôi nghĩ AI rất có khả năng sẽ được giao quyền hạn và mức độ tự chủ lớn hơn hiện nay. Nhìn vào xu hướng hiện tại, phạm vi giao cho AI làm thay con người đang dần mở rộng. Không chỉ viết báo cáo hay vibe coding, mà còn có xu hướng muốn để AI tác động đến thế giới bên ngoài giao diện chat thông qua trình duyệt web hay thậm chí là robot. Nếu vậy, ban điều hành rốt cuộc sẽ muốn AI thay thế hoàn toàn con người trong một số công việc hay lĩnh vực nhất định, và nếu điều đó trở nên khả thi thì ít nhất trong phạm vi đó AI sẽ có quyền hạn và mức độ tự chủ tương đương con người. Vì thế, tôi nghĩ cần xem khả năng một ngày nào đó trong tương lai AI được trao quyền ở mức ngang con người là khá cao.
Khi đó, việc AI sẽ hành xử thế nào khi được trao nhiều quyền hạn và tự chủ như vậy đương nhiên sẽ trở nên rất quan trọng. Về mặt cấu trúc thì nên làm thế nào cho tốt và hợp lý, phần này được tổng hợp khá rõ trong các câu trả lời của dòng GPT. Họ nói cần có việc xác định phạm vi một cách minh thị, tách biệt quyền hạn, nhiều lớp giám sát trước/sau, và nhiều phương thức để con người có thể can thiệp vào AI. Từ lúc đã liên quan đến các khu vực có thể can thiệp vật lý thì ngay từ đầu việc trao cho AI quyền tự chủ hoàn toàn đã là không phù hợp. Nhưng ngay cả trong trường hợp đó, việc giữ con người ở trong vòng lặp cũng có thể sẽ dần suy yếu vào một ngày nào đó.
Tham khảo thêm thì hiện tôi đang dùng AI chủ yếu ở 3 mảng trong công việc: viết tài liệu hoặc email, phân tích mã nguồn hiện có và các issue hiện tại, tạo và chỉnh sửa mã theo issue. Trong đó, với tài liệu hay email thì tôi chỉ cần tự đọc lại kết quả rồi dùng nguyên xi hoặc sửa sơ qua là được, nhưng khi có dính đến việc sinh mã hay sửa mã thì tôi dùng thận trọng hơn rất nhiều. Chỉ cần nói kiểu đại khái "sửa cái này giúp tôi" là AI có lúc diễn giải chỉ thị của tôi một cách mơ hồ, thậm chí tự ý đụng vào cả những phần tôi còn chưa hề nhắc đến. Vì vậy trước khi sửa mã, tôi luôn bắt AI đưa ra tài liệu đặc tả theo STICC trước để được phê duyệt một cách minh thị, và tôi đã đóng điều này thành prompt toàn cục. Công việc chỉnh sửa thực tế thì buộc phải làm đúng y những gì có trong đặc tả, còn sau khi sửa xong thì toàn bộ
difftôi đều tự kiểm tra. Cả việc chạy các lệnh như build cũng luôn phải có sự chấp thuận của tôi, hoặc đơn giản là tôi tự tay chạy trong terminal. Làm vậy thì có nhược điểm là những thứ nhỏ nhặt đôi khi tự tôi sửa tay còn nhanh hơn, nhưng vẫn tốt hơn là để AI tự tiện đụng vào những thứ linh tinh rồi gây nổ tung. Rốt cuộc nếu nó nổ trong môi trường production thì trách nhiệm vẫn là của tôi mà.Một câu trích dẫn phản bác định luật Goodhart khiến tôi nghĩ đến câu nói thường được cho là của Peter Drucker: “Nếu không thể đo lường, thì không thể quản lý (If you can't measure it, you can't manage it)”.
Tìm hiểu thêm thì ngay cả Drucker Institute cũng nói rằng Drucker chưa từng nói như vậy.
Ngược lại, tôi lại tìm thấy một câu nói theo hướng đối lập.
Cho rằng nếu không thể đo lường thì không thể quản lý là sai lầm — đó là một huyền thoại đắt giá. (It is wrong to suppose that if you can't measure it, you can't manage it—a costly myth) - Edwards Deming
Cảm ơn bạn đã chia sẻ thông tin hữu ích :D
Việc đặt cho AI câu hỏi như “bạn nghĩ nên trao cho AI bao nhiêu mức tự chủ, quyền hạn?” quả là khá gợi nhiều suy nghĩ.
Nếu CEO hỏi một nhân viên rằng “tôi nên trao cho bạn bao nhiêu quyền hạn?”, thì cảm giác sẽ giống như người đó trả lời “tôi muốn được trao toàn quyền điều hành công ty” vậy. CEO sẽ xem đó là một câu trả lời hay, hay là nghĩ đó là một nhân viên chưa được xã hội hóa đủ tốt, thì còn tùy gu của người đó...
Tuy vậy, tôi nghĩ câu hỏi nên trao cho AI bao nhiêu quyền hạn có lẽ không phải nên hỏi AI, mà nên hỏi các nhà phát triển dùng AI, ban lãnh đạo và những con người sử dụng nó.
Thỉnh thoảng tôi có chỉnh sửa frontend chạy trên intranet nội bộ của công ty, và từng bị mắng vì đưa mấy biểu tượng như ☰ ⋮ ⋯ + vào dashboard mà ban lãnh đạo xem. Họ hỏi chức năng nọ kia biến đâu mất rồi, tôi bảo là bấm nút này là được, thì họ lại nói là không nhìn thấy, cứ viết thẳng bằng văn bản đi, rồi phàn nàn đủ thứ... Cuối cùng có lần tôi phải đưa nó quay lại giao diện kiểu những năm 2000 như trước. Có lẽ chuyện gì cũng vậy, nhưng frontend đúng là khó thật.
Tiêu đề lại thành
kills.. hahahaCó vẻ như cả Tesla lẫn Rivian đều đang đi theo hướng tự làm chip riêng. Tất nhiên sau thông báo này, giá cổ phiếu đã giảm tới 10%. Tôi chưa có dịp lái thử Rivian, chỉ mới ngồi bên trong thôi, nhưng chất lượng hoàn thiện thực sự rất tốt. Họ cũng đã đăng ký thương hiệu và bằng sáng chế ở Hàn Quốc từ năm 2021 rồi, nhưng vẫn chưa nghe tin ra mắt.
Cảm ơn bạn đã thông cảm.
Nếu có ai đó nói họ có một con ngỗng đẻ trứng vàng, thì chẳng phải chúng ta cần có khả năng kiểm chứng xem quả trứng đó có thật sự là vàng không, có đúng là con ngỗng đó đẻ ra không, và họ lấy đi điều gì như cái giá của những quả trứng vàng ấy sao.
Tôi đọc lập luận của Stallman rằng để có được điện toán đáng tin cậy thì phải có quyền truy cập vào mã nguồn theo sắc thái như vậy.
Gần đây có một trường hợp phát hiện micro trong sản phẩm tên là nanokvm do sipeed, một nhà sản xuất nền tảng nhúng của Trung Quốc, phát hành.
Tôi biết là có một cảm giác bất an rằng các sản phẩm nhúng của Trung Quốc yếu về bảo mật, thậm chí có thể bị lợi dụng cho các chiến dịch an ninh của chính phủ.
Vì thế, có lẽ do định kiến đó được phản chiếu, nên gần đây cũng đã có bài như thế này về sản phẩm đó. 중국산 NanoKVM에서 숨겨진 마이크를 발견한 과정
Nhưng tôi nghĩ sipeed đã có thể thoát khỏi hiểu lầm như một sự cố ngoài ý muốn vì từ phần cứng đến phát triển phần mềm đều được họ tiến hành theo hướng mã nguồn mở: https://x.com/lexifdev/status/1999340940805439775
Vào thời của Stallman, trong những cuộc thảo luận kiểu này, thay vì chính phủ Trung Quốc thì ở vị trí đó là chính phủ Mỹ thời vẫn còn ảnh hưởng của chủ nghĩa McCarthy và NSA.
Cũng từng có những trường hợp backdoor của NSA mà ban đầu tưởng là thuyết âm mưu nhưng sau đó được chứng minh là có thật, và cả những thứ như printer tracking dots (https://en.wikipedia.org/wiki/Printer_tracking_dots) nữa.
Dạo này, thay vì các thuyết âm mưu có chính phủ can dự, câu chuyện nóng hơn lại là các công ty sống nhờ quảng cáo nghe lén micro trên smartphone để phục vụ quảng cáo nhắm mục tiêu.
Và trong các công ty công nghệ phần mềm, mã nguồn tất nhiên đóng vai trò lớn, nhưng tôi nghĩ sự tiện lợi tổng thể, năng lực vận hành dịch vụ và độ tin cậy còn đóng vai trò lớn hơn.
Dù có lấy được toàn bộ mã nguồn của OpenAI đi nữa, những kẻ đến sau cũng đâu dễ dàng đảm bảo và vận hành ổn định hạ tầng có thể gánh được vô số người dùng, rồi đuổi kịp độ tin cậy thương hiệu của họ.
Có khá nhiều trường hợp vận hành sản phẩm chủ lực theo mô hình mã nguồn mở, có vô số bản fork, nhưng vẫn không đánh mất quyền chủ đạo.
Chỉ cần kể những ví dụ hiện ra ngay lúc này thì cũng có Chrome hay VS Code.
Tất nhiên cũng có những trường hợp đánh mất quyền chủ đạo, như vụ Elastic hay Redis liên quan đến giấy phép mã nguồn mở vì AWS, nhưng tương tự, tôi cho rằng đó cũng là vì hai công ty này tương đối thua kém AWS ở sự tiện lợi, năng lực vận hành dịch vụ và độ tin cậy.
Nói thế nào thì những câu chuyện này suy cho cùng cũng là chuyện mang tính chính trị và ý thức hệ. Nên tôi xin thêm một chút chia sẻ cá nhân.
Với tư cách là người làm phát triển phần mềm là nghề chính, và nghịch phần cứng nhúng như sở thích, thì khi phải đối mặt với các black box không có mã nguồn hay sơ đồ mạch, thực sự là... cực kỳ khó để phát triển và bảo trì.
Khi định phát triển bằng cách dùng một thư viện phần mềm hay phần cứng nào đó, nếu có thể tiếp cận được mã nguồn hay bản thiết kế, hoặc ít nhất là tài liệu đặc tả được sắp xếp tử tế, thì việc phát triển thật sự dễ dàng hơn rất nhiều; còn nếu không thì thực sự rất đau đầu.
Gần đây ở nước ngoài cũng có khá nhiều câu chuyện về quyền được sửa chữa, và một điều khiến tôi ấn tượng là ngày xưa khi mở nắp các thiết bị điện tử ra thì bên trong có vẽ sơ đồ dây để người ta tham khảo lúc sửa chữa. (Gần đây Apple cũng được nói là cung cấp sơ đồ mạch cho các thợ sửa chữa.)
Những trải nghiệm như vậy ảnh hưởng rất lớn đến việc hình thành độ tin cậy với các sản phẩm đó. Dạo này khi chọn công nghệ nào đó hay mua một sản phẩm, điều đầu tiên tôi cân nhắc là nếu nó hỏng hoặc phát sinh vấn đề thì liệu tôi có thể dễ dàng hiểu nó, tự sửa để tiếp tục dùng, hoặc lách qua mà dùng tiếp được hay không.
Bạn đã nhìn rất chính xác
Stallman cũng chủ trương rằng đừng dùng cả SaaS
https://www.gnu.org/philosophy/who-does-that-server-really-serve.html
Trông giống phong cách gốm sứ.
Biểu đồ tăng lương của tôi đã 5 năm nay ở mức 0%.
Dù khó có thể khái quát hóa, nhưng trước hết đây chắc chắn là công cụ tốt nhất để thuyết phục ban lãnh đạo.
Nên từ chối sử dụng vì cách thức thực hiện tính toán trên máy chủ của người khác làm xói mòn quyền tự do điện toán của người dùng.
Vậy chẳng phải đây là lập luận rằng nên từ chối không chỉ LLM mà cả mọi dịch vụ đám mây và dịch vụ bên ngoài hay sao...? Hay là bản dịch đã bị sai?
Có vẻ đây là bài viết tôi đã đọc từ rất lâu rồi.. Đây lại là một bài viết tiếp thêm động lực cho chính tôi. Cảm ơn bạn đã đăng lên.
Nếu định coding kiểu vibe thì sao không làm bằng C đi?
Tin rằng khi code bằng mô hình ngôn ngữ thì nó sẽ tự hiểu và thần kỳ tạo ra những biểu đạt gần với máy móc, đúng là tâm lý của kẻ muốn ăn không ngồi rồi.
Càng bị ràng buộc thì lại càng làm việc tốt trong phạm vi những ràng buộc đó.
Dạo này có vẻ để bản thân bài thuyết trình thật sự có ý nghĩa thì chủ yếu phải xoay quanh các mẹo xử lý AI, nhưng thật tiếc khi cảm giác bản chất của việc thuyết trình ngày càng trở nên dễ dãi và phai nhạt đi.