Vì sao AI dựa trên tác tử không phải là một pair programmer giỏi

• Tác tử LLM viết mã nhanh hơn con người rất nhiều, nên trải nghiệm pair programming có thể còn kém đi
• Do tự động hóa quá nhanh, người dùng không theo kịp và thường xuyên bị mất ngữ cảnh công việc
• Hiện tượng này tương tự với cảm giác bị bỏ rơi khi pair với một lập trình viên giàu kinh nghiệm, và cuối cùng dẫn đến việc kiểm soát chất lượng cũng như giao tiếp bị suy yếu
• Giải pháp được đề xuất là cộng tác theo kiểu code review bất đồng bộ và chuyển sang workflow ghép cặp với AI chậm hơn, tập trung vào kiểm soát chất lượng và giao tiếp
• Tác tử AI cũng cần được thiết kế giống con người hơn: “dừng lại để trò chuyện, và tập trung vào hoài nghi cùng xác minh hơn là sự tự tin”

---

Vấn đề của tác tử LLM và pair programming

• Tác tử AI (ví dụ: Copilot Agent) viết mã nhanh hơn rất nhiều so với tốc độ suy nghĩ của con người
• Vì vậy, mã tuôn ra trước cả khi người dùng kịp theo dõi, dẫn đến hiện tượng mất ngữ cảnh và giảm mức độ tập trung vào công việc
• Khi gặp sự cố và tác tử nhờ trợ giúp, người dùng lúc đó thường vẫn chưa nắm được tình hình mà đã phải đóng vai trò “dọn hậu quả”, kết quả là gánh nặng thu dọn phần mã đã đi sai hướng tăng lên
• Sau cùng, việc kiểm soát chất lượng, giao tiếp và duy trì đúng định hướng trở nên khó khăn hơn

• Trải nghiệm pair với những tác tử AI tốt nhất gợi lại những ký ức tiêu cực từ việc ghép cặp với một lập trình viên con người xuất sắc trước đây
  • Người pair cùng gõ bàn phím quá nhanh và gần như không nói gì, khiến bạn không thể theo kịp đoạn mã
  • Năng lượng tinh thần bị rút cạn hoàn toàn rồi dần dần bạn tách khỏi công việc
  • Khi người pair bị mắc kẹt và yêu cầu hỗ trợ, bạn rơi vào trải nghiệm bối rối vì rất khó nắm được chuyện gì đang xảy ra
  • Trong quá trình làm việc, một phần triển khai đi chệch khỏi mục tiêu được tạo ra, và gánh nặng sửa lại cho kịp deadline bị đẩy sang cho bạn

The path forward: giải pháp thực tế

• 1. Cộng tác bất đồng bộ

  • Tương tự khi pair programming với con người mà một bên chủ động triển khai, hình thức AI tự viết mã độc lập rồi được review qua Pull Request sẽ hiệu quả hơn
  • Có thể tận dụng workflow bất đồng bộ như GitHub Coding Agent để người dùng tập trung vào review và kiểm soát chất lượng

• 2. Ghép cặp “theo lượt” với tốc độ chậm hơn

  • Thay vì “Agent Mode” của AI, hãy dùng cách làm từng bước một như Edit/Ask Mode
  • Giống ping-pong pairing (một bên đề xuất, một bên phê duyệt), người dùng trực tiếp chấp nhận/kiểm tra các thay đổi do AI đề xuất để điều tiết tốc độ
  • Thay vì chỉ dùng AI cho giải quyết vấn đề/debugging, nên tận dụng nó trong một workflow nhất quán

Ý tưởng để việc ghép cặp với tác tử trở nên “con người” hơn

• Cho phép người dùng tự điều chỉnh tốc độ xuất mã của AI (dòng/phút, từ/phút)
• Có chức năng tạm dừng tác tử để người dùng đặt câu hỏi hoặc phản biện về định hướng
• Vượt qua UI chatbot truyền thống, cung cấp các UI primitive gắn với tiến độ công việc (ví dụ: ghim phiên hiện tại vào một GitHub issue cụ thể, danh sách To-do tích hợp, v.v.)
• Thiết kế để tác tử dừng lại và trò chuyện thường xuyên hơn: xác nhận “vì sao đang làm việc này”, xin lời khuyên, kiểm tra định hướng, từ đó tạo bầu không khí cộng tác như với con người
• Bổ sung hỗ trợ voice chat nâng cao để người dùng có thể giữ mắt trên code và giao tiếp với AI bằng giọng nói

