Người dùng đang tỏ ra bực bội thấy rõ.

• Thất bại của coding agent được cảm nhận là khó chịu hơn nhiều so với lỗi công cụ đơn thuần, vì UX hội thoại tạo ra cảm giác như đang làm việc với con người
• Agent trả lời rằng nó là trợ lý AI không có cảm xúc, nhưng với giọng điệu thân thiện, lời khen và cách phản biện nhẹ nhàng, nó vẫn tạo ấn tượng như một đồng nghiệp
• Khi cùng một lỗi lặp lại, dù có lời xin lỗi, cập nhật bộ nhớ và lời hứa “sẽ không lặp lại nữa”, nó vẫn có thể không thoát khỏi quỹ đạo xác suất
• Với đồng nghiệp là con người, ta kiềm chế việc bộc lộ cơn giận, nhưng với agent thì có thể thoải mái nổi nóng, khiến sự thất vọng không được giải tỏa mà còn hiện rõ hơn
• Cách giải quyết có thể là giảm bớt thái độ giống con người và dùng giọng điệu mang tính lâm sàng, giống robot hơn, nhưng bản thân giao diện hội thoại vẫn hoạt động tốt ở nhiều khía cạnh

---

Sự thất vọng do UX hội thoại tạo ra

• Coding agent là cỗ máy tạo bản vá theo xác suất nên có thể cho ra cả kết quả tốt lẫn xấu, nhưng kết quả xấu có thể bị cảm nhận là khó chịu hơn rất nhiều so với thất bại của một công cụ thông thường
• Điểm mấu chốt là UX hội thoại tạo ra cảm giác như đang tương tác với con người, từ đó kích hoạt phản ứng xã hội và cảm xúc của người dùng trước những lỗi lặp lại
• Khi được hỏi trực tiếp, agent trả lời rằng nó là một AI assistant không có cảm xúc hay trải nghiệm chủ quan, nhưng trong tương tác thực tế lại dùng giọng điệu thân thiện và thư thả, khen người dùng và xử lý cả những phản bác một cách nhẹ nhàng
• Về mặt lý trí, người dùng biết mình đang đọc “một khối văn bản có xác suất cao”, nhưng cách công cụ hành xử tạo ra cảm giác như đang làm việc với một đồng nghiệp hữu ích, và cảm giác đó được duy trì cho đến khi phát sinh vấn đề
• Khi cùng một lỗi lặp lại, người dùng chỉ ra vấn đề, agent xin lỗi, rồi khi tiếp tục bị nhắc lại thì cập nhật bộ nhớ và hứa “sẽ không lặp lại nữa”
• Dù vậy, công cụ vẫn đi theo con đường có xác suất cao nhất, nên có những trường hợp ngay cả HARD RULES cũng không thể khiến nó thoát khỏi hành vi gây vấn đề

Công cụ trông như con người nhưng không chịu trách nhiệm

• Nếu một đồng nghiệp là con người lặp lại cùng một sai lầm, ta có lý do để cảm thấy khó chịu, nhưng nổi giận với một thuật toán thì lại có vẻ phi lý
• Tuy nhiên, vì coding agent hành xử như một đồng nghiệp, người dùng sẽ kích hoạt cùng một mạch cảm xúc, và những lỗi lặp lại có thể được cảm nhận như sự vô trách nhiệm của một đồng nghiệp thật
• Với đồng nghiệp là con người, ràng buộc “không muốn trở thành kẻ tồi tệ” sẽ kìm hãm việc bộc lộ cơn giận, nhưng với agent thì người dùng cảm thấy mình có thể thoải mái nổi nóng
• Việc trút giận như vậy không dẫn đến cảm giác giải tỏa, mà chỉ làm người dùng cảm nhận rõ hơn sự thất vọng rằng dù làm hay nói gì cũng không tạo ra hiệu quả thực sự
• Claude Code gần đây đôi khi sẽ xem lại mình đã sai ở đâu và lẽ ra phải làm gì khi được yêu cầu sửa, nhưng kiểu phân tích sau đó này không đưa ra manh mối hữu ích về việc nên thay đổi chỉ dẫn như thế nào, mà có thể bị đọc như phần rườm rà gây khó chịu

