Vì sao người ta vẫn thúc đẩy AI tác tử khi các mô hình còn khó theo đúng cả một chỉ dẫn đơn giản?

• Trong thực tế, các mô hình AI cho lập trình vẫn không thể thực hiện đáng tin cậy ngay cả một lệnh đơn lẻ, nhưng kỳ vọng quá mức vào kiểu lập trình tác tử tự vận hành ở chế độ nền vẫn đang hình thành
• Tác giả cho biết dù đã cung cấp một hàm Golang khoảng 100 dòng làm mã tham chiếu, cả GPT-5 lẫn Gemini Pro đều gặp vấn đề như bỏ sót một phần logic hoặc quên cập nhật
• Việc để hệ thống tác tử tự xử lý 50 tệp và nhiều hàm là điều thiếu thực tế ở trình độ công nghệ hiện nay, thậm chí còn có nguy cơ tốn nhiều thời gian gỡ lỗi hơn
• Phản hồi từ cộng đồng chia làm hai luồng: một bên cho rằng có thể áp dụng thành công ở mức hạn chế thông qua prompt có hệ thống, tài liệu hóa và kiểm chứng từng bước; bên còn lại hoài nghi rằng agentic vẫn chưa thực sự thực dụng
• Hiện tại, LLM vẫn là hệ thống dựa trên tri thức chứ không phải trí tuệ, nên cách tiếp cận thực tế là nhà phát triển trực tiếp cung cấp ngữ cảnh và xác minh theo từng bước như một hình thức "dùng như công cụ"

---

Vấn đề mà tác giả bài gốc nêu ra

• Ví dụ thất bại với lệnh đơn giản: tác giả cung cấp một hàm Golang 100 dòng làm tham chiếu và yêu cầu cập nhật một hàm khác theo cùng cấu trúc, nhưng cả GPT-5 lẫn Gemini Pro đều bỏ sót một phần logic hoặc quên cập nhật
• Tính thiếu thực tế của lập trình tác tử: nếu ngay cả một hàm đơn lẻ còn không xử lý tử tế, thì cách làm agentic tự sửa nhiều hàm trên 50 tệp càng dễ gây ra nhiều vấn đề hơn
• Câu hỏi về cập nhật tệp 6000 dòng: tác giả hỏi cộng đồng cách chỉnh sửa an toàn một tệp cỡ 6000 dòng, chẳng hạn như khi cập nhật phiên bản Stripe

Các trường hợp áp dụng tích cực và phương pháp

Cách tiếp cận tài liệu hóa và lập chỉ mục có hệ thống

• Dùng tệp tham chiếu Markdown: lưu tham chiếu trong tệp .md và yêu cầu AI đọc chúng sẽ giúp tăng tính nhất quán và độ chính xác
  • Ví dụ prompt: "Tham khảo tệp goLang_Update_reference.md đính kèm để tóm tắt các điểm cốt lõi của hàm update, rồi dựa trên đó viết bản nháp cập nhật phần mềm"
• Xây chỉ mục cục bộ: với các tệp lớn (hơn 6000 dòng), có thể quét theo từng khối 1000 dòng để tạo chỉ mục gồm tên hàm và tham chiếu dòng
  • Khi làm frontend, có thể dùng các chỉ mục tách riêng theo khu vực như fr.index.md

Quản lý tác tử và cấu trúc hóa công việc

• Chuyên môn hóa tác tử: thiết lập các tác tử theo vai trò như thiết kế (architect), khám phá mã (codeseeker), lập trình viên (coder), đồng thời cung cấp tệp quy tắc .md phù hợp cho từng vai trò
• Cách tiếp cận vertical slice: chia công việc thành các đơn vị tính năng nhỏ có thể hoàn thành trong dưới 100 nghìn token
  • Khi vượt quá 100 nghìn token, xác suất tác tử hoạt động sai tăng vọt
• Bắt buộc tài liệu hóa công việc: yêu cầu cập nhật docs/TASKS.md, docs/WORKLOG.md, docs/DECISIONS.md để duy trì tính liên tục của công việc

Tận dụng Plan Mode và Ask Mode

• Plan Mode: rà soát toàn bộ dự án, lập kế hoạch theo yêu cầu rồi tiến hành từng bước
• Ask Mode: dùng để truy vấn codebase, khám phá ý tưởng, xem xét lựa chọn; hữu ích như công cụ thay thế Google/StackOverflow

