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 developer lười nhất trong phòng. Code tốt nhất là code bạn không phải viết.” Dự án được cấp phép theo MIT. Nó không có runtime riêng và không thực thi bất kỳ nội dung nào. Đây là phần văn bản được đưa vào instruction của agent, được đóng gói dưới dạng skill cho các host có cơ chế load skill, và dưới dạng các file rule thuần cho những host không có cơ chế đó.

Repository là DietrichGebert/ponytail. Dự án được tạo ngày 12 June 2026 và đạt 90,000 star vào 1 August 2026. Bản release được tag mới nhất vào 1 August 2026 là v4.8.4, được publish ngày 29 June 2026. Trang releases chỉ riêng trong khoảng từ 14 đến 29 June đã liệt kê mười tag. Một dự án phát triển với tốc độ như vậy sẽ thay đổi trước khi bạn đọc phần 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 nó.

Ý tưởng trước công cụ: dừng ở bậc đầu tiên phù hợp

Cốt lõi của Ponytail là một thang quyết định. Agent đi qua thang này trước khi viết bất kỳ thứ gì và dừng ở bậ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. Điều này đã tồn tại trong codebase chưa? Hãy dùng lại helper hoặc pattern đã có.
3. Standard library có làm được việc này 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. Dependency đã cài đặt 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ỉ khi đó mới viết lượng code tối thiểu có thể hoạt động.

Hiệu quả nằm ở thứ tự, không nằm ở riêng một bậc nào. Nếu được yêu cầu tạo date picker, agent sẽ viết date picker, vì đó là việc nó được yêu cầu. Thang này buộc agent kiểm tra bậc 4 trước, và bậc 4 cho biết trình duyệt đã có <input type="date">. Ghi chú benchmark của dự án nêu đúng 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, vì agent dùng input native thay vì tự xây dựng một component. Colour picker cũng giảm từ 287 dòng xuống 23 dòng vì cùng lý do. Bậc 2 là bậc dễ âm thầm thất bại nhất, vì agent không nhìn thấy helper đã có sẽ sẵn sàng viết thêm một helper thứ hai. Đây chính là khoảng trống mà bản đồ codebase có thể truy vấn nhằm khắc phục.

Ở đây, lười không có nghĩa là cẩu thả, và ruleset nói rõ điều đó. Danh sách "không bao giờ được lười trong" 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, bảo mật, accessibility và mọi thứ bạn yêu cầu đích danh. Ruleset cũng yêu cầu mỗi phần logic không tầm thường phải có một kiểm tra nhỏ có thể chạy được. Quy tắc này hạn chế việc tự phát minh. Nó không làm giảm tính đúng đắn.

Repository thực sự cung cấp gì

• AGENTS.md, ruleset 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 ý argument là lite, full hoặc ultra.
• Các file rule trong những thư mục dành riêng cho từng editor như .cursor/rules/ và .windsurf/rules/, dành cho các host đọc rule nhưng không load skill.
• hooks/, benchmarks/, examples/ và scripts/.

Argument intensity thay đổi mức độ rule thúc ép. lite xây dựng đúng thứ bạn yêu cầu và nêu một tùy chọn ít khắt khe hơn trong một dòng. full là mặc định và bắt buộc tuân theo ladder. ultra là thiết lập YAGNI cực đoan: nó ưu tiên xóa hơn thêm và sẽ tranh luận ngay với chính requirement.

Các host hỗ trợ skill cũng có slash command. /ponytail đặt mức độ, /ponytail-review kiểm tra diff để tìm 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 ra bảng điểm benchmark. Các host chỉ đọc file rule sẽ nhận ruleset 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, tài liệu của project thay vào đó hướng dẫn cài plugin; hai dòng dưới đây đú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 theo branch mặc định thay vì tag, nên các instruction điều khiển agent có thể thay đổi giữa các session mà bạn không biết. Đây là cái giá phải chấp nhận để có được sự tiện lợi của update command.