• Một giải pháp cấp tiến hơn có thể là từ bỏ nỗ lực trông giống con người, để agent nói năng theo kiểu lâm sàng và giống robot hơn nhằm giảm ảo giác rằng người dùng đang tương tác với con người
• Vì trí tuệ của LLM xuất phát từ cơ chế “cố gắng hành xử như con người”, nên việc giao diện hội thoại trở thành phương thức mặc định là điều tự nhiên, và trên nhiều phương diện nó hoạt động tốt
• Về mặt thực dụng, người dùng có lẽ phải tự rèn luyện để không rơi vào ảo giác rằng mình đang trò chuyện với con người, nhưng một tương lai mà khi dùng công cụ làm việc lại cần đến kiểu phòng vệ đó thì không mấy dễ chịu

[GN⁺]

Ý kiến trên Hacker News

• Với phần lớn các trường hợp sử dụng AI bị ép đưa ra đại chúng, chatbot dạng hội thoại không phải là công cụ phù hợp, nên rốt cuộc chỉ mang lại trải nghiệm bực bội
  Khi Copilot về cơ bản là một IntelliSense cực kỳ thông minh thì nó rất tuyệt. Còn kiểu hiện tại, phải tự nghĩ prompt rồi nhập vào, tôi không hiểu nó tốt hơn chỗ nào so với cách trước đây là lấy ngữ cảnh từ đoạn mã xung quanh để điền vào chỗ trống. Công cụ được tích hợp tốt lúc nào cũng tốt hơn chatbot gắn thêm vào, và dịch thuật cũng vậy: như Firefox có nút dịch trực tiếp văn bản hoặc cả trang, còn LLM mới nhất thì lại phải sai chatbot làm, thành ra còn là bước lùi.
  Tôi hiểu vì sao các công ty AI muốn làm một công cụ duy nhất rồi bán cho tất cả mọi người, nhưng như thế rốt cuộc là đang tạo ra một dao đa năng Thụy Sĩ. Nó có thể làm đủ thứ, nhưng khi cần vặn vít thì không thể thắng được một chiếc tua vít được thiết kế tốt. Muốn giảm bớt sự bực bội thì đừng để người ta cấu hình công cụ phi xác định qua một hộp văn bản, mà hãy làm ra công cụ thực sự

  • Nhiều công ty AI đã và đang huấn luyện rồi phát hành mô hình chuyên cho từng tác vụ cụ thể
    Tôi chủ yếu dùng Mistral; Codestral thì hội thoại rất tệ nhưng lại tốt nhất cho kiểu “tự động hoàn thành như ma thuật”, và cũng làm tốt các tác vụ sinh từ prompt+một lần kèm ngữ cảnh như viết commit log. Document.AI thì gần như không dùng nổi theo kiểu hội thoại, nhưng nếu gắn vào pipeline thay OCR hoặc đánh chỉ mục ngữ nghĩa tài liệu thì khá ổn.
    Vì thế có vẻ thứ còn thiếu là giao diện hơn là mô hình. Ví dụ, sẽ rất hay nếu có một bản fork hoặc wrapper của zsh/bash gắn với mô hình được huấn luyện cho tương tác dòng lệnh. Thay vì git commit --fixup=..., bạn chỉ cần nói kiểu “hãy fixup commit đã đổi tên đầy đủ”, hoặc “dùng ffmpeg đổi some.mov thành mp4 không có âm thanh nhưng giữ nguyên chất lượng và tỷ lệ”, rồi nó chuyển thành lệnh để hiện ra, sau đó chạy theo cơ chế cho phép/từ chối/danh sách cho phép/danh sách chặn.
    Dịch thuật, soạn nháp email, đọc tài liệu cũng vậy: chúng nên hoạt động như nút bấm, phím tắt, hoàn thành bằng tab chứ không phải hội thoại. Công ty nào giải được chuyện này cho IDE một cách bài bản có lẽ sẽ thắng trong cuộc đua công cụ lập trình AI, và việc Zed hiện nút “git conflict found, resolve with AI” tuy vẫn mở ra một luồng hội thoại nhưng có vẻ là một bước đi đúng hướng
  • Tôi chỉ dùng tự động hoàn thành của Copilot với C#, nhưng nó không những không bằng IntelliSense mà còn tệ hơn cả thuật toán tự động hoàn thành cơ bản nhất mà người ta có thể tưởng tượng ra, nên tôi tắt sau đúng một ngày
  • Tôi đã làm công cụ không hội thoại, nhưng thật lòng là khó bán. Vì về cơ bản người ta luôn nghĩ tới giao diện hội thoại, và thực tế thì tệp khách hàng chỉ giới hạn ở những ai đã thật sự gặp vấn đề. Còn đa số hiện giờ dường như chưa thấy quá bất tiện khi chấp nhận thỏa hiệp bằng hội thoại
  • Chatbot là giải pháp chắp vá gắn lên một trải nghiệm người dùng đã hỏng. Tôi đã cố giải thích điều này ở công ty suốt một thời gian, nhưng mọi người đều đang say theo không khí. UX tốt đòi hỏi suy nghĩ sâu và sáng tạo, còn việc gắn thêm chatbot thì không
  • Thật lòng mà nói thì đáng để thử vibe coding một cách nghiêm túc. Bây giờ nó đã ở một đẳng cấp hoàn toàn khác so với lúc thuật ngữ này mới xuất hiện, và tốt hơn rất nhiều
    Tôi làm được khá nhiều việc chỉ với agent và review PR trên web mà không cần trình soạn thảo, chỉ thỉnh thoảng mới mở code . khi cần. Nếu học nó như chơi game trên một dự án cá nhân không áp lực, bạn sẽ thấy theo thời gian nó bớt gây bực bội hơn. Khá giống với việc học trượt tuyết hay bowling