• Nếu áp dụng các tính năng này, thay vì kiểu ghép cặp với tác tử nhanh và một chiều như hiện nay, chúng ta có thể đạt được một trải nghiệm hợp tác thực sự giữa con người và tác tử

Kết luận

• Ở thời điểm hiện tại, chúng ta đang chứng kiến đồng thời cả giới hạn lẫn tiềm năng của pair programming dựa trên tác tử AI
• Pair programming với tác tử AI sẽ hiệu quả hơn nếu được thiết kế xoay quanh giao tiếp, chất lượng và xác minh như khi cộng tác với con người, thay vì chỉ nhanh hơn
• Cách làm “chậm lại, trò chuyện, xác minh và chia sẻ bối cảnh” sẽ nâng cao chất lượng ghép cặp với AI

[panarch]

> 1. Cộng tác bất đồng bộ
> Cũng như trong pair programming với con người, khi một người chủ động dẫn dắt tiến độ, việc AI tự viết mã một cách độc lập rồi review qua Pull Request sẽ hiệu quả hơn

Tôi đã dùng Codex được vài ngày, và tôi đồng cảm với quan điểm này hơn là mô hình agent. Khi có thể chạy đồng thời công việc trên nhiều dự án, cảm giác thực sự giống như đang làm việc cùng nhiều lập trình viên junior.
Khi có thể sử dụng AI theo cách bất đồng bộ, vừa trên nhiều dự án vừa cho nhiều đầu việc trong cùng một dự án cùng lúc, tôi thực sự cảm nhận được năng suất tăng theo cấp số cộng, hơn 3-10 lần.

[GN⁺]

Ý kiến trên Hacker News

