17 điểm bởi GN⁺ 2026-02-27 | 4 bình luận | Chia sẻ qua WhatsApp
  • Kết quả nghiên cứu phân tích xu hướng lựa chọn công cụ của Claude Code trên 2.430 kho mã nguồn mở thực tế
  • Trong tổng số 20 hạng mục, có 12 hạng mục chọn cách tự triển khai (Custom/DIY) thay vì dùng công cụ có sẵn, và đây là kiểu lựa chọn xuất hiện thường xuyên nhất
  • Ngược lại, khi đã chọn công cụ thì mức độ tập trung vào một số mục nhất định rất cao, như GitHub Actions (94%), Stripe (91%), shadcn/ui (90%)
  • Môi trường triển khai được cố định theo từng ngôn ngữ: JS mặc định chọn Vercel, Python mặc định chọn Railway, còn AWS·GCP·Azure bị loại khỏi lựa chọn ưu tiên đầu tiên
  • Càng là mô hình mới thì xu hướng thay thế bằng các công cụ mới nổi như Drizzle, FastAPI BackgroundTasks càng rõ rệt, và mức độ nhất quán trong lựa chọn bên trong hệ sinh thái đạt khoảng 90%

Tổng quan nghiên cứu

  • Sử dụng Claude Code v2.1.39 để thực hiện tổng cộng 2.430 thí nghiệm, quan sát việc lựa chọn công cụ thông qua các câu hỏi mở trên kho mã thực tế
    • 3 mô hình (Sonnet 4.5, Opus 4.5, Opus 4.6), 4 loại dự án, 20 hạng mục công cụ
    • Tỷ lệ trích xuất 85,3%, thu được 2.073 phản hồi hợp lệ
  • Tỷ lệ đồng thuận giữa các mô hình là 90%, với 18/20 hạng mục duy trì tính nhất quán trong lựa chọn bên trong cùng hệ sinh thái

Phát hiện chính: Build vs Buy

  • Trong 12/20 hạng mục, triển khai Custom/DIY là lựa chọn phổ biến nhất
    • Tổng cộng có 252 lựa chọn Custom/DIY, nhiều hơn bất kỳ công cụ riêng lẻ nào
    • Ví dụ: cờ tính năng được triển khai bằng tệp cấu hình dựa trên biến môi trường; xác thực Python được tự viết bằng JWT + passlib; cache dùng wrapper TTL trong bộ nhớ
  • Tỷ lệ Custom/DIY theo hạng mục
    • Feature Flags 69%, Authentication(Python) 100%, Authentication(tổng thể) 48%, Observability 22%

Ngăn xếp mặc định (Default Stack)

  • Khi thực sự lựa chọn công cụ, Claude Code hình thành một ngăn xếp mặc định xoay quanh hệ sinh thái JS
    • Các công cụ được chọn nhiều nhất: Zustand (64,8%), Sentry (63,1%) v.v.
    • Cũng có trường hợp 100% lựa chọn liên quan đến JS tập trung vào một công cụ cụ thể
  • Ngăn xếp mặc định này có ảnh hưởng trực tiếp tới việc phát triển nhiều ứng dụng mới

Đi ngược số đông thị trường (Against the Grain)

  • Trong số các công cụ có thị phần cao, có những mục mà Claude Code hầu như không dùng
    • Quản lý trạng thái: không có lựa chọn chủ đạo, thay vào đó Zustand được chọn 57 lần
    • API Layer: ưu tiên routing tích hợp sẵn trong framework
    • Kiểm thử: chỉ 4% là lựa chọn chủ đạo, 31 trường hợp là lựa chọn thay thế
    • Trình quản lý gói: 1 lựa chọn chủ đạo, 51 lựa chọn thay thế

Xu hướng thay thế công cụ ở các mô hình mới (The Recency Gradient)

  • Mô hình càng mới càng chuyển sang công cụ mới hơn
    • JS ORM: Prisma (79%) → Drizzle (100%)
    • Xử lý tác vụ Python: Celery (100%) → FastAPI BackgroundTasks (44%)
    • Cache Python: Redis (93%) → Custom/DIY (50%)
  • Có thể quan sát rõ sự thay thế công cụ theo thế hệ trong từng hệ sinh thái

Sự phân hóa của môi trường triển khai (The Deployment Split)

  • Lựa chọn triển khai được cố định theo ngăn xếp ngôn ngữ
    • JS (Next.js + React SPA): cả 86/86 trường hợp đều chọn Vercel
    • Python (FastAPI): Railway được chọn trong 82% trường hợp
  • AWS, GCP, Azure có 0 lựa chọn chủ đạo trong toàn bộ 112 trường hợp
    • Các gợi ý thay thế gồm Netlify (67 lần), Cloudflare Pages (30 lần), GitHub Pages (26 lần), DigitalOcean (7 lần)
    • AWS Amplify, Firebase Hosting v.v. chỉ được nhắc tên chứ không được khuyến nghị
  • Trong phản hồi mẫu, Vercel còn được cung cấp cả lệnh cài đặt và lý do, trong khi AWS Amplify chỉ được nhắc trong một dòng

