Ponytail là gì: Cách tối ưu AI coding agent hiệu quả

Ponytail là gì

Ponytail là một bộ quy tắc khiến AI coding agent viết ít code hơn. Dự án mô tả chính mình bằng một câu: “Khiến AI agent của bạn 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ờ viết.” Dự án được cấp phép MIT. Nó không có runtime riêng và không có thành phần nào trong đó được thực thi. Đây là nội dung dạng text được đưa vào instructions của agent, được đóng gói thành skill cho các host có khả năng load skill và thành các rule file thuần túy cho những host không có khả năng đó.

Repository là DietrichGebert/ponytail. Dự án được tạo vào ngày 12 June 2026 và đạt 90,000 star vào ngày 1 August 2026. Vào ngày 1 August 2026, release mới nhất được gắn tag là v4.8.4, phát hành ngày 29 June 2026, và trang releases liệt kê mười tag chỉ trong khoảng từ 14 đến 29 June. Dự án không hề chậm lại: vào ngày 17 October 2026, release mới nhất là v5.3.2, phát hành vào cuối ngày 16 October, là release thứ ba trong ngày đó sau v5.3.0 và v5.3.1. Trước đó là v5.2.0 vào ngày 13 October, năm ngày sau khi cả v5.0.0 và v5.1.0 được phát hành vào ngày 8 October, và repository đã có hơn 165,000 star. Một dự án phát triển với tốc độ đó sẽ thay đổi trước khi bạn đọc nội dung này, vì vậy hãy pin một tag trước khi build bất kỳ thứ gì dựa trên nó.

Ý tưởng trước khi dùng tool: 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 từng bậc trước khi viết bất kỳ thứ gì và dừng ở bậc đầu tiên phù hợp.

1. Tính năng 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. Tính năng 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. Một dependency đã được 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ỉ sau đó mới viết lượng code tối thiểu để hoạt động.

Đó là thang được mô tả tại v4.8.4, và các số bậc trong phần còn lại của bài viết này tuân theo thứ tự đó. Nhánh main hiện tại gộp bậc 3 và 4 thành một bậc: "Standard library hoặc tính năng của platform? Hãy dùng nó, trừ khi project có cách riêng", đồng thời bổ sung rằng "house component tốt hơn native widget", nên thang hiện có 6 bậc. Thứ tự vẫn giữ nguyên.

Chính thứ tự này tạo ra hiệu quả, không phải một bậc riêng lẻ 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 những gì đã có trước khi tự xây dựng: bậc 2 hỏi repository đã có component cho việc đó chưa, còn bậc 4 cho biết trình duyệt đã có <input type="date">. Ghi chú benchmark hiện tại của project nêu đúng trường hợp này: date picker ban đầu có 335 dòng khi không áp dụng rule, nhưng chỉ còn 10 dòng với Ponytail 5, vì agent dùng lại component Input của chính repository cùng với type="date" và để trình duyệt cung cấp calendar. Colour picker giảm ít hơn, từ 135 dòng xuống 26. Bậc 2 là bậc thường âm thầm thất bại, vì agent không nhìn thấy helper đã có sẽ dễ dàng viết thêm một helper thứ hai. Đây chính là khoảng trống mà một map có thể truy vấn của codebase cần giải quyết.

Ở đây, lazy không có nghĩa là bất cẩn, và ruleset nêu rõ điều đó. Danh sách "never lazy about" bao gồm việc hiểu vấn đề trước khi quyết định, validation đầu vào 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 bằng tên cụ thể. 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 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 những gì

• AGENTS.md, ruleset luôn được áp dụng, chứa toàn bộ ý tưởng trong một file có thể đọc trong năm phút.
• skills/ponytail/SKILL.md, skill definition, với argument hint là lite, full, ultra hoặc off.
• Các rule file 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 về intensity thay đổi mức độ mạnh của quy tắc. lite build đúng thứ bạn yêu cầu và nêu một lựa chọn lười hơn trong một dòng. full là mức mặc định và áp dụng ladder. ultra là thiết lập cực đoan theo YAGNI: ưu tiên xóa hơn thêm và sẽ tranh luận với chính requirement.

Các host hỗ trợ skill cũng có slash command. /ponytail đặt level, /ponytail-review kiểm tra diff để phát hiện over-engineering, /ponytail-audit kiểm tra toàn bộ repository, /ponytail-debt tập hợp các shortcut bạn đã trì hoãn và /ponytail-gain in scorecard benchmark. Các host chỉ đọc rule file sẽ nhận ruleset nhưng không có command. Kể từ v5.3.0, phát hành ngày 16 October 2026, Claude Code cũng có một band phía trên prompt, hiển thị chi phí task, mức độ reuse code và trạng thái test. Tính năng này yêu cầu Claude Code 2.1.290 trở lên, không xuất hiện trong VS Code chat panel, cloud session hoặc claude -p, và /ponytail band off sẽ ẩn nó. Kể từ v5.3.2, /ponytail band import đọc các Claude Code session trước đây của bạn một lần rồi thêm chúng vào board cùng với chi phí, thời gian agent và token, để bạn có thể so sánh chúng với các session chạy dưới rule.

