DevOps

Ponytail Coding: Mengurangi Token Usage dan Overengineering pada AI Agent

admin
admin

1 Sep 20268 min baca

Ponytail Coding: Mengurangi Token Usage dan Overengineering pada AI Agent

Ponytail adalah ruleset open source yang menjadi inti dari ponytail coding, praktik membuat AI coding agent menulis kode paling sedikit yang tetap bekerja, seperti senior dev yang sudah terlalu sering dibangunkan jam 3 pagi karena codebase yang over engineered. Agent AI punya kebiasaan buruk yang konsisten: diminta satu fungsi, dia bikin class lengkap dengan interface, factory, dan konfigurasi. Diminta refactor kecil, dia tambah tiga dependency baru. Ponytail memotong kebiasaan itu secara sistematis, dan hasilnya terukur: median 54% kode lebih sedikit dan 22% token lebih hemat pada benchmark resminya.

Apa Itu Ponytail?

Ponytail adalah ruleset berbentuk skill atau plugin yang dipasang di AI coding agent seperti Claude Code, Codex CLI, Gemini CLI, OpenCode, Cursor, Windsurf, dan 14+ agent lainnya. Isinya bukan library dan bukan framework, melainkan seperangkat aturan perilaku yang diinjeksi ke context agent: tulis solusi paling malas yang tetap benar. Lisensinya MIT dan repository resminya ada di GitHub pada ponytail.dev.

Aturan intinya dibungkus dalam satu konsep bernama the ladder, tangga tujuh anak tangga yang harus dinaiki agent secara berurutan dan berhenti di anak tangga pertama yang sudah menyelesaikan masalah. Anak tangganya dari atas ke bawah: apakah kode ini perlu ada sama sekali, apakah sudah ada implementasinya di codebase, apakah standard library menyediakannya, apakah fitur native platform cukup, apakah dependency yang sudah terpasang bisa dipakai, bisakah diselesaikan satu baris, dan hanya jika semuanya gagal barulah tulis kode minimal baru.

Bagaimana Cara Kerja Ponytail?

Diagram alur kerja ponytail dari prompt masuk, tangga keputusan, sampai output kode minimal
Alur kerja ponytail: agent memahami masalah dulu, lalu naik tangga keputusan dan berhenti di anak tangga pertama yang menyelesaikan masalah.

Mekanismenya sederhana secara teknis: ponytail menyisipkan ruleset ke system context agent, lalu aturan itu aktif di setiap respons sampai dimatikan. Ketika kamu memberi prompt, agent tidak langsung menulis kode. Dia membaca task dan kode yang tersentuh dulu, menelusuri alur nyatanya end to end, baru memilih anak tangga. Pendekatan ini penting: ponytail mempersingkat solusi, bukan mempersingkat pemahaman. Agent yang malas memahami masalah tapi rajin menulis diff kecil justru melahirkan bug baru.

Untuk bug fix ada aturan tambahan yang khas: perbaiki root cause, bukan gejala. Sebelum mengedit sebuah fungsi, agent diwajibkan menelusuri semua caller-nya. Satu guard di fungsi bersama yang dipakai semua caller adalah diff lebih kecil daripada guard di tiap pemanggil, dan patch yang hanya menyentuh jalur yang dilaporkan ticket meninggalkan caller lain tetap rusak.

Ada tiga level intensitas yang bisa dipilih dari chat: lite membangun apa yang diminta tapi menyebutkan alternatif yang lebih malas dalam satu baris, full yang menjalankan tangga penuh dan menjadi default, serta ultra yang ekstrem: hapus dulu sebelum tambah, kirim one-liner, dan tantang sisa requirementnya di respons yang sama.

Bagaimana Ponytail Mengurangi Over Engineering pada Kode yang Dihasilkan AI?

Over engineering pada kode AI terjadi karena model dilatih dari jutaan repo dengan pola enterprise, sehingga default-nya adalah menawarkan fleksibilitas: interface untuk satu implementasi, config untuk nilai yang tidak pernah berubah, scaffold untuk kebutuhan masa depan yang belum ada. Ponytail melawan arah ini dengan larangan eksplisit: tidak ada abstraksi yang tidak diminta, tidak ada factory untuk satu produk, tidak ada boilerplate untuk nanti. Deletion over addition.