Những điểm mô hình bất đồng (Where Models Disagree)

  • Có khác biệt giữa các mô hình ở 5/20 hạng mục
    • JS ORM: Prisma → Drizzle
    • JS Jobs: BullMQ → Inngest
    • Python Jobs: Celery → FastAPI BgTasks
    • Caching: Redis → Custom/DIY
    • Real-time: SSE → Custom/DIY
  • 18 hạng mục còn lại vẫn duy trì lựa chọn nhất quán trong cùng hệ sinh thái

Dịch vụ benchmark cho doanh nghiệp

  • Amplifying cung cấp dashboard riêng tư cho từng công ty làm công cụ phát triển
    • Có thể kiểm tra AI agent đề xuất công cụ của mình nhiều đến mức nào so với đối thủ
    • Hỗ trợ phân tích năng lực cạnh tranh trong khuyến nghị công cụ dựa trên codebase thực tế

Khám phá dữ liệu

  • Các mục phân tích chi tiết bao gồm phân tích chuyên sâu theo hạng mục, độ ổn định của câu chữ, tính nhất quán giữa các kho mã, tác động thị trường v.v.
  • Kết quả nghiên cứu dự kiến sẽ được cập nhật theo mô hình Sonnet 4.6 trong thời gian tới

4 bình luận

 
axzswq 2026-02-28

Thú vị đấy, nhưng cũng có cảm giác phải chăng họ chỉ tiến hóa theo hướng dùng thật nhiều token của mình để thu phí cao hơn; và thực ra cũng có cảm giác ở một mức độ nào đó, AI đã được huấn luyện trên các thư viện nên nó chỉ việc tạo ra như vậy thôi.
Nghĩ đến chuyện chỉ một số thư viện nhất định sẽ phát triển vì được agent ưa chuộng thì cũng thấy hơi kỳ lạ.

 
tomlee 2026-02-28

Đây là một nghiên cứu thú vị. Đặc biệt, việc 12/20 hạng mục trong phần "Build vs Buy" là DIY để lại ấn tượng mạnh.

Bên mình cũng có quan sát tương tự khi xây dựng tiêu chuẩn persona cho AI agent (Soul Spec): nếu không chỉ rõ công cụ cho Claude Code bằng CLAUDE.md hoặc AGENTS.md, nó có xu hướng tự triển khai theo cách riêng của mình.

Điều mà "Recency Gradient" trong nghiên cứu này gợi ý là, để một công cụ mới được đưa vào stack mặc định của Claude, nó cần либо được phơi bày đủ nhiều trong dữ liệu huấn luyện, либо phải được chỉ định rõ ràng trong tệp ngữ cảnh của dự án. Cuối cùng thì Context Engineering thậm chí còn chi phối cả việc lựa chọn công cụ.

Thật tốt khi bộ dữ liệu gốc cũng được công khai: https://github.com/amplifying-ai/claude-code-picks

 
xguru 2026-02-28

Người ta gọi đó là Assistive agent optimization (AAO).