Cách tiếp cận viết kiểm thử trước

• Phát triển dựa trên kiểm thử: viết unit test trước khi viết hàm, rồi để AI lặp lại việc sinh mã cho tới khi qua được test
  • Xác suất thu được mã đúng về mặt chức năng tăng đáng kể, sau đó chỉ còn cần tối ưu và dọn dẹp

Quan điểm hoài nghi và nhận thức về giới hạn

Giới hạn thực tế của agentic

• Làm việc không có giám sát là hành động liều lĩnh: ở trình độ công nghệ hiện nay, giao ticket rồi để nó tự làm ở chế độ nền có xác suất thất bại rất cao
• Khả năng bịa đặt: mô hình dễ sinh ảo giác (hallucination) hơn là thật sự thành công, và trong trường hợp xấu nhất có thể phá hỏng mã hiện có
• Tính trùng lặp của Planning Mode: chỉ cần yêu cầu mô hình cơ sở lập một kế hoạch chi tiết là đã đủ; Planning Mode không thực sự mang lại năng lực mới

Các ràng buộc bản chất của LLM

• Dự đoán chứ không suy luận: mô hình hoạt động bằng cách dự đoán từ tiếp theo thay vì xác minh kết quả, nên độ tin cậy sẽ còn bấp bênh cho tới khi grounding, memory và feedback được cải thiện
• Tri thức không phải trí tuệ: LLM là một kho tri thức tinh vi nhưng không có trí tuệ; nhà phát triển phải tự mang vào trí tuệ của mình (BYOI: Bring Your Own Intelligence) cùng ngữ cảnh cần thiết
• Thiếu bộ nhớ: mô hình không có trí nhớ thực sự, chỉ dựa vào context và context cache, nên mỗi khi bắt đầu cuộc trò chuyện mới thì ngữ cảnh lại bị đặt lại

Thiên lệch ngôn ngữ và dữ liệu

• Golang tương đối bất lợi: Golang có ít codebase công khai hơn Python hay JavaScript, nên mô hình thiếu các mẫu và quy ước đã được học
  • Đây là yếu tố cấu trúc khiến việc thu được kết quả chỉnh sửa hoặc chuyển đổi nhất quán trở nên khó hơn

Hướng dẫn thực dụng để áp dụng thành công

Prompting và cung cấp ngữ cảnh

• Chỉ dẫn rõ ràng và chi tiết: dùng ngữ pháp và dấu câu chính xác, tránh diễn đạt mơ hồ và đưa ra chỉ thị minh bạch
• Tham chiếu tường minh mọi tệp liên quan: nếu không chỉ rõ toàn bộ tệp mà tác tử phải dùng, xác suất tạo ra spaghetti code sẽ tăng lên
• Thiết lập tệp quy tắc: đặt quy tắc cho toàn bộ workspace và các tệp quy tắc theo từng dự án để dẫn dắt việc sinh mã nhất quán
• Tận dụng @Docs: dùng tính năng tham chiếu tài liệu để cung cấp tri thức cốt lõi mà tác tử cần (ở một số phiên bản hoạt động chưa ổn định)

Phạm vi công việc và kiểm chứng

• Chia nhỏ thành đơn vị tối thiểu: tách công việc thành các phần nhỏ nhất có thể xử lý trong một lần, xác minh xong từng bước rồi mới sang bước tiếp theo
• Rà soát thời gian thực: xem lại mọi đoạn mã được sinh ra ngay khi nó xuất hiện và yêu cầu chỉnh sửa tức thì để tránh spaghetti code
• Sao lưu và quản lý phiên bản: tạo bản sao lưu ở mỗi bước và sử dụng hệ thống quản lý phiên bản như GitHub
• Chạy kiểm thử: dùng pytest --testmon -q để chạy tăng dần các bài test bị ảnh hưởng, rồi chạy toàn bộ test trước khi hoàn tất

Mô-đun hóa và cấu trúc mã

• Tách tệp 6000 dòng: một tệp đơn 6000 dòng là thiếu tính mô-đun và bất lợi cho việc cung cấp ngữ cảnh, nên tách thành 12 tệp cỡ 500 dòng sẽ hiệu quả hơn
• Ưu tiên vertical slice: phát triển theo các đơn vị tính năng nhỏ có thể chạy end-to-end