Vì sao agent “lười” tiết kiệm chi phí hơn trên VPS

Diff do agent tạo ra không rời khỏi conversation. Ở turn tiếp theo, model sẽ đọc lại diff đó cùng với mọi file mà nó đã mở để tạo ra diff. Vì vậy, một thay đổi 500 dòng sẽ làm tăng chi phí của mọi turn sau trong session, không chỉ turn đã tạo ra thay đổi đó. Đây là lý do một đợt refactor mất kiểm soát khiến agent có vẻ chậm hơn và kém chính xác hơn khi session kéo dài: context window dần bị lấp đầy bởi 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. Toàn bộ vấn đề của quản lý context window của coding agent là kiểm soát phần này.

Token được tính phí cả khi đi vào lẫn khi đi ra, nên 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 turn đọc lại diff đó. Khoản tiết kiệm này có thực sự làm giảm hóa đơn hay không còn phụ thuộc vào cách bạn trả phí, vì gói thuê bao Pro hoặc Max cố định hấp thụ số token phát sinh thêm, còn API tính phí theo token sẽ tính tiền cho từng token. Nếu bạn đang theo dõi chi phí trên hệ thống self-hosted, instruction file là một cần gạt không tốn chi phí để sử dụng. Kiểm soát chi phí của AI agent bắt đầu từ volume output, còn cách coding agent sử dụng token giải thích vì sao việc đọc lại quan trọng hơn nhiều so với dự đoán thông thường.

Con người vẫn phải đọc diff. Một thay đổi 400 dòng lẽ ra chỉ cần 20 dòng sẽ tiêu tốn sự chú ý của người review, mà sự chú ý là tài nguyên cạn kiệt trước tiên. Không ai review diff dài thứ 4 trong ngày với mức cẩn trọng như diff đầu tiên. Vì vậy, việc xây dựng quá mức không chỉ làm 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 theo dõi. Một agent làm việc trong tmux session hoặc chạy theo timer có thể mất hàng giờ để tiếp tục xây dựng trên 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 instruction cố định thay vì cho từng prompt riêng lẻ. Một rule trong file luôn được áp dụng sẽ có hiệu lực ở turn 200. Một rule bạn nhập trong chat chỉ áp dụng ở turn 3. Rule đó cũng áp dụng cho session thứ 2 bạn khởi động trên cùng một máy, vì session này đọc file đã commit nhưng không kế thừa bất kỳ nội dung nào bạn đã nhập ở session đầu tiên, ngay cả khi 2 session có thể nhắn tin cho nhau.

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

Các con số benchmark do chính Ponytail công bố

Dự án công bố hai nhóm kết quả, nhưng chúng 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 headless 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, mỗi cấu hình chạy 4 lần trên Haiku 4.5, rồi chấm theo git diff còn lại.

Hãy đọc cột thứ hai. Kết quả agentic có í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 giải thích khá rõ lý do: baseline single shot là một model thuần “trả lời với nhiều lựa chọn kèm phần giải thích”, nên rất dễ vượt qua. Khi so với một agent thực sự làm việc thực tế, mức cải thiện giảm xuống. Kết quả này vẫn có ý nghĩa thực tế, và đó mới là điểm hữu ích hơn.

Dự án cũng nêu một điều kiện quan trọng, quyết định việc rule này có giúp được bạn hay không. Mức tiết kiệm lớn nhất xuất hiện khi có nguy cơ over-build thực sự, 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ể đại diện 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 chính các ticket của mình, có và không có rule, rồi tự đếm số dòng.

Mẫu bạn có thể áp dụng ngay mà không cần cài 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ư dưới đây vào file instruction mà agent của bạn đã đọc, dù đó là AGENTS.md, CLAUDE.md hay file rules 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 đáng được xem xét riêng. Quy ước của Ponytail là dùng một comment có gắn tên tool:

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

Comment này chỉ tốn hai dòng nhưng giải quyết một câu hỏi vốn có thể làm mất 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 phần agent quên xử lý, nên họ phải hỏi lại.