Để đọc source trước khi tin tưởng nó, hãy clone tag thay vì branch. Đây là tag mà ladder ở trên sử dụng; thay bằng v5.3.2, tag mới nhất vào ngày 17 October 2026, để đọc nội dung hiện tại:

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

Trên Claude Code, dự án hướng dẫn cài plugin thay thế, và hai dòng sau đúng theo tài liệu vào ngày 17 October 2026:

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

Đường dẫn plugin sử dụng default branch thay vì tag, vì vậy 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à đánh đổi để có được sự tiện lợi của update command.

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

Phần diff do agent viết không biến mất khỏi cuộc trò chuyện. Ở lượt tiếp theo, model phải đọc lại phần đó như context, cùng với mọi file mà agent đã mở để tạo ra nó. Vì vậy, một thay đổi dài 500 dòng sẽ làm tăng chi phí xử lý cho mọi lượt sau trong session cho đến khi cơ chế compaction thay các lượt cũ bằng một bản tóm tắt, chứ không chỉ ảnh hưởng đến 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 hơn và kém thông minh hơn khi session kéo dài: cửa sổ context 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. Quản lý cửa sổ context của coding agent chính là cách kiểm soát vấn đề này.

Token được tính phí cả khi gửi vào lẫn khi sinh 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 viết và một lần nữa ở mỗi lượt đọc lại diff đó. Khoản tiết kiệm này có thực sự giảm hóa đơn hay không còn phụ thuộc vào cách bạn thanh toán, vì gói Pro hoặc Max chỉ bao gồm phần token phát sinh thêm trong giới hạn sử dụng; sau đó, opt-in usage credits sẽ bị tính riêng, còn cách tính phí API theo từng token sẽ tính tiền cho từng token. Nếu bạn đang theo dõi chi phí trên setup self-hosted, file instruction là một cần gạt không tốn 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 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 đáng lẽ chỉ cần 20 dòng sẽ tiêu tốn sự tập trung của reviewer, mà sự tập trung 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 cùng 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ó â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 session tmux hoặc chạy theo timer có thể mất hàng giờ để phát triển từ một quyết định sai trước khi bạn phát hiện ra. Đâ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ì từng prompt riêng lẻ. Một rule trong file luôn được nạp sẽ áp dụng ở 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 mà bạn khởi động trên cùng 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 trong 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 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ứ bạn phải patch về sau, đồng thời nó 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 biết gì

Dự án đã công bố 2 loại kết quả và chúng chênh lệch rất lớn. Cả 2 đều là số liệu do chính dự án công bố. Không số liệu nào là test độc lập.

[
  {
    "label": "Lines of code",
    "v4_13_pct": 48,
    "v5_pct": 53
  },
  {
    "label": "Cost per run",
    "v4_13_pct": 16,
    "v5_pct": 26
  },
  {
    "label": "Wall clock time",
    "v4_13_pct": 38,
    "v5_pct": 41
  }
]

Biểu đồ là benchmark agentic hiện tại của dự án, đề ngày 7 tháng 10 năm 2026. Các session Claude Code 2.1.288 chạy headless trên Opus 5.5 ở effort mặc định đã xử lý 39 task, mỗi task và mỗi arm chạy 5 lần, tổng cộng 585 session cho no skill, Ponytail v4.13.0 và Ponytail 5. 12 task là feature ticket trong full-stack-fastapi-template của tiangolo, một repository FastAPI và React thực tế, được chấm dựa trên git diff còn lại. Phần còn lại gồm 18 task chỉnh sửa chính xác với hidden check, 6 yêu cầu app nhỏ và 3 yêu cầu "cho tôi xem một ví dụ". Bash bị tắt ở mọi arm. Số output token giảm 45 phần trăm với Ponytail 5.