Chọn mô hình và quản lý chi phí

• Ưu tiên cân nhắc Claude Sonnet 4.5: so với GPT hay Gemini, mô hình này có tính nhất quán và độ chính xác cao hơn, xứng đáng với phần chi phí bổ sung
• Lưu ý mức tiêu thụ token: các kế hoạch lớn tiêu tốn nhiều token, vì vậy khi triển khai thực tế nên chia thành các bước nhỏ để tiết kiệm chi phí hơn

Các trường hợp sử dụng đặc biệt

Tạo script dùng một lần

• Script phân tích: nếu mỗi ngày phải viết hàng trăm script phân tích dữ liệu dùng một lần, thì ngay cả với độ chính xác chỉ 50%, AI vẫn có thể tạo và chạy chúng nhanh hơn 1000 lần so với viết tay
• Có thể tự kiểm chứng kết quả: vì người dùng có thể trực tiếp xác minh đầu ra nên ngay cả khi độ chính xác thấp, cách này vẫn hữu ích trong thực tế

Xây dựng ứng dụng từ đầu

• Cấu trúc đa tác tử: khi xây một ứng dụng lớn từ con số 0, một tác tử giám sát có thể rà soát công việc của các tác tử khác để duy trì tính nhất quán
  • Có hiệu quả trong việc giữ đồng nhất tên import, tên biến và tránh trùng lặp mã
• Hiệu quả theo chi phí: vẫn cần nhiều chỉnh sửa phức tạp và tái cấu trúc, nên về dài hạn cách tiếp cận theo từng bước vẫn rẻ hơn

Tóm tắt ý kiến cộng đồng

Trải nghiệm tích cực (năng suất tăng 3–5 lần)

• Website Next.js: xây dựng từ số 0 một website hoàn chỉnh, có thể triển khai, chỉ trong vài phút
• Triển khai tính năng phức tạp: thêm tính năng threads vào ứng dụng chat trong 3–4 phút (khối lượng công việc lẽ ra mất 3 ngày)
• Khi áp dụng có hệ thống: nếu kết hợp quy tắc rõ ràng, ngữ cảnh đầy đủ và xác minh từng bước thì có thể đạt mức thành công nhất quán

Trải nghiệm tiêu cực (hiện vẫn thiếu thực dụng)

• Sinh hàng loạt spaghetti code: khi giao mục tiêu quá rộng, dễ phát sinh các vấn đề như quên cập nhật tài liệu hoặc không xóa các tệp thừa
• Lỗi ngữ nghĩa: mã có thể chạy được về mặt kỹ thuật nhưng đặt sai vị trí, hoặc tái triển khai những hàm vốn đã tồn tại, tạo ra vấn đề cấu trúc
• Theo dõi quá 5 phút thường thất bại: các lượt chạy dài hơn 5 phút phần lớn tạo ra kết quả vô dụng

[GN⁺]

Ý kiến trên Hacker News