Aturan praktisnya konkret. Butuh cache? Satu decorator lru_cache, bukan class CacheManager 48 baris dengan lock dan TTL buatan sendiri. Butuh date picker? Input type date bawaan HTML, bukan library picker. Butuh integritas data? Constraint di database, bukan validasi duplikat di aplikasi. Shortcut yang sengaja memotong pojok wajib ditandai komentar ponytail yang menyebut ceiling-nya dan jalur upgrade, misalnya global lock yang perlu jadi per-account lock saat throughput naik, sehingga utang teknis terlihat dan tercatat, bukan tersembunyi.

Yang tidak pernah disederhanakan juga ditulis tegas: validasi input di trust boundary, error handling yang mencegah kehilangan data, security, dan aksesibilitas. Benchmark resminya mencatat 100% safety kept, artinya pengurangan 54% kode tidak mengorbankan jalur pelindung. Logika non-trivial juga diwajibkan meninggalkan satu runnable check terkecil yang gagal jika logikanya rusak.

Apakah Ponytail Bisa Menghemat Token AI?

Bisa, dan angkanya bukan klaim marketing. Benchmark ponytail.dev, median dari 12 feature tasks pada repository FastAPI plus React, mencatat empat angka sekaligus: 54% kode lebih sedikit, 22% token lebih hemat, 20% biaya lebih rendah, dan 27% eksekusi lebih cepat.

Mekanisme penghematannya logis. Token terbesar dalam sesi coding justru di output dan context: kode yang ditulis agent masuk kembali ke context sebagai bahan iterasi berikutnya, jadi kode 54% lebih pendek berarti context yang dibawa tiap putaran juga menyusut. Satu session agent yang tadinya 10 putaran dengan file bengkak menjadi 10 putaran dengan file ramping, dan penghematannya berlipat. Biaya 20% lebih rendah adalah konsekuensi langsung dari kombinasi keduanya. Perlu dicatat jujur: penghematan terbesar ada di output dan iterasi, sedangkan biaya memuat ruleset ponytail sendiri di input relatif kecil dan hanya dibayar sekali per sesi.

Cara Menggunakan Ponytail

Instalasinya dua baris di Claude Code:

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

Untuk agent lain polanya serupa:

# Codex CLI
codex plugin marketplace add DietrichGebert/ponytail

# Copilot CLI
copilot plugin install ponytail@ponytail

# Gemini CLI
gemini extensions install github.com/DietrichGebert/ponytail

# pi harness
pi install git:github.com/DietrichGebert/ponytail

Setelah terpasang, ponytail aktif otomatis di setiap respons. Kontrol dari chat:

ponytail lite|full|ultra|off   # atur intensitas atau matikan
ponytail-review               # cari over engineering di diff saat ini
ponytail-audit                # scan seluruh repo
ponytail-debt                 # kumpulkan shortcut tertunda jadi ledger
ponytail-gain                 # tampilkan scoreboard benchmark

OpenCode, Cursor, Windsurf, Cline, Kiro, dan Zed juga didukung, total 14+ agent dengan daftar lengkap di README resminya.

Integrasi di Agent: Hermes, 9Router, dan Lainnya

Ada dua lapisan integrasi yang harus dipahami: ponytail sebagai plugin resmi di agent yang punya sistem plugin, dan ponytail sebagai ruleset teks yang disuntikkan sebagai system prompt di tool apa pun yang kamu kontrol prompt-nya. Keduanya memakai ruleset yang sama, bedanya cuma mekanisme injeksinya.

Instalasi di Hermes Agent

Hermes adalah salah satu agent yang didukung plugin resmi. Instalasinya satu perintah:

hermes plugins install DietrichGebert/ponytail --enable

Setelah instalasi, restart Hermes. Yang terjadi di balik layar: plugin menginjeksi mode ponytail aktif sebelum setiap LLM turn, meregistrasi skill bawaannya dengan prefix ponytail, dan menambahkan enam slash command: /ponytail untuk mengatur intensitas, /ponytail-review untuk mengaudit diff, /ponytail-audit untuk seluruh repo, /ponytail-debt untuk ledger utang teknis, /ponytail-gain untuk scoreboard, dan /ponytail-help untuk referensi. Penggunaannya sederhana: panggil /ponytail full di chat, dan semua keputusan coding di sesi itu tunduk pada tangga ponytail sampai kamu ketik normal mode. Satu catatan operasional: pada gateway yang dipakai bersama, batasi akses /ponytail ke user terpercaya lewat access control slash-command Hermes, karena mode runtime bersifat process-local.

