Ponytail: Aturan Agen Coding AI agar Menulis Lebih Sedikit

Apa itu Ponytail

Ponytail adalah kumpulan aturan yang membuat agen coding AI menulis lebih sedikit kode. Proyek ini menjelaskan dirinya dalam satu kalimat: "Membuat agen AI Anda berpikir seperti developer senior paling malas di ruangan. Kode terbaik adalah kode yang tidak pernah Anda tulis." Lisensinya adalah MIT. Ponytail tidak memiliki runtime sendiri, dan tidak ada bagian di dalamnya yang dieksekusi. Isinya adalah teks yang dimasukkan ke instruksi agen, dikemas sebagai skill untuk host yang memuat skill dan sebagai file aturan biasa untuk host yang tidak memuat skill.

Repository-nya adalah DietrichGebert/ponytail. Proyek ini dibuat pada 12 June 2026 dan mencapai 90,000 star pada 1 August 2026. Pada 1 August 2026, rilis terbaru yang diberi tag adalah v4.8.4, dipublikasikan pada 29 June 2026, dan halaman rilis mencantumkan sepuluh tag hanya dalam rentang 14 hingga 29 June. Perkembangannya belum melambat: pada 17 October 2026, rilis terbaru adalah v5.3.2, dipublikasikan pada akhir 16 October, dan merupakan rilis ketiga pada hari itu setelah v5.3.0 dan v5.3.1. Sebelumnya, v5.2.0 dirilis pada 13 October, lima hari setelah v5.0.0 dan v5.1.0 sama-sama dirilis pada 8 October, dan repository ini menunjukkan lebih dari 165,000 star. Proyek yang bergerak secepat itu dapat berubah saat Anda membacanya, jadi tetapkan sebuah tag sebelum membangun apa pun di atasnya.

Gagasan sebelum alat: berhenti pada tingkat pertama yang memenuhi syarat

Inti Ponytail adalah tangga keputusan. Agen menaikinya sebelum menulis apa pun dan berhenti pada tingkat pertama yang memenuhi syarat.

1. Apakah ini memang perlu ada? Ini adalah YAGNI (Anda tidak akan membutuhkannya). Jika jawabannya tidak, lewati.
2. Apakah ini sudah ada di codebase ini? Gunakan kembali helper atau pola yang sudah ada.
3. Apakah standard library dapat menanganinya? Gunakan.
4. Apakah fitur bawaan platform dapat menanganinya? Gunakan.
5. Apakah dependency yang sudah terpasang dapat menyelesaikannya? Gunakan.
6. Apakah ini dapat ditulis dalam satu baris? Tulis dalam satu baris.
7. Hanya setelah itu, tulis kode minimum yang berfungsi.

Itulah tangga sebagaimana ditulis pada v4.8.4, dan nomor tingkat dalam sisa artikel ini mengikutinya. Branch main saat ini menggabungkan tingkat 3 dan 4 menjadi satu, "Standard library atau fitur platform? Gunakan, kecuali project memiliki implementasinya sendiri", serta menambahkan bahwa "komponen internal mengungguli widget bawaan", sehingga tangga ini memiliki enam tingkat. Urutannya tetap sama.

Urutan inilah yang berperan, bukan satu tingkat tertentu. Agen yang diminta membuat date picker akan menulis date picker karena itulah yang diperintahkan kepadanya. Tangga ini membuat agen memeriksa apa yang sudah ada sebelum membangun apa pun: tingkat 2 menanyakan apakah repository sudah memiliki komponen untuk itu, dan tingkat 4 menyatakan bahwa browser sudah memiliki <input type="date">. Catatan benchmark project saat ini menunjukkan kasus tersebut secara tepat: date picker yang menghasilkan 335 baris tanpa aturan ini menghasilkan 10 baris dengan Ponytail 5, karena agen menggunakan kembali komponen Input milik repository dengan type="date" dan membiarkan browser menyediakan kalender. Colour picker berkurang lebih sedikit, dari 135 baris menjadi 26. Tingkat 2 adalah tingkat yang gagal secara diam-diam, karena agen yang tidak dapat melihat helper yang sudah Anda miliki akan dengan mudah menulis helper kedua. Celah inilah yang hendak ditutup oleh peta codebase yang dapat dikuerikan.

Bersikap malas di sini bukan berarti ceroboh, dan ruleset menyatakannya secara langsung. Daftar hal yang "jangan pernah dianggap sepele" mencakup memahami masalah sebelum mengambil keputusan, validasi input pada trust boundary, penanganan error yang mencegah kehilangan data, keamanan, aksesibilitas, serta semua hal yang Anda minta secara eksplisit. Ruleset ini juga meminta satu pemeriksaan kecil yang dapat dijalankan untuk setiap bagian logika yang tidak trivial. Aturan ini mengurangi penemuan yang tidak perlu. Aturan ini tidak mengurangi correctness.