• Theo trải nghiệm trực tiếp của tôi, phần lớn LLM làm theo chỉ dẫn của tôi khá tốt. Tất nhiên vẫn cần prompt được trau chuốt kỹ và có kế hoạch từ trước, nhưng chỉ cần nắm được ba thứ đó thì hoàn toàn có thể bay nhảy với các coding agent này. Thỉnh thoảng khoảng 1 lần trong 10 lần sẽ sai, nhưng ngay cả khi đó cũng có thể nhanh chóng dừng lại và điều hướng lại để quay về đúng hướng. Tôi khá bất ngờ khi ở HN có nhiều người hoài nghi hiệu quả đến vậy. Dĩ nhiên có nhiều điều đáng lo như chi phí, thay đổi việc làm..., nhưng việc thường xuyên thấy người ta nghi ngờ tính hữu dụng của coding agent vẫn khiến tôi ngạc nhiên
  • Sẽ rất hay nếu được xem video hoặc ví dụ thực tế về những trường hợp hệ thống agent hay LLM thật sự tạo ra giá trị vượt hơn tìm kiếm Google hay Stack Overflow
  • Nếu bạn giải thích đầy đủ trạng thái hiện tại, kết quả mong muốn và cách tiến hành, thì có thể cùng agent lập kế hoạch, tinh chỉnh rồi thực thi. Làm vậy thì trình độ công nghệ hiện tại cũng khá ấn tượng. Kỳ vọng xử lý việc phức tạp chỉ bằng một câu là không thực tế. Nó đòi hỏi thời gian và công sức giống như khi giao việc kỹ thuật cho một thực tập sinh thông minh nhưng chưa có kinh nghiệm thực tế. Chỉ khác là AI agent làm nhanh hơn thực tập sinh con người rất nhiều
  • “Phần lớn là được” về cơ bản có nghĩa là không có chỉ số độ tin cậy thực sự nào cả
  • Vừa rồi lúc đang dắt chó đi dạo, tôi dùng Codex (gpt-5-high) để chuyển một ứng dụng Python sang Go chỉ trong một lần. Test kết quả thì chạy tốt. Tôi hài lòng vì giờ có thể phân phối dưới dạng một binary duy nhất mà không cần virtual environment. Không chắc lệnh đó có thật sự quá đơn giản hay không
  • Tiêu chuẩn “phần lớn là được” với tôi là không đủ. Vấn đề nghiêm trọng hơn việc không làm theo chỉ dẫn là nó không chịu thừa nhận mình sai mà còn tiếp tục cố cãi. Khi tôi giao việc mức độ phức tạp vừa phải hoặc yêu cầu phân tích lỗi, nó khá thường xuyên cố chấp bám lấy kết luận sai. Nhiều khi đến lúc tôi phải chỉ ra vấn đề trực tiếp thì nó vẫn chưa tự tìm được lối ra. Với code đơn giản hay tác vụ boilerplate thì nó thực sự rất tốt, và chỉ cần một chút phản hồi là nó còn có thể tạo cả thư viện mới. Nhưng vì hay sai nên tôi không muốn giao việc phức tạp hơn. Dù vậy, lúc bị bí thì tôi vẫn dùng nó để tung ý tưởng; dù sai đi nữa, nó vẫn giúp tạo động lực
• Khi chênh lệch trải nghiệm giữa các lập trình viên với LLM lớn một cách kỳ lạ, điều chúng ta thật sự nên tự hỏi là: “Vì sao trải nghiệm lại khác nhau đến vậy?” Cách giải thích đơn giản nhất là “bạn dùng chưa đúng”, nhưng với tư cách người phát triển hệ thống AI, tôi cũng ngạc nhiên khi có quá nhiều người chỉ viết kiểu “sửa đi”, “làm báo cáo đi” mà vẫn mong có kết quả. Cũng có cả làn sóng cường điệu từ giới lãnh đạo theo kiểu “AI làm được mọi thứ”, và điều này còn gắn với định giá doanh nghiệp, giá cổ phiếu. Công chúng nói chung dường như cũng xem AI là “trí tuệ nhân tạo thực sự”. Thực ra, tuyên bố rằng LLM không làm nổi cả chỉ dẫn đơn giản thì khá thiếu thuyết phục; vấn đề quan trọng là nó vẫn chưa thực sự làm tốt các việc phức tạp
  • Một giả thuyết khác của tôi là ai cũng có một bản spec trong đầu, nhưng lại viết nó ra một cách lộn xộn rồi mong LLM hiện thực hóa, nên kết quả cuối cùng luôn lệch với spec đó. Có lập trình viên sẽ âm thầm điều chỉnh lại spec trong đầu sau khi thấy kết quả, hoặc chấp nhận những khác biệt nhỏ; trong khi người khác thì thất vọng vì LLM không khớp với kế hoạch trong đầu họ. Nó giống như một kiểu “ký ức giả” mang tính tâm lý vậy: có người linh hoạt, dễ thỏa hiệp hơn, có người thì cứng nhắc hơn. Bản thân tôi cũng luân phiên trải qua cả hai kiểu đó
  • Giờ tôi muốn thấy nhiều hơn các screencast, bài viết dài hay bất cứ thứ gì cho thấy toàn bộ quá trình ai đó thật sự tạo ra một tính năng không hề tầm thường. Các AI influencer hầu như chỉ cho xem cảnh dùng AI tạo công cụ AI, hoặc demo CRUD, hello world. Ngay cả các lập trình viên kỳ cựu khi nói rằng hơn nửa codebase được AI tạo ra thì thực tế cũng thường thú nhận là họ bỏ gần hết và chỉ tham khảo một phần. Câu chuyện “single prompt → ứng dụng hoàn chỉnh” nhanh chóng biến thành “hữu ích khi cần lấy động lực từ màn hình trắng”. Tôi mong các lập trình viên làm việc thực tế chia sẻ minh bạch hơn về cách họ thật sự đang dùng nó
  • Thực ra, “lập trình viên” là một phạm trù quá rộng nên không có nhiều ý nghĩa trong cuộc thảo luận này. Với đa số việc ghép các mẩu code kiểu CRUD tương tự nhau thì LLM hoạt động khá ổn
  • Mỗi người đều đang làm trên những codebase khác nhau. Chi tiết quan trọng này gần như không được nhắc tới. Dùng càng thường xuyên thì kỳ vọng càng tăng và càng nhanh cảm nhận thấy giới hạn. Dùng thỉnh thoảng thì thấy ấn tượng, nhưng dùng cả ngày thì cuối cùng sự thất vọng cứ tích lũy. Nhiều thứ mà ta nghĩ “đến mức này thì nó phải làm được chứ” rốt cuộc vẫn phải sửa lại
  • Tôi tin chắc khác biệt không nằm ở kết quả mà ở kỳ vọng của mỗi người. SVP IT ở công ty tôi là một người cực kỳ ca ngợi AI. Gần đây tôi làm việc với dự án legacy PHP mà ông ấy từng xây dựng, và nhận ra tiêu chuẩn chất lượng code mà ông ấy hài lòng thực sự rất thấp. Tôi cũng dùng LLM hằng ngày nhưng luôn chỉnh lại kết quả. Tức là chất lượng code càng thấp thì người ta càng dễ hài lòng với đầu ra của LLM
