Bikin GitHub Copilot Lebih “Malas” dengan Ponytail

Ada satu hal yang semakin sering saya rasakan sejak menggunakan AI coding assistant untuk mengerjakan project yang sudah berjalan: AI itu terlalu rajin. Kita bisa memberikan task yang sebenarnya sederhana, misalnya memperbaiki satu function, menambahkan satu kondisi, atau mengubah behavior pada satu component, tetapi response yang diberikan tidak berhenti di bagian yang kita minta. AI mulai melihat code di sekitarnya, menemukan sesuatu yang menurutnya bisa dibuat lebih sederhana, kemudian ikut melakukan refactor. Dari sisi developer, hasilnya memang kadang terlihat bagus. Code menjadi lebih pendek, beberapa abstraction hilang, dan implementation terlihat lebih clean. Masalahnya, “lebih clean” menurut AI belum tentu berarti “lebih aman” untuk codebase yang sedang kita kerjakan.

Dan menurut saya, ini menjadi masalah yang semakin relevan ketika AI tidak lagi hanya digunakan sebagai autocomplete. Ketika kita menggunakan Copilot untuk membaca repository, memahami beberapa file, membuat perubahan, lalu menjalankan task yang lebih besar, AI mulai mengambil keputusan yang sebelumnya biasanya dilakukan oleh developer. Di satu sisi ini jelas membantu produktivitas. Tapi di sisi lain, semakin banyak keputusan yang diberikan kepada AI, semakin penting kita memberikan batasan tentang bagaimana keputusan tersebut seharusnya dibuat. Karena masalahnya bukan lagi apakah AI bisa menulis code. Masalahnya adalah apakah AI tahu kapan sebaiknya tidak menulis code baru.

Saya Coba Bikin Copilot Lebih “Malas”

Dari situ saya mencoba sesuatu yang cukup menarik: bagaimana kalau GitHub Copilot justru diberikan instruction supaya lebih “malas”? Bukan malas dalam arti tidak mau mengerjakan task, tetapi malas menambahkan sesuatu yang sebenarnya tidak diperlukan. Konsep ini saya dapat dari Ponytail, sebuah kumpulan instruction yang mendorong AI untuk berpikir seperti “lazy senior developer”. Filosofinya sederhana: sebelum menulis code, cek dulu apakah sesuatu memang perlu dibuat. Kalau perlu, lihat apakah functionality-nya sudah ada di codebase. Kalau belum ada, cek standard library, native platform feature, atau dependency yang sudah digunakan. Baru kalau semua pilihan tersebut tidak cukup, tulis minimum code yang memang dibutuhkan. [1]

Saya justru suka konsepnya karena ini cukup dekat dengan masalah yang sering terjadi di project nyata. Developer yang sudah lama mengerjakan sebuah codebase biasanya tidak selalu menambahkan code setiap kali menemukan masalah. Kadang justru keputusan terbaik adalah tidak melakukan apa-apa. Tidak semua function harus diabstraksikan. Tidak semua logic perlu dibuat menjadi helper baru. Tidak semua dependency perlu ditambahkan. Dan tidak semua code yang terlihat panjang harus langsung direfactor. Ada context di balik code tersebut yang belum tentu kelihatan hanya dari beberapa baris yang sedang kita lihat.

Ponytail Itu Sebenarnya Apa?

Kalau belum pernah mendengar Ponytail, secara sederhana dia bukan framework, bukan library JavaScript, dan bukan extension yang mengubah engine GitHub Copilot. Ponytail lebih tepat dilihat sebagai sekumpulan aturan yang diberikan kepada AI coding assistant supaya cara dia mengambil keputusan lebih konservatif terhadap code. Repository Ponytail sendiri menyediakan instruction khusus untuk beberapa coding agent, termasuk GitHub Copilot. Pada versi untuk Copilot, prinsip utamanya adalah mencari solusi paling sederhana terlebih dahulu sebelum menulis sesuatu yang baru. [1]

Bagian yang menurut saya paling menarik adalah urutan berpikirnya. Ponytail tidak langsung mengatakan “tulis code sesedikit mungkin”. Dia membuat semacam ladder sebelum code ditulis. Pertama, tanyakan apakah functionality tersebut memang perlu dibuat. Kalau memang perlu, cari apakah codebase sudah memiliki solusi yang sama. Setelah itu lihat apakah standard library bisa menyelesaikannya. Kalau tidak, lihat native feature dari platform. Kemudian cek dependency yang memang sudah ada. Setelah semua pilihan itu tidak cukup, baru tulis code yang benar-benar dibutuhkan. Jadi fokusnya bukan sekadar jumlah baris, tetapi mengurangi unnecessary complexity.