Apa yang sebenarnya disertakan repository ini

• AGENTS.md, ruleset yang selalu aktif dan merangkum seluruh gagasan dalam satu file yang dapat Anda baca dalam lima menit.
• skills/ponytail/SKILL.md, definisi skill dengan petunjuk argumen lite, full, ultra atau off.
• File aturan di dalam direktori khusus editor seperti .cursor/rules/ dan .windsurf/rules/, untuk host yang membaca aturan tetapi tidak memuat skill.
• hooks/, benchmarks/, examples/ dan scripts/.

Argumen intensity mengubah seberapa kuat aturan tersebut diterapkan. lite membangun hal yang Anda minta dan menyebutkan opsi yang lebih sederhana dalam satu baris. full adalah nilai default dan menerapkan ladder tersebut. ultra adalah pengaturan ekstremis YAGNI: pengaturan ini lebih memilih penghapusan daripada penambahan dan akan memperdebatkan requirement itu sendiri.

Host yang mendukung skill juga mendapatkan slash command. /ponytail menetapkan level, /ponytail-review memeriksa diff untuk mendeteksi over-engineering, /ponytail-audit memeriksa seluruh repository, /ponytail-debt mengumpulkan shortcut yang Anda tunda, dan /ponytail-gain menampilkan benchmark scorecard. Host yang hanya membaca file aturan mendapatkan ruleset tanpa command. Sejak v5.3.0, yang dirilis pada 16 October 2026, Claude Code juga mendapatkan panel di atas prompt yang menampilkan biaya task, penggunaan ulang kode, dan status test. Fitur ini memerlukan Claude Code 2.1.290 atau yang lebih baru, tidak muncul di panel chat VS Code, cloud session, atau claude -p, dan /ponytail band off menyembunyikannya. Sejak v5.3.2, /ponytail band import membaca session Claude Code sebelumnya satu kali dan menambahkannya ke panel beserta biayanya, waktu agen, dan token, sehingga Anda dapat membandingkannya dengan session yang dijalankan menggunakan aturan tersebut.

Untuk membaca source sebelum mempercayainya, clone tag, bukan branch. Inilah tag yang menjadi sumber ladder di atas; ganti dengan v5.3.2, yaitu tag terbaru pada 17 October 2026, untuk membaca teks saat ini:

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

Pada Claude Code, proyek ini mendokumentasikan instalasi plugin sebagai gantinya. Dua baris berikut sesuai dengan dokumentasi pada 17 October 2026:

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

Path plugin mengikuti default branch, bukan tag. Karena itu, instruksi yang mengarahkan agen Anda dapat berubah tanpa Anda sadari di antara session. Itulah trade-off yang Anda terima demi kemudahan update command.

Mengapa agent yang malas lebih hemat di VPS

Diff yang ditulis agent tidak keluar dari percakapan. Pada giliran berikutnya, diff tersebut kembali menjadi konteks yang dibaca model, bersama setiap file yang dibuka model untuk membuatnya. Karena itu, perubahan sebanyak 500 baris membebani setiap giliran berikutnya dalam sesi sampai compaction mengganti giliran lama dengan ringkasan, bukan hanya giliran yang menghasilkan perubahan tersebut. Inilah alasan refactor yang tidak terkendali membuat agent terasa semakin lambat dan kurang cerdas selama sesi berlangsung: context window dipenuhi output agent sendiri, sehingga ruang untuk kode Anda menyusut. Mengendalikan hal ini adalah inti dari mengelola context window agent coding.

Token dikenai biaya saat dikirim ke model dan saat dihasilkan model. Karena itu, diff yang ukurannya setengah lebih murah dua kali: saat ditulis dan pada setiap giliran ketika dibaca ulang. Apakah penghematan tersebut mengurangi tagihan Anda bergantung pada cara pembayaran, karena langganan Pro atau Max hanya menanggung token tambahan sampai batas penggunaannya. Setelah batas tersebut tercapai, usage credit yang dipilih secara opt-in ditagihkan secara terpisah. Sementara itu, penagihan API per token mengenakan biaya untuk setiap token. Jika Anda memantau biaya pada setup self-hosted, instruction file adalah pengungkit yang tidak memerlukan biaya untuk digunakan. Mengendalikan biaya AI agent bagi Anda dimulai dari volume output, sedangkan cara agent coding menggunakan token menjelaskan mengapa pembacaan ulang lebih berpengaruh daripada yang diperkirakan.