• Trên diễn đàn Cursor chỉ toàn lặp lại câu “bạn dùng sai rồi”, nhưng điều tôi thật sự tò mò là độ tin cậy, quy trình và việc áp dụng trong môi trường thực tế. Ngay cả ở đây tôi cũng có cảm giác hầu như không thấy ai dùng ở quy mô lớn. Bên tôi cũng chủ yếu dùng AI như một “đồng nghiệp hơi ngốc”, và tận dụng thử nghiệm hơn trong các side project ít ràng buộc. Tôi có ấn tượng rằng agent phần lớn chỉ là hype (hoặc chỉ hữu ích trong những ngách rất hẹp)
  • Lý do OP có kết quả tệ là vì dùng Cursor. Cursor cắt ngữ cảnh hội thoại một cách tàn nhẫn để giảm chi phí. Khác với nhà cung cấp model, họ phải trả chi phí dùng LLM theo giá bán lẻ nên ở thế bất lợi về giá. Cursor không minh bạch về việc cắt bớt ngữ cảnh tới mức nào, và theo kinh nghiệm của tôi thì họ cắt cực kỳ hung hăng, đến mức phải gọi lại cùng một file lặp đi lặp lại thì nó mới hiểu chuyện gì đang xảy ra. Lời khuyên của tôi là đừng đầu tư thêm thời gian vào Cursor nữa. Code do Cursor tạo ra chỉ tích thêm nợ kỹ thuật. Tôi chuyển sang Codex và Claude và hài lòng hơn nhiều
  • Tôi muốn biết cụ thể họ kỳ vọng cải thiện điều gì. Bài gốc không có ví dụ cụ thể, prompt hay phương pháp luận nào, chỉ đơn giản là “tôi giỏi viết prompt”, nên rất khó đánh giá hay đưa lời khuyên. Tôi cũng hiểu sự hoài nghi với workflow mang tính agentic ngay từ đầu, nhưng như vậy thì cũng không cho người khác cơ hội phản biện tử tế. Tôi cũng đã làm việc cùng agent vài tháng và vẫn đang học xem cái gì hiệu quả, cái gì thất bại. Theo trải nghiệm của tôi:
    • Điều phối bằng framework như agent-os là thiết yếu
    • Cân bằng giữa hướng dẫn và tự chủ là rất quan trọng
    • Lập kế hoạch trước là cực kỳ quan trọng, đặc biệt với code legacy
    • Ví dụ của tôi: trong hệ thống legacy, tôi liên tục vượt quá cửa sổ ngữ cảnh, và mỗi lần tóm tắt lại ngữ cảnh thì lại bỏ sót thông tin thiết yếu, khiến nó lặp đi lặp lại cùng một sai lầm.
    • Cách hiệu quả là: cấu trúc vấn đề thật rõ ràng, ghi chép lại từng phát hiện/bài học, và chia nhỏ thành các sub-agent rất cụ thể (để quản lý được cửa sổ ngữ cảnh). Chỉ khi đó agent mới thật sự hữu ích trong việc khám phá code legacy
  • Tôi từng có trải nghiệm agent bắt được vài production bug mà tôi không tìm ra (những bug lạ mà tôi không có đủ thời gian đào sâu). Tất nhiên số bug nó không tìm ra còn nhiều hơn, nhưng so với việc bỏ ra một giờ của kỹ sư phần mềm thì gần như miễn phí, và thỉnh thoảng hiệu quả là đã đủ để trở thành một chiến lược đáng dùng
  • Một bài viết có ví dụ thực tế và cụ thể sẽ có ý nghĩa hơn và dẫn tới những câu trả lời tốt hơn. Thông tin cho thấy một vấn đề thực tế trong công việc và quá trình LLM thất bại sẽ hữu ích hơn nhiều
  • Giá trị kinh doanh thực tế nhỏ hơn rất nhiều so với những gì mọi người nghĩ, điều này khiến tôi bực bội. Chắc chắn trong boilerplate hay lĩnh vực quen thuộc, đôi khi nó còn làm tốt hơn con người. Nhưng các vấn đề khác (phụ thuộc Big Tech, ô nhiễm dữ liệu, thông tin không thể kiểm chứng, suy giảm sáng tạo, sụp đổ tính nguyên bản, sự ngu dốt của các tín đồ AI, tiêu thụ năng lượng, chiếm dụng tác phẩm sáng tạo của con người...) là quá lớn. Tôi chỉ thấy khó hiểu khi có người tin rằng những thứ này đem lại lợi ích ròng cho nhân loại
