- Chia sẻ các trường hợp sử dụng thực tế về agentic coding
- Chủ yếu sử dụng mô hình Claude Code Sonnet, và ưu tiên cách giao toàn bộ công việc cho AI hơn là tích hợp vào IDE
- Ngôn ngữ Go đặc biệt được khuyến nghị cho các dự án backend mới nhờ cấu trúc thân thiện với agent và hệ sinh thái ổn định
- Tốc độ và sự đơn giản là cốt lõi của agentic coding; cache test và một hệ công cụ đơn giản là rất quan trọng
- Mã nguồn nên được tổ chức đơn giản và có thể xử lý song song; để tối đa hóa hiệu năng của agent, việc chọn đúng thời điểm refactor là cực kỳ quan trọng
Lời mở đầu
- Gần đây số lượng lập trình viên chia sẻ trải nghiệm về agentic coding đang tăng mạnh
- Hiện tôi đang dùng mô hình Claude Code Sonnet với gói Max ($100/tháng)
- Vai trò của IDE đã giảm đi; thay vào đó tôi quay lại dùng Vim và làm việc theo luồng giao việc cho Claude rồi chỉ kiểm tra kết quả
- Tốc độ đổi mới đang diễn ra rất nhanh nên nội dung bài viết có thể nhanh chóng lỗi thời; vì vậy tôi tập trung vào các khái niệm có giá trị lâu dài
Những điều cơ bản
- Thiết lập alias cho lệnh
claude --dangerously-skip-permissions thành claude-yolo để loại bỏ mọi giới hạn quyền hạn
- Việc này có thể được quản lý an toàn bằng cách cô lập môi trường dev trong Docker
- Claude xử lý tốt hầu hết các công cụ cơ bản, vì vậy MCP (Multi Capability Protocol) chỉ được dùng trong các trường hợp đặc biệt
- Ví dụ: tự động hóa trình duyệt thông qua playwright-mcp
- Các công cụ tự viết được cấu thành dưới dạng script thông thường, và cố gắng duy trì cấu trúc công cụ đơn giản nhất có thể
Lựa chọn ngôn ngữ
- Sau khi thử nghiệm agentic coding với nhiều ngôn ngữ khác nhau, Go là lựa chọn lý tưởng nhất cho các dự án backend mới
- Hệ thống Context: cung cấp cấu trúc dữ liệu chảy rõ ràng xuyên suốt mã nguồn, giúp agent truyền và nhận ngữ cảnh theo cách tường minh
- Test cache: so với các ngôn ngữ khác như Rust, việc chạy test và cache đơn giản hơn, giúp vòng lặp code-test của agent hiệu quả hơn
- Sự đơn giản: bản thân Go đơn giản, và điều đó cũng mang lại lợi thế cho agent
- Giao diện có tính cấu trúc: chỉ cần một type có đúng các method là được nhận diện như interface, nên LLM có thể xử lý dễ dàng
- Tốc độ thay đổi thấp của hệ sinh thái: phiên bản bền lâu và thay đổi tường minh giúp giảm việc tự động sinh ra mã nguồn đã lỗi thời
- Python gây ra nhiều vấn đề
- fixture, xử lý async, tốc độ thực thi chậm... khiến hiệu suất trong agentic loop kém đi
- Frontend là Tailwind + React + Tanstack Query/Router + Vite
- Ký hiệu
$ trong tên file của Tanstack Router có thể làm agent nhầm lẫn và gây ra vấn đề
Công cụ, công cụ, công cụ
- Tiêu chí cho công cụ như sau
- Phải nhanh
- Cung cấp thông báo lỗi thân thiện
- Vẫn hoạt động ổn định ngay cả khi LLM sử dụng sai
- Có thể quan sát được và dễ debug
- Cung cấp các lệnh như
make dev, make tail-log dựa trên Makefile
- Dùng phiên bản fork của shoreman để quản lý pid nhằm tránh trùng trạng thái chạy
- Log được ghi cả ra stdout lẫn file để agent có thể trực tiếp trích xuất thông tin từ log
- Ví dụ: cấu hình để cả link xác thực email cũng được ghi vào log, nhờ đó có thể thực hiện quy trình xác thực email bằng tự động hóa trình duyệt
Tất cả xoay quanh tốc độ
- Sự kém hiệu quả lớn nhất của agentic coding là chi phí suy luận và việc dùng công cụ không hiệu quả
- Tốc độ phản hồi nhanh của công cụ là chìa khóa của năng suất
- Khi agent tự tạo và dùng các công cụ tạm thời, tốc độ chạy/biên dịch nhanh có thể cải thiện đáng kể hiệu quả công việc
- Trong môi trường chậm, việc tận dụng các phương án thay thế như nạp module động sẽ có lợi hơn, ví dụ: giám sát module file cho Sentry và tự động chạy
- Log phải được điều chỉnh ngắn gọn và rõ ràng để tối ưu mức tiêu thụ token và tốc độ; nếu cần, việc cung cấp giao diện để LLM tự điều chỉnh mức log cũng sẽ hữu ích
- Ngay từ giai đoạn sinh mã, cần thiết kế sao cho log/observability có ý nghĩa được tạo ra
Tính ổn định và copy/paste
- Sự ổn định của hệ sinh thái rất quan trọng đối với khả năng tái sử dụng mã nguồn và tránh gây nhầm lẫn cho agent
- Khuyến nghị dùng các ngôn ngữ/framework có ít biến động và dễ dự đoán như Go và Flask
- Cần cẩn thận với việc tự động nâng cấp thư viện, vì comment hoặc luồng mã mà agent để lại có thể bị phá vỡ
- Nếu có thể, nên ưu tiên chiến lược tự viết mã trực tiếp → giảm thiểu phụ thuộc
Viết mã đơn giản
- Agent phản ứng tốt hơn với mã nguồn đơn giản và tường minh
- Chính sách được khuyến nghị
- Ưu tiên dùng các hàm có tên dài, giàu tính mô tả, và viết theo hướng hàm hơn là dùng class
- Tránh kế thừa và các kỹ xảo phức tạp
- Khuyến nghị dùng SQL thuần; agent rất thành thạo SQL, đồng thời dễ so sánh và truy vết qua log
- Kiểm tra quyền hạn rõ ràng nên được thể hiện trực quan ngay trong mã nguồn, không tách sang file/cấu hình riêng
Làm cho nó có thể song song hóa
- Tốc độ xử lý của từng agent riêng lẻ không quá nhanh, nhưng có thể tăng hiệu quả tổng thể bằng xử lý song song
- Ví dụ: sao chép checkout dựa trên hệ thống file
- Cần suy nghĩ cách tách biệt các tài nguyên dùng chung như Redis hay DB
- Công cụ ví dụ: dùng container-use để tách session dựa trên Docker
- Công việc song song dựa trên CI hay background agent của Cursor cũng là những công cụ đáng chú ý
Học cách refactor
- Với cách làm agentic, refactor vào đúng thời điểm là rất quan trọng
- Khi độ phức tạp tăng cao, agent sẽ không còn xử lý mã nguồn đúng cách
- Ví dụ: trước khi class Tailwind bị phân tán ra 50 file, hãy chuyển thành thư viện component
- Refactor quá sớm hoặc quá muộn đều kém hiệu quả, nên cần chỉ đạo cải thiện cấu trúc đúng thời điểm
Tiếp theo là gì?
- Agentic coding đang tiến hóa rất nhanh, và các nguyên tắc cốt lõi là “đơn giản, ổn định, khả kiến, song song”
- Dù công cụ và phương pháp có thay đổi, các nguyên tắc này vẫn còn hiệu lực
- Mục tiêu không chỉ là tăng năng suất mà còn hướng tới chất lượng mã tốt hơn
- Chất lượng mã do agent viết đã cải thiện rõ rệt so với vài tháng trước
- Hãy linh hoạt thích ứng với thay đổi và mở rộng trải nghiệm lập trình
2 bình luận
Tôi cũng mới chỉ dùng AI để hỏi mấy thứ như mã kiểm thử đơn giản hay ví dụ mẫu, nhưng giờ ngày càng có nhiều người bắt đầu áp dụng nó một cách toàn diện hơn.
Có thể vẫn còn hơi sớm, nhưng chỉ vài năm nữa thôi thì chuyện này sẽ trở nên hiển nhiên.
Ý kiến trên Hacker News
Tôi đang trải nghiệm agentic coding bằng cách dùng kết hợp Copilot và Claude Sonnet 4 trên VS Code Nightlys. Dù nửa ngày của tôi bị lấp đầy bởi các cuộc họp, chỉ nhìn vào lịch sử git thì gần như không thể nhận ra điều đó vì năng suất tăng lên rõ rệt. Giờ tôi ở mức không còn tập trung vào những chi tiết triển khai nhỏ nhặt nữa, mà suy nghĩ xem thay đổi có thực sự hoạt động đúng không, mình có hiểu được đoạn mã này không, nên tổ chức cấu trúc thế nào để dễ hiểu hơn, và cần bổ sung gì vào tài liệu Markdown quy ước cho AI để giảm hiểu nhầm của Agent. Tối qua tôi giao cho Agent xử lý một file có tới 38 lỗi mypy, đi nói chuyện với gia đình 15 phút rồi quay lại thì Agent đã tóm tắt những gì nó sửa và lý do sửa. Tôi cũng tranh luận về một trong các thay đổi đó, nhưng cuối cùng kết luận là Agent đúng. Kiểm tra mypy cũng đã pass. Giờ tôi còn đang cố giúp cả nhóm hiểu được tiềm năng thực sự của công nghệ này, dù vẫn có những người hoài nghi và phản đối vì cho rằng AI không hoàn hảo. Nhưng mượn lời một người bạn: “Hôm nay là ngày tệ nhất mà từ nay về sau bạn và công nghệ này sẽ phải trải qua”, và tôi nghĩ đó chính là bằng chứng của đổi mới
Lỗi của type checker thực ra gần như là phần nên tốn ít thời gian nhất trong công việc phát triển, nên tôi khá tò mò vì sao phần đó lại ngốn nhiều thời gian đến vậy. Tôi nghĩ nếu trong mọi cuộc thảo luận về việc dùng AI, mọi người có thể cùng nhìn thấy cụ thể mỗi người đang dùng nó cho tác vụ nào (giống bài viết của Cloudflare), hiệu quả sẽ lớn hơn rất nhiều
Cá nhân tôi tin Agent với code Rust hơn là Python. Python không có mức phân tích tĩnh tốt như clippy hay rust-analyzer, nên tôi vẫn phải tự chạy kiểm tra mọi luồng code mỗi lần
Bạn nói rằng dù nửa ngày toàn họp thì nhìn vào lịch sử git cũng không nhận ra, nhưng nếu tôi là nhân viên ở công ty bạn thì tôi sẽ ghi nhớ rằng sắp tới người ta sẽ kỳ vọng mức sản lượng này là bình thường
Tôi tò mò về workflow của bạn. Tôi đã thử Claude Code để thử nghiệm trên dự án cá nhân, và cũng dùng Copilot bằng tài khoản công ty trong agent mode của VS Code, trộn đủ kiểu từ 3.5, 3.7 Sonnet đến 04-mini. Tôi dùng nó trên một dự án Go lớn, và ngoài phần test ra thì kết quả tệ khủng khiếp. Tôi còn nghĩ có lẽ mình dùng sai công cụ nên đã thử hết mọi “best practice mới nhất”: thay đổi context, đổi model, đặt rule, cải thiện prompt, nhưng vẫn không thấy cải thiện gì
Bạn nói có thể bổ sung thêm nội dung vào tài liệu Markdown quy ước cho AI để giảm lỗi của Agent; tôi muốn hỏi đó là file được đính kèm làm context cho từng công việc, hay là quy ước chính thức của VS Code Copilot Agent. Và bạn có tài liệu tham khảo nào để quyết định cấu trúc tài liệu không, hay đó là sản phẩm bạn tự cải tiến dần theo thời gian dựa trên những lỗi AI cứ lặp đi lặp lại
Điều rất đáng khích lệ là phần lớn kỹ thuật giúp agentic coding hiệu quả hơn cũng đồng thời nâng cao hiệu quả coding của con người. Trước đây người ta lo về thứ code “một đống bùn” mà chỉ AI mới hiểu được, nhưng thực tế lại ngược lại. Code rõ ràng giờ còn quan trọng hơn nhiều với năng suất của AI, và nhờ vậy chênh lệch năng suất cũng hiện ra rất rõ bằng số liệu. Vì có thể đo được Claude hoạt động tốt đến mức nào trên từng codebase, nên tranh luận về việc code có được cấu trúc tốt hay không không còn chỉ là khác biệt quan điểm nữa, mà có thể dựa trên cơ sở khách quan
Nỗi lo code sẽ thành “đống bùn” thật ra là mối bận tâm xuyên suốt lịch sử lập trình rồi (xem bài nói chuyện của Rich Hickey). Mọi người chọn “cứ làm cho tiện bây giờ đã” rồi ngày mai lại gánh một núi nợ kỹ thuật. Nhờ LLM, việc sản xuất ra những boilerplate vô nghĩa còn dễ hơn nữa. Khi bớt đau đớn, người ta thậm chí có thể không còn nghĩ đến chuyện sửa lại
Tôi cũng rất muốn để lại ý này: “Nỗi lo rằng code sẽ chỉ còn AI hiểu được, có thể hiện tại chưa đúng, nhưng tương lai thì chưa ai biết”
Tôi cực kỳ đồng cảm với đoạn này. Thông báo lỗi tốt, công cụ nhanh, hệ sinh thái ổn định, code đơn giản không “ma thuật”, SQL trực quan — đó vốn là môi trường phát triển tôi luôn mơ ước. Vì agent làm việc quá nhanh nên từng độ trễ nhỏ cũng trở nên rất dễ cảm nhận, và tôi nghĩ chính những kỹ thuật này có thể nâng toàn bộ trải nghiệm phát triển phần mềm lên một mức mới
Tôi nghe nói rằng khi dùng Agent thì người ta tự nhiên bị dẫn về Go và Tailwind. Vì dữ liệu huấn luyện quá dồi dào nên AI mới thực sự xử lý tốt được chúng. Thế thì tôi cũng lo rằng trong tương lai khi ai cũng dùng những công cụ này, việc xuất hiện ngôn ngữ, framework hay thư viện mới sẽ khó khăn hơn. Sẽ khó cạnh tranh với các giải pháp hiện có hơn, và những cộng đồng con người như StackOverflow cũng có thể biến mất
Tôi không đồng ý với lo ngại rằng sẽ không còn ngôn ngữ hay framework mới xuất hiện nữa. LLM rất mạnh trong việc dịch và chuyển đổi, nên ngay cả khi không có dữ liệu huấn luyện sẵn, với một framework độc đáo nhưng có cấu trúc rõ ràng thì chúng vẫn có thể học rất nhanh chỉ bằng cách đọc codebase. Tôi đã thực sự thấy LLM xử lý rất tốt framework C# rất idiosyncratic của tôi — loại mà chưa ai từng thấy. Tất nhiên những đặc tính đặc biệt như lifetime của Rust có thể không tương thích ngay, nhưng kiểu đơn giản như Go thì thích nghi rất nhanh. Sau này có lẽ khi tạo ngôn ngữ mới, người ta còn phải tính luôn cả khả năng tương thích với LLM ngay từ khâu thiết kế, tooling và tài liệu
Đây là một câu hỏi cực kỳ quan trọng. Nói cách khác, khi Internet bị phủ kín bởi dữ liệu do LLM sinh ra thì lượng dữ liệu huấn luyện chất lượng cao sẽ giảm đi, và các lập trình viên thân thiện với LLM có thể sẽ còn bị hút về những công nghệ “ít phóng xạ” của quá khứ như JS/React hơn nữa. Trong tương lai, JavaScript/React có thể trở thành COBOL của thời đại mới nhưng không còn cần các tư vấn viên đắt đỏ, vì LLM sẽ lo hết việc bảo trì. Nếu muốn tránh làn sóng AI, thì phát triển ngôn ngữ mới — nhất là các ngôn ngữ lạ kiểu Lisp+DSL mà LLM không học ngay được — có thể là vùng khá an toàn cho tới trước thời AGI
Chu kỳ truyền thống của software stack đại khái là thế này. (1) Khi stack hiện tại cố ôm hết mọi ngách và trở nên phức tạp, các chuyên gia bắt đầu tung ra vô số “atotecture” không cần thiết. (2) Vì vậy sẽ xuất hiện một stack mới đơn giản hơn, rõ ràng hơn, giải quyết xu hướng mới tốt hơn và trở nên phổ biến. (3) Theo thời gian stack mới đó cũng lại nặng nề vì cùng lý do, và vòng luẩn quẩn lặp lại. Tôi nghĩ AI coding cũng khó phá vỡ chu kỳ này vì khả năng mở rộng context đang tiến bộ rất nhanh
Luận điểm rằng Agent ép người ta dùng Go hay Tailwind thật ra phản ánh khá nhiều thiên hướng cá nhân của chính người viết. Việc Sonnet gặp vấn đề trong CLI
cargo testkhông có nghĩa là Rust, cargo hay rộng hơn là AI đều có vấn đề. Trong các bài test PHP thực tế, Junie đúng là không dùng tốt built-in runner, nhưng khi tôi tạo scriptbin/test-phpthì nó tự hiểu và dùng ổn. Việc ghi yêu cầu rõ ràng vào guideline quả là có ích, nhưng khác biệt ở đây là nó có xu hướng bám vào công cụ mặc định. Còn về trải nghiệm Stack Overflow, AI assistant của tôi có một ưu điểm là không đóng câu hỏi vì trùng lặp. Nỗ lực curate của SO là tốt, nhưng đúng là cũng đã khiến nhiều người dùng rời điHôm qua tôi cũng giao cho Claude (dùng qua Zed) tạo một dự án mới bằng elixir phoenix chỉ từ vài điều kiện, và nó làm ổn không vấn đề gì. CSS thì có dùng tailwind, nhưng tôi nghĩ là do phoenix tự cấu hình mặc định như vậy. Tôi không đồng cảm với nhận định rằng AI dẫn người ta về Go. Ngược lại, khi hỏi mà không có context thì tôi thấy nó đề xuất Python rất nhiều, và ngay cả với cộng đồng nhỏ như elixir thì trải nghiệm của tôi vẫn dùng tốt bình thường
Tôi đã thử Claude Code Sonnet 4.0 với code Rust khoảng một tuần nhưng thấy kém kỳ vọng (chưa kể dùng qua Bedrock nên còn đắt). Nó mất nhiều thời gian lên kế hoạch ban đầu nhưng thực tế thường chỉ hoàn thành được một nửa. Tôi tò mò không biết có phải mình đang bỏ sót điều gì không
Tôi cũng gần như thấy y hệt. Trong Cursor Edit/Agent mode thì sửa một phát gần như ra đúng thứ tôi muốn nên cực kỳ hiệu quả, còn trong môi trường CLI thì quá bất tiện. Tôi muốn hỏi là bạn có dùng Claude Code kiểu giao cho nó một việc 10–15 phút rồi chỉ review diff thôi, hay là bạn vẫn thực sự review code cẩn thận
Tôi cũng có đúng trải nghiệm đó. Tôi đã cố đi tìm những use case phù hợp để dùng nó mà vẫn thấy không chạy ra hồn, nên thực sự rất khó hiểu
Không nên thấy nó là đắt. Gói Pro là 20 USD/tháng, Max là 100–200 USD, vẫn rẻ hơn nhiều so với dùng API mà hóa đơn có thể vượt 1.000 USD/tháng
Tôi khá vui khi thấy có nhắc đến việc dùng container. Tôi đang tham gia dagger/container-use, trong nhóm còn có thành viên ex-Docker và cả nhà sáng lập Docker. Tôi nghĩ việc chạy các Agent song song sẽ là điểm bẻ lái của một bước tiến kỹ thuật lớn, một khi chúng ta dùng nó đủ đáng tin. Ngay cả trước khi tới mức đó, nếu bạn muốn tranh thủ làm việc khác khi Agent chạy hoặc lo Agent đụng nhầm vào những phần không nên đụng, thì container hóa môi trường phát triển là cực kỳ hữu ích. Kỹ thuật dùng container cho việc này vẫn còn ở giai đoạn đầu, nhưng đang tiến bộ rất nhanh; hiện tại trọng tâm cải thiện là độ ổn định, giảm xung đột git, và tăng tương tác giữa con người với Agent
Quan điểm của tôi về lựa chọn ngôn ngữ là thế này. 1) Java là ngôn ngữ toàn diện nhất nhờ quy mô dữ liệu khổng lồ và lâu đời để LLM tham khảo (không có nghĩa là chính xác nhất). 2) Quan trọng hơn cả là nên làm với ngôn ngữ mà bản thân bạn giỏi nhất, để có thể nhanh chóng bắt được các lỗi suy luận sai, lỗi thông thường và ảo giác của LLM
Ý kiến rằng Java có dataset lớn nhất, lâu đời và rõ ràng nhất có vẻ là lời khuyên chỉ đúng khi LLM không có công cụ để tra API, tài liệu hay mã nguồn bên thứ ba. Nếu công cụ có thể tự tìm ra nên dùng gì, thì chọn ngôn ngữ nào cũng được miễn là Agent đọc được source. Nhưng tôi hoàn toàn đồng ý với ý thứ hai: phải dùng ngôn ngữ mình biết rõ. Cuối cùng thì con người vẫn phải review cẩn thận, và biết ngôn ngữ đó sẽ giúp phán đoán lỗi dễ hơn
Tại sao lại là Java có dataset lớn nhất nhỉ? Có phải vì Java có nhiều dự án mã nguồn mở nhất không (do toàn bộ Apache suite chẳng hạn), hay vì tài liệu của các thư viện mã nguồn mở Java đặc biệt phong phú
Tôi vẫn luôn nghĩ Python mới là ngôn ngữ có dataset lớn nhất. Khi không có chỉ dẫn gì cụ thể, phần lớn LLM dường như đều nghiêng về đề xuất Python trước
Có ý kiến phản biện lại lập luận rằng context system của Go (thiết kế để truyền dữ liệu một cách tường minh và chạy theo luồng thực thi của code) mang lại sự đơn giản cho AI agent, rằng “việc nhét dữ liệu ngoài tracing vào
context.Contextthực tế là một thông lệ không tốt”Đồng ý. Trong chromedp (trình điều khiển Chrome headless cho Go),
context.Contextđược dùng làm tham số đầu tiên, nhưng cấu trúc lại yêu cầu phải dùng context lấy từ một factory đặc biệt chứ không phải chỉcontext.Background(). Việc đặt timeout thì lại xử lý riêng bằngcontext.WithTimeout, thành ra nó gần như bị dùng như con trỏvoid*Tôi chưa phải chuyên gia Go, nhưng thực tế tôi thấy khá nhiều thư viện nhét vào context những thứ như kết nối database, config, rate limiter, cache backend, nên trước mắt tôi không thấy đó là vấn đề quá lớn
“Viết code đủ đơn giản để AI hiểu” không phải là điểm đột phá mà tôi từng kỳ vọng. Tôi cũng tò mò không biết điều đó va chạm thế nào với cách tiếp cận trong bài viết trước của tôi về ugly code
Đúng như tác giả viết về Claude Code, thực tế có nhiều lựa chọn thay thế như OpenCode, goose, Codex, Devin, Cursor background agent, v.v. Có người hỏi liệu có giải pháp mã nguồn mở + local LLM nào tương tự Claude Code không
Hiện tại chưa có giải pháp mã nguồn mở + local LLM nào mà tôi có thể thực sự khuyên dùng. Dù vậy, OpenCode của SST đang tiến hóa rất nhanh về UX, và nếu sau này có thêm local model tốt thì việc áp dụng cũng sẽ khá dễ. Vấn đề lớn nhất là hầu như chưa có model nào thực sự giỏi “tool use”. Sonnet gây sốc vì nó làm việc này quá tốt nhờ được huấn luyện chuyên biệt cho việc dùng công cụ. Gemini hiện vẫn còn kém khá xa; cuối cùng đây có lẽ là vấn đề sẽ tự được giải khi model đủ tốt xuất hiện
Với Aider thì gần như đã tới nơi, nhưng họ cố ý không làm nó hoàn toàn agentic. Nó có thể tự chạy test/phân tích tĩnh, tự sửa lỗi, và xử lý cả đặc tả toàn dự án dựa trên to-do list. Hiện tại nó có giới hạn cứng 3 vòng lặp reflection, nhưng có thể hack để tăng tùy ý; chỉ cần thêm self prompting nữa là gần như thành Agent tự động hoàn toàn
Ứng dụng tôi sắp ra mắt cũng sẽ là một lựa chọn thay thế tốt. Nó là file tải về đơn lẻ, không cần cài đặt, chạy được trên Mac, Windows, Linux và Docker. Có thể dùng mọi model tương thích OpenAI API, kể cả model tự host, giao diện nền web nên tiện không kém Claude Code, và còn có thể tạo ứng dụng console dựa trên lệnh. Ngoài ra còn có thể mở terminal trực tiếp để tích hợp với dịch vụ. Hiện đang ở closed alpha, nhưng nếu muốn dùng thì cứ email cho tôi
Gần như ngày nào cũng có lựa chọn mới (hoặc ít nhất là bản thử nghiệm) xuất hiện, nên tôi kỳ vọng chẳng bao lâu nữa sẽ có phương án “vừa khít”. Ví dụ như app.build vừa mới được nhóm Neon (nay thuộc Databricks) ra mắt và trông khá hứa hẹn
Plugin Neovim CodeCompanion cũng đang tiến dần theo hướng agentic hơn. Nó đã hỗ trợ auto-submit loop, built-in tool, và tích hợp MCP. Dù không phải công cụ CLI độc lập, nhưng lợi thế lại là có thể tận dụng ngay toàn bộ môi trường editor đầy đủ, đặc biệt phù hợp nếu bạn thích hack/custom hoặc ưu tiên editor nhẹ
100–200 USD/tháng là quá đắt đối với một AI viết code còn chưa được kiểm chứng. Trải nghiệm cá nhân của tôi chưa đủ thuyết phục, lại còn có tranh cãi đạo đức nên càng thành rào cản để bắt đầu
Claude Code có thể dùng bằng API key hoặc chỉ cần đăng ký gói Pro 20 USD/tháng
Tôi khuyên thử Aider với mô hình tính phí API. Bạn có thể kiểm soát kích thước context bằng
/clear,/add,/dropđể giới hạn quanh mức 25K. Có thể dùng model mình muốn, ví dụ Sonnet 4 hoặc Gemini 2.5 Pro. Với script đơn giản, tôi thường hoàn thành với chi phí dưới 1 USD; ngay cả khi làm công cụ rất lớn, tính cả prompt + code và hơn 100 bài test thì cũng dưới 6 USD. Khi đã quen với việc viết code cùng AI, lúc đó hãy chuyển sang Claude Code — mạnh hơn nhưng nếu không dùng thường xuyên thì lại đắt hơnChỉ với gói thuê bao 20 USD trong một tháng là đã đủ để thử vài dự án nhỏ và quyết định có nên cân nhắc gói 100 USD hay không. Hoặc bạn cũng có thể đợi thêm vài tháng rồi đọc thêm trải nghiệm thực chiến của những người khác