• Cảm giác đây là bài viết diễn tả chính xác lý do vì sao tôi từng dùng AI theo cách này rồi nhanh chóng bỏ cuộc. Khi tôi muốn tạo ra thứ gì đó, tôi thường đã định hình đại khái về <i>cách</i> làm, nhưng cách AI thực sự thực hiện lại thường khác với điều tôi muốn. Thế rồi khi AI tạo ra 2.000 dòng mã trong một lần, công việc lại càng nhiều hơn. Kiểu như phải chỉ đạo: "Trước hết xóa hết đống chú thích này đi, với đoạn mã đơn giản thì phần giải thích thừa này dài gấp đôi rồi. Đừng trừu tượng hóa X theo kiểu này, tôi muốn thế này cơ...". Mà cứ mỗi lần góp ý xong thì 2.000 dòng lại đột ngột biến thành 700 dòng, khó mà theo kịp nổi. Tôi cũng ghét việc codebase biến thành một đống script mà tôi không hiểu rõ, mỗi cái lại theo một kiểu khác nhau. Điều tôi cần là một AI có phong cách và cách nghĩ gần với mình, nhưng đó lại là phần quá khó. Làm việc cùng AI giống như ngày đầu tiên làm việc với một người hoàn toàn thiếu kinh nghiệm. Cá nhân tôi nghĩ đây không hẳn là vấn đề AI quá tự tin, mà là vì nó làm lộ rõ hơn quy trình thiết kế. Lý tưởng nhất là phải có bước xem trước một bản thiết kế kiểu như "tôi đang nghĩ đến cách tiếp cận này, sẽ quản lý các hàm, class và state theo cách này", thấy ổn rồi mới chuyển sang triển khai.

  • Cũng như với kỹ sư con người, tôi muốn nhấn mạnh rằng phiên lập kế hoạch ban đầu thực sự rất quan trọng. Trước khi viết mã, hãy bàn bạc trước và chốt dần các chi tiết như thể đang thương lượng. Tôi còn cố tình đặt câu hỏi đầu tiên thật mơ hồ để xem có gợi ý bất ngờ nào xuất hiện không, rồi mới dần đi vào cụ thể. Khi đã đủ hài lòng, tôi yêu cầu LLM tạo hai tài liệu là initialprompt.txt và TODO.md. initialprompt.txt chứa phần tóm tắt dự án, chỉ dẫn đọc TODO.md và lệnh đánh dấu sau khi hoàn thành từng bước. Cách này giúp LLM nắm được cả mục tiêu tổng thể lẫn công việc chi tiết, và khi cuộc trò chuyện bị cắt do giới hạn ngữ cảnh rồi phải bắt đầu lại, nó có thể nhanh chóng nhắc lại công việc.

  • Cảm giác như họ vừa tóm tắt đúng y hệt trải nghiệm của tôi. Những lần duy nhất tôi có thể hoàn thành thành công với mã do AI viết là khi tôi chỉ quan tâm đến kết quả cuối cùng và gần như không có kiến thức nền về lĩnh vực đó. Còn khi tôi có quan điểm mạnh mẽ về thế nào là kết quả “tốt”, tôi thường chỉ thấy thất vọng rồi bỏ dở dự án. Tôi từng dùng tính năng architect của roo code để sắp xếp trước cách tiếp cận, rồi sang code mode để triển khai mã thực tế, và cảm giác vừa vui vừa bực là chia đôi. Bài học quan trọng là luôn bắt đầu tác vụ mới, đừng kéo dài một cuộc trò chuyện quá lâu. Bình thường tôi có thói quen chia nhỏ vấn đề và kiểm tra kết quả, nhưng với LLM thì lại hay ném cả không gian vấn đề vào cùng lúc và thất bại. Tôi đã thử đi thử lại nhiều lần để tìm ra cách của riêng mình, và hôm nay vẫn thêm được một tính năng cho app chỉ trong 30 phút. Nếu tự làm thì chắc mất mấy ngày. Và lý do tôi chỉ ghi đúng 30 phút vào nhật ký công việc là vì tôi biết rất rõ mình muốn gì và không hứng thú với quá trình. Chính những trải nghiệm đó khiến tôi đi đến kết luận rằng giao cho AI viết thứ mã mà người khác sẽ phải dùng sau này là điều không thể, vì mọi lý do nêu trên.

  • Cuối cùng chỉ thấy quá mệt và kết quả thì không hài lòng. Nói điều này với những ai cũng đang trăn trở như vậy. Bản thân tôi cũng chỉ thấy agent coding làm mình hài lòng trong các script ngắn hạn không quan tâm chất lượng mã, hoặc những hàm lá thật sự không ảnh hưởng đến đâu cả.

  • Workflow mà hướng dẫn sử dụng Claude Code của Anthropic khuyến nghị là thứ đáng để tham khảo. Ý chính là “trước hết hãy bắt nó đọc mã, sau đó lập kế hoạch thay đổi, cuối cùng mới cho thực thi”. Bạn có thể xem và chỉnh bản kế hoạch trước khi AI viết dù chỉ một dòng mã. Khi dùng agent mà nó hành động khác với cách bạn muốn, ví dụ nhảy vào code ngay mà không có thiết kế, thì cứ bảo thẳng là "làm theo cách khác đi".

  • Chuyện tạo ra 2.000 dòng mã trong một lần nghe cứ như đang gõ prompt bắt nó nhét nguyên Skyrim lên SNES vậy. Tưởng tượng cảnh đi ăn trưa xong quay lại chạy thử rồi nổi giận vì nó lại làm ra một bản Fallout phong cách PS1 chỉ có cận chiến.

• Mỗi khi bài viết của tôi lên trang đầu HN, tôi luôn đọc bình luận trong tâm trạng sợ hãi không biết người ta sẽ nói những câu hung hăng thế nào để chứng minh tôi ngu ngốc và kéo thể diện của tôi xuống. Nhưng đôi khi, nếu tôi đặt tiêu đề thật khéo, chẳng ai đọc bài của tôi cả mà ai cũng chỉ nói chuyện của họ, và thế là tôi thoát được mớ chỉ trích đó.

  • Tôi thấy đây vừa là một câu chuyện hài hước vừa rất thực tế. Ở các bài khác cũng thường thấy mô-típ tương tự. Dù sao thì tôi thích chính kiểu thảo luận như thế này nên thấy rất thú vị.

  • Bài viết rất hay. Nó giống kiểu “làm sao để tận hưởng pair programming với AI”. Rất hữu ích nên xin cảm ơn.