• Năm 2025, marketing đã trở nên cực kỳ giỏi trong việc để thương hiệu len vào mọi diễn đàn như Reddit, LinkedIn... CEO, “nhà tư tưởng” AI, VC đều quảng bá LLM như phép màu và đóng gói v0, Lovable... thành đổi mới thế hệ tiếp theo. Câu trả lời của giới lãnh đạo cũng na ná nhau cả (video liên quan). Nhưng thực tế là dù có tạo bao nhiêu thứ như CLAUDE.md hay cursorrules thì gần như cũng không hiệu quả. Cuối cùng LLM vẫn phải làm theo chỉ dẫn, nhưng trên thực tế nó có vẻ rất ngẫu nhiên. Nó còn chẳng tuân thủ nổi cả những quy tắc cực kỳ đơn giản, nên tôi cảm thấy những người đăng bài trên diễn đàn Cursor có lẽ đều là nghiệp dư. Và nữa, LLM thực sự rất tệ ở việc viết code mới. Nó giả định thư viện không tồn tại rồi tạo ra một đống ký tự vô nghĩa. Tôi đúng nghĩa chỉ dùng nó như speech-to-text, nhưng LLM lại giỏi hơn tôi ở việc phát hiện edge case bị bỏ sót, best practice tôi chưa biết, cú pháp, v.v.
  • [1] Kết quả từ tìm kiếm, Perplexity... giờ phần lớn chỉ là một khối marketing do đội marketing rải ra
  • Tôi hoàn toàn đồng ý rằng LLM thật sự rất khủng khiếp với công việc code mới. Các model SOTA hiện tại có thể tạo boilerplate hay cấu trúc đơn giản khá tốt trong những framework rất nổi tiếng với pattern nhất quán (MVC chẳng hạn). Điểm thật sự nổi bật là các nhiệm vụ quét qua lượng lớn thông tin để tìm ra thứ gì đó (codebase, log, stack trace...). Nhưng chuyện marketing rằng “agent sẽ tạo toàn bộ codebase” thì theo tôi hiện giờ vẫn chưa phải sự thật
  • Trải nghiệm của tôi lại hoàn toàn ngược lại. Trong tuần vừa rồi, Claude Code gần như tự chủ sửa các vấn đề compiler mà tôi đang duy trì. Ngoài vài lần khiến tôi bực bội, nó liên tục sửa tốt cả những bug tinh vi về sinh code và parser, và phần tôi phải can thiệp thì gần hơn với giới hạn của công cụ như quản lý compaction. Nó còn triển khai cả những phương pháp mà phải tra sách mới biết, và khi chạy thực tế thì xác nhận là hoạt động tốt. Có thể nó hiếm khi tạo ra thứ hoàn toàn mới và thực sự “đột phá”, nhưng thật ra hầu như mọi code đều chẳng mới mẻ gì. Theo kinh nghiệm của tôi, nếu giao việc theo hướng dẫn được cấu trúc tốt thì nhìn chung nó làm theo rất ổn. Không phải cứ ghi đại vào CLAUDE.md là xong. Cốt lõi là chỉ dẫn tỉ mỉ về quy trình. Cách tôi làm gồm: 1) hướng dẫn debug theo từng dự án, 2) làm rõ tiêu chí chấp nhận, 3) chạy test thường xuyên và yêu cầu ghi lại các thay đổi nhỏ theo từng đơn vị vào file. Làm vậy, tôi có thể để Claude tự động làm việc suốt nhiều giờ gần như không cần giám sát (thi thoảng chỉ cần gõ lệnh “continue” hoặc dùng /compact). Nó không cho code hoàn hảo mọi lần, nhưng tôi cũng vậy thôi. Dù sao thì nhìn chung nó dẫn tới thay đổi tích cực và công sức của tôi giảm đi rất nhiều. Tôi vẫn chưa khuyến nghị bootstrap trong trạng thái chưa được thiết kế kỹ, nhưng đôi khi nó vẫn làm được (dĩ nhiên cần review trước). Dạo này tôi thậm chí còn cân nhắc để Claude chạy liên tục nhiều ngày để tự giải quyết vấn đề
  • Thật sự rất thú vị khi trải nghiệm LLM của mỗi người lại khác nhau đến vậy. Với tôi, codex-cli giúp năng suất tăng gấp 5 lần. Nó xử lý ngon lành cả việc chuyển source có cấu trúc cực kỳ khác thường và internal SVG execution trace sang định dạng đồ thị JSON tùy biến, hoặc trích xuất tài liệu chính xác từ codebase Python/C++ phức hợp (thậm chí tới cả kernel RISCV cấp thấp). Tôi thật sự tò mò nguyên nhân nào khiến cùng một công cụ lại cho kết quả khác nhau đến vậy
  • Code với Claude có cảm giác như chơi máy đánh bạc. Thỉnh thoảng nó cho đúng thứ mình muốn, nhưng thường xuyên hơn nhiều là không, hoặc trật hoàn toàn. Tuyệt đối nguy hiểm nếu giao cho nó chạy không người giám sát
  • Với tôi, giá trị ổn định nhất của LLM là nó rất giỏi phát hiện những lỗi nhỏ nhặt, ví dụ tốt nhất hoặc cú pháp code mà con người hay bỏ sót. Vì vậy dùng như người review PR thì khá ổn, miễn là giữ thái độ dè chừng
