Ponytail: skill giúp AI agent viết ít code hơn

Ponytail là gì

Ponytail là một bộ quy tắc giúp AI coding agent viết ít code hơn. Dự án tự mô tả bằng một câu: “Giúp AI agent suy nghĩ như senior dev lười nhất trong phòng. Code tốt nhất là code bạn không bao giờ phải viết.” Dự án được cấp phép theo MIT. Dự án không có runtime riêng và không thực thi bất kỳ thành phần nào. Đây là nội dung văn bản được đưa vào instructions của agent, được đóng gói dưới dạng skill cho các host có hỗ trợ tải skill và dưới dạng các file quy tắc thuần văn bản cho các host không hỗ trợ.

Repository là DietrichGebert/ponytail. Repository được tạo vào ngày 12 June 2026 và đạt hơn 90,000 star vào ngày 1 August 2026. Bản release mới nhất có tag vào ngày 1 August 2026 là v4.8.4, được publish ngày 29 June 2026. Trang releases liệt kê mười tag chỉ trong khoảng từ 14 đến 29 June. Một dự án phát triển với tốc độ này có thể đã thay đổi khi bạn đọc nội dung này. Vì vậy, hãy pin một tag trước khi xây dựng bất kỳ thứ gì dựa trên dự án.

Công cụ chỉ là bước sau: dừng ở nấc đầu tiên phù hợp

Cốt lõi của Ponytail là một thang quyết định. Agent đi qua từng nấc trước khi viết bất kỳ thứ gì và dừng ở nấc đầu tiên phù hợp.

1. Điều này có thực sự cần tồn tại không? Đây là YAGNI (bạn sẽ không cần nó). Nếu câu trả lời là không, hãy bỏ qua.
2. Nó đã tồn tại trong codebase này chưa? Hãy dùng lại helper hoặc pattern đã có.
3. Standard library có xử lý được không? Hãy dùng nó.
4. Tính năng native của platform có đáp ứng được không? Hãy dùng nó.
5. Một dependency đã cài có giải quyết được không? Hãy dùng nó.
6. Có thể viết thành một dòng không? Hãy viết thành một dòng.
7. Chỉ sau đó mới viết lượng code tối thiểu có thể chạy được.

Hiệu quả nằm ở thứ tự, không nằm ở riêng nấc nào. Khi được yêu cầu tạo date picker, agent sẽ viết date picker vì đó là việc được yêu cầu. Thang này buộc agent kiểm tra nấc 4 trước, và nấc 4 cho biết browser đã có <input type="date">. Ghi chú benchmark của dự án nêu chính xác trường hợp này: date picker có 404 dòng khi không áp dụng quy tắc, nhưng chỉ còn 23 dòng khi áp dụng quy tắc, vì agent dùng native input thay vì xây dựng một component. Colour picker cũng giảm từ 287 dòng xuống còn 23 dòng vì cùng lý do.

Ở đây, lười không có nghĩa là cẩu thả, và ruleset nêu rõ điều đó. Danh sách những việc "không bao giờ được lười" bao gồm việc hiểu vấn đề trước khi quyết định, validation input tại các trust boundary, error handling để ngăn mất dữ liệu, security, accessibility và mọi thứ bạn yêu cầu rõ ràng. Ruleset cũng yêu cầu một kiểm tra nhỏ có thể chạy được cho mỗi phần logic không tầm thường. Quy tắc này cắt giảm việc tự phát minh. Nó không cắt giảm tính đúng đắn.

Kho lưu trữ thực sự cung cấp gì

• AGENTS.md, bộ quy tắc luôn được áp dụng, chứa toàn bộ ý tưởng trong một file mà bạn có thể đọc trong năm phút.
• skills/ponytail/SKILL.md, định nghĩa skill, với gợi ý đối số là lite, full hoặc ultra.
• Các file quy tắc trong những thư mục dành riêng cho từng editor, chẳng hạn như .cursor/rules/ và .windsurf/rules/, dành cho các host có đọc quy tắc nhưng không load skill.
• hooks/, benchmarks/, examples/ và scripts/.

Đối số intensity thay đổi mức độ áp dụng của quy tắc. lite xây dựng đúng thứ bạn yêu cầu và nêu một tùy chọn ít tích cực hơn trong một dòng. full là mặc định và thực thi đầy đủ các cấp độ. ultra là thiết lập YAGNI cực đoan: ưu tiên xóa thay vì thêm và sẽ chất vấn cả yêu cầu.