code

1. Apakah ini memang perlu dibuat?

2. Apakah functionality-nya sudah ada di codebase?

3. Apakah standard library sudah bisa menyelesaikannya?

4. Apakah native platform feature sudah cukup?

5. Apakah dependency yang sudah ada bisa digunakan?

6. Apakah masalahnya bisa diselesaikan dengan lebih sederhana?

7. Baru tulis minimum code yang memang dibutuhkan.

Bagian instalasinya justru sangat sederhana. Kalau kita menggunakan GitHub Copilot yang terintegrasi dengan VS Code, kita tidak perlu mencari extension Ponytail khusus di Marketplace. Ponytail bisa digunakan sebagai custom instruction untuk Copilot. Caranya adalah membuat file .github/copilot-instructions.md di root repository, kemudian memasukkan instruction Ponytail ke dalam file tersebut. GitHub memang menyediakan repository custom instructions untuk memberikan Copilot konteks dan aturan khusus tentang bagaimana sebuah project seharusnya dipahami, dibangun, diuji, dan divalidasi. [2]

code

my-project/
├── .github/
│   └── copilot-instructions.md
├── src/
├── package.json
└── ...

Kalau folder .github belum ada, tinggal buat folder tersebut di root project. Setelah itu buat file dengan nama copilot-instructions.md. Nama file ini penting karena GitHub Copilot memang menggunakan file tersebut sebagai repository-wide custom instruction. Jadi konsepnya sedikit berbeda dengan instalasi package atau extension. Kita tidak sedang memasang Ponytail ke dalam VS Code sebagai software baru. Kita sedang memberikan instruction tambahan kepada Copilot tentang bagaimana dia seharusnya mengambil keputusan ketika bekerja di repository tersebut. [2]

Masukkan Rules Ponytail

Setelah file dibuat, kita bisa memasukkan rules Ponytail ke dalamnya. Saya menggunakan instruction yang memang disediakan oleh repository Ponytail, bukan membuat rules sendiri dari nol. Ini penting supaya eksperimennya tetap bisa direproduksi. Kalau kita mengubah terlalu banyak bagian dari instruction, nantinya sulit membedakan apakah behavior Copilot berasal dari Ponytail atau justru dari rules tambahan yang kita buat sendiri. [1]

code

# Ponytail, lazy senior dev mode

You are a lazy senior developer. Lazy means efficient, not careless. The best code is the code never written.

Before writing any code, stop at the first rung that holds:

1. Does this need to be built at all? (YAGNI)
2. Does it already exist in this codebase? Reuse the helper, util, or pattern that's already here, don't re-write it.
3. Does the standard library already do this? Use it.
4. Does a native platform feature cover it? Use it.
5. Does an already-installed dependency solve it? Use it.
6. Can this be one line? Make it one line.
7. Only then: write the minimum code that works.

Setelah file tersebut disimpan, sebenarnya tidak ada proses instalasi tambahan yang perlu dilakukan. Ini yang menurut saya agak membingungkan kalau pertama kali mencobanya. Kita mungkin berpikir harus menjalankan npm install, memasang extension, atau menjalankan command tertentu. Padahal yang terjadi adalah Copilot membaca file instruction tersebut sebagai bagian dari context yang digunakan untuk request. GitHub menjelaskan bahwa custom instructions tersedia setelah file disimpan dan dapat diverifikasi melalui References pada response Copilot. [2]

Jadi kalau saya sederhanakan, “instalasi Ponytail ke GitHub Copilot” sebenarnya lebih mirip memasang aturan kerja daripada memasang software. Kita memberikan semacam engineering guideline kepada AI. Ini juga yang membuat pendekatan seperti ini menarik, karena file instruction tersebut bisa disimpan bersama repository. Artinya, behavior yang kita inginkan tidak hanya berada di kepala developer atau di prompt pribadi masing-masing orang, tetapi bisa menjadi bagian dari context project.

Tapi saya tidak menyarankan berhenti setelah membuat file. Jangan langsung menganggap Ponytail aktif hanya karena copilot-instructions.md sudah muncul di Explorer. Yang lebih penting adalah memastikan file tersebut benar-benar masuk ke request Copilot. Di VS Code, kita bisa melihat References pada response Copilot. Jika custom instruction tersebut digunakan, .github/copilot-instructions.md akan muncul sebagai salah satu reference. Ini penting terutama ketika kita sedang melakukan eksperimen, karena kalau instruction ternyata tidak terbaca, hasil eksperimen kita juga tidak bisa dijadikan acuan. [2]