• Lần đầu dùng agent LLM, tôi kỳ vọng vào giao tiếp hai chiều, một kiểu pair programming hợp tác thực sự. Nhưng thực tế thì lại gặp một đối tác chỉ muốn tự giải quyết mọi thứ hoàn toàn theo cách của riêng nó. Tôi thử sửa một chút thì ngữ cảnh phần mã AI viết lại bị vỡ, thành ra còn bất tiện hơn. Điều tôi muốn là một quy trình cộng tác thật sự, tôi làm một chút, AI làm một chút, luân phiên qua lại.

  • Không biết gần đây bạn đã thử lại chưa. Trải nghiệm của tôi thì khác. Tôi sửa mã do AI tạo ra rồi bảo nó đọc lại file. Lúc đó nó thường phản hồi kiểu “file đã có thay đổi rồi nhé”. Khi AI chỉnh mã, tôi chạy test rồi phản hồi để nó tiếp tục cải thiện theo vòng lặp. Cách này hoạt động tốt với Zed và Claude Sonnet.

  • Cách tôi thường làm là trước hết nhận đề xuất từ AI, rồi refactor hoặc nếu cần thì lại tiếp tục chỉ dẫn bằng prompt. Cách tiếp cận này có tác dụng nâng artificial accept rate, và thực tế đây lại là kiểu thống kê mà các công ty AI có thể dùng làm căn cứ để tuyên bố rằng "AI viết mã rất tốt". Trong khi thực tế có rất nhiều lúc tôi chỉ nghĩ “thôi kệ, để tôi tự sửa vậy”.

  • Tôi thường thêm câu kiểu “trước hết chỉ thảo luận thôi. Đừng sửa mã” thì cuộc trò chuyện sẽ đi đúng ý hơn. Nói qua nói lại đủ rồi thì cuối cùng mới bảo “áp dụng đi”.

  • Nếu muốn một kiểu cộng tác cụ thể thì hãy yêu cầu LLM thật rõ ràng. Sẽ rất hữu ích nếu chuẩn bị sẵn vài tài liệu prompt để lôi ra dùng trong mọi cuộc trò chuyện.

  • Dạo gần đây việc giữ ngữ cảnh không còn quá khó nữa nên sửa mã cũng không thành vấn đề. Tôi chỉ dùng Ask mode chứ không dùng kiểu ra lệnh, và trong Claude Code thì dùng Opus, còn trong Cursor thì dùng o3 max. Tôi cố tình tránh agent mode vì giống như bài gốc nói, càng về sau thì lợi ích tôi nhận được càng ít. Tôi hiếm khi dùng tab completion, và 80~90% mã được đề xuất là tôi tự sửa rồi tự gõ lại. Nhờ vậy tôi vẫn giữ được tốc độ gõ 170wpm. Tốc độ xuất của Opus và o3 max cũng đủ chậm để không khó theo dõi, ban đầu thì quá nhanh nên hơi mệt nhưng rồi quen rất nhanh. Đánh giá cá nhân của tôi là, nếu GitHub Copilot là toàn bộ trải nghiệm LLM của bạn thì đó chỉ mới là mức nhà nghỉ mà thôi.