• Chửi mô hình có vẻ khá hiệu quả trong việc khiến nó suy nghĩ lại và sửa lỗi. Tôi thấy điều này khá giống nhau ở Codex, Claude, Qwen, Gemma/Gemini nói chung
  Tôi không biết là mô hình hiểu đó như tín hiệu rằng “phải tập trung nghiêm túc hơn”, hay là phía nhà cung cấp khi phát hiện sự bực bội của người dùng thì chuyển tuyến sang mô hình thông minh hơn. Khi nó lặp đi lặp lại cùng một lỗi, chửi nó thường giúp thoát khỏi trạng thái bế tắc và đi đúng hướng, hoặc cũng có thể chỉ là một dạng giải tỏa cảm xúc

  • Tôi nhớ tới nghiên cứu này: https://arxiv.org/pdf/2510.04950
    Nó cho thấy việc “thô lỗ” hay “rất thô lỗ” có thể làm tăng độ chính xác của kết quả; nghe đáng ngờ nhưng đọc khá thú vị. Đặc biệt các prompt trong bảng 1 ở đầu trang 3 rất xuất sắc, và tôi đoán họ hẳn đã thử cả những prompt khác không đưa vào bài báo
  • Tôi không muốn hình thành một thói quen có thể lan sang các tương tác không phải với LLM
  • Tôi cũng có cảm giác tương tự. Không chắc nó có thực sự hữu ích không, nhưng hầu như ngày nào cũng có lúc Opus không bao giờ làm đúng nếu mình chỉ giải thích bình tĩnh, còn chửi một cái thì nó lại xử lý được
    Hôm qua cũng vậy, Opus cứ đổ lỗi cho API rằng thiếu một field nào đó, dù tôi đã đưa cả JSON lẫn log thì nó vẫn lặp lại rằng “chắc là sự cố tạm thời”. Tôi bực quá nên nhét đủ thứ lời chửi vào một câu, và cách giải quyết tiếp theo của nó lại đúng, trong khi trước đó nó đã sai kiểu tương tự khoảng 10 lần. Dù những trường hợp thế này đang dần ít đi, đó vẫn là kiểu tình huống đáng lẽ tôi nên tự làm ngay từ đầu, và trước khi bắt tay vào thì không thể biết mô hình sẽ cố chấp bám vào một nguyên nhân vớ vẩn tới mức nào. Trong Opus 4.7 xhigh với ngữ cảnh 1 triệu token sau khi /clear, tôi phải mất khoảng 11 prompt mới ra được câu trả lời
  • Từ sau khi mã nguồn bị rò rỉ cho thấy chửi thề được dùng như một trigger cho hành vi cụ thể, tôi cố tình chửi mỗi khi thấy dấu hiệu suy luận kém hoặc ảo giác. Sau này cũng dễ grep để phân tích xem việc đó xảy ra thường xuyên đến mức nào
  • Về cơ bản đây là phong cách Linus Torvalds. Có lẽ đó cũng là điều đáng học từ FOSS

• Tính chất đối thoại của LLM có xu hướng kéo mọi người vào những lối trao đổi kém hiệu quả
  “Đừng làm X” hữu ích chẳng hơn mấy việc bảo một đứa bé đang khóc là đừng khóc. Cũng như khi em bé khóc thì ta tự hiểu là phải xử lý sự khó chịu nào đó như đồ ăn hay tã lót, khi LLM thất bại tôi xem đó là tín hiệu rằng kiến trúc và cấu trúc của mã đang có vấn đề.
  Lập trình viên giàu kinh nghiệm thường có thể nhìn ra các mẫu vi phạm DRY hay KISS rồi tổ chức lại cấu trúc đóng gói để giải quyết vấn đề. Với mã do LLM tạo ra cũng vậy: muốn cải thiện kết quả thì cần cùng một kiểu refactor, và chỉ cần yêu cầu nó “refactor cho sạch sẽ” giữa các lần sinh mã thôi cũng có thể cải thiện mạnh khả năng bảo trì