Các host hỗ trợ skill cũng có slash command. /ponytail đặt cấp độ, /ponytail-review kiểm tra diff để phát hiện over-engineering, /ponytail-audit kiểm tra toàn bộ repository, /ponytail-debt thu thập các shortcut bạn đã trì hoãn, còn /ponytail-gain in bảng điểm benchmark. Các host chỉ đọc file quy tắc sẽ nhận bộ quy tắc nhưng không có command.

Để đọc source trước khi tin tưởng, hãy clone tag thay vì branch:

git clone --depth 1 --branch v4.8.4 https://github.com/DietrichGebert/ponytail.git

Trên Claude Code, project chỉ dẫn cài plugin; hai dòng sau đúng theo tài liệu tại ngày 1 August 2026:

/plugin marketplace add DietrichGebert/ponytail
/plugin install ponytail@ponytail

Đường dẫn plugin sử dụng branch mặc định thay vì tag. Vì vậy, các chỉ dẫn điều khiển agent có thể thay đổi giữa các session mà bạn không biết. Đây là đánh đổi để có sự tiện lợi của update command.

Vì sao agent ít làm sẽ tiết kiệm hơn trên VPS

Phần diff mà agent tạo ra vẫn nằm trong cuộc trò chuyện. Ở lượt tiếp theo, model sẽ đọc lại phần đó cùng với mọi file mà nó đã mở để tạo ra diff. Vì vậy, một thay đổi dài 500 dòng sẽ làm tăng chi phí cho mọi lượt sau trong session, không chỉ lượt đã tạo ra thay đổi đó. Đây là lý do một lần refactor mất kiểm soát khiến agent có vẻ chậm và kém chính xác hơn khi session tiếp diễn: context window đầy bằng chính output của agent, nên phần còn lại dành cho code thực tế của bạn bị thu hẹp. Quản lý context window của coding agent chính là cách kiểm soát vấn đề này.

Token được tính phí cho cả input và output. Vì vậy, một diff có kích thước giảm một nửa sẽ rẻ hơn 2 lần: một lần khi được tạo ra và một lần nữa trong mỗi lượt mà agent đọc lại diff đó. Nếu bạn đang theo dõi chi phí trên hệ thống tự host, instruction file là một cần gạt không tốn chi phí để điều chỉnh. Kiểm soát chi phí của AI agent bắt đầu từ khối lượng output, còn cách coding agent sử dụng token giải thích vì sao việc đọc lại tốn nhiều hơn mọi người thường nghĩ.

Con người vẫn phải đọc diff. Một thay đổi dài 400 dòng trong khi chỉ nên dài 20 dòng sẽ tiêu tốn sự tập trung của người review, và sự tập trung là tài nguyên cạn kiệt đầu tiên. Không ai review diff dài thứ 4 trong ngày với mức cẩn thận như diff đầu tiên. Vì vậy, việc xây dựng quá mức không chỉ lãng phí thời gian. Nó còn âm thầm làm giảm chất lượng của quá trình review, vốn có nhiệm vụ phát hiện lỗi.

Trên server, mức độ rủi ro khác đi vì agent thường chạy mà không có ai giám sát. Agent làm việc trong một session tmux hoặc chạy theo timer có thể mất hàng giờ để tiếp tục phát triển từ một quyết định sai trước khi bạn phát hiện. Đây là rủi ro thực tế khi chạy coding agent trên VPS, và đó là lý do những người thực hiện loop engineering dành nhiều công sức cho các chỉ dẫn cố định thay vì từng prompt riêng lẻ. Quy tắc trong file luôn được áp dụng sẽ có hiệu lực ở lượt 200. Quy tắc bạn nhập trong chat chỉ áp dụng ở lượt 3.

Dependency mới là một chi phí âm thầm khác. Rung 5 yêu cầu sử dụng những gì đã được cài đặt. Mỗi package agent tự ý thêm vào là một thành phần bạn phải patch về sau, đồng thời sẽ xuất hiện trong mọi container image được build từ repository đó.

Các con số benchmark của chính Ponytail cho thấy gì

Dự án công bố hai nhóm kết quả và hai nhóm này chênh lệch rất lớn. Cả hai đều là số liệu do chính dự án công bố. Không nhóm nào là kết quả kiểm thử độc lập.

[
  {
    "label": "Lines of code",
    "single_shot_pct": 93,
    "agentic_pct": 54
  },
  {
    "label": "Cost per run",
    "single_shot_pct": 63,
    "agentic_pct": 20
  },
  {
    "label": "Wall clock time",
    "single_shot_pct": 74,
    "agentic_pct": 27
  }
]