Manusia tetap membaca diff. Perubahan sebanyak 400 baris yang seharusnya hanya 20 baris menghabiskan perhatian reviewer, dan perhatian adalah sumber daya yang paling cepat habis. Tidak ada orang yang meninjau diff panjang keempat pada hari yang sama dengan ketelitian yang diberikan pada diff pertama. Karena itu, pembangunan berlebihan tidak hanya membuang waktu. Hal tersebut secara perlahan menurunkan kualitas review yang seharusnya menemukan kesalahan.

Di server, risikonya berbeda karena agent sering berjalan tanpa pengawasan. Agent yang bekerja dalam sesi tmux atau berdasarkan timer memiliki waktu berjam-jam untuk memperbesar dampak keputusan yang salah sebelum Anda melihatnya. Inilah risiko praktis dalam menjalankan agent coding pada VPS, dan karena itu orang yang melakukan loop engineering sangat memperhatikan instruksi permanen, bukan hanya prompt individual. Aturan dalam file yang selalu aktif berlaku hingga turn 200. Aturan yang Anda ketik di chat hanya berlaku hingga turn 3. Aturan tersebut juga berlaku pada sesi kedua yang Anda mulai di server yang sama. Sesi itu membaca file yang telah di-commit, tetapi tidak mewarisi apa pun yang Anda ketik pada sesi pertama, meskipun kedua sesi dapat saling mengirim pesan.

Dependensi baru adalah biaya tersembunyi lainnya. Rung 5 menyatakan untuk menggunakan apa yang sudah terpasang. Setiap package yang ditambahkan agent atas inisiatifnya sendiri harus Anda patch nantinya dan akan masuk ke setiap container image yang Anda build dari repository tersebut.

Apa yang ditunjukkan angka benchmark milik Ponytail

Proyek ini menerbitkan dua jenis hasil, dan keduanya berbeda jauh. Keduanya merupakan angka yang diterbitkan oleh proyek itu sendiri. Tidak satu pun merupakan pengujian independen.

[
  {
    "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
  }
]

Grafik tersebut adalah benchmark agentic terbaru dari proyek ini, bertanggal 7 October 2026. Sesi Claude Code 2.1.288 tanpa antarmuka pada Opus 5.5 dengan tingkat effort default mengerjakan 39 task, lima run untuk setiap task dan arm, dengan total 585 sesi untuk no skill, Ponytail v4.13.0, dan Ponytail 5. Dua belas task merupakan feature ticket dalam full-stack-fastapi-template milik tiangolo, yaitu repositori FastAPI dan React nyata yang dinilai berdasarkan git diff yang tersisa. Sisanya terdiri atas 18 task bedah dengan pemeriksaan tersembunyi, enam permintaan aplikasi kecil, dan tiga permintaan "tunjukkan contoh". Bash dinonaktifkan untuk setiap arm. Jumlah token output turun 45 persen dengan Ponytail 5.

Bandingkan hasil ini dengan angka single-shot yang diterbitkan proyek pada June 2026. Angka tersebut berasal dari model tanpa agen yang menjawab lima prompt sehari-hari dengan dan tanpa aturan, lalu dilaporkan sebagai median dari beberapa run. Hasilnya menunjukkan 80 hingga 94 persen lebih sedikit kode pada Haiku, Sonnet, dan Opus, sedangkan verifikasi biaya bertanggal 17 June 2026 menunjukkan Haiku 63 persen lebih murah. Hasil agentic saat ini untuk Ponytail 5 adalah 53 persen lebih sedikit baris kode, biaya 26 persen lebih rendah, dan waktu wall clock 41 persen lebih singkat. Proyek ini segera mengoreksi angka single-shot tersebut. Pada v4.8.4, yaitu 29 June 2026, README sudah menampilkan hasil agentic sebagai judul utama, "~54% less code (up to 94%)", dengan catatan bahwa angka 80 hingga 94 persen sebelumnya adalah "batas atas per task, bukan rata-rata", dan angka single-shot telah dipindahkan ke bagian yang dapat diciutkan berjudul "Older single-shot numbers". Bagian tersebut menjelaskan dengan jujur alasan perbedaannya: baseline single-shot adalah model tanpa agen yang "menambahkan prosa dan opsi ke jawabannya", sehingga mudah dikalahkan. Jika pengukuran dilakukan terhadap agen nyata yang mengerjakan pekerjaan nyata, keunggulannya menyusut. Namun keunggulan tersebut tetap nyata, dan itulah fakta yang lebih berguna. Run agentic pada June itu, yang mengerjakan dua belas ticket pada Haiku 4.5 dengan empat run untuk setiap ticket, menghasilkan angka yang mendekati angka saat ini, yaitu 54 persen lebih sedikit baris. README saat ini tidak lagi memuat angka single-shot tersebut.