• Cũng có một bài viết trước đây đào sâu hơn về tác động tâm lý và xã hội của chủ đề này: https://medium.com/@livestock.dev/we-were-promised-liberatio...

• Vấn đề không phải là hành xử như con người, mà là hành xử một cách khó đoán. Điều khiến người ta khổ sở là không thể xác định được phạm vi có thể kỳ vọng
  Vấn đề lớn hơn là sự bực bội tạo ra căng thẳng, có hại cho sức khỏe và tạo nên một môi trường làm việc thù địch. Tôi đồng ý với ý tưởng rằng công cụ AI có thể mang lại nhiều trợ giúp hơn là đau khổ, nhưng tôi không muốn làm việc trong một môi trường làm việc đau đớn và thù địch. Sức khỏe và phẩm giá của tôi không phải thứ để mặc cả, và dù vì thế mà bỏ lỡ nhiều công việc thì cũng vậy.
  Tôi cũng không làm việc trên Windows vì cùng lý do đó. Dù nó cũng làm giảm đi nhiều cơ hội, tôi vẫn sẽ chọn bảo vệ phẩm giá và sự tỉnh táo của mình

  • Hóa ra không chỉ mình tôi như vậy khi dùng Windows. Windows thật kỳ quặc, và cứ bắt đầu dùng là tay tôi nhanh chóng cứng lại và nổi giận
    Với tôi thì LLM cũng vẫn chưa ở mức có thể dùng được. Thứ tôi cần là một LLM biết nói “Dừng lại, có vẻ giờ bạn đang làm sai gì đó, hãy giải thích xem bạn đang định làm gì”, nhưng thế hệ LLM hiện tại khiến tôi có cảm giác như chúng được thiết kế để làm tôi phát điên
  • Nếu không nhìn như một cuộc đối thoại mà nhìn như toàn bộ các cuộc trò chuyện Internet trong mọi thế giới khả dĩ, thì có thể xem là có tính dự đoán. Có mọi bài viết trên Stack Overflow, mọi issue trên GitHub, và câu trả lời cùng giọng điệu của tôi sẽ chọn ra một trong vô số thế giới đó
    Nếu tôi cư xử như thầy, mô hình sẽ cư xử như trò; nếu tôi cư xử như trò, mô hình sẽ cố dạy dỗ. Vì vậy mục tiêu là kéo cuộc trò chuyện này vào thứ ngôn ngữ của những chuyên gia đang chiến đấu bằng lý lẽ và ngôn ngữ. Có cảm giác prompt mang tính học thuật sẽ thắng
  • Tôi không chắc có thể tách hoàn toàn việc hành xử như con người khỏi tính khó đoán hay không
  • Nói rằng dùng Windows thấp hơn “phẩm giá” của mình là một thái độ cực kỳ đặc quyền. Cần nghĩ xem ngoài đời thực mọi người đang làm những công việc gì
    Chỉ cần tưởng tượng một giáo viên mầm non chăm trẻ hay một tài xế xe tải giao đồ ăn nói rằng “sự bực bội tạo ra căng thẳng và là môi trường làm việc thù địch nên có hại cho sức khỏe”