Cột single shot lấy từ một model thuần trả lời một tập prompt nhỏ, có và không có rule, rồi tính median qua các lần chạy lặp vào ngày 13 và 17 tháng 6 năm 2026. Cột agentic lấy từ một phiên Claude Code không có giao diện chỉnh sửa full-stack-fastapi-template của tiangolo, một repository FastAPI và React thực tế, qua 12 ticket tính năng với 4 lần chạy cho mỗi ticket trên Haiku 4.5. Kết quả được chấm dựa trên git diff còn lại.

Hãy xem cột thứ hai. Kết quả agentic tạo ra ít hơn 54 phần trăm dòng code, chi phí thấp hơn 20 phần trăm và thời gian chạy thực tế ngắn hơn 27 phần trăm, so với lần lượt 93 phần trăm và 74 phần trăm cho cùng các chỉ số trong thiết lập single shot. README nói rõ lý do: baseline single shot là một model thuần “trả lời bằng nhiều lựa chọn cùng phần giải thích”, nên rất dễ vượt qua. Khi so sánh với một agent thực hiện công việc thực tế, mức cải thiện giảm xuống. Kết quả này vẫn có giá trị thực tế, và đó mới là thông tin hữu ích hơn.

Có một điểm cần lưu ý do chính dự án nêu ra, và đây là yếu tố quyết định việc cách này có giúp ích cho bạn hay không. Mức tiết kiệm lớn nhất xuất hiện ở nơi thực sự có nguy cơ build quá mức, và gần bằng 0 với code vốn đã tối giản. 12 ticket trong một repository Python và TypeScript không thể dự đoán kết quả cho repository của bạn. Nếu con số này quan trọng với bạn, hãy chạy phép so sánh trên các ticket của chính bạn, có và không có rule, rồi tự đếm số dòng.

Mẫu bạn có thể sao chép ngay hôm nay mà không cần cài đặt gì

Ladder là văn bản, nên bạn không cần plugin để áp dụng ý tưởng này. Dán một block như sau vào file hướng dẫn mà agent của bạn đã đọc, dù đó là AGENTS.md, CLAUDE.md hay file quy tắc của editor.

## Before you write code

Climb this list in order. Stop at the first line that applies.

1. Does this need to exist? If not, say so and stop.
2. Does this repo already have it? Reuse the helper.
3. Does the standard library do it? Use it.
4. Does the platform do it natively? Use it.
5. Does an installed dependency do it? Use it.
6. Can it be one line? Write one line.
7. Otherwise write the minimum that works.

Never take the shortcut on: reading the code before changing it, validating
input that crosses a trust boundary, error handling that would otherwise lose
data, security, accessibility, or anything I asked for by name.

Do not add an abstraction I did not ask for. Do not add a dependency without
saying why in one line. Prefer deleting code to adding it.

Mark a deliberate simplification with a comment naming its ceiling and the
upgrade path.

Quy tắc cuối cùng đáng được xem xét riêng. Quy ước của Ponytail là dùng comment có gắn tên của tool:

# ponytail: global lock, per-account locks if throughput matters

Comment này chỉ mất hai dòng để viết nhưng giải quyết một câu hỏi vốn có thể làm tốn một vòng review. Nó cho người đọc tiếp theo biết rằng phiên bản đơn giản là một quyết định có chủ ý, đồng thời nêu điều kiện khiến quyết định đó không còn phù hợp. Nếu không có comment này, reviewer không thể phân biệt một shortcut có cân nhắc với việc agent bỏ sót điều gì, nên họ phải hỏi lại.

Vị trí đặt block cũng quan trọng như nội dung của nó. File được agent load trong mỗi lần chạy sẽ điều hướng mọi lần chạy, kể cả những lần bạn không theo dõi. Sự khác biệt đó là chủ đề của viết AGENTS.md mà agent thực sự tuân thủ, và đó là lý do pattern này nên nằm trong một file được commit thay vì trong shell history.

Khi quy tắc không còn phù hợp

Bậc thang này được thiết kế cho việc phát triển tính năng trong một codebase đã tồn tại, nơi việc tái sử dụng thường khả dụng và thường là lựa chọn đúng. Nó không phù hợp với dự án greenfield, vì bậc 2 không có gì để tái sử dụng còn bậc 5 không có gì được cài đặt, nên agent luôn rơi xuống bậc 7. Nó cũng không phù hợp khi bạn thực sự muốn có abstraction. Nếu bạn sắp thêm caller thứ tư cho cùng một đoạn code đã sao chép, “diff ngắn nhất” sẽ tạo thêm một bản sao thứ năm.