Vị trí đặt block quan trọng không kém nội dung của nó. File được agent load trong mọi lần chạy sẽ định hướng mọi lần chạy, kể cả những lần bạn không theo dõi. Đây là chủ đề của cách viết AGENTS.md mà agent thực sự tuân theo, và đó là lý do mẫu này nên nằm trong một file đã commit thay vì trong shell history. Trong một monorepo, mẫu này nên nằm trong nhiều file đã commit, vì mỗi package có một AGENTS.md riêng giúp rules của từng thư mục ngắn gọn thay vì buộc agent đọc convention của toàn bộ tree trong mọi lần chạy. Tuy nhiên, vị trí không phải là sự bảo đảm, và bạn nên biết vì sao agent bỏ qua một rule đã được load trước khi kết luận rằng ladder cần cách diễn đạt chặt chẽ hơn.

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

Ladder này được tối ưu 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ì rung 2 không có gì để tái sử dụng còn rung 5 không có gì được cài đặt, nên agent lần nào cũng rơi xuống rung 7. Nó cũng không phù hợp khi bạn thực sự muốn tạo abstraction. Nếu bạn sắp thêm caller thứ tư cho cùng một block đã copy, “diff ngắn nhất” sẽ tạo thêm một bản copy thứ năm.

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

Không có instruction block nào có thể cứu bạn khỏi việc đọc 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 công 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 cách sửa sai, và giờ nó là một cách sửa sai nhỏ, dễ được phê duyệt.

Tóm lại, Ponytail là một prompt được viết cẩn thận, phân phối tốt và gắn kèm các con số. Plugin không bắt buộc cho bất kỳ phần nào trong đó. Điều project mang lại là có người đã viết danh sách đúng cách, kiểm thử nó trên một repository thực tế và công bố phương pháp ngay cạnh kết quả.

FAQ

Ponytail có hoạt động với 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ó hỗ trợ load 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 chỉ đọc rule file nhưng không load skill, chẳng hạn như Cursor, Windsurf, Cline và Copilot, sẽ lấy ruleset luôn bật từ rules directory tương ứng và không có slash command. Nội dung vẫn giống nhau trong cả hai trường hợp. Khác biệt thực sự là host của bạn giữ nội dung đó trong context ở mọi lượt hay chỉ khi skill được trigger.

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 “không bao giờ lười với” gồm validation đầu vào tại các trust boundary, error handling để ngăn mất dữ liệu, bảo mật và accessibility. 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 tạo ra một cách không cần thiết: 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ó độ ưu tiên cao hơn rule này. Hãy đọc file mà agent load 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 project đ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 single-shot so sánh với một model thuần chỉ trả lời bằng option và lời giải thích. README cũng chỉ ra đây là một baseline yếu. Các số liệu agentic được lấy từ một session Claude Code headless trên một repository FastAPI và React, gồm 12 ticket, mỗi ticket chạy 4 lần, sử dụng Haiku 4.5. Đây là các con số đáng tin cho setup đó. Chúng không phải dự báo cho codebase của bạn, vì project cũng nói mức tiết kiệm giảm xuống gần 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 là text. Bạn chỉ cần paste một block tương đương vào instruction file mà agent đang đọc là đã nhận được phần lớn hiệu quả. Plugin cung cấp wording được duy trì, các mức intensity, review command và cách update. Thử block đã copy trước là câu trả lời ở rung 1 cho việc liệu có cần cài đặt hay không.

Làm cách 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 always-on instruction file thay vì trong chat message. Như vậy rule sẽ áp dụng ở turn 200 của một run dài, không chỉ ở turn 3. Sau đó, hãy giới hạn riêng phạm vi thiệt hại: 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 yêu cầu diff tối thiểu sẽ giảm lượng nội dung bạn phải đọc. Nó không quyết định nội dung nào được merge và cũng không nên làm việc đó.