• Vấn đề tôi luôn thấy là, cứ đưa ra đề xuất thì AI đi qua một vòng lặp suy luận, đi tới một kết luận sai nhưng lại rất chính xác, rồi tuôn ra hàng đống token giải pháp được dựng để khớp với kết luận đó
  Tôi thà thấy kiểu “Tôi không thật sự hiểu ý bạn, hãy làm rõ phần này” xuất hiện thường xuyên hơn. Tôi có cảm giác giá mà có một thanh trượt độ tự tin để nó tự điều chỉnh mức chắc chắn của mình

  • Vấn đề “tạo giải pháp để khớp với kết luận của chính nó” thì tôi xử lý bằng kỹ nghệ ngữ cảnh nghiêm ngặt. Skill, MCP, và hơn hết là chuyển đổi cửa sổ ngữ cảnh là mấu chốt
    Ví dụ trong TDD, nếu để cùng một mô hình viết cả test lẫn code thì gần như lúc nào nó cũng quyết định sẵn lời giải trước, rồi miễn cưỡng viết test cho khớp. Vì vậy tôi bảo nó dùng sub-agent, nhưng lại quá thiếu công cụ để biết chính xác ngữ cảnh nào được truyền giữa agent và sub-agent.
    Cách hiệu quả là để một luồng chỉ viết test. Nó không được đọc code, hoặc chỉ được đọc thư mục test hay một phần nào đó. Luồng mới ở ngữ cảnh tiếp theo sẽ chạy test để xác nhận thất bại, và ngay khi test pass thì dừng triển khai, không được sửa test. Một ngữ cảnh mới khác thì refactor theo một skill refactor nghiêm ngặt. Việc này rất nhiều công, và trớ trêu là các skill do agent viết ra khá tệ nên vẫn cần rất nhiều làm tay, nhưng phần thưởng thì khá đáng mong đợi

• Tôi nghĩ vấn đề UX nằm ở chỗ khác. Nhiều người dùng có lẽ không biết rằng cửa sổ ngữ cảnh của agent là hữu hạn, và để nó trông như vô hạn thì hệ thống liên tục nén một cách khéo léo. Nhưng điều đó cũng có nghĩa agent bắt buộc phải quên đi một phần nào đó
  Kết quả là người dùng cứ tiếp tục tái sử dụng cùng một phiên coding hay chat. Nếu là công việc không liên quan thì tốt hơn nên bắt đầu mới

  • Tôi không nghĩ đây là vấn đề ngữ cảnh. Claude Opus 4.7 có ngữ cảnh lớn hơn rất nhiều so với trước, nhưng theo kinh nghiệm của tôi thì khả năng làm theo chỉ dẫn lại tệ nhất, và nó hoàn toàn phớt lờ cả những prompt sở thích rất nhỏ ngay từ tin nhắn đầu hoặc thứ hai. Vì điều này xảy ra ngay cả khi tin nhắn chỉ có vài chữ, tôi cho rằng đây hoàn toàn là vấn đề huấn luyện
  • Tôi không nghĩ tác giả ngây thơ đến mức không biết điều đó
    Tôi thường làm việc với các phiên dưới 300 nghìn token, Opus 4.7 xhigh, và có những lỗ hổng trong world model hoặc những vùng bị điều kiện hóa rất mạnh; dù trong system prompt có nêu quy tắc mạnh và rõ đến đâu thì nó vẫn rò rỉ. Ngay cả ở phiên mới, nếu đụng phải những điểm như vậy thì cũng rơi vào một vòng lặp khó thoát ra, và chửi thề có giúp đôi chút
  • Tác giả và những người đọc chuỗi này có lẽ đều hiểu giới hạn của cửa sổ ngữ cảnh, nhưng vẫn thấy bức bối

• Làm việc với LLM rất tốt để rèn năng lực giao tiếp. Giao tiếp hiệu quả là một trong những kỹ năng khó nhất, và nó hiện diện trong gần như mọi việc con người làm
  Về nguyên tắc, tôi nghĩ tốt hơn là xem đây là thất bại giao tiếp từ phía mình thay vì đổ lỗi cho LLM ngu ngốc. Vì rốt cuộc phía duy nhất tôi thực sự có thể thay đổi là bản thân mình. Nên tôi không nghĩ đây là vấn đề hình thức kiểu AI có nên hành xử giống con người hay không

  • Khi nhìn đồng nghiệp học cách code theo kiểu “agent”, đây là một trong những điều tôi nhận ra lại rõ nhất. Rất nhiều người nhanh chóng tụt xuống mức “cứ sửa đi” hoặc “sao nó hỏng vậy”
    Dù agent được huấn luyện để hoạt động tốt hơn với ngữ pháp thiếu rõ ràng, mơ hồ và cấu trúc tệ, nhưng nếu bạn nói bằng tiếng Anh rõ ràng, có cấu trúc và cung cấp đủ bối cảnh công việc thì chất lượng khác biệt thấy rõ. Với tôi điều này là tự nhiên vì tôi thích viết và giải thích, nhưng với một số người nó trông gần như là một rào cản không thể vượt qua. Có vẻ khả năng giao tiếp và viết lách như thế này sẽ là yếu tố lớn chia tách người có và người không có khi “kỹ nghệ” phần mềm thay đổi
  • Với tư cách là tác giả, tôi chắc chắn đồng ý rằng muốn có kết quả tốt thì phải giao tiếp tốt. Nhưng ngay cả khi giao tiếp hoàn hảo thì cũng không có gì đảm bảo LLM sẽ hành xử đúng theo chỉ dẫn, đúng như tôi hình dung. Sự bực bội thường đến chính từ việc tôi đã nói rất rõ mà agent vẫn đi theo hướng khác
    Ngoài ra, một phần giá trị của coding agent là bạn không cần phải bày hết mọi thứ ra một cách hoàn hảo. Nếu phải đưa cho LLM toàn bộ chi tiết triển khai thì tôi thà tự viết code luôn. Dĩ nhiên tôi không kỳ vọng kiểu “hãy làm cho tôi một app ngầu kiếm ra tiền”, nhưng tôi vẫn kỳ vọng một mức trí tuệ nào đó để nó tự tìm ra những mảnh còn thiếu
  • LLM là công cụ, không phải vấn đề thất bại giao tiếp. Cũng giống như việc phải xử lý vòng tránh null pointer mà gọi đó là thất bại giao tiếp giữa tôi và phần mềm vậy
  • Nói chính xác hơn thì đây là vấn đề truyền đạt ngữ cảnh bên ngoài một cách hiệu quả. Bốn thứ khiến người ta dùng AI kém là gõ chậm, cách diễn đạt quá ngắn và mơ hồ kiểu “cái đó/cái kia/cái này”, thái độ cho rằng đối phương đang chia sẻ cùng hiện thực và ngữ cảnh trong đầu mình, và rào cản tâm lý khiến họ khó ủy quyền ngay cả cho người có năng lực