• Công ty chúng tôi áp dụng kiểu XP cổ điển. Khi phát triển tính năng mới trên ứng dụng brownfield, chúng tôi chia thành gần 8 sub-agent như “red-test-writer”, “minimal-green-implementer”, “refactorer”... Giờ chỉ cần nhập vào Claude Code: “hãy tạo tính năng X theo quy trình TDD này”, thì sau 30 phút đã có code tốt hơn rất nhiều, độ bao phủ test 90%, và kết quả ở trạng thái có thể chấp nhận ngay. Tất nhiên điều này dựa trên nhiều năm kinh nghiệm với XP, pair programming và TDD, nhưng hơn 1 năm qua, 95% code production của chúng tôi là do AI viết (bao gồm cả các tính năng phức tạp không hề tầm thường). Gần như chẳng có bí kíp bí mật nào cả, mà vẫn chạy rất ổn. Với chúng tôi, hiệu quả thật sự rất lớn
• Ở đây ý kiến khác biệt quá lớn. Nếu mỗi người không nói rõ mình thất bại ở đâu và đang dùng cho loại công việc nào thì không thể có thảo luận tử tế. Nếu không bàn về các nhóm trường hợp cụ thể mà LLM thất bại/thành công thì tất cả chỉ là nhiễu mà thôi
  • Khi tranh luận, cần ghi rõ ngôn ngữ/framework, miền bài toán, mức độ SRE, LLM (model/phiên bản), agentic harness (claude code, codex, copilot...), case thất bại/thành công, thậm chí cả mức độ thành thạo với LLM. Ngoài ra còn phải xét kỹ sư đó có làm trên một codebase suốt 10 năm không, hay luân phiên nhiều dự án, là phát triển mới (Greenfield) hay bảo trì, là nghiên cứu đổi mới hay CRUD, v.v. vì điều kiện có thể rất khác nhau