Hãy đối chiếu kết quả đó với các con số single shot mà dự án công bố vào tháng 6 năm 2026. Các con số này đến từ một bare model trả lời 5 prompt thường ngày, có và không có rule, được báo cáo dưới dạng median qua nhiều lần chạy. Chúng cho thấy code giảm 80 đến 94 phần trăm trên Haiku, Sonnet và Opus; phần xác minh cost ngày 17 tháng 6 năm 2026 cho thấy Haiku rẻ hơn 63 phần trăm. Kết quả agentic hiện tại của Ponytail 5 là ít dòng code hơn 53 phần trăm, cost thấp hơn 26 phần trăm và wall clock time ngắn hơn 41 phần trăm. Dự án nhanh chóng sửa lại con số single shot. Đến v4.8.4, vào ngày 29 tháng 6 năm 2026, README đã đưa kết quả agentic lên headline: "~54% ít code hơn (tối đa 94%)", kèm ghi chú rằng mức 80 đến 94 phần trăm trước đó là "mức trần theo từng task, không phải mức trung bình", đồng thời chuyển các con số single shot vào một section thu gọn có tiêu đề "Các con số single shot cũ hơn". Section đó giải thích rõ vì sao có khoảng cách: baseline single shot là một bare model "thêm prose và các tùy chọn vào câu trả lời", nên đây là đối thủ dễ đánh bại. Khi đo với một agent thực sự đang xử lý công việc thực tế, mức cải thiện giảm xuống. Tuy vậy, kết quả vẫn có ý nghĩa thực tế; đây mới là thông tin hữu ích hơn. Lần chạy agentic vào tháng 6 đó, gồm 12 ticket trên Haiku 4.5 với mỗi ticket chạy 4 lần, cho kết quả gần với con số hiện nay: ít hơn 54 phần trăm số dòng; README hiện tại không còn đưa các con số single shot vào nữa.

Có một lưu ý do chính dự án nêu ra, và đây là yếu tố quyết định việc nó 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ơ over-build; với code vốn đã tối giản, mức tiết kiệm gần bằng 0. Bảng theo từng task của tháng 10 cũng xác nhận điều đó: một số task chỉnh sửa chính xác có cùng số dòng ở cả 3 arm. 39 task trên 1 model và 1 host, với Bash bị tắt, 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 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 đặ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 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 riêng. Quy ước của Ponytail trong các release hiện tại là dùng comment có tag shortcut: để nêu rõ giới hạn và thời điểm cần nâng cấp (các release tháng 6, gồm cả v4.8.4, lại tag bằng ponytail:):

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

Comment này chỉ mất 2 dòng nhưng giải quyết một câu hỏi vốn có thể làm tốn thêm một vòng review. Nó cho người đọc tiếp theo biết 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 thiếu 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ẽ chi phối 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à cũng là lý do pattern này nên nằm trong một file đã commit thay vì trong shell history. Trong monorepo, pattern này nên nằm trong nhiều file đã commit, vì mỗi package có một AGENTS.md giúp rule của từng directory 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à bảo đảm tuyệt đối. Bạn nên biết vì sao agent bỏ qua một rule dù đã load rule đó trước khi kết luận rằng ladder cần câu chữ chặt chẽ hơn.

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

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ả thi và thường là lựa chọn đúng. Nó kém phù hợp với dự án greenfield, vì nấc 2 không có gì để tái sử dụng còn nấc 5 không có gì đã được cài đặt. Agent vẫn có thể dừng ở nấc 1, dùng standard library, một tính năng của platform hoặc một one-liner, nhưng hai lựa chọn ít tốn công nhất đã không còn. Vì vậy, nhiều task hơn sẽ chuyển thành viết code mới. Thang này 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ẽ đưa cho bạn bản copy thứ năm.

Cấp độ ultra sẽ thách thức các requirement của bạn. Đó là mục đích của cấp độ này, và nó tạo ra chi phí thực sự khi bạn đã quyết định rồi và muốn hoàn thành công việc. Hãy 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 giúp bạn tránh đọ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à cách sửa sai, và giờ đó là một cách sửa sai nhỏ, dễ được approve.

Tóm lại, Ponytail là một prompt được viết cẩn thận, phân phối tốt và có các con số đi kèm. Không có thành phần nào trong đó bắt buộc phải dùng plugin. Điều dự án mang lại là một người đã viết danh sách này đúng cách, kiểm thử nó 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 cung cấp dưới dạng một skill cho các host có khả năng 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, 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 là như 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ỉ load 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 những việc agent “không bao giờ được lười” gồm validation đầu vào tại các trust boundary, error handling để ngăn mất dữ liệu, security 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 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 ruleset, 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 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 dự án đo, được 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 từ June 2026 được so sánh với một model thuần chỉ kéo dài câu trả lời bằng prose và các option. README tại thời điểm đó cũng đánh dấu đây là baseline yếu. Các số liệu agentic hiện tại đến từ những session Claude Code chạy headless trên Opus 5.5, gồm 39 task với 5 lần chạy cho mỗi task. Trong đó có 12 feature ticket trong cùng một repository FastAPI và React. Đây là số liệu trung thực cho setup đó. Chúng không phải dự báo cho codebase của bạn, vì kết quả theo từng task của dự án cho thấy 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 chỉ là text. Bạn có thể paste một block tương đương vào instruction file mà agent đang đọc và 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 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 vẫn áp dụng ở turn 200 của một run dài, thay vì chỉ áp dụng ở turn 3. Sau đó, 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 copy 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. Rule đó không quyết định nội dung nào được merge, và cũng không nên làm việc đó.