- Dù cách kết nối công cụ theo MCP được cho là “tương lai”, trên thực tế nó vẫn có những giới hạn như thiếu tính kết hợp và tiêu tốn ngữ cảnh quá mức, nên cách viết code trực tiếp vẫn hiệu quả hơn
- Ngay cả trong thời đại LLM, với các tác vụ tự động hóa và lặp đi lặp lại, việc tạo và sử dụng code vẫn vượt trội hơn về độ tin cậy và khả năng kiểm chứng
- LLM mạnh hơn ở việc sinh code và chạy lặp lại hơn là tự động hóa dựa trên suy luận, còn quy trình dựa trên code thì rất tốt ở việc xác định vấn đề, kiểm chứng và mở rộng
- Một số công cụ như Playwright (theo kiểu MCP) khiến độ bất định và độ khó khi debug tăng lên ở từng bước “dựa trên suy luận”, còn nếu tự sinh/chỉnh sửa script bằng code thì khả năng lặp lại, tốc độ và độ tin cậy đều tốt hơn
- Vòng lặp “code - review - lặp lại” trong đó một LLM sinh code và một LLM khác kiểm tra/giải thích đoạn code đó, trên thực tế là luồng tự động hóa mạnh nhất
Chỉ cần có code là đủ
- Nếu bạn theo dõi tôi trên Twitter thì có lẽ bạn biết rằng dạo gần đây tôi không mấy tích cực về Model Context Protocol (MCP)
- Lý do không phải vì tôi phản đối ý tưởng này, mà vì MCP không hiệu quả như những gì nó quảng bá
- MCP có hai khuyết điểm chính
- Không mang lại tính kết hợp (composable) thực sự
- Do đòi hỏi cung cấp quá nhiều ngữ cảnh, nó tiêu tốn ngữ cảnh nhiều hơn cả việc tự viết và chạy code trực tiếp
- Chỉ cần một thử nghiệm đơn giản là có thể xác nhận điều này
- Ví dụ, hãy dùng GitHub MCP để làm một tác vụ, rồi thử cùng tác vụ đó bằng công cụ
gh CLI, bạn sẽ thấy cách sau dùng ngữ cảnh hiệu quả hơn nhiều và đi đến kết quả mong muốn nhanh hơn
But MCP is the Future! : Nhưng MCP mới là tương lai mà?
- Tôi muốn nói về những phản hồi mà tôi nhận được đối với quan điểm này (rằng code tốt hơn)
- Tôi đã thử nghiệm MCP khá sâu trong bối cảnh agentic coding, và đánh giá nó chính ở nơi những giới hạn bộc lộ rõ nhất
- Một phản hồi là: “MCP không thực sự cần thiết cho việc sinh code đa dụng, vì bản thân mô hình đã đủ giỏi ở việc sinh code.” Trong khi đó, tôi cũng nhận được ý kiến rằng MCP có thể có ý nghĩa trong ứng dụng hướng đến người dùng cuối ở một miền cụ thể (ví dụ: tác vụ tự động hóa ở công ty tài chính)
- Một ý kiến khác là, trong tương lai mô hình sẽ có thể truy cập nhiều công cụ hơn và xử lý các công việc phức tạp hơn, nên cần chú ý đến tiềm năng đó
- Nhưng đánh giá hiện tại của tôi là thế này: dựa trên dữ liệu thử nghiệm và trải nghiệm thực tế, MCP hiện nay lúc nào cũng khó dùng hơn so với việc tự viết code trực tiếp
- Lý do lớn nhất là MCP phụ thuộc vào suy luận (inference)
- Nếu nhìn vào “mọi nỗ lực kết nối thêm nhiều công cụ cho LLM” hiện nay, cuối cùng vẫn sẽ có một lớp nơi LLM nhận tất cả công cụ rồi lọc ra thứ phù hợp với tác vụ
- Cho đến nay chưa từng có cấu trúc hay cách tiếp cận nào tốt hơn được đề xuất
- Vì vậy tôi đi đến kết luận này: ngay cả trong những trường hợp đặc thù như tự động hóa theo miền dành cho người không phải lập trình viên, thì cuối cùng sinh code vẫn luôn là lựa chọn tốt hơn về tính kết hợp và khả năng tái sử dụng
Replace Yourself With A Shellscript
- Một cách để nhìn vào vấn đề này là: khi chưa có AI, với lập trình viên thì công cụ để giải quyết vấn đề chính là code
- Với người không phải lập trình viên, code là thứ khó tiếp cận, và nhiều công việc hiện đang làm thủ công thực ra có thể được tự động hóa bằng phần mềm
- Vấn đề thực tế là ai sẽ viết đoạn code đó. Nếu bạn ở trong một môi trường đặc thù và không thể tự lập trình, thì việc học code từ đầu là khó, mà cũng khó mong đợi ai đó viết code tùy chỉnh giúp bạn
- Tất nhiên có những việc bắt buộc cần suy luận (phán đoán/độ linh hoạt của con người), nhưng trên thực tế phần lớn các công việc lặp lại và rõ ràng đều có thể tự động hóa bằng code
- Có một thành ngữ lâu đời trong giới lập trình là “thay thế chính mình bằng một shell script”, và thực tế kiểu tự động hóa này đã tồn tại từ lâu
- Trong thời đại LLM và lập trình, người ta lại đang cố thay thế chính mình bằng LLM thay vì shell script, nhưng ở đây xuất hiện ba vấn đề (chi phí, tốc độ, độ tin cậy)
- Trước khi giải quyết được ba vấn đề này, thậm chí còn chưa đến giai đoạn để cân nhắc dùng công cụ (như MCP)
- Tức là, điều cốt lõi là trước tiên phải bảo đảm việc tự động hóa thực sự hoạt động đúng theo cách có thể mở rộng
Automation at Scale : Bản chất của tự động hóa ở quy mô lớn
- Cốt lõi của tự động hóa là xử lý các tác vụ lặp lại và tái sử dụng được bằng code
- Những việc chỉ làm một lần rồi không làm lại thì không cần tự động hóa. Tự động hóa bắt đầu từ những việc sẽ lặp đi lặp lại nhiều lần, nơi máy móc thực sự mang lại lợi ích năng suất
- Trên thực tế, bản chất của tự động hóa là làm thủ công 1–2 lần để hiểu cách nó hoạt động, sau đó biến nó thành thứ mà máy có thể lặp lại hàng nghìn lần
- Với loại tự động hóa lặp lại này, dùng “code” luôn là lựa chọn tốt nhất
- Nếu lần nào cũng yêu cầu LLM “suy luận”, thì những việc nhỏ có thể vẫn tạm ổn, nhưng thời gian/công sức để kiểm chứng cuối cùng sẽ làm giảm hiệu quả tự động hóa
- Ví dụ: thay vì bắt LLM trực tiếp làm phép tính, hãy để LLM viết code Python rồi dùng chính đoạn code đó để tính toán, như vậy cả độ tin cậy lẫn khả năng mở rộng đều cao hơn
- Khi dùng code, bạn có thể xem xét trực tiếp công thức/logic, và khi cần có thể tự sửa hoặc để LLM review xem “cách này có đúng không”
- Không cần phải lo Python tính sai, nên có thể thấy rất rõ rằng cách tiếp cận sinh code tốt hơn về kiểm chứng và độ tin cậy
- Lập luận này không chỉ áp dụng cho tính toán đơn giản mà còn mở rộng tới công việc phát triển thực tế
- Ví dụ: gần đây tôi đã chuyển toàn bộ định dạng của blog này từ reStructuredText sang Markdown
- Tôi đã trì hoãn việc đó khá lâu, một phần vì ngại, nhưng cũng vì nếu giao trực tiếp việc chuyển đổi cho LLM thì tôi không tin tưởng rằng sẽ không có những thiếu sót/lỗi tinh vi hoặc biến dạng ngữ cảnh ở đâu đó
- Vì thế cuối cùng tôi không dùng LLM để trực tiếp thực hiện chuyển đổi, mà dùng nó để sinh code chuyển đổi rồi xử lý bằng code
LLM → code → LLM: thực tế của tự động hóa kiểm chứng lặp lại
- Ở bước đầu tiên, tôi yêu cầu LLM sinh logic chuyển đổi lõi từ reStructuredText sang Markdown
- Không phải kiểu chuyển đổi đơn giản, mà là trực tiếp tận dụng AST (cây cú pháp trừu tượng) để
- parse reStructuredText thành AST → chuyển sang Markdown AST → render thành HTML
- Làm như vậy sẽ có được giai đoạn chuyển đổi trung gian, và kết quả cũng dễ so sánh/kiểm chứng trực tiếp hơn
- Tiếp theo, tôi cũng yêu cầu LLM viết script so sánh HTML cũ và HTML mới
- Khi phân tích diff của HTML sau chuyển đổi, script được thiết kế để tự động hiệu chỉnh trước các khác biệt nhỏ (ví dụ: khoảng trắng, cách xử lý footnote, v.v.) trước khi so sánh
- Tôi để LLM tự cân nhắc các loại lỗi có thể chấp nhận được trong quá trình chuyển đổi
- Ví dụ: ngay cả khi biểu diễn HTML của thư viện Markdown/reStructuredText có khác nhau đôi chút, script vẫn phản ánh điều đó để chỉ lọc ra những mất mát/lỗi mang tính bản chất
- Thứ ba, tôi còn yêu cầu LLM bổ sung script batch để phân tích kết quả của hàng trăm file cùng lúc
- Với script này, tôi chạy toàn bộ file và tiếp tục cải tiến lặp đi lặp lại (agentic loop) cho đến khi mức chênh lệch giảm xuống
- Toàn bộ quy trình diễn ra như sau:
- Ban đầu chỉ chạy thử khoảng 10 file mẫu rồi lặp lại cho đến khi chênh lệch giảm đáng kể
- Khi đã đạt trạng thái đủ hài lòng thì áp dụng cho toàn bộ bài viết, tự động xử lý trong khoảng 30 phút
- Điểm mấu chốt là, tôi tin tưởng không phải vì LLM thực sự “thành công” trong việc chuyển đổi, mà vì tôi có thể kiểm chứng và review toàn bộ quá trình bằng “code”
- Ngoài ra, tôi còn tăng độ tin cậy hơn nữa bằng cách để một LLM khác kiểm tra/giải thích phần code được sinh ra và các thay đổi
- Tôi có sự chắc chắn rằng việc chuyển đổi diễn ra đúng về mặt cơ học mà không mất dữ liệu, đồng thời việc kiểm tra mẫu/chỉnh sửa cũng dễ dàng bất cứ lúc nào
- Ngay cả trong tình huống xấu nhất thì cũng chỉ xuất hiện vài lỗi nhỏ về cú pháp Markdown, chứ nội dung bài viết thực tế không hề bị hỏng
- Một điểm quan trọng khác là, cách làm này có chi phí suy luận (inference) ổn định, nên chênh lệch gánh nặng giữa tổng số file (15 file hay 150 file) là không lớn
- Ở giai đoạn phân tích cuối, những khác biệt nhỏ đã được tự động bỏ qua nên ngay cả khi chuyển đổi số lượng lớn, gánh nặng kiểm chứng lặp lại cũng không cao
MCP Cannot Do That
- Ý chính của phần giải thích dài này là toàn bộ pipeline chuyển đổi và tự động hóa đều chạy bằng “code”
- Cấu trúc kiểu đầu vào của con người → sinh code → LLM review → cải tiến lặp lại này có thể áp dụng y hệt cho các bài toán phổ quát khác
- Ví dụ, có Playwright, một trường hợp tiêu biểu của cách tiếp cận kiểu MCP
- Đây là công cụ tự động hóa điều khiển trình duyệt từ xa; nó phải đọc trang, hiểu trang, bấm nút, v.v., và suy luận (inference) được lặp lại ở từng bước
- Kiểu tác vụ này đúng là khó có thể bị thay thế hoàn toàn bằng “cách tiếp cận bằng code” trong mọi trường hợp
- Nhưng nếu đã biết cấu trúc của trang (ví dụ: test ứng dụng nội bộ mà chính tôi đang phát triển)
- Thì cách để LLM sinh script Playwright bằng Python rồi chạy script đó sẽ nhanh hơn nhiều và cũng đáng tin cậy hơn
- Với cách này, chỉ cần tạo script một lần là có thể chạy lặp lại hàng chục, hàng trăm lần mà không cần suy luận bổ sung
- Không cần phải giải thích màn hình theo thời gian thực hay tìm vị trí nút bấm ở mỗi lần, và có thể chạy toàn bộ luồng tự động hóa trong một lần
- Cách tiếp cận kiểu MCP đòi hỏi gọi công cụ trừu tượng và suy luận ở từng bước, nên rất khó để bảo đảm LLM luôn hoạt động chính xác, và việc debug cũng khó
- Ví dụ, ngay cả khi muốn nhúng một MCP client vào shell script để gọi dịch vụ từ xa hiệu quả hơn, tôi vẫn cảm nhận rõ rằng cách này trên thực tế rất kém hiệu quả và cũng khó triển khai
- Rốt cuộc, tôi là con người chứ không phải MCP client.
- Code thì dễ chạy và debug, còn lời gọi MCP lúc nào cũng có yếu tố bất định và khó tin cậy
- Trên thực tế, tôi lại đang dùng những công cụ nhỏ mà LLM tạo ra trong quá trình sinh code (ví dụ: snippet của Claude Code) như những công cụ dài hạn trong quy trình phát triển của mình
Kết luận này sẽ dẫn đến đâu?
- Thành thật mà nói, ngay cả tôi cũng không biết xu hướng này sẽ đi đến đâu. Nhưng đây chính là thời điểm tốt để suy nghĩ về cách cải thiện hơn nữa phương pháp sinh code cho “agentic coding có chủ đích”
- Nghe có thể hơi lạ, nhưng MCP đôi khi thực sự hoạt động rất tốt. Tuy vậy, cấu trúc hiện tại phụ thuộc quá nhiều vào “suy luận”, và tôi cảm thấy nó giống như một ngõ cụt không phù hợp với tự động hóa quy mô lớn có thể mở rộng
- Vì vậy, có lẽ cần tìm ra cách phân tách và trừu tượng hóa rõ ràng hơn giữa những lĩnh vực MCP có thể phát huy thế mạnh và vai trò của phương pháp sinh code
- Muốn làm được điều đó thì cần cả những nỗ lực như xây dựng sandbox tốt hơn (môi trường thực thi an toàn) và thay đổi thiết kế API để agent có thể tự do suy luận kiểu “fan out/fan in” qua API
- Tôi cho rằng cấu trúc mong muốn là “việc gì làm được bằng code thì hãy xử lý tối đa bằng code”, còn sau khi chạy hàng loạt thì để LLM đánh giá và review toàn bộ kết quả
- Và nếu trong quá trình sinh code, ta bổ sung đủ thông tin ngữ cảnh để LLM có thể giải thích bằng ngôn ngữ tự nhiên cho người không phải lập trình viên biết script được sinh ra đang làm gì, thì trong tương lai cả người không phải lập trình viên cũng có thể dễ dàng tận dụng luồng tự động hóa này
- Tóm lại, tôi khuyến nghị tận dụng mạnh dạn hơn khả năng sinh code của LLM thay vì MCP, và thử nghiệm những khả năng mới
- Nếu để LLM trực tiếp viết code, chúng ta có thể tự động hóa được nhiều thứ hơn rất nhiều so với tưởng tượng
Tài liệu tham khảo
2 bình luận
Tôi đồng ý, nhưng có vẻ vấn đề không nằm ở MCP mà là ở nơi tạo ra nó, hay đúng hơn là tối ưu hóa theo hướng thiết kế. Ngay cả khi cùng thực hiện một chức năng, tùy là MCP nào mà nó sẽ nội bộ tạo mã và sinh lệnh để giảm bớt các công việc không cần thiết. Nếu dùng
gh cli mcphoặc terminal mcp thay vì Github mcp thì vẫn có dùng token, nhưng sẽ dùng ít hơn rất nhiều và vẫn đạt được cùng hiệu quả; có lẽ điểm này đã bị bỏ qua.Ý kiến Hacker News
Nhìn chung tôi đồng ý rằng đây là hướng đi đúng. Việc dùng LLM quy mô lớn thường được tận dụng để lấp khoảng trống giữa hai giao diện vững chắc. Cốt lõi của độ tin cậy không nằm ở đầu ra của LLM, mà thực ra đến từ việc chính các giao diện đó chỉ cho phép những cấu hình nhất định.
Đầu ra của LLM thường bị ép chuyển thành những giá trị có tính quyết định hơn, như kiểu dữ liệu hay primary key của DB. Giá trị của LLM thay đổi rất nhiều tùy vào việc code và công cụ hiện có mô hình hóa dữ liệu, logic và hành vi trong domain của tôi tốt đến đâu.
Cá nhân tôi dạo này thấy LLM khá giống máy in 3D. Cả hai đều giúp tạo mẫu nhanh và nối các bộ phận lại rất nhanh, nhưng nếu muốn khả năng mở rộng và độ vững chắc thì cuối cùng kỹ sư hoặc LLM vẫn phải thay các mối nối tạm thời bằng các cấu trúc hỗ trợ mang tính quyết định như kim loại/code.
Giống như những kỳ vọng bị thổi phồng trước đây về máy in 3D, LLM cũng có vẻ như sẽ thay thế mọi thực tế vận hành, nhưng trên thực tế nó chỉ thực sự hữu ích khi mô hình hóa số hiện có đã là một nền tảng vững chắc
Có một điều tôi nhận ra khi dùng công cụ LLM. Nếu thu nhỏ vấn đề vào trong sandbox để LLM có thể giải bằng cách lặp đi lặp lại sử dụng công cụ, thì có thể giải bài toán đó bằng brute force. Điều then chốt là xác định được loại vấn đề như vậy, rồi chọn sandbox phù hợp, công cụ cần dùng và tiêu chí thành công.
Quá trình này cũng đòi hỏi khá nhiều kỹ năng và kinh nghiệm, nhưng vẫn ở cấp độ cao hơn nhiều so với việc tự mình thử sai thủ công từng bước.
Tôi nhận ra điều này khi làm 'thí nghiệm Assembly Mandelbrot'.
(Link thí nghiệm: https://simonwillison.net/2025/Jul/…)
Lý tưởng nhất là phải có tiêu chí đánh giá dưới dạng hàm liên tục, hoặc ít nhất là tạo ra định lượng với nhiều đầu vào và đầu ra kỳ vọng tương ứng thì mới tự động hóa thật sự được
Ví dụ LLM yếu ở generic của TypeScript, nhưng nếu cho chạy TSC thật thì nó có thể liên tục kiểm chứng bằng test và thử lại cho đến khi đúng. Khả năng bảo trì code có thể giảm, nhưng về mặt lý thuyết đây là một cấu trúc rất hấp dẫn.
Hơn nữa Cursor có thể xem lỗi TypeScript, nên chỉ cần tạo test cho utility type thì Cursor cũng có thể tự viết test và giải vấn đề bằng brute force lặp đi lặp lại
Báo cáo tham khảo: https://github.com/davidkimai/Context-Engineering/…
Tôi vẫn chưa đọc hết nhưng thấy khá ấn tượng
Không biết có thể làm bằng mô hình local hay qua các gói thuê bao như Claude Code Pro không.
Thí nghiệm Mandelbrot cũng vui, nhưng độ khó khác khá nhiều so với codebase thương mại phức tạp ngoài đời
Tôi không nghĩ đây là vấn đề của bản thân MCP. Ở trình độ AI hiện tại, mô hình có con người ở giữa vượt trội hơn hẳn.
LLM mạnh ở một số tác vụ cụ thể nhưng thường mắc kẹt trong local minima. Vì vậy nếu đi qua đi lại trên giao diện web theo vòng lặp "viết chương trình → kiểm tra & đưa gợi ý → test" thì chất lượng tăng lên rõ rệt.
Có thể biến 10.000 dòng code hỗn độn thành 400 dòng code rõ ràng. Hiện tại thực tế là như vậy.
Tất nhiên nhiều công ty hay lập trình viên sẽ cố thay thế chính lập trình viên bằng LLM, nhưng thực tế hiện giờ vẫn chưa thể.
Tác dụng thật sự là tăng tốc độ làm việc của lập trình viên lên nhiều lần, hoặc giúp người mới nhanh chóng làm được công việc có năng suất nhờ LLM. Nhưng "agentic coding" vẫn chưa hoạt động tốt.
Ở thời điểm hiện tại, cách đúng là dùng LLM như đồng nghiệp hoặc trợ lý. Thực tế bây giờ là nó chưa phải một "AI agent" tự chủ có phản hồi khép kín
Tôi đang làm với ngôn ngữ biên dịch, type-safe và thiên về hàm, nên lúc nào cũng phải tự đọc lại kết quả; nếu là ngôn ngữ kém chặt chẽ hơn thì chắc tôi còn lo hơn nữa.
Dù vậy hiệu quả tiết kiệm thời gian là rất lớn. Đặc biệt tôi hài lòng với việc có thể chia nhỏ công việc để xử lý mục tiêu lớn dễ hơn
Tôi đã thử làm task bằng GitHub MCP thật, và nếu làm cùng việc đó bằng gh CLI thì gh CLI dùng ngữ cảnh hiệu quả hơn nhiều nên nhanh hơn hẳn.
Tôi có một file CLAUDE.md trong thư mục "devops" (một bộ sưu tập các lệnh bash dùng chung).
Mỗi khi hoàn thành một task mới, tôi bảo Claude thêm ví dụ vào đó, rồi sau này với truy vấn tương tự Claude sẽ giải quyết ngay trong một lần.
Chia sẻ nội dung ban đầu của CLAUDE.md:
(Các lệnh cụ thể được lược bớt)
Vì vậy nó trở thành phần mềm tự chữa lành, bằng cách thêm vào lệnh những thao tác test & sửa app khi có vấn đề
Trong các cách dùng MCP mà tôi từng thấy, ấn tượng nhất là clojure-mcp của Bruce Hauman.
Nó cung cấp cho LLM (a) bash, (b) Clojure REPL dạng persistent, (c) công cụ chỉnh sửa có cấu trúc.
Nhờ vậy khi chỉnh sửa code Clojure, nó hoạt động hiệu quả hơn nhiều so với cách tiếp cận thuần dựa trên diff văn bản.
Nếu có test suite tử tế, vòng lặp chỉnh sửa file, reload và chạy test lặp lại diễn ra gần với cách con người làm đến mức rất đáng ngạc nhiên
Nó hỗ trợ các tính năng chính như debug code, đánh giá từng biểu thức riêng lẻ, tài liệu hóa kiểu trả về của hàm, v.v.
Tôi cảm thấy các ngôn ngữ có REPL mạnh vượt trội hơn hẳn ở những khả năng đó, và khi thấy tiềm năng ứng dụng của clojure-mcp thì ấn tượng của tôi về AI đã thay đổi rất nhiều
Ví dụ GitHub CLI không cho thấy hết điểm mạnh của MCP.
Với những công cụ có tài liệu dễ truy cập như gh CLI, LLM dễ sinh code nên dĩ nhiên tận dụng tốt hơn.
Nhưng lợi thế thật sự của MCP lại bộc lộ ở các công cụ nội bộ hoặc API ngách hầu như không có tài liệu online.
Cũng có cách nhét toàn bộ tài liệu vào ngữ cảnh, nhưng trong các trường hợp như vậy MCP còn hiệu quả hơn.
Nếu dùng công cụ MCP được thiết kế tốt với đầu vào phù hợp, gánh nặng cho LLM trong việc hiểu API, xác thực, xử lý edge case, v.v. giảm đi rất nhiều.
Có thể GitHub không thật sự cần MCP, nhưng trong môi trường như API nội bộ/không hoàn chỉnh thì các công cụ MCP được chuẩn bị sẵn phát huy tác dụng mạnh hơn
Ví dụ với sonnet4 thì chỉ cần hơn 15 công cụ là đã chạm giới hạn. Chỉ riêng official playwright MCP cũng đã ngốn dung lượng công cụ rồi
Rốt cuộc ưu điểm duy nhất của MCP có thể chỉ là khi API quá khó dùng thì nó giúp xác nhận lại rằng "à, thứ này vốn dĩ chỉ là quá phức tạp"
Về ví dụ Playwright,
tuần này chính tôi cũng từng làm agent dựa trên Playwright MCP server, nhưng vì nó chậm, tốn token và kém tin cậy nên lại quay về gọi Playwright trực tiếp.
MCP server tốt để test xem có thể làm gì, nhưng trong thực tế gọi API hiệu quả và ổn định hơn.
Tôi chia sẻ ví dụ và demo về personal LinkedIn agent mà tôi làm:
LinkedIn nổi tiếng là nền tảng rất khó tự động hóa, nên tôi tò mò không biết khi làm personal LinkedIn agent bạn có gặp khó khăn hay giới hạn nào không
Thật ra tôi cảm thấy chỉ cần terminal là đủ.
Tôi đã dùng MCP hằng ngày suốt nhiều tháng, nhưng giờ chỉ dùng đúng một MCP server dựa trên iTerm2 (terminal).
Khi cần thì có OpenAPI spec, nhưng trên thực tế chỉ với shell command và curl là đã làm được gần như mọi thứ
Nhận xét kiểu "cần quá nhiều ngữ cảnh" thực ra có thể xử lý bằng cách thiết lập mặc định prompt ban đầu cho tốt.
Các công cụ lớn gồm Claude Code và Gemini CLI đều hỗ trợ điều này
Việc đưa toàn bộ danh sách công cụ cho LLM rồi để nó tự sàng lọc không phải cách tiếp cận tốt nhất, nhưng
LLM mới nhất đang tiếp tục cải thiện, và trên thực tế tôi chưa từng gặp khó khăn lớn trong việc chọn đúng hàm MCP phù hợp.
Các vấn đề về chi phí, tốc độ, độ tin cậy cũng vậy
Không cần tự bỏ thời gian trực tiếp vào cuộc hội thoại
Ví dụ gần đây, LLM đã tự xử lý hàng loạt công cụ ngoài như Notion, Linear, git, log PR/CI trên GitHub,
còn tôi chỉ review PR đúng một lần.
Chi phí cũng dưới 1 đô la
Thậm chí càng thêm công cụ thì càng cần nhiều thông tin từ đầu hơn, nên có thể tạo ra hạn chế rất nghiêm trọng
mà chỉ là hiện tại vẫn đang bị che giấu, và mô hình khuyến mãi miễn phí/giá rẻ sẽ không kéo dài.
Ví dụ Cursor cũng đã có gói 200 USD/tháng, còn chất lượng dịch vụ của gói giá rẻ thì giảm đi.
Khi các chương trình miễn phí kết thúc, mọi thứ sẽ quay về mức ban đầu
Tôi làm việc với Julia, và thấy có lợi trong môi trường phiên chạy dài hạn.
Vì hàm được biên dịch ở lần chạy đầu tiên, tôi tạo MCP để Claude Code gửi code vào một Julia kernel (Jupyter) persistent.
Việc chạy test nhanh hơn nhiều, và CC cũng tận dụng các hàm sẵn có trong codebase tốt hơn thay vì tự viết bash riêng lẻ.
Theo CCUsage, lượng token sử dụng cũng giảm gần 50%.
Không nhất thiết phải là MCP, nhưng điểm chính là việc gắn 'một chức năng cụ thể' vào codebase dễ hơn là phải viết custom code riêng cho Claude từng chút một