- Một thử nghiệm kéo dài 2 tuần để xây dựng ứng dụng chỉ bằng quy trình phát triển có AI hỗ trợ đã được thực hiện, nhưng kết quả không thỏa mãn như kỳ vọng
- Sử dụng stack dựa trên Claude Code và Remix, tác giả lặp lại quy trình định nghĩa issue → AI triển khai → review code → triển khai
- Tuy nhiên, tác giả ngày càng thất vọng vì thiếu ngữ cảnh, mã trùng lặp không thể tái sử dụng, đứt gãy luồng làm việc, ảo giác (hallucination) và vấn đề theo quy luật Pareto
- Cuối cùng, sau 2 tuần tác giả từ bỏ phát triển lấy AI làm trung tâm, quay lại cách làm cũ và hài lòng với việc dọn dẹp mã cũng như cải thiện chất lượng
- Hiện tại, AI chỉ được dùng cho những mục đích giới hạn như tìm kiếm, rubber ducking, code snippet, kiểm thử, hiệu đính ngôn ngữ; và chưa có kế hoạch mở rộng thêm cho đến khi có thay đổi công nghệ mang tính nền tảng
Tổng quan thử nghiệm
- Một thử nghiệm phát triển ứng dụng trong 2 tuần đã được tiến hành bằng cách trực tiếp áp dụng quy trình làm việc phát triển với LLM (mô hình ngôn ngữ lớn) đang được chú ý gần đây
- Dựa trên trải nghiệm UI phức tạp của tài khoản Facebook Ads, tác giả bắt tay phát triển prototype adbrew, một công cụ quản lý quảng cáo được đơn giản hóa chỉ sử dụng Facebook Ads API
- Thử nghiệm được tiến hành với mục tiêu kiểm chứng tiềm năng của AI và kỳ vọng giải quyết vấn đề thực tế
Cách tiếp cận
- Theo dõi nhiều tài khoản liên quan đến AI, nghiên cứu workflow và chọn stack công nghệ là Remix/React Router v7
- Sau khi đăng ký Claude Code, tác giả dành thời gian cho việc thiết lập ban đầu như prompt, công cụ DX và định nghĩa issue
- Quy trình hằng ngày
- Định nghĩa issue
- Yêu cầu AI triển khai
- Điều chỉnh yêu cầu cùng AI
- Rà soát chi tiết mã được tạo ra
- Commit/triển khai mã
- Lặp lại quy trình
- Định kỳ cải thiện guideline và các tệp kiểm tra tự động
- Tác giả liên tục cố gắng đồng bộ luồng phát triển với AI
Những vấn đề xảy ra thường xuyên
- Luôn thiếu ngữ cảnh
- Dù đã cung cấp nhiều ngữ cảnh, AI vẫn không yêu cầu thêm phản hồi cần thiết
- AI tự ý đưa ra giả định và tiến hành công việc, dẫn đến việc triển khai sai diễn ra thường xuyên
- Không thể tái sử dụng và bảo trì mã
- Kém trong việc trừu tượng hóa và tạo ra mã có thể tái sử dụng
- Lặp đi lặp lại việc tạo các component sẵn có, làm tăng sự mệt mỏi khi review
- Hiệu quả phản ánh guideline là không đáng kể
- Đứt gãy luồng công việc
- Cần liên tục theo dõi khi AI làm việc
- Khó đảm bảo thời gian tập trung hiệu quả theo từng issue, dẫn đến giảm năng suất
- Hiện tượng ảo giác (Hallucination)
- Khi kết hợp với Facebook API phức tạp, tài liệu thiếu sót và SDK bị gõ sai, sự tự tin sai lầm của AI càng làm tăng sự hỗn loạn
- AI lặp đi lặp lại việc tạo ra thông tin sai về nhiều framework và library khác nhau
- Hiện tượng Pareto trầm trọng hơn
- AI có thể xử lý nhanh 80% tổng công việc, nhưng 20% còn lại để hoàn thiện/chỉnh sửa cuối cùng lại tốn 80% công sức
- Nhiều lỗi và khiếm khuyết nghiêm trọng xuất hiện ở xử lý ngoại lệ, tương tác giữa các tính năng, v.v.
Kết quả và nhìn lại
- Sau 2 tuần, mã ngày càng trở nên lộn xộn và mất kiểm soát
- Do đánh mất niềm vui trong quá trình phát triển và các vấn đề về chất lượng, tác giả quay lại workflow cũ
- Khi tự tay dọn dẹp lại mã, tác giả phát hiện những phần mà review bằng AI đã bỏ sót, và cuối cùng có được nền tảng mã tốt hơn
Cách sử dụng AI hiện tại
- Công cụ tìm kiếm mạnh mẽ: hiệu quả cho việc tìm kiếm thông tin phức tạp và câu trả lời phù hợp ngữ cảnh, đồng thời có thể nhanh chóng quay lại cách làm cũ nếu thất bại
- Rubber duck (brainstorm ý tưởng): đặc biệt hiệu quả trong việc gợi ý phương án thay thế, mở rộng phạm vi khám phá và tăng cường tìm kiếm từ khóa liên quan
- Trợ lý code snippet: tự động hóa việc tạo các hàm tiện ích lặp lại để giảm mệt mỏi khi phát triển
- Hỗ trợ mã kiểm thử: dùng AI để tìm ra các kịch bản kiểm thử mới
- Công việc liên quan đến ngôn ngữ: hữu ích trong vai trò biên tập văn bản như commit message, issue, PR
- Gần đây xuất hiện xu hướng đảo ngược: thay vì để AI viết, nhà phát triển viết trước rồi để AI review
Kết luận và triển vọng
- Tác giả sẽ tiếp tục dùng AI cho hỗ trợ công việc thường ngày, nhưng hiện tại có quan điểm tiêu cực về việc mở rộng sang ủy quyền toàn bộ quy trình phát triển
- Đang nỗ lực ưu tiên dùng local LLM và duy trì quyền kiểm soát dữ liệu
- Tiếp tục theo dõi khả năng thay đổi công nghệ trong tương lai, nhưng ở thời điểm hiện tại sẽ giữ phạm vi sử dụng AI ở mức hạn chế
2 bình luận
Đây là nhược điểm mà tôi cảm nhận rất nhiều khi làm các công việc phức tạp.
Mất đi niềm vui + mã nguồn trở nên lộn xộn..
Thật sự có nhiều lúc tôi thấy nó không phù hợp để dùng ngoài mục đích refactor code + lên ý tưởng.
Ý kiến trên Hacker News
Gần đây tôi đã mất hơn một tiếng cố hỏi ChatGPT một lệnh rsync rất đơn giản, nhưng nó cứ liên tục đưa ra các tham số dòng lệnh không chạy được với phiên bản rsync trên máy Mac của tôi. Khoảng một nửa số lần thất bại là nó sa đà vào phần xử lý sự cố vô nghĩa, nửa còn lại thì bảo rằng nó đã “nhận ra” lỗi của mình rồi lại đưa ra câu trả lời sai cho nhầm phiên bản. Tôi đã yêu cầu nó xác minh tham số theo đúng phiên bản tôi có, nhưng rõ ràng nó không làm được việc đó. Thực ra đây là việc nếu tự làm thì 5 phút là xong, vậy mà tôi cứ đứng nhìn công nghệ kỳ diệu này lãng phí thời gian của mình mà không dừng lại được. Tôi không phải lập trình viên chuyên nghiệp, nên tôi tự hỏi trải nghiệm này có phổ biến trong giới dev không. Có lẽ nếu bạn đang code với phiên bản phần mềm khớp với tập dữ liệu huấn luyện chính của LLM thì sẽ đỡ gặp vấn đề hơn, và tôi cũng thắc mắc liệu có cách nào tránh được bằng prompt hay không. Ở thời điểm hiện tại, tôi không thấy LLM thực sự giúp tiết kiệm thời gian trong công việc lập trình; ngược lại, vì tính cách kỳ quặc của nó mà tôi còn thấy mình tốn thời gian hơn.
Ngay cả khi tôi yêu cầu LLM xác minh tham số cho đúng phiên bản của mình thì nó cũng không làm ra hồn. Tôi muốn nghe ý kiến của những người am hiểu AI về điểm này. Tôi cũng gặp chuyện như vậy rất nhiều. Cuối cùng thì LLM đâu có thực sự hiểu điều tôi đang nói. Xét về mặt toán học thì cũng có thể giải thích được vì sao lại như vậy. Nhưng đồng thời, có vẻ như người ta cũng đã thêm vào những kỹ thuật như transformer hay các mẹo riêng cho những bài toán không đến mức gây xấu hổ như đếm chữ cái. Không biết có điều gì tôi đang bỏ sót hay không.
Trải nghiệm này cực kỳ phổ biến ngay cả trong giới lập trình viên. Có thể sẽ có ai đó nói “tôi chưa từng như vậy”, nhưng đó chỉ là thiểu số rất hiếm, còn đa số mọi người đều than phiền tương tự. Bạn cũng hỏi liệu có thể tránh chuyện này bằng prompt không; nếu nội dung đó không có trong dữ liệu huấn luyện thì hoàn toàn vô ích. Ở nhiều ngôn ngữ, LLM thực sự rất tệ. Với các công cụ CLI, ngay cả khi bạn nói với LLM rằng đây là macOS hay bản BSD thì phần lớn trường hợp nó vẫn đưa cờ GNU. Đặc biệt trên macOS, gần đây rsync còn có thay đổi nên trên mạng cũng rất ít thông tin. Xem thêm bài viết về việc thay rsync. Và ngay cả ý tưởng cho rằng LLM sẽ giúp tiết kiệm thời gian khi code cũng đã là kịch bản đẹp nhất rồi. Không ít trường hợp người ta mù quáng tin vào code do LLM sinh ra rồi commit, dẫn đến bug hoặc lỗ hổng bảo mật. Tài liệu tham khảo: blog ai-coding-slowdown và bài báo arxiv
Về chuyện có thể tránh việc này bằng prompt hay không thì tôi không chắc, nhưng trong Claude Code bạn có thể chạy trực tiếp lệnh. Tức là thay vì để LLM tự tưởng tượng linh tinh, hãy thêm đầu ra thật của lệnh vào ngữ cảnh, như
! man rsynchoặc! rsync --help.Tôi thật sự không hiểu tại sao khi chỉ cần tra manual của một công cụ cụ thể mà lại còn phải dùng tới LLM.
Về việc bạn đã mất hơn một tiếng chỉ để kiếm một lệnh rsync đơn giản trên ChatGPT: tôi sẽ thử vài lần, bổ sung đầy đủ thông tin môi trường và thông báo lỗi, rồi nếu vẫn không được thì chuyển sang model khác như Claude hay Gemini. Nếu thử đến số lần mình đặt trước mà vẫn không giải được thì coi như LLM không giúp được việc này; dừng lại và quay về cách cũ như đọc manual hay tìm forum sẽ nhanh hơn nhiều. Thường thử khoảng 10–20 phút rồi bỏ qua là mốc thực tế hơn. Có những vấn đề mà LLM có thử bao lâu cũng không giải được, nó chỉ quay vòng mà thôi.
Tôi cũng có rất nhiều trải nghiệm như vậy. AI thực sự hữu ích khi tôi dùng nó cho những việc mà bản thân tôi vốn đã biết làm. Nếu tôi mô tả vấn đề đủ chính xác để LLM hiểu thì nó có thể cho ra kết quả ổn, và tôi cũng có thể kiểm tra ngay đoạn code đầu ra có đúng ý mình hay không. Còn giao cho nó thứ mình hoàn toàn không biết thì chỉ làm mọi thứ rối hơn.
Tôi nghĩ bài này (trừ cái tiêu đề) có góc nhìn khá cân bằng. Kiểu “giao hết mọi thứ cho LLM đi!” thì đầy vấn đề, còn “giao cho nó một phần code lặp đi lặp lại để tiết kiệm thời gian, hoặc vài đoạn test code thì khá ổn; chỉ là với tiêu đề bình thường như ‘AI có lúc hữu ích, có lúc không’ thì chắc chắn sẽ không có view.”
AI giống một thực tập sinh hơn là một nhà thầu.
Tôi rất đồng cảm với câu “thông tin ngữ cảnh là không đủ”. Dù chúng ta có nhập nhiều bối cảnh đến đâu, phần lớn trường hợp AI vẫn không hỏi lại để lấy phản hồi mà cứ tự suy đoán theo ý nó rồi thất bại. Tôi nhớ có cảnh trong một chương trình TV, khi người ta ước điều gì đó với thần đèn thì phải nói chuyện như luật sư, rà kỹ từng điều kiện một. Cảm giác nói chuyện với LLM cũng khá giống như vậy.
AI giống như một đồng nghiệp cực kỳ thông minh nhưng tuyệt đối không bao giờ nói ra suy nghĩ thật của mình. Trông thì có vẻ làm được mọi thứ, nhưng lại không có tinh thần làm việc nhóm, và những câu như “Tôi không hiểu bạn muốn gì ở đây, giải thích thêm được không?” thì AI gần như chẳng bao giờ nói ra.
(Tôi nghĩ tôi biết cảnh TV mà bạn đang nói tới.) Trong cảnh đó thì cuối cùng mọi thứ được xử lý ổn thỏa, nhưng tôi cho rằng LLM hoàn toàn không thấy cần phải giữ “lời hứa” của nó. Thậm chí thần đèn còn giống kiểu AI trong sci-fi cổ điển hơn, bị trói chặt bởi luật lệ và quy định. LLM thì hoàn toàn khác.
Tôi không thích kiểu vibe coding là chủ yếu đi giao tiếp với AI hơn là code thực sự. Thay vào đó, điều tôi thay đổi nhiều nhất là cấu trúc quy trình phát triển sớm hơn một chút. Trước tiên tôi viết file đặc tả, rồi bảo LLM dựa trên codebase và thông tin trên mạng để làm rõ các phần yêu cầu, tách việc triển khai thành checklist từng bước. Chỉ sau khi xong từng bước tôi mới chuyển sang phiên làm việc tiếp theo để tăng dần độ hoàn thiện. Nếu thấy mệt vì đối thoại với AI thì tôi hoặc đồng đội có thể tự triển khai theo spec, nên cách này khá linh hoạt.
Gần đây tôi đã đưa AI coding vào một dự án. Tôi không chắc chính xác vibe coding là gì, nhưng cách tôi chọn là tương tác lặp đi lặp lại một cách thư thả. Tôi dùng Gemini AI studio và rất hài lòng với kết quả, đến mức tài liệu hóa toàn bộ quy trình đó rồi công bố thành một dự án mã nguồn mở. Nó tạo ra cú hích năng suất rất rõ rệt cho tôi. Điểm chưa thích là AI nói năng quá lịch sự. Theo tôi, AI mang lại ROI cao nhất khi tôi đã biết rõ mình muốn kết quả gì, nhưng trong quá trình thì cần so sánh các lựa chọn. Tôi dùng nó cho mọi đầu ra của dự án: code lõi, test case, build script, tài liệu, app mẫu, tiện ích. Toàn bộ nhật ký trao đổi phát triển có thể xem tại đây, còn mã nguồn dự án xem ở đây.
Tôi dùng AI khá giống cách tôi dùng. Kỳ vọng AI tạo ra những trừu tượng mang tính đột phá là quá sức đối với nó. Nó hoạt động tốt trên những con đường hết sức quen thuộc mà hàng nghìn lập trình viên đã đi qua. Ở khía cạnh đó, nó khá giống một công cụ tìm kiếm cực mạnh.
Cách tôi thích là nhờ LLM đưa ra nhanh một lời giải đầu tiên hoặc một ví dụ code ban đầu, rồi sau đó tôi tự làm tiếp chứ không tiếp tục sa vào vòng lặp tinh chỉnh prompt. Cuối cùng, nếu cần thì nhờ LLM review code của tôi. Lợi ích lớn nhất là bỏ qua được vòng lặp chỉnh prompt. Vòng lặp đó thực sự rất chán và ngốn cực nhiều thời gian, về dài hạn còn có thể làm giảm hiệu suất công việc.
Việc AI cứ tự tiến hành mà không có phản hồi hay câu hỏi làm rõ thực sự rất bực bội.
Có ý kiến trong nhóm tôi là “ở thời điểm hiện tại chúng tôi chỉ dùng AI đến mức đó thôi; nếu sau này công nghệ thay đổi một cách căn bản thì sẽ đánh giá lại”. Tôi vẫn tò mò liệu LLM có thể làm hơn thế hay không. Ngay cả bây giờ, nếu dùng đúng cách thì tôi vẫn thấy nó rất hữu ích.
agentic wrapperhay pipeline thôi cũng có thể tăng trưởng rất lớn.Dùng AI để tối ưu Facebook Ads giống như những breakers trong loạt Dark Tower vậy.