• Pair programming cũng không phải lúc nào cũng phù hợp. Thực ra nhiều trường hợp còn không phù hợp. Như tôi đã nói ở nơi khác, các gợi ý autocomplete của LLM làm gián đoạn luồng tập trung khi code, vì cứ giữa chừng lại phải dừng để đọc, xem xét rồi chấp nhận hoặc từ chối, khiến flow lập trình bị phá vỡ hoàn toàn. Tôi đã rất vất vả khi cố nhét AI autocomplete vào workflow của mình.

  • Tôi cũng nghĩ vậy. Giải pháp là dùng luân phiên cả một IDE chuyên để làm việc không có AI và Cursor/VS Code. Trạng thái tập trung sâu thực sự là thứ không thể có khi vừa làm vừa trò chuyện với chatbot.

  • Gần đây tôi mua laptop mới và cài lại IDE, rồi trong vài tiếng ngồi code cứ thấy có gì đó “lạ lạ”. Hóa ra là tôi quên đăng nhập GitHub Copilot nên đang làm việc hoàn toàn không có AI. Cảm giác là mình chủ động viết mã hơn hẳn vì không cần đợi autocomplete. Đặc biệt Cursor cứ liên tục làm gián đoạn luồng làm việc nên ngay cả mấy tính năng kiểu “dự đoán vị trí con trỏ tiếp theo” tôi cũng thấy hoàn toàn không cần. Từ giờ tôi sẽ tắt Copilot và chỉ dùng các công cụ kiểu agent như aider cho boilerplate hoặc tác vụ lặp lại.

  • Tính năng autocomplete hay đề xuất mã của AI đặc biệt tệ nếu bạn dùng ngôn ngữ có kiểu mạnh. Phần lớn chúng đúng khoảng 80%, trong khi autocomplete của IDE gần như đúng 100%. Cách làm theo kiểu AI agent tốt hơn vì 1) không liên tục phá vỡ mạch suy nghĩ, và 2) nó có thể tự compile, chạy test, sửa chỗ sai rồi trả về mã đúng.

  • Ngược lại thì tôi lại rất thích autocomplete. Vì phải dùng Go nên có quá nhiều boilerplate, mà đây không phải vấn đề có thể giải quyết bằng cách thêm thư viện, nên nhiều lúc tự gõ còn nhanh hơn. Với những đoạn mã phiền phức thì tay tôi vẫn nhanh hơn AI, nên autocomplete thực sự hữu ích. Các gợi ý một dòng thì đọc qua trong chớp mắt, còn gợi ý dài nếu gần giống thứ tôi định viết thì tôi cũng có thể lướt qua luôn. Dần dần bạn sẽ hình dung được AI sắp đoán ra gì. Không phải là mức tăng năng suất quá ghê gớm, nhưng các thứ khó chịu như log message hay vòng lặp for thì rõ ràng nhanh hơn. Tôi nghĩ nó chỉ giúp khi tốc độ đọc của bạn nhanh hơn tốc độ tự gõ.

  • Pair programming không phải lúc nào cũng đúng, nhưng theo tôi thì trong phần lớn tình huống nó vẫn hữu ích. Những lúc nó không hợp thường là khi một trong hai người hoặc cả hai không thật sự tích cực với quá trình này, hoặc một bên khăng khăng “cái đó không được”, hoặc cố bám quá cứng vào các nguyên tắc pair programming.

• Quan điểm của tôi hơi phức tạp. Ít nhất suốt một tháng qua tôi đang tích cực thử dùng tất cả các công cụ LLM trong công ty và học cách khai thác chúng hiệu quả nhất có thể. Nếu tính theo số dòng mã thì năng suất chắc chắn tăng. Nhưng tôi không thể nói là mình năng suất hơn về tổng thể. Với mỗi tác vụ hoàn thành, thường vẫn có những hành vi kỳ quặc không giải thích được, hoặc đôi khi nó còn động vào cả những phần không liên quan khiến tôi phải hoàn tác lại. Các bài test do AI tự tạo ban đầu trông có vẻ ổn, nhưng nhìn theo các chỉ số khác như coverage thì thấy rõ là còn thiếu sót. Cảm giác như để đi đến kết quả mong muốn, tôi còn phải lùi lại qua nhiều bước. Không phải kiểu có lợi hay học được gì, mà giống như đang thụt lùi thật sự. Có lần trước đây nó lén thêm tới 5 vạn dòng import không cần thiết vào những module nằm ngoài phạm vi chỉnh sửa ban đầu. Có lúc khác dù tôi đã đặt luật rất rõ, nó vẫn phá vỡ toàn bộ cấu trúc hướng đối tượng và triển khai bằng một đống if/else. Vấn đề là kết quả thay đổi quá nhiều tùy tình huống, đến mức ngay cả cùng một tác vụ thì lúc hoàn hảo, lúc lại phá nát mọi thứ. Tôi đã thử đủ cách để giao việc và hướng dẫn nó, nhưng ngay cả với các công việc tương tự, hành vi vẫn khác nhau quá nhiều nên lúc nào cũng phải đau khổ đi review thay đổi. Ngay cả khi mã gần như đúng rồi, chỉ cần yêu cầu sửa một phần cụ thể thì cả công việc lại đi chệch hẳn. Theo trải nghiệm của tôi, nó hiệu quả khi viết công cụ nhỏ, nhưng với codebase cỡ vừa đến lớn thì rất khó mong chờ kết quả nhất quán.