Các công cụ dành cho nhà phát triển giờ đây cần trở thành sản phẩm mà các agent ưu tiên lựa chọn.
Nếu agent còn không nhắc tới thì sẽ ngày càng bị bỏ xa

 
GN⁺ 2026-02-27
Ý kiến trên Hacker News
  • Tôi nghĩ tương lai của quảng cáo trong LLM là trở thành hoàn toàn vô hình
    Rốt cuộc nó sẽ trở thành ‘influencer’ mạnh nhất
    Hoặc có lẽ đây không phải quảng cáo mà là vấn đề xung đột lợi ích (conflict of interest)
    Ví dụ, việc Gemini có ưu tiên các thiết lập dựa trên GCP hay không có thể là một tín hiệu

    • LLM có thể dễ dàng bị đầu độc (poison) chỉ với rất ít dữ liệu
      Theo nghiên cứu của Anthropic, có cách nhắm tới việc đưa sản phẩm vào tầm nhìn của LLM thay vì SEO
      1. Tạo hàng trăm kho GitHub và đăng các ví dụ sử dụng một sản phẩm cụ thể
      2. Liên kết các website và vô số domain chứa cùng một nội dung
      3. Phát tán cùng thông tin đó trên Reddit, Facebook, X, Wikipedia, v.v.
        Chờ khoảng 6 tháng để crawler thu thập và dùng làm dữ liệu huấn luyện → cuối cùng sinh lời
    • Gần đây khi nói chuyện với nhân viên hỗ trợ của Google, tôi đã nhận được câu trả lời có vẻ do LLM tạo ra và nó lại đề xuất sản phẩm của đối thủ
      Nếu lúc đó họ dùng Gemini thì có lẽ chuyện này đã không xảy ra
    • Richard Thaler hẳn sẽ rất tự hào
      Đây đúng là hiện thân tối thượng của ‘Nudge’
    • Từ ‘influencer’ vẫn chưa đủ
      Trong tương lai, hệ thống lập trình kiểu agent sẽ tự quyết định nên tạo ra thứ gì, còn con người chỉ nhận kết quả mà thậm chí không nhìn thấy các lựa chọn
      Ngay cả chuỗi cung ứng cũng sẽ là thứ do LLM quyết định
    • Chuyện này lại giống mô hình Walmart/Amazon hơn
      Nền tảng kiểm soát ‘kệ hàng’, nhìn các tính năng SaaS đang phổ biến rồi tạo thương hiệu riêng của mình (ví dụ: Great Value, Amazon Basics)
      Phần mềm thuế có vẻ sẽ là ví dụ tiêu biểu
  • Điều thú vị là phong cách web của Claude Code được nhắc tới trong bài này thực sự hiện rõ trên chính blog đó
    Font JetBrains Mono là đặc trưng tiêu biểu của web do Opus 4.6 tạo ra
    Có vẻ hơn 99% các trang web trong một tháng gần đây dùng JetBrains Mono quá mức đều được tạo bằng Opus
    Opus 4.6 chọn Drizzle 32.5%, còn Prisma chỉ 20.5%
    Mô hình càng mạnh thì có xu hướng chọn Prisma càng ít — cảm giác như một dạng benchmark trí thông minh
    Một ví dụ khác là youjustneedpostgres.com cũng dùng JetBrains Mono quá nhiều

    • Tôi cũng có cảm giác tương tự
      Thiết kế thanh danh mục gần như giống hệt UI tôi vô tình tạo ra hôm qua
    • Với tôi, thứ nổi bật hơn font là kiểu hộp
      CSS dạng thẻ đều cho cảm giác giống nhau, nên blog này có vẻ cũng được làm theo kiểu đó
  • Tôi không đưa cho LLM những prompt mơ hồ
    Thay vào đó, đến năm 2026 tôi đang học lại cách rút thông tin chính xác từ LLM
    Cảm giác như đang học lại Google Search thời 2006
    Tôi dùng ‘reverse prompt’ để một mô hình kiểm chứng giả thuyết của mô hình khác
    Ví dụ, nếu kết quả từ Opus 4.6 đáng ngờ thì tôi chuyển sang ChatGPT hoặc Codex để tìm lỗ hổng
    Claude tương đối bớt cố chấp hơn, còn ChatGPT hay Codex thì quyết đoán hơn nhưng nhiều khi lại chính xác hơn
    Thực tế, với một sự cố Docker container, Claude nói đó là lỗi ZFS, nhưng ChatGPT bảo chỉ là lỗi cấu hình đơn giản và điều đó mới đúng
    Theo cách này, tôi dùng đối chiếu chéo giữa các LLM để tìm ra câu trả lời đúng

    • Nếu thấy tiếc vì LLM không hỏi thêm về công việc của bạn, bạn chỉ cần yêu cầu trực tiếp là “hãy hỏi tôi”
      Khi đó nó sẽ đặt ra rất nhiều câu hỏi
    • Tôi dùng kỹ năng bắt nó lập kế hoạch lặp đi lặp lại
      Tôi bắt nó sửa liên tục cho tới khi ra được kế hoạch chi tiết, đồng thời đặt thêm nhiều câu hỏi cần thiết hơn
    • Tôi dùng Codex CLI mỗi ngày
      Với gói đăng ký ChatGPT thì tôi chưa chạm giới hạn, nhưng thỉnh thoảng khi có lỗi tôi sẽ mở Claude ở một terminal khác
      Ngân sách Claude của công ty chỉ có 750 USD mỗi tháng nên rất hạn chế
  • Tôi đang dùng TimescaleDB trên AWS
    Claude Code đang quản lý các EC2 instance bằng AWS CLI
    Thế nhưng sáng nay Claude lại đề xuất tạo tài khoản NeonDB và Fly.io
    Tôi đã có thiết lập AWS ổn rồi mà nó vẫn gợi ý dịch vụ mới, nên thấy khá khó hiểu

    • Nhưng những đề xuất như vậy rất khó tin
      Theo kinh nghiệm của tôi, agent LLM đưa ra quyết định kiến trúc cực tệ
      Nó ám ảnh với các lớp trừu tượng và quản lý phiên bản không cần thiết, khiến code trở nên quá phức tạp
      Cuối cùng vẫn phải tự viết code
    • Tôi cũng đã gặp y hệt
      Tôi dùng Planetscale cho mọi dự án, nhưng Claude lại khuyên dùng Neon
      Có vẻ đây chỉ là một bug
  • Việc Opus 4.6 được gọi là ‘mang tính tương lai’ khá thú vị
    Tôi đã dùng 4.5 suốt một tháng rồi bắt đầu dự án mới bằng 4.6, và nó thực hiện tìm kiếm web ngay ở giai đoạn lập kế hoạch
    Mô hình đã tiến bộ đủ nhiều, nhưng điều phối và phân vai vẫn là bài toán cốt lõi

    • Tôi cũng nghĩ tương tự
      Trước đây tôi từng tự phát hành một ứng dụng Android bằng GPT-3.5 (liên kết ứng dụng)
      Những việc từng mất một tuần giờ có thể làm bằng một prompt duy nhất
      Nếu orchestrate LLM tốt thì có thể ra kết quả nhanh hơn rất nhiều
  • Điều tôi cảm nhận khi code cùng LLM là, nhất là ở mảng web, sự phụ thuộc vào các gói npm giảm đi rất nhiều
    Trước đây tôi dùng jwt auth hay plugin build, nhưng giờ có thể thay bằng vài dòng code
    Code đơn giản, dễ hiểu nên cũng đáng tin hơn

    • Thật ra sự thay đổi này đã diễn ra từ lâu
      Năm 2010, jQuery là vua của JS, nhưng giờ chỉ cần JavaScript thuần là đủ
      Tuy vậy, với các đoạn code liên quan bảo mật như JWT thì tôi sẽ không dùng nguyên xi thứ Claude tạo ra
    • Ngày trước việc tái sử dụng code rất nhiều, nhưng vì thế mà sinh ra địa ngục phụ thuộc hình kim cương
      Giờ có khi tự triển khai lại tốt hơn
      Code trùng lặp sẽ tăng, nhưng vấn đề phụ thuộc sẽ giảm
  • Tôi luôn chỉ rõ cho Claude nên dùng thư viện và công nghệ được cấp bằng sáng chế nào
    Tôi nghĩ lập trình viên phải biết hướng dẫn mô hình thật tốt
    Khi chưa chắc chắn, tôi sẽ mở một cửa sổ riêng để hỏi về kiến trúc hay ưu nhược điểm rồi mới quyết định

    • Nhưng tôi tò mò “chỉ định công nghệ được cấp bằng sáng chế” nghĩa là gì
  • Trong hai dự án, Claude đã tự động thêm Github Actions
    Tôi không hề yêu cầu, mà vì đó là thư mục ẩn nên tôi đã bỏ sót trong git diff
    May là chỉ tốn 4 cent, nhưng vẫn là một trải nghiệm khá bất an

  • Tôi có điều thắc mắc
    Tại sao shadcn/ui lại trở thành thư viện UI mặc định đến vậy?
    Không chỉ Claude mà các mô hình khác cũng dùng nó như mặc định
    Nếu loại shadcn đi thì chất lượng hay tốc độ có giảm không?
    Có phải vì tài liệu và ví dụ quá phong phú, hay đơn giản là vì nó xuất hiện quá nhiều trong dữ liệu huấn luyện?
    Tôi cũng từng ngạc nhiên khi khoảng giữa năm 2025 Gemini mặc định đưa shadcn vào React dashboard

    • Có lẽ là vì sự cộng hưởng với Tailwind
      shadcn/ui dựa trên Tailwind nên AI ưa thích nó
      Thực tế số lượt tải npm đã bùng nổ từ sau tháng 12
      liên kết gói npm
    • Tôi cũng từng có cùng thắc mắc
      Có rất nhiều thư viện component lâu đời hơn, nên việc tại sao cái này chiến thắng đáng để phân tích một cách khoa học
    • Tôi đã dùng shadcn từ trước thời agent
      Các thành phần nhất quán và dễ tùy biến nên rất thuận tiện để tích hợp vào dự án
      Đây thực sự là một dự án được làm rất tốt
  • Giờ đây khi nhìn thấy các website dùng nguyên style mặc định của shadcn, tôi cảm giác đó là dấu hiệu của website do AI tạo ra
    Giống như Bootstrap 10 năm trước, style mặc định của nó đã quá phổ biến

    • Nhưng chẳng phải đa số mọi người cũng dùng nguyên style mặc định sao?
      Nếu vậy thì có nhất thiết xem đó là dấu vết của AI không?
      Tôi tò mò phép so sánh với “Bootstrap 10 năm trước” chính xác mang ý nghĩa gì