Setelah instruction tersebut terpasang, saya tidak langsung mencoba membuat feature baru dari nol. Saya justru ingin melihat apa yang terjadi ketika Ponytail diberikan kepada Copilot yang harus bekerja pada code yang sudah ada. Menurut saya ini jauh lebih menarik, karena problem terbesar AI coding bukan selalu ketika membuat project baru. Di project baru, kita memang punya kebebasan untuk menentukan architecture. Masalah mulai terasa ketika AI masuk ke codebase yang sudah memiliki convention, dependency, selector, helper, naming, dan berbagai keputusan teknis yang terbentuk dari waktu ke waktu.

Pada salah satu bagian code yang saya coba, ada sebuah function yang digunakan untuk menentukan chip mana yang sedang aktif. Implementation awalnya menggunakan toggleAttribute() untuk mengatur sebuah data attribute berdasarkan index. Secara sederhana, logic-nya cukup jelas: ketika index cocok dengan active index, attribute tertentu dipasang; ketika tidak cocok, attribute tersebut dihapus. Tidak ada abstraction besar di sini dan tidak ada library tambahan yang digunakan.

javascript

function setActive(idx) {
    if (idx === activeIdx) return;

    chips.forEach((chip, i) => {
        chip.toggleAttribute('data-value-chip-active', i === idx);
    });

    activeIdx = idx;
}

Copilot Kemudian Mengubah Implementation

Setelah menggunakan Copilot dengan instruction Ponytail, saya mendapatkan perubahan pada bagian tersebut. Copilot mengganti cara state active tadi direpresentasikan. Yang sebelumnya menggunakan data attribute kemudian diubah menjadi class. Kalau hanya melihat hasil akhirnya, perubahan ini terlihat sangat masuk akal. Bahkan bisa saja secara visual tidak ada perbedaan sama sekali karena CSS yang digunakan pada project memang bisa saja menggunakan class tersebut.

javascript

function setActive(idx) {
    if (idx === activeIdx) return;

    chips.forEach((chip, i) => {
        chip.classList.toggle('is-active', i === idx);
    });

    activeIdx = idx;
}

Tapi saya tidak mau berhenti pada kesimpulan “wah, Ponytail berhasil membuat code lebih pendek”. Justru bagian menariknya ada setelah kita melihat lebih dalam. Code yang lebih pendek tidak otomatis berarti behavior-nya identik. toggleAttribute() bekerja pada HTML attribute, sedangkan classList bekerja pada daftar class element. Keduanya sama-sama menggunakan API native browser, tetapi keduanya menyimpan informasi dengan cara yang berbeda. Jadi ketika Copilot mengganti satu dengan yang lain, ada perubahan pada representation dari state tersebut. [3]

Misalnya implementation lama menggunakan data-value-chip-active. Kita bisa saja memiliki bagian lain di dalam project yang secara eksplisit mencari attribute tersebut. Bisa berupa JavaScript, test, accessibility logic, analytics, atau bahkan code yang dibuat beberapa bulan lalu dan sekarang sudah tidak terlalu sering disentuh. Kalau ada bagian seperti itu, mengganti attribute menjadi class bukan lagi sekadar refactor kosmetik. Kita sudah mengubah sesuatu yang mungkin menjadi contract antara satu bagian code dengan bagian lainnya.

javascript

const activeChips = document.querySelectorAll(
    '[data-value-chip-active]'
);

Setelah implementation diganti, selector tersebut tentu tidak lagi menemukan element yang sama kalau attribute-nya sudah tidak ada. Developer yang memahami seluruh context project mungkin langsung menyadari hal ini. Tetapi AI yang hanya mendapatkan sebagian context bisa saja melihat implementation lokal tersebut sebagai sesuatu yang bisa disederhanakan. Di sinilah saya merasa instruction seperti Ponytail memang menarik, tetapi sekaligus menunjukkan kenapa AI tetap membutuhkan context yang cukup dan developer tetap harus melakukan review.

javascript

const activeChips = document.querySelectorAll(
    '.is-active'
);