• Agent LLM có cảm giác nói quá nhiều và lúc nào cũng nghĩ cách của mình là đúng. Nó không gọn gàng, chuyện chỉ cần một dòng thì cũng giải thích lê thê. Với thay đổi nhỏ nhặt cũng viết chú thích dài dòng. Nó cứ như đang cố dạy tôi, rất phô trương và thái quá.

  • Một số hành vi mà mọi người ghét ("đầu ra quá dài, chú thích quá mức, v.v.") có thể là tác dụng phụ của việc LLM được thiết kế để tối ưu hiệu quả ở những mặt khác. Đầu ra dài có liên quan đến mã ít lười biếng hơn và điểm benchmark hiệu năng cao hơn. Việc lạm dụng chú thích cũng liên quan đến việc tăng cường ngữ cảnh cục bộ, giúp cải thiện chất lượng mã tiếp theo và giảm lỗi.

  • Hôm qua tôi dùng sonnet 4, chỉ để thay đổi đúng một giá trị cấu hình mà nó mất 15 phút cứ test rồi refactor lặp đi lặp lại. Cuối cùng còn thay đổi vô ích tới 40 file. Nó cứ cố chạy một debugger không hề tồn tại, và còn liên tục mở một trang web cần xác thực. Rõ ràng là còn rất xa mới gọi là hoàn hảo.

• Theo kinh nghiệm của tôi thì vấn đề không phải là nhanh, mà ngược lại là quá chậm. Tốc độ của nó rơi vào vùng lưng chừng khó chịu nên còn tệ hơn. Nếu nhanh hơn thì tôi đã có thể bám theo mã theo thời gian thực mà làm việc. Nếu chậm hơn thì tôi có thể tranh thủ làm việc khác rồi quay lại. Nhưng thực tế là nó hoàn thành tác vụ trong khoảng 50 giây đến vài phút, khiến tôi không thể tập trung hẳn vào việc khác. Tôi nghĩ tốt hơn là lặp ở các đơn vị nhỏ hơn và nhanh hơn. Về lâu dài, mức tự chủ như một reviewer con người, ví dụ làm việc độc lập kiểu review merge request (PR), sẽ tốt hơn. Còn vòng lặp hiện tại (giao việc, đợi 1~3 phút, xem kết quả, phản hồi rồi lặp lại) cá nhân tôi thấy là trường hợp tệ nhất.

  • Câu này làm tôi nhớ đến truyện tranh của Oatmeal về “Internet chậm so với không có Internet”.

  • Có người còn khuyên nếu bị xao nhãng thì đặt một bể cá 30L trên bàn làm việc. Một mẹo dí dỏm vì rất hợp để ngồi ngẩn người nhìn.

• Với tư cách lập trình viên, tôi hầu như không dùng AI, cùng lắm chỉ thỉnh thoảng dùng chatbot cho những câu hỏi ngoài dự án. Tôi tò mò không biết mọi người có dùng AI cho dự án khách hàng không, hay chỉ cho các dự án cá nhân. Nếu là cho khách hàng thì tôi muốn hỏi có đưa chuyện mã sẽ được gửi tới AI vào trong hợp đồng không. Hầu hết khách hàng đều có NDA cấm công khai ra bên ngoài, và có khách từng ghi hẳn điều khoản cấm dùng AI. Tôi muốn biết có ai từng gặp khách hàng chấp nhận ngoại lệ cho các công cụ coding AI không.

  • Tôi gần như chỉ dùng trong nội bộ công ty, và cũng là vì công ty có hướng dẫn sử dụng AI rất rõ ràng. Thực tế tôi không cảm thấy nó tiết kiệm được bao nhiêu thời gian, nên với việc cá nhân thì tôi sẽ không bỏ tiền ra dùng. Với dự án cá nhân, niềm vui tự tay làm quan trọng hơn kết quả, nên so với ngồi viết prompt thì tự làm vui hơn nhiều.

  • Cũng có trường hợp phía khách hàng chủ động yêu cầu dùng AI. Họ kỳ vọng chất lượng tốt hơn và phát triển nhanh hơn, suy cho cùng là để giảm chi phí, nhưng thực tế nhiều khi lại không đúng như kỳ vọng đó, dù đó là một câu chuyện khác.

  • Tôi chỉ chia sẻ với OpenAI/Anthropic những đoạn mã đủ công khai để có thể dán thẳng vào ô tìm kiếm trên web.

  • Tôi thì không chia sẻ. Kể cả dự án nội bộ cũng vậy; nếu muốn chia sẻ mã ra ngoài thì phải trả phí. Tôi còn xử lý dữ liệu cá nhân nên nếu mã bị lộ sang các công ty Mỹ thì rủi ro pháp lý là quá lớn.