Ada satu catatan dari proyek itu sendiri, dan catatan inilah yang menentukan apakah Ponytail bermanfaat bagi Anda. Penghematan terbesar terjadi ketika terdapat jebakan nyata berupa implementasi berlebihan, dan hampir nol pada kode yang sejak awal sudah minimal. Tabel per task bulan October menguatkan hal tersebut: beberapa task bedah menghasilkan jumlah baris yang sama pada ketiga arm. Tiga puluh sembilan task pada satu model dan satu host, dengan Bash dinonaktifkan, tidak dapat memprediksi hasil pada repositori Anda. Jika angka tersebut penting bagi Anda, jalankan perbandingan pada ticket Anda sendiri, dengan dan tanpa aturan, lalu hitung sendiri jumlah barisnya.

Pola yang dapat langsung Anda salin tanpa menginstal apa pun

Ladder tersebut berupa teks, jadi Anda tidak memerlukan plugin untuk menggunakan idenya. Tempelkan blok seperti ini ke dalam file instruksi yang sudah dibaca oleh agent Anda, baik itu AGENTS.md, CLAUDE.md, maupun file aturan editor Anda.

## 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.

Aturan terakhir tersebut layak dibahas secara terpisah. Konvensi Ponytail dalam rilis terbarunya menggunakan komentar bertanda shortcut: yang menyebutkan batas tersebut dan kapan harus melakukan upgrade (rilis bulan Juni, termasuk v4.8.4, menggunakan tanda ponytail:):

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

Komentar tersebut hanya memerlukan dua baris, tetapi menyelesaikan pertanyaan yang jika tidak demikian dapat menghabiskan satu siklus review. Komentar itu memberi tahu pembaca berikutnya bahwa versi sederhana tersebut merupakan keputusan yang disengaja, sekaligus menyebutkan kondisi yang membuat keputusan itu tidak lagi berlaku. Tanpa komentar tersebut, reviewer tidak dapat membedakan jalan pintas yang dipertimbangkan dari hal yang terlupakan oleh agent, sehingga mereka harus bertanya.

Lokasi blok sama pentingnya dengan isinya. File yang dimuat agent pada setiap eksekusi akan memengaruhi setiap eksekusi, termasuk eksekusi yang tidak Anda awasi. Perbedaan tersebut dibahas dalam menulis AGENTS.md yang benar-benar diikuti agent Anda, dan itulah alasan pola ini sebaiknya ditempatkan dalam file yang di-commit, bukan dalam riwayat shell Anda. Dalam monorepo, pola ini sebaiknya ditempatkan dalam lebih dari satu file yang di-commit, karena AGENTS.md per package menjaga aturan setiap direktori tetap singkat, alih-alih membuat agent membaca konvensi seluruh tree pada setiap eksekusi. Namun, penempatan bukan jaminan, dan Anda perlu mengetahui mengapa agent melewati aturan yang sudah dimuatnya sebelum menyimpulkan bahwa ladder tersebut memerlukan penjelasan yang lebih tegas.

Saat aturan ini tidak lagi tepat

Tangga ini ditujukan untuk pekerjaan fitur pada codebase yang sudah ada, saat penggunaan ulang biasanya tersedia dan biasanya tepat. Pendekatan ini kurang cocok untuk proyek greenfield, karena rung 2 tidak memiliki apa pun untuk digunakan ulang dan rung 5 belum memiliki apa pun yang terpasang. Agent tetap dapat berhenti pada rung 1, standard library, fitur platform, atau one-liner, tetapi dua pilihan termurah sudah tidak tersedia. Akibatnya, lebih banyak tugas berakhir dengan penulisan kode baru. Pendekatan ini juga kurang tepat saat Anda memang ingin menggunakan abstraction tersebut. Jika Anda akan menambahkan pemanggil keempat untuk blok yang sama dan telah disalin, "diff terpendek" akan memberi Anda salinan kelima.

Level ultra akan menantang requirements Anda. Itulah tujuan level tersebut, dan ini merupakan biaya nyata ketika Anda sudah mengambil keputusan dan ingin pekerjaan diselesaikan. Gunakan full untuk pekerjaan biasa, dan gunakan ultra ketika Anda menduga feature request adalah masalahnya.