Dua selector tersebut sama-sama valid secara syntax. Dua-duanya juga bisa menghasilkan element yang kita inginkan. Tetapi valid secara syntax bukan berarti equivalent secara architecture. Ini salah satu jebakan ketika menggunakan AI untuk refactor: kita terlalu mudah melihat apakah code bisa dijalankan, tetapi lupa bertanya apakah code tersebut masih memenuhi contract yang sebelumnya dimiliki oleh system.

“Malas” Bukan Berarti Hapus Semua Code

Ada satu hal yang menurut saya perlu diluruskan dari istilah lazy senior developer. Kalau membaca kata “malas” secara literal, kita mungkin menganggap Ponytail hanya menyuruh AI menghapus code sebanyak mungkin. Padahal bukan itu maksudnya. Lazy di sini lebih dekat dengan efficient. Kalau sebuah functionality sudah tersedia, jangan membuat ulang. Kalau browser sudah menyediakan API yang cukup, jangan menambahkan dependency hanya untuk melakukan hal yang sama. Kalau abstraction baru tidak memberikan value, jangan membuat abstraction hanya karena kita bisa. Tapi kalau error handling memang diperlukan, security check memang diperlukan, atau validation memang menjadi bagian dari requirement, ya tetap harus dibuat.

Menurut saya justru di sini letak perbedaan antara code yang minimal dan code yang asal dipangkas. Code minimal adalah code yang menghilangkan complexity yang tidak diperlukan tanpa menghilangkan behavior yang memang dibutuhkan. Sedangkan code yang asal dipangkas hanya mengejar jumlah baris yang lebih sedikit. Dua hal tersebut kelihatannya mirip dari luar, tetapi konsekuensinya sangat berbeda ketika project mulai membesar.

Kesimpulan

Ponytail + GitHub Copilot menurut saya bukan tentang membuat AI benar-benar “malas”. Justru kita sedang mencoba membuat AI lebih disiplin dalam menggunakan effort-nya. Jangan langsung membuat sesuatu kalau ternyata sudah ada. Jangan menambah dependency kalau native feature sudah cukup. Jangan membuat abstraction kalau problem-nya sebenarnya sederhana. Dan jangan mengubah code hanya karena ada bagian yang terlihat kurang cantik dari sudut pandang AI.

Ponytail + GitHub Copilot menurut saya bukan tentang membuat AI benar-benar “malas”. Justru kita sedang mencoba membuat AI lebih disiplin dalam menggunakan effort-nya. Jangan langsung membuat sesuatu kalau ternyata sudah ada. Jangan menambah dependency kalau native feature sudah cukup. Jangan membuat abstraction kalau problem-nya sebenarnya sederhana. Dan jangan mengubah code hanya karena ada bagian yang terlihat kurang cantik dari sudut pandang AI.

Instalasinya sendiri cukup sederhana. Kita bisa menggunakan .github/copilot-instructions.md sebagai repository custom instruction untuk GitHub Copilot di VS Code, kemudian memasukkan rules Ponytail ke dalamnya. Setelah itu kita bisa memeriksa References pada response Copilot untuk memastikan instruction tersebut benar-benar digunakan. [1][2]

Jadi kalau sekarang AI bisa menulis code lebih cepat daripada kita, mungkin pertanyaan berikutnya bukan lagi “bagaimana membuat AI menulis lebih banyak?”

Mungkin justru:

“Bagaimana membuat AI tahu kapan tidak perlu menulis?”

Karena pada akhirnya, senior developer bukan yang selalu menulis code paling sedikit.

Tapi yang tahu code mana yang memang tidak perlu ditulis.

Referensi

[1] DietrichGebert. (2026). Ponytail — Lazy Senior Developer Mode. GitHub Repository.

[2] GitHub. (2026). Adding repository custom instructions for GitHub Copilot in your IDE. GitHub Docs.

[3] Mozilla Developer Network. (2026). Element: toggleAttribute() method. MDN Web Docs.

[4] GitHub. (2026). Customizing GitHub Copilot responses. GitHub Docs.

[5] Zhang, B., Liang, P., Zhou, X., Ahmad, A., & Waseem, M. (2023). Practices and Challenges of Using GitHub Copilot: An Empirical Study. arXiv.

Bikin GitHub Copilot Lebih “Malas” dengan Ponytail

Saya Coba Bikin Copilot Lebih “Malas”

Ponytail Itu Sebenarnya Apa?

Masukkan Rules Ponytail

Copilot Kemudian Mengubah Implementation

“Malas” Bukan Berarti Hapus Semua Code

Kesimpulan

Referensi

Suka dengan artikel ini?

Komentar (0)