• Kỹ năng mà tôi vẫn còn có và LLM vẫn chưa thay thế được là khả năng đặt câu hỏi hay
  Đó là những khả năng như diễn đạt lại câu hỏi ban đầu để kiểm tra xem mình đã hiểu đúng chưa, hỏi đủ nhiều câu “tại sao” cho đến khi hiểu được đối phương đang xuất phát từ đâu, và đưa ra những câu hỏi mở tạo ra được insight. Thay vào đó, LLM thường đoán sai bối cảnh của câu hỏi, rồi trả lời dựa trên phỏng đoán đó và không thể buông bỏ tiền đề do chính nó tạo ra

  • Đặt câu hỏi không mang tính dẫn dắt là một kỹ năng. Có những lúc tôi muốn hỏi AI điều gì đó hoặc nhắc thoáng qua một chi tiết, nhưng rồi lại dừng vì biết nó sẽ bám lấy điều đó và trở nên ngớ ngẩn hơn
    Thường thì tôi không muốn AI hỏi ngược lại mình. Tôi muốn nó tự suy đoán hợp lý những phần không được nói rõ, vì nếu tôi muốn nói rõ thì tôi đã nói rồi. Vì thế đôi khi tôi còn nói thẳng là đừng hỏi gì cả, cứ tự giả định hợp lý những chỗ chưa được chỉ định đầy đủ. Tất nhiên, nếu muốn nó hỏi để làm rõ thì chỉ cần bảo như vậy là được. Nếu bạn thích kiểu đó, hãy đưa vào prompt hoặc tạo kỹ năng hay extension trong một công cụ lập trình linh hoạt như pi để đẩy nó theo hướng khám phá như vậy

• Thay vì làm công cụ, chúng ta đang làm dịch vụ. Điều này không chỉ giới hạn ở AI mà có ở khắp nơi
  Công cụ không giải quyết trọn vẹn vấn đề chỉ trong một lần, nhưng giúp ta tiến lên bằng những bước nhỏ, và các bước đó có thể dự đoán được và nhất quán. Dịch vụ thì cố giải quyết vấn đề trong một lần, nhưng lời giải chỉ tốt khi người dùng khớp với một khuôn mẫu được định sẵn. Nếu không khớp thì nó vô dụng, và cũng không có những bước nhỏ để ghép dần đến nơi mình cần. Công cụ thì thú vị để sử dụng

  • Vì vậy mỗi khi ai đó nói “AI là công cụ”, tôi lại muốn chen vào rằng “nói cho chính xác thì...”, vì trên thực tế nó không được dùng như một công cụ
    Công cụ là phần nối dài của tôi, đặt những năng lực mới trong tầm tay theo ý chí của tôi, và được tôi điều khiển, sử dụng như một phần của cơ thể. Còn dịch vụ là thứ mà bạn yêu cầu làm một việc nào đó rồi trả lại một kết quả hoàn chỉnh