Tidak ada blok instruksi yang dapat menyelamatkan Anda dari pemahaman masalah yang keliru. Item pertama dalam ruleset ini sendiri adalah memahami kode sebelum mengambil keputusan. Itulah bagian yang mahal dan bagian yang tidak dapat dikerjakan oleh teks untuk Anda. Diff minimal pada function yang salah tetap merupakan perbaikan yang salah, dan kini perbaikan salah tersebut berukuran kecil sehingga mudah disetujui.

Ringkasan yang jujur adalah bahwa Ponytail merupakan prompt yang ditulis dengan cermat, didistribusikan dengan baik, dan dilengkapi angka. Tidak ada bagian di dalamnya yang mengharuskan plugin tersebut. Yang diberikan proyek ini adalah daftar yang ditulis dengan benar, diuji pada repository nyata, lalu dipublikasikan bersama hasilnya.

FAQ

Apakah Ponytail berfungsi dengan agent selain Claude Code?

Ya. Ponytail tersedia sebagai skill untuk host yang memuat skill, termasuk Claude Code, Codex, OpenCode, Gemini, dan beberapa lainnya yang disebutkan dalam README. Editor yang membaca file aturan tetapi tidak memuat skill, seperti Cursor, Windsurf, Cline, dan Copilot, menggunakan ruleset yang selalu aktif dari direktori aturan yang sesuai dan tidak mendapatkan slash command. Teksnya sama dalam kedua kasus tersebut. Perbedaan utamanya adalah apakah host Anda mempertahankan teks itu dalam konteks pada setiap giliran atau hanya saat skill dipicu.

Apakah agent yang malas akan melewati pengujian, validasi, atau keamanan?

Tidak, dan ruleset menyatakan hal ini secara langsung. Daftar "never lazy about" mencantumkan validasi input pada trust boundary, penanganan error yang mencegah kehilangan data, keamanan dan aksesibilitas, serta permintaan untuk satu pemeriksaan kecil yang dapat dijalankan pada setiap bagian logika yang tidak sederhana. Aturan ini menghapus struktur yang dibuat-buat: abstraksi yang tidak diminta siapa pun dan dependensi yang tidak diperlukan. Jika agent Anda mulai menghapus pengujian setelah Anda memasangnya, penyebabnya adalah instruksi lain dalam konfigurasi Anda sendiri memiliki prioritas lebih tinggi daripada aturan ini. Karena itu, baca file yang terakhir dimuat oleh agent.

Apakah angka kecepatan dan biaya yang dipublikasikan dapat dipercaya?

Angka tersebut merupakan hasil pengukuran proyek sendiri yang dipublikasikan bersama metodenya, dan harus dipahami dalam konteks tersebut. Angka single shot dari June 2026 dibandingkan dengan model dasar yang memperpanjang jawabannya menggunakan prosa dan berbagai opsi. README pada saat itu sendiri menyatakan bahwa model tersebut merupakan baseline yang lemah. Angka agentic saat ini berasal dari sesi Claude Code tanpa antarmuka pada Opus 5.5, dengan 39 task dan lima run untuk setiap task. Dua belas di antaranya merupakan feature ticket dalam satu repository FastAPI dan React. Angka tersebut valid untuk konfigurasi itu. Angka tersebut bukan perkiraan untuk codebase Anda, karena hasil per task dari proyek sendiri menunjukkan bahwa penghematan turun hingga hampir nol pada kode yang sejak awal sudah minimal.

Apakah saya perlu memasang sesuatu untuk mendapatkan manfaatnya?

Tidak. Ladder ini berupa teks. Blok yang setara dan ditempelkan ke file instruksi yang sudah dibaca oleh agent Anda akan memberikan sebagian besar manfaatnya. Plugin menyediakan susunan kata yang dipelihara, tingkat intensitas, review command, dan jalur pembaruan. Mencoba blok yang disalin terlebih dahulu merupakan jawaban rung 1 untuk pertanyaan apakah instalasi memang perlu dilakukan.

Bagaimana cara mencegah agent tanpa pengawasan membangun terlalu banyak pada malam hari?

Letakkan aturan tersebut dalam file instruksi yang selalu aktif, bukan dalam pesan chat, agar aturan itu berlaku pada turn 200 dalam proses panjang dan bukan hanya pada turn 3. Selanjutnya, batasi dampaknya secara terpisah: berikan checkout yang boleh dirusak oleh agent, bukan satu-satunya salinan Anda, dan wajibkan human diff review sebelum apa pun di-merge. Aturan diff minimal mengurangi jumlah hal yang harus Anda baca. Aturan ini tidak menentukan apa yang di-merge, dan memang seharusnya tidak.