Pemakaian di 9Router

9Router adalah router API OpenAI-compatible, bukan agent. Ia menerima request chat completion dari client, lalu meneruskannya ke provider di belakangnya. Karena tidak punya konsep skill atau plugin, ponytail tidak dipasang di sisi router, melainkan di sisi client yang mengirim request. Polanya: ambil ruleset ponytail dari file .agents/rules/ponytail.md di repository resminya, lalu jadikan system prompt di aplikasi atau CLI yang menunjuk ke endpoint 9Router.

curl -s https://raw.githubusercontent.com/DietrichGebert/ponytail/main/.agents/rules/ponytail.md \
  -o ponytail.md

curl -s http://localhost:20128/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $ROUTER_KEY" \
  -d @- <<EOF
{
  "model": "minimax-m3",
  "messages": [
    {"role": "system", "content": "$(cat ponytail.md)"},
    {"role": "user", "content": "tulis fungsi cache untuk fetch produk"}
  ]
}
EOF

Dengan pola ini, semua request yang membawa system prompt ponytail akan menghasilkan output sesuai tangganya, tidak peduli model atau provider yang dipilih 9Router untuk melayani request itu. Aturannya hidup di lapisan prompt, bukan di lapisan routing, jadi pergantian model atau failover antar provider tidak mengubah perilakunya. Pola ini juga berlaku untuk agent custom apa pun: selama kamu bisa menyuntik system prompt, ponytail bisa dipakai.

Pengalaman Memakai Ponytail di Hermes Agent

Saya nggak mau cuma percaya angka benchmark dari situsnya, jadi ponytail langsung saya pasang di Hermes Agent yang bekerja setiap hari di MacBook saya. Ini yang saya rasakan selama memakainya, lengkap dengan angka asli dari database sesi Hermes saya.

Soal token usage, ini datanya, saya ambil langsung dari database sesi Hermes saya:

Metrik Sebelum Sesudah Selisih
Panjang respons rata-rata 510 karakter 443 karakter 13% lebih pendek
Panggilan tool per respons 1,66 1,34 19% lebih hemat

Angka ini nggak sehebat klaim 22% di benchmark, wajar sih, karena benchmark-nya khusus tugas coding murni sedangkan agent saya dipakai untuk macam-macam hal, tapi arahnya sama: output lebih pendek, iterasi lebih sedikit.

Yang paling saya rasakan selama pemakaian bukan cuma jumlah karakter, tapi kebiasaan agent yang berubah. Dulu waktu saya suruh bikin sesuatu, agent langsung nulis solusi paling lengkap: class, interface, konfigurasi, kadang dependency baru ikut masuk padahal nggak saya minta. Sekarang dia berhenti dulu dan mikir: apakah ini perlu dibuat? stdlib udah cukup? fitur native platform udah nutupin? Kalau iya, dia ambil jalur pendek dan selesai. Diff hasil review juga jadi lebih pendek dan gampang saya baca, dan itu bikin review jadi cepat.

Ada satu temuan teknis yang jarang dibahas orang. Skill di Hermes itu cuma aktif kalau dipanggil, sedangkan yang saya mau ponytail nyala terus di semua tugas coding tanpa harus saya ingat. Solusinya: esensi tangga ponytail saya tulis ulang jadi satu instruksi, lalu dipasang permanen lewat hermes config set agent.coding_instructions. Sejak itu tiap sesi coding baru otomatis jalan dengan aturan yang sama: stdlib dulu, native dulu, dependency baru paling terakhir, validasi dan security tetap wajib. Instalasi enam skill bawaannya sendiri gampang, tinggal salin folder skill dan muncul di hermes skills list.

Kalau ditanya worth it atau nggak, menurut saya iya. Bukan karena kodenya jadi drastis lebih pendek di semua kasus, tapi karena agent berhenti bikin barang yang nggak saya minta. Ngobrolnya jadi lebih enak: minta satu fungsi, dapat satu fungsi, bukan satu framework kecil.

Artikel Terkait

(3)

Komentar

(0)

Komentar Anda akan dimoderasi.

Memuat komentar...