Mức ultra sẽ thách thức các yêu cầu của bạn. Đó là mục đích của mức này, và đây là một cái giá thực sự khi bạn đã quyết định xong và muốn hoàn thành công việc. Dùng full cho công việc thông thường và chọn ultra khi bạn nghi ngờ chính yêu cầu tính năng mới là vấn đề.

Không có instruction block nào có thể giúp bạn tránh hiểu sai vấn đề. Mục đầu tiên của chính ruleset là hiểu code trước khi quyết định. Đây là phần tốn nhiều công sức nhất và là phần mà văn bản không thể làm thay bạn. Một diff tối thiểu trong sai function vẫn là một bản sửa sai, và giờ đây đó là một bản sửa sai nhỏ, dễ được approve.

Tóm lại, Ponytail là một prompt được viết cẩn thận, được phân phối tốt và có kèm các con số. Không có gì trong đó yêu cầu plugin. Giá trị mà dự án mang lại là có người đã viết danh sách một cách đúng đắn, kiểm thử danh sách đó trên một repository thực tế và công bố phương pháp cùng với kết quả.

FAQ

Ponytail có hoạt động với các agent khác ngoài Claude Code không?

Có. Ponytail được phát hành dưới dạng skill cho các host có thể tải skill. Danh sách này gồm Claude Code, Codex, OpenCode, Gemini và một số host khác được nêu trong README. Các editor đọc rule file nhưng không tải skill, như Cursor, Windsurf, Cline và Copilot, sẽ dùng ruleset luôn bật trong thư mục rule tương ứng và không có slash command. Nội dung trong cả hai trường hợp là như nhau. Khác biệt thực tế là host của bạn giữ nội dung đó trong context ở mỗi lượt hay chỉ tải khi skill được kích hoạt.

Agent lười có bỏ qua test, validation hoặc bảo mật không?

Không. Ruleset nêu rõ điều này. Danh sách những việc agent không được lười biếng gồm validation đầu vào tại các trust boundary, xử lý lỗi để ngăn mất dữ liệu, bảo mật và khả năng tiếp cận. Ruleset cũng yêu cầu một kiểm tra nhỏ có thể chạy được cho mỗi phần logic không tầm thường. Rule này loại bỏ cấu trúc được bịa ra: các abstraction không ai yêu cầu và dependency không ai cần. Nếu agent bắt đầu bỏ test sau khi bạn cài đặt Ponytail, nguyên nhân là một instruction khác trong config của bạn đang có mức ưu tiên cao hơn. Hãy đọc file mà agent tải sau cùng.

Các số liệu về tốc độ và chi phí được công bố có đáng tin không?

Đó là số liệu do chính dự án đo và công bố cùng phương pháp đo. Bạn nên đọc chúng theo đúng phạm vi đó. Các số liệu cho một lần chạy duy nhất được so sánh với một model thô chỉ trả lời bằng các lựa chọn và phần giải thích. README cũng chỉ ra đây là baseline yếu. Các số liệu agentic đến từ một session Claude Code chạy headless trên một repository FastAPI và React, gồm 12 ticket, mỗi ticket chạy 4 lần, với Haiku 4.5. Đây là số liệu đáng tin cho cấu hình đó. Chúng không dự báo kết quả trên codebase của bạn, vì dự án cũng nói mức tiết kiệm giảm gần về 0 với code vốn đã tối giản.

Tôi có cần cài đặt gì để nhận được lợi ích không?

Không. Ladder này chỉ là text. Bạn có thể dán một block tương đương vào instruction file mà agent hiện đã đọc và nhận được phần lớn hiệu quả. Plugin cung cấp nội dung được duy trì, các mức độ áp dụng, các command để review và quy trình cập nhật. Thử block đã sao chép trước là câu trả lời ở rung 1 cho câu hỏi liệu có cần cài đặt hay không.

Làm thế nào để ngăn agent không có người giám sát xây dựng quá mức qua đêm?

Đặt rule trong instruction file luôn bật thay vì trong tin nhắn chat. Khi đó rule áp dụng ở turn 200 của một lượt chạy dài, không chỉ ở turn 3. Sau đó, hãy giới hạn thiệt hại theo cách riêng: cấp cho agent một checkout mà nó được phép làm hỏng thay vì bản sao duy nhất của bạn, đồng thời yêu cầu con người review diff trước khi merge. Rule về diff tối thiểu giúp giảm lượng nội dung bạn phải đọc. Rule này không quyết định nội dung nào được đưa vào, và cũng không nên quyết định.