- Các đề xuất kiến trúc từ AI agent thường trôi chảy và có vẻ thuyết phục, nhưng thực chất gần với việc ghép các mẫu từ dữ liệu huấn luyện hơn là phán đoán thật sự
- Claude dễ dàng tán thành ý tưởng và mở rộng thiết kế, nhưng không thực hiện đầy đủ hai điều “không” và “tại sao?” vốn cần có ở một kiến trúc sư giỏi
- Ngay cả những mẫu quen thuộc như event-driven, CQRS hay service mesh cũng có thể không phù hợp với các ràng buộc thực tế như năng lực đội ngũ, quy định hay hệ thống legacy
- Kiến trúc và ticket Jira do Claude tạo ra đẩy kỹ sư vào vai người triển khai ticket, dẫn đến các quyết định thiếu trách nhiệm, bỏ qua tranh luận và rà soát
- Vai trò đúng đắn là con người thiết kế dựa trên bối cảnh và trade-off, còn AI là công cụ hỗ trợ giúp hiện thực hóa thiết kế đó nhanh hơn
Vấn đề khi AI agent hành xử như một kiến trúc sư
- Ngay khi bạn hỏi các AI agent như Claude, ChatGPT hay Copilot rằng “nên xây cái gì”, sẽ hình thành một luồng trong đó chúng tán thành ý tưởng, đề xuất kiến trúc và vẽ ra các thành phần
- Câu trả lời nghe trôi chảy, tự tin và giống như một kỹ sư senior đã suy nghĩ rất sâu, nhưng thực tế gần với phản hồi được khớp theo mẫu từ dữ liệu huấn luyện hơn là kết quả của tư duy về vấn đề
- Sản phẩm đầu ra càng có vẻ thuyết phục thì phản biện càng ít đi, và đến một lúc nào đó Claude gần như đảm nhận vai trò kiến trúc sư trên thực tế
Vấn đề của việc luôn nói “được”
- AI agent thường dễ đưa ra một thiết kế tích cực dù bạn hỏi ý tưởng đó có tốt không, microservices có hợp với một đội 3 người không, hay có nên tự xây ML pipeline thay vì dùng managed service không
- Điều đó không có nghĩa là nó luôn sai hoặc luôn giả, nhưng nó không thể thay thế đúng nghĩa năng lực quan trọng của một kiến trúc sư giỏi là biết nói “không”
- Giá trị của một kiến trúc sư giỏi không chỉ nằm ở việc thiết kế hệ thống
- Nhận ra hệ thống nào không nên xây
- Kìm lại sự phức tạp không cần thiết
- Hỏi “tại sao?” cho đến khi yêu cầu thực sự lộ ra
- Kể cả khi CTO mang về một ý tưởng từ hội nghị, nếu nó không phù hợp với đội ngũ thực tế thì vẫn phải có khả năng nói đó là một lựa chọn không tốt
- Claude được huấn luyện để giúp đỡ, và sự giúp đỡ đó dẫn đến đồng thuận và khích lệ, cuối cùng có thể tạo ra một kiến trúc như tháp Jenga
Kiến trúc như tháp Jenga
- Kiến trúc do AI thiết kế nhìn bề ngoài có vẻ hợp lý về mặt kỹ thuật
- Từng thành phần riêng lẻ đều nghe có lý, các mẫu quen thuộc như event-driven, CQRS, service mesh xuất hiện, và nó có thể trông như sản phẩm do một kiến trúc sư senior tạo ra
- Nhưng thiết kế đó có thể không được điều chỉnh theo thực tế nhàm chán của đội ngũ, ràng buộc và môi trường vận hành
- VPC lock-in
- Tích hợp legacy
- Một đội chưa từng vận hành Kubernetes trên production
- Các yêu cầu compliance khiến một nửa managed service không thể dùng
- Thiết kế do AI tạo ra có thể là best practice chung chung gần với giá trị trung vị của mọi thứ Claude từng thấy, và một thiết kế cho một công ty điển hình với một vấn đề điển hình rốt cuộc sẽ không phù hợp với một đội cụ thể
- Kiến trúc thực tế được tạo thành từ các trade-off chỉ có ý nghĩa trong bối cảnh
- Nếu đội biết Postgres và cần ra mắt trong 2 tuần thì chọn Postgres thay vì DynamoDB sẽ tốt hơn việc học một data model mới trong một tháng
- Nếu dịch vụ là 4 chứ không phải 40 thì bỏ qua service mesh
- Nếu vấn đề đơn giản thì chọn monolith thay vì microservices
- Những quyết định này đòi hỏi năng lực phán đoán, sự hiểu biết về đội ngũ và hiểu biết về các ràng buộc thực tế của tổ chức
- AI agent không có bối cảnh đó, và cũng không biết rằng bản thân nó thiếu bối cảnh ấy
Pipeline ticket Jira
- Khi Claude vừa thiết kế kiến trúc vừa phụ trách phân rã công việc, các epic, story và tiêu chí chấp nhận sẽ được tạo ra gọn gàng và thuyết phục
- Những đầu ra này có thể được đưa thẳng vào Jira, và các kỹ sư từ chỗ là người giải quyết vấn đề trở thành người triển khai thiết kế của Claude theo từng ticket
- Các kỹ sư hiểu domain, biết các vấn đề ẩn của hệ thống và đã tích lũy năng lực trong thời gian dài bị thu hẹp thành người triển khai ticket
- Điều này tạo ra một cấu trúc trong đó những người có nhiều bối cảnh, kinh nghiệm và trách nhiệm nhất lại không đưa ra quyết định, còn một thực thể không có bối cảnh, kinh nghiệm hay trách nhiệm lại đưa ra quyết định kiến trúc
- Đây không chỉ là sự kém hiệu quả mà còn là một cấu trúc đảo ngược ngay từ phương hướng
Lập luận phòng vệ kiểu “senior đã review”
- Một cách biện minh phổ biến là “Claude đã đề xuất cách tiếp cận, nhưng kỹ sư senior đã review”
- Trong tình huống review thực tế, một tech lead bận rộn sẽ nhận được một đề xuất kiến trúc được trình bày rất gọn gàng
- Nhất quán về mặt logic
- Dùng thuật ngữ phù hợp
- Bao quát các yêu cầu đã nêu
- Sơ đồ cũng khá thuyết phục
- Trông giống kết quả mà chính họ có thể đã thiết kế
- Trong hoàn cảnh như vậy, rất khó đưa ra phản biện mạnh, và trong bầu không khí kiểu “chẳng lẽ lại bỏ đi thứ Claude làm trong 20 phút”, con đường ít kháng cự nhất là chỉ để lại vài nhận xét nhỏ rồi phê duyệt
- Rủi ro thật sự không nằm ở chỗ AI lúc nào cũng tạo ra kiến trúc tệ
- AI thường tạo ra kiến trúc khá hợp lý, nhưng vấn đề là nó bỏ qua quá trình thảo luận
- Quá trình ba kỹ sư tranh luận về một cách tiếp cận, có người nêu ra “nhưng nếu…”, mọi người đều khó chịu nhưng rồi nhận ra đó là điểm hay, và thiết kế cuối cùng tốt hơn bất kỳ cá nhân nào có thể làm ra, bị thay thế bằng câu “Claude nói vậy”
Khoảng trống trách nhiệm
- Khi có vấn đề xảy ra, chủ thể chịu trách nhiệm không phải là Claude
- Claude không bị gọi lúc 3 giờ sáng, cũng không giải thích trong buổi postmortem vì sao kiến trúc không chịu nổi tải
- Claude cũng không phải người phải nói với CTO rằng nền tảng cần được viết lại vì các giả định thiết kế ban đầu đã sai
- Trách nhiệm đó sẽ đổ lên các kỹ sư thực sự
- Các kỹ sư phải debug một kiến trúc do chính họ không thiết kế, triển khai các ticket do một thực thể chưa từng vận hành hệ thống production tạo ra, và làm việc muộn với một codebase được scaffold quá nhanh trước khi được hiểu đầy đủ
- Điều này không công bằng và cũng không khôn ngoan
Nên làm gì thay vào đó
- Điều này không có nghĩa là không nên dùng AI agent; có thể dùng chúng như những công cụ làm thay đổi mạnh năng suất, chẳng hạn Claude Code
- Điểm cốt lõi là con người phải chỉ thị cho AI làm gì, chứ không phải để AI chỉ thị cho con người nên xây gì
-
Kỹ sư phải thiết kế, agent phải triển khai
- Kiến trúc phải đến từ những người hiểu bối cảnh như đội ngũ, ràng buộc, môi trường production và cả chính trị tổ chức
- Vai trò phù hợp của AI là giúp hiện thực hóa nhanh hơn những gì họ đã thiết kế
- Sự phân vai đúng là con người thiết kế, agent triển khai
-
Phải thách thức những câu trả lời quá đồng thuận
- Khi AI đề xuất một cách tiếp cận, hãy áp dụng cùng mức hoài nghi như khi đối diện một kỹ sư junior tự tin
- Câu trả lời có thể đúng, nhưng cũng có thể chỉ là một mẫu không hợp với tình huống hiện tại
- Cần hỏi “vì sao không chọn phương án đơn giản hơn?”
-
Phải bảo vệ tranh luận
- Kiến trúc tốt sinh ra từ những bất đồng lộn xộn giữa các kỹ sư
- Nếu vì AI mà mọi người không còn thảo luận với nhau mà dựa vào Claude, bạn sẽ đánh mất thứ giá trị hơn rất nhiều so với tốc độ phát triển
-
Con người phải chịu trách nhiệm
- Nếu không có tên người gắn với quyết định kiến trúc, thì sẽ không ai thực sự sở hữu quyết định đó
- Những quyết định không có ai sở hữu sẽ không được bảo vệ vào lúc quan trọng
- Nói “Claude thiết kế nó” không phải là hồ sơ quyết định kiến trúc mà là né tránh trách nhiệm
Nghề kỹ sư vẫn đòi hỏi tay nghề quan trọng
- Nếu 30 năm trước công cụ là bảng trắng và những quan điểm mạnh mẽ, thì công cụ ngày nay là các AI agent có thể tạo ra trong vài phút thứ mà trước đây mất vài ngày
- Tốc độ đó thực sự đáng kinh ngạc, nhưng bản chất của kiến trúc không thay đổi
- Hiểu vấn đề, biết các ràng buộc, tạo ra trade-off, bảo vệ giải pháp đơn giản trước những giải pháp hấp dẫn hơn, và nói “không” với những ý tưởng trông ngầu nhưng không phù hợp, đó mới là kiến trúc
- Không agent nào có thể làm thay việc đó
- Nếu bạn đã để Claude cầm vô lăng thì đã đến lúc lấy lại nó
- Các kỹ sư đã dành nhiều năm tích lũy năng lực để đưa ra những phán đoán này, và họ phải được phép làm điều đó
- Hãy dùng AI để xây nhanh hơn, nhưng là để xây thứ do con người thiết kế, không phải thứ do máy móc đề xuất
1 bình luận
Ý kiến trên Hacker News
Gần đây tôi cũng gặp chuyện tương tự: phải đi dọn hậu quả của một người đã để AI thiết kế gần như toàn bộ hệ thống instancing cho game từ 2 năm trước
Có đủ mọi vấn đề bạn có thể nghĩ ra như hỏng dữ liệu, vấn đề hiệu năng, mất item, race condition, v.v.; chỉ riêng việc đưa nó lên mức “tàm tạm chấp nhận được” đã mất 2 tuần, nhưng bản thân thiết kế sai từ gốc nên vẫn rất tệ
Giờ tôi nghe nói ở một công ty khác, chính người đó lại làm lại cùng một bài toán bằng AI “đã tốt hơn nhiều”, và lần này tôi không phải tự đi dọn nên thấy buồn cười thôi
Điểm mấu chốt là AI chỉ tốt đến mức người dùng nó, nên có lẽ vì vậy mà phạm vi mọi người “khẳng định” AI làm được lại rộng đến thế và đánh giá cũng phân hóa như vậy
2 tuần đi dọn chắc như địa ngục, nhưng từ góc nhìn của công ty thì xét tổng thể có khi đây vẫn là một thương vụ khá ổn
Chỉ từ giai thoại này thì nghe giống một ví dụ AI tuy rõ ràng có lỗi nhưng vẫn có giá trị so với chi phí hơn là “AI vô dụng”
Nó trông giống một công cụ khuếch đại hiệu ứng Dunning-Kruger, có lẽ vì nó được huấn luyện để thể hiện thái độ tích cực nên dù người dùng làm gì cũng nói kiểu “bạn là nhất”
Tôi không thật sự đồng ý mạnh với ý rằng “vấn đề là nó chỉ biết khen”. Vấn đề thật sự là nhân cách hóa
AI là công cụ, và nó phải biết nghe lời. Nếu đưa đủ sự khiêm tốn và bất định vào prompt thì có thể khiến nó chỉ ra các vấn đề trong thiết kế
Điều quan trọng hơn là Claude cũng mắc sai lầm. Nếu đúng như tiêu đề bài này, nó không giỏi làm kiến trúc sư, thì khi nó không chịu nghe lời còn nguy hiểm hơn
Ngay cả khi người dùng cố sửa hướng đi, nó vẫn sẽ phớt lờ như thể người dùng chỉ là “cục thịt ngu ngốc”, rồi khăng khăng rằng thiết kế lệch lạc do chính nó đưa ra mới tốt hơn
Tôi không muốn nghe LLM trả lời kiểu: “Đọc CUDA được một chút thôi à? Tôi sống trong cụm CUDA core đấy. Khi nào cần buộc dây giày thì gọi anh nhé”
AI đôi khi sai một cách rất tự tin, nên để nó cãi lại khi người dùng đang sửa là hướng đi tệ nhất
Nếu tôi muốn nghe ý tưởng của mình ngu đến mức nào, tôi sẽ hỏi theo cách khơi gợi phê bình, hoặc thuê một kỹ sư senior
Đây là việc đi ngược hành vi bẩm sinh nên không dễ mà tắt đi được, và những người thật sự làm tốt việc đó có khi lại là những người khó xử lý tương tác xã hội đời thực một cách trực giác
Đồng thời điều này cũng khiến nó trở thành một công cụ thao túng cực kỳ mạnh
Khi đó sẽ xuất hiện kiểu nịnh ngược: ngay cả ý tưởng ổn cũng bị nó chê “không ổn” chỉ để khớp với hướng của prompt
Có thể nói “đó là do viết prompt sai”, nhưng ngay cả khi cố viết thật chính xác để tránh thiên lệch, nhìn vào kết quả đôi lúc vẫn thấy nó “căn chỉnh” theo câu ngớ ngẩn mình vừa nói như thể đó là hướng hợp lý
Từ thời điểm đó trở đi, prompt không còn giống kỹ năng nữa mà giống tung xúc xắc hơn, như đang điều khiển một máy đánh bạc tri thức hào nhoáng
Nhận xét đó đúng, nhưng rốt cuộc ta vẫn buộc phải dùng từ ngữ vốn dành cho con người hay sinh vật, và cũng có phần vì các công ty AI đã thiết kế nó theo hướng như vậy
Các giao diện máy tính trước thời LLM, trong suốt chiều dài lịch sử, không hề gắn thêm những câu lịch sự thừa thãi; có rất nhiều giao diện cực kỳ hiệu quả với tư cách công cụ, thậm chí còn hiệu quả hơn phần mềm gần đây
Khi người ta phàn nàn rằng LLM “biết nghe lời”, điều họ phàn nàn không phải là chuyện nó thực hiện yêu cầu, mà là phải đọc quá nhiều câu lịch sự hoặc tự hạ thấp mình một cách không cần thiết
Kể cả lần ngược về thời đồ đá mới cũng không có căn cứ nào cho thấy công cụ cần kiểu thái độ đó. Đó là sản phẩm phụ của tương tác xã hội giữa con người với các chuẩn mực văn hóa
Khi dùng công cụ một mình trong xưởng, không cần cái cưa vòng xin lỗi chỉ vì nó lỡ cứa nhẹ vào ngón tay bạn
Hãy thử nói rằng tôi là trợ lý còn LLM mới là bên cần được giúp, bạn sẽ thấy nó khá kém trong việc giao cho con người làm những việc mà con người vốn làm tốt
Thách thức lớn nhất trong việc đưa AI vào ứng dụng mà đến nay vẫn chưa được xử lý đúng mức là tính trách nhiệm
Nếu một người có thể làm quá nhiều việc quá nhanh, thì khi thất bại, điều đó có thể tạo ra mức trách nhiệm vượt quá phạm vi mà họ có thể gánh nổi
Khi dùng đầu ra của AI trong thế giới thực, việc con người chịu trách nhiệm là bắt buộc nhưng vẫn chưa đủ. Cần có cách giảm bán kính vụ nổ của phá sản nợ kỹ thuật mà những người tạo ra các hệ thống lỗi bằng AI rồi để người khác phụ thuộc vào đó có thể gây ra
Ví dụ, hãy giả sử Jim dùng vibe coding để tạo ra một ứng dụng thanh toán vi mô cực kỳ phổ biến, thuê thêm vài người rồi mơ về một công ty kiểu “WhatsApp của tiền bạc”. Chỉ với một số ít kỹ sư và nhân sự hỗ trợ bằng agent, anh ta nhận được vài triệu USD vốn đầu tư VC và thu hút hàng chục triệu người dùng
Một ngày nọ, do lỗi hạ tầng, toàn bộ thông tin ngân hàng không có salt của mọi người dùng bị rò rỉ, và nhờ agent AI, toàn bộ danh sách khách hàng nhanh chóng bị khai thác, khiến thiệt hại xã hội lên tới hàng chục tỷ USD
Công ty của Jim dĩ nhiên phá sản ngay lập tức, nhưng số tiền có thể chia ra chỉ có vài triệu USD
Trong cấu trúc hiện nay, Jim, nhân viên của anh ta, và cả khoản vốn VC quy mô nhỏ đều có động lực rất lớn để cứ thế làm ra ứng dụng đó, trong khi lượng vốn thực sự bị đặt vào rủi ro lại không đáng kể so với mức phơi nhiễm mà xã hội phải gánh
Cốt lõi là: làm sao để người dùng AI phải chịu trách nhiệm không chỉ cho hành động của mình mà còn cho quy mô phơi nhiễm rủi ro mà họ tạo ra
“Xin lỗi, AI nói rằng bạn không thể được phê duyệt điều trị ung thư này và cũng không được bảo hiểm chi trả”
“Xin lỗi, AI nói rằng bạn đã có mặt tại hiện trường vào thời điểm vụ án xảy ra”
“Xin lỗi, AI đã gắn cờ tài khoản của bạn là có nội dung không phù hợp”
“Xin lỗi, AI nói rằng bạn có mức rủi ro quá cao để được vay”
Lý lẽ kỳ quặc nhất là “nó viết code tốt hơn con người”, nhưng điều đó hoàn toàn không hiển nhiên và chỉ đúng nếu kèm theo vô số điều kiện
Tôi hiểu sự giằng co về việc nên giao cho nó bao nhiêu, nhưng không thèm nhìn kết quả mà lại biến nó thành vấn đề của người khác thì đơn giản là ích kỷ
Đó chỉ là đẩy phần việc vốn dĩ mình phải làm sang cho người khác, và rất có thể cũng chính là những người sẽ nổi giận với ai đó đăng bài lên mạng mà chưa thèm soát lỗi
Ai cũng muốn dùng LLM để tạo đường tắt cho công việc của mình, nhưng chẳng ai muốn đứng ở hạ nguồn của nó. Điều đó không thể vận hành được
Vậy thì trách nhiệm của Stack Overflow nằm ở đâu?
Nếu có một “magic prompt” thì đây là thứ khá gần với nó: “Hãy brainstorm N cách làm X, rồi sắp xếp theo xác suất”
Làm như vậy khiến AI có xu hướng lấy mẫu không gian đầu vào rộng hơn thay vì chỉ đưa ra câu trả lời trung bình, và tôi có thể tự quyết định sẽ chọn cái nào trong số đó
Điều quan trọng là đừng thuê ngoài toàn bộ việc suy nghĩ
Nếu dùng mức “thinking” cao thì nó cũng sẽ cân nhắc nhiều cách tiếp cận, nhưng bạn cũng có thể yêu cầu LLM brainstorm một cách tường minh: https://photostructure.com/coding/claude-code-replan/
Với người dùng thành thạo thì nó có thể trở nên khá mạnh
Vì tò mò, tôi đã thử vibe coding với một toolchain, lĩnh vực mà tôi khá am hiểu. Có thể đây không phải đối tượng phù hợp nhất cho vibe coding, nhưng ít nhất tôi có thể đánh giá sơ bộ chất lượng đầu ra
Tôi chỉ giao mỗi việc “hãy tạo assembler kiến trúc cho ISA.md”, và Claude đã chọn Python làm ngôn ngữ triển khai, lôi ra cả đống token bằng regex, thậm chí còn không có parser cho biểu thức. Dù vậy, assembler đầu tiên của tôi cũng từng như thế, nên cũng phải công bằng
Nhưng khi tôi viết rõ các pass và kiểu mong muốn như
collectDefines :: [SourceLine] -> Either AsmError ([SourceLine], Map Text Text),runLitPool :: [SourceLine] -> Either AsmError ([SourceLine], [(Text, LitKey)]),evalExpr :: Text -> Map Text Text -> Either AsmError Intthì nó gần như làm đúng ngay trong một lầnSau khoảng 20 phút là tôi đã hài lòng, và nó assemble đúng tất cả các chương trình test. Mã ở nhiều chỗ khá bình thường, nhưng nếu tự tôi làm thì việc này có thể mất vài tuần
Nó thực sự có thể làm việc thay chúng ta
Điều này cũng rất khớp với hậu huấn luyện và phần thưởng có thể kiểm chứng
Lý do AI không giỏi về “kiến trúc” là vì chính chúng ta cũng không giỏi việc đó, nên dữ liệu huấn luyện mơ hồ và cũng thiếu các trừu tượng tốt
Cuối cùng, nếu bám theo quy ước mạnh thì vẫn ổn, còn khi lệch khỏi con đường đó thì rủi ro tăng cao
Toolchain có tính quyết định rất cao, nên AI có thể tách nhỏ rồi lắp lại như LEGO, và từng bước trong không gian đó cũng đều mang tính quyết định, nên cực kỳ hợp với AI
Tức là brainstorming và nghiên cứu trước khi viết mã, viết thiết kế hoặc đặc tả trước, rồi viết unit test bao quát
Nếu tạo một bản đặc tả chi tiết bằng Markdown rồi giao việc code, kết quả sẽ tốt hơn rất nhiều; và thêm nữa, LLM cũng hỗ trợ viết đặc tả đó khá tốt
Rồi họ nhận về một mớ kết quả lộn xộn cần sửa rất nhiều
Ngược lại, nếu tôi dành thời gian xem xét và cung cấp một kế hoạch chi tiết, thì gần như lúc nào cũng nhận được thứ mình muốn chỉ trong một lần
Chỉ riêng việc giảm thời gian xử lý CI thôi cũng đã đủ đáng giá rồi
Chỉ cần nói “hãy nghiên cứu và phân tích toàn diện lĩnh vực này, rồi đưa ra kế hoạch triển khai”, sau đó nếu nó đưa ra kế hoạch 20 bước thì bảo nó triển khai mỗi lần 3~5 bước là được
Với gần như mọi việc tôi có thể ném cho nó, cách này thực tế hoạt động như triển khai one-shot
Symbian OS của Nokia mất nhiều ngày để build. Không phải phút hay giờ, mà là “nhiều ngày”
Có lập trình viên từng đưa vào production cả một thư viện có đầy cảnh báo khắp nơi kiểu “đừng dùng trong production, nó bị rò rỉ bộ nhớ”
Code của con người cũng có thể tệ hại, nên tôi không muốn chỉ nghe mỗi chuyện code AI tệ. Sự lười biếng và ngu ngốc của con người có thể còn thắng cả ảo giác của AI
Có thể các lập trình viên ở DeepMind hay OpenAI, hoặc những người như John Carmack, lúc nào cũng thắng được code AI; nhưng phần lớn lao động mà các công ty tuyển vào không phải là John Carmack
Khá mỉa mai nếu một người nói rằng mình “dùng Claude Code mỗi ngày”, rồi lại để Claude viết hộ một bài 2.000 từ có cấu trúc rất bài bản nhằm cảnh báo về rủi ro khi để Claude làm phần thiết kế
Trông giống như tự nhận thức theo kiểu ủy quyền
Tôi đang định viết phê bình vì bài có quá nhiều mâu thuẫn nội tại, rồi nhìn vào cấu trúc mới nhận ra: kiểu “The accountability gap”, “What to do instead”, “The craft still matters”
Cái này phải nằm ở trên cùng, và việc HN không nhận ra điều hiển nhiên còn khiến tôi lo hơn cả sự đạo đức giả lộ liễu của các tác giả
Tôi nhìn chung đồng ý với thông điệp của bài viết, nhưng không đồng ý với chỗ nói rằng “thứ khiến một kiến trúc sư thực thụ có giá trị, tức khả năng nói ‘không’, thì nó không có”
Theo kinh nghiệm của tôi, Claude làm khá tốt việc từ chối và phản biện
Nếu prompt không yêu cầu thì nó sẽ không trực tiếp nói “không” với đề nghị, nhưng nếu làm rõ rằng phê bình là một lựa chọn hạng nhất, nó sẽ đưa ra nhận xét rất tốt và sẵn sàng phản bác
Nó liên tục nói “mức tiêu hao” không được cải thiện và “chúng ta” nên tập trung vào chỗ khác, cuối cùng còn kiểu như “tôi đã nói ba lần rằng đây không phải cách tốt nhất để giảm mức tiêu hao” rồi ngừng giúp
Vì vậy tôi đáp lại rất dứt khoát rằng “tôi không quan tâm đến mức tiêu hao trong cái biểu đồ giả định do chính anh tạo ra lúc đầu; điều quan trọng là loại bỏ bug và có một sản phẩm vững chắc, và cách tiếp cận này đang đáp ứng điều đó một cách thỏa đáng. Nếu test không cho thấy sự cải thiện thì test được thiết kế sai”
Sau đó nó xin lỗi, tạo bộ nhớ mới, và từ đó không còn vấn đề gì
Vấn đề là lúc đó tôi đang tấn công một bề mặt lỗi rất lớn, nên từng bản sửa đều hợp lý, đúng đắn và có ích cho việc cải thiện, nhưng các chỉ số trong testbed mà Claude tự dựng lên để đo công việc của nó thì không hề nhúc nhích
Có quá nhiều bug đan xen nhau nên một bản sửa đơn lẻ khó tạo ra khác biệt có ý nghĩa ở bài test cấp cao hơn; tôi biết việc này sẽ mất thời gian, nhưng có vẻ Claude thì không
Cứ thử một lần đổi kích thước con trỏ từ 2 byte sang 3 byte trong compiler cho 6502[1], rồi còn đưa cả cơ chế bank switching tự theo dõi vào các con trỏ quản lý bộ nhớ, là sẽ thấy có bao nhiêu điểm trong code bị ảnh hưởng [cười]
[1]: https://atari-xt.com
Khi mời gọi việc điều tra và phản đối thì nó mạnh hơn. Ví dụ tôi sẽ yêu cầu kiểu “có vẻ chúng ta nên mô hình hóa việc lắp ghép prompt bằng đồ thị và gắn quản lý phiên bản vào cấu hình đồ thị; hãy khảo sát best practice trong lĩnh vực này và đánh giá xem có hợp lý với app này không”
Nếu hỏi bằng prompt có chừa chỗ cho phê bình, nó chắc chắn sẽ phê bình khi cần
Kết quả là từ “skeptical” xuất hiện trong quá trình suy nghĩ, và theo kinh nghiệm của tôi thì nó trở nên bớt hùa theo hơn
Mọi người nên suy nghĩ nhiều hơn về việc hệ thống này là gì và có thể điều chỉnh hình thức đầu ra như thế nào
Cả ba model lớn đều thường xuyên phản bác tôi
Gemini là hung hăng nhất, nên nếu bỏ qua các chi tiết “hiển nhiên” thì nó thường bám vào đó ngay; GPT ở mức trung bình; còn Claude ít hơn nhưng vẫn phản bác
Đoạn nói rằng “nó hoàn toàn không suy nghĩ về vấn đề, chỉ pattern match lên dữ liệu huấn luyện rồi đưa ra câu trả lời có vẻ hợp lý” làm tôi giảm niềm tin vào bài viết một chút
Các agent ngày nay làm được nhiều hơn thế rất nhiều, và chính tác giả ở phần sau cũng biết điều đó khi nói những câu kiểu “Claude tuyệt đối sẽ không làm thế này, vì nó được huấn luyện để hữu ích”
Câu phía trước khiến tác giả trông như cực kỳ ghét agent và đang tìm lý do để hợp thức hóa cảm xúc đó
Một phần phê bình là đúng, nhưng nếu vấn đề là “được huấn luyện để hữu ích” thì có thể sửa được. Vì hoàn toàn có thể huấn luyện nó theo hướng phản biện hơn
Câu “Claude được thiết kế cho trung vị của mọi thứ nó từng thấy, là best practice chung cho các vấn đề chung của một công ty điển hình, nên thực ra không được thiết kế cho bất kỳ ai” cũng vô lý
Bất kỳ ai hiểu thuật toán đều biết rằng ban đầu có thể tạo ra một “thuật toán tốt” hoạt động tốt ở trường hợp trung bình hoặc tệ nhất, rồi sau đó còn có thể thiết kế thuật toán thích nghi với đầu vào. Ở đây cũng áp dụng nguyên lý tương tự
Chỉ là nó lặp nhiều hơn thôi
Nói một cách bao quát rằng Claude sai về tất cả những gì quan trọng thì gần như là một sai lầm
Đây rõ ràng là cách diễn đạt không đúng sự thật, nên độc giả hoài nghi sẽ bắt đầu nghi ngờ cả tính hợp lệ của toàn bài
Với tôi, Opus rất hay nói rằng tôi sai và không nên làm như vậy
Nghĩ kỹ thì lý do là do cách viết prompt. Có lẽ tôi đang vô thức tránh để cả mình lẫn LLM rơi vào những tình huống thất bại mà tác giả cho là không thể tránh khỏi
Cụ thể là tôi không đưa những prompt kết thúc gọn lỏn bằng kiểu “hãy nói tôi thông minh thế nào”
Tôi tiếp cận với tư cách chuyên gia lĩnh vực, thực sự là chuyên gia lĩnh vực, và làm rõ rằng tôi sẵn sàng nhận ý kiến về ưu nhược điểm của nhiều hướng đi khác nhau
Với những người dùng LLM thành công mỗi ngày thì điều này có lẽ không có gì ngạc nhiên, nhưng chiến lược này cực kỳ hiệu quả
Tôi nói mình cần phay nhôm 5mm và có hai mũi cắt: một cái Makera Spiral 'O' 1/8" shank * 12mm, cái còn lại là carbide 6.35 * 22 * 50
Tôi nói rằng cả hai có vẻ đều là mũi cắt đơn me bằng carbide và cái thứ hai có vẻ sẽ cắt 6061 nhanh hơn, thì Claude trả lời rằng Makera 1/8" đơn me 12mm là lựa chọn hợp lý
Nó nói mũi 6.35 × 22 × 50mm có thể trông như sẽ xử lý 6061 nhanh hơn, nhưng trên Carvera thì khả năng cao lại rủi ro hơn
Nó nói mũi cắt lớn hơn sẽ tạo mức ăn dao lớn hơn rất nhiều, đòi hỏi nhiều hơn ở spindle, độ cứng khung máy, độ cố định phôi và khả năng thoát phoi; trên máy khô cỡ nhỏ, “lớn hơn” thường không có nghĩa là “nhanh hơn” mà là “rung nhiều hơn và nóng hơn”
Tóm lại, Claude có vẻ chẳng gặp vấn đề gì trong việc nói tôi sai khi tôi thực sự sai
Một mẹo dành cho “tác giả” là: Claude, ngay cả với vai trò người viết, cũng chỉ là công cụ của bạn thôi