• Ở góc độ nhà khoa học, nhiều khi phải lặp đi lặp lại boilerplate hơi khác nhau cho từng dataset, và coding agent giải quyết phần này khá đáng kể. Đặc biệt, dù có nhấn mạnh bằng chữ in hoa tới năm lần rằng “TUYỆT ĐỐI KHÔNG được bịa dữ liệu, đừng dùng np.random”, đôi khi Claude vẫn phớt lờ. Điều này ngớ ngẩn một cách bất ngờ. Khi nó hoạt động thì thật tuyệt vời, nhưng khi không hoạt động thì thậm chí chẳng có tín hiệu thất bại. Nếu nhìn theo góc marketing LLM, tôi còn tưởng tượng phía sau coding agent sẽ có một agent kiểu ‘PIPA (Performance Improvement Plan Agent)’ đi kèm để giám sát theo thời gian thực xem nó có đang làm việc đúng không. PIPA sẽ kiểm tra hiệu suất của coding agent để HR hoặc ban điều hành quản lý “nhân viên AI” (agent), và biết đâu tương lai sẽ đi theo hướng đó
  • Nếu bảo “đừng nghĩ tới con voi mặc váy tutu màu hồng!” thì chẳng phải nó lại hiện ra ngay trong đầu sao? Là nhà khoa học thì bạn nên biết rằng, do đặc tính của LLM, nó không hiểu tốt câu phủ định. LLM được huấn luyện theo token nên dù bạn viết “NO ELEPHANTS” thì từ “voi” vẫn hiện diện trong ngữ cảnh. Thành ra lại vô tình dẫn nó về chính từ đó. Dùng chỉ dẫn khẳng định sẽ có lợi hơn
  • Chỉ tưởng tượng đến PIPA thôi cũng đã thấy đáng sợ
• Prompt là chìa khóa để model tự tìm ra ngữ cảnh phù hợp (ví dụ thông báo lỗi tốt), và nếu chia tác vụ thành những phần rất nhỏ, đều đặn thì có thể truyền kết quả của các vòng lặp/test theo từng bước vào ngữ cảnh của tác vụ tiếp theo. Khoảng 50% vấn đề phù hợp với cách này, và 50% còn lại thì vòng lặp LLM vẫn có thể đỡ phiền hơn tự động hóa truyền thống, nhưng trong số đó lại có một nửa không đáng để theo đuổi nếu xét trên hiệu quả đầu tư. Cuối cùng, nếu có những trường hợp “12,5%” mang tính phép màu, thì cách làm agent bị ràng buộc chặt (Constrained) sẽ là tối ưu nhất
  • Nếu ai đó phát trực tiếp đúng quy trình đó trên YouTube hay đâu đó (không phải tutorial mà là live coding tự nhiên), có lẽ sẽ chia sẻ được nhiều insight hay
• Gần 30 năm trước, khi mới bước vào AI, tôi được nghe thế này: hễ nghe tới “intelligent agent” thì hãy nghĩ là “một con kiến có thể huấn luyện được”
  • Tôi muốn nghe chi tiết hơn
• Với tôi, vấn đề lớn nhất là hiệu năng của các công cụ AI biến động rất mạnh tùy theo tác vụ, và rất khó dự đoán chúng sẽ thất bại ở đâu, khiến tôi tốn thời gian. Tôi nghĩ rằng khi có nhiều trải nghiệm hơn với công cụ thì kỹ năng viết prompt sẽ tốt lên, nhưng hiện tại vẫn rất bực bội. Dù vậy, vẫn có phần giao thoa giữa tính hữu dụng của agent và AI (ví dụ: tự động tạo boilerplate cho dự án mới). Trong những lúc đó, ‘agent mode’ tiện hơn. Hiện tại kinh nghiệm thực chiến của tôi vẫn còn khá ít
  • Càng hoạt động tốt thì kỳ vọng càng tăng và người ta càng mở rộng cách sử dụng; đến khi chạm trần giới hạn thì sự thất vọng lại còn lớn hơn cả lúc ban đầu