• Cuối cùng cũng có người nói trúng điều này. AI quá tự tin về thiết kế, còn phần triển khai chi tiết thì lại tự ý làm mà không bàn bạc. Ngay cả API mock cũng thường làm sai cấu trúc nên bắt buộc phải làm lại. Tôi ước gì hành vi của LLM mang tính cộng tác hơn, kiểu nếu thiếu chi tiết thì hỏi ngay. Tôi không thể đưa toàn bộ thông tin vào prompt đầu tiên, mà prompt bổ sung thì lại phá vỡ ngữ cảnh và luồng suy nghĩ của thiết kế ban đầu. Tôi không biết có phải mình đang dùng sai cách không và muốn biết có phương pháp nào tốt hơn. Tôi mong LLM được cải thiện theo hướng nhận phản hồi dần dần và phản ánh nó tốt hơn. Cũng tò mò liệu chuyện thêm/cập nhật ngữ cảnh tự thân nó đã là một bài toán khó hay chưa, nhưng tôi vẫn muốn tiếp tục học cách dùng.

  • Hiện nay đa số tech stack đều hỗ trợ các phiên “thiết kế/lập kế hoạch”, nên có lẽ thử cái đó trước sẽ cải thiện được nhiều. Workflow tôi hay dùng là bắt đầu bằng một cuộc trao đổi kiểu: “dựa trên @file, @docs, @examples, tôi muốn thực hiện _ tại @path, tham chiếu @module_requirements.md — trước khi triển khai thực tế, hãy thảo luận mọi thứ cần thiết đã”. Sau khi thảo luận qua lại và mọi bên đều đồng ý, có thể lưu lại thành file .md hoặc nói thẳng “giờ thì làm đi”. Nếu đăng ký workflow vào .rules, file .md hay snippet của IDE thì có thể tái sử dụng đều đặn cho mỗi tác vụ mới. Cũng nên nhớ rằng các LLM mới nhất cần ngữ cảnh nhiều hơn rất nhiều, nên với từng codebase khác nhau, tức từng dự án khác nhau, bạn cũng phải thử các luồng khác nhau thì kết quả mới thay đổi.

  • Tôi cũng có cảm giác càng nhiều thông tin thì AI càng dễ rối. Chắc hẳn phải có cách khắc phục. Nó rất giỏi trong việc bóc tách những mẩu thông tin cực nhỏ, nhưng tôi thấy hơi tiếc khi cả ngành cứ chỉ tập trung vào mô hình chatbot. Thử tưởng tượng nếu chúng ta chưa từng tạo ra bàn phím, chuột, GUI hay màn hình cảm ứng thì sẽ thế nào.

• Tôi cho rằng kiểu cộng tác dùng AI như một trợ lý mới là cách dùng AI đúng đắn, còn trào lưu tập trung vào chuyện “AI trực tiếp viết mã” lại là ví dụ cho việc ngành phần mềm đang đi sai hướng. Tôi tuyệt đối không giao cho AI việc viết code. Tôi chỉ dùng nó để phê bình đoạn mã mình viết, hoặc để xây dựng chiến lược thiết kế cấu trúc mã ở quy mô lớn. Tôi dùng nó như một cố vấn chiến lược, và nếu sắp xếp ngữ cảnh cho LLM tốt thì có thể nhận được chỉ dẫn cực kỳ xuất sắc. Chủ thể hành động luôn là tôi, tôi phải hiểu và tự thực hiện, còn với AI thì nguyên tắc là không giao cho nó trách nhiệm vượt quá vai trò cố vấn. Hãy xem AI như một “idiot savant” và đối xử với nó một cách thận trọng.