PR 2.000 baris dari AI agent itu bukan tanda produktivitas kalau reviewer cuma bisa bengong di tab “Files changed”.
Intinya begini: GitHub Stacked Pull Requests membantu developer memecah perubahan besar menjadi beberapa pull request kecil yang berurutan. Di era AI coding, ini penting karena agent bisa menghasilkan diff besar dengan cepat, sementara manusia tetap harus memahami desain, risiko, test, dan dampak perubahan. Stacked PR bukan solusi ajaib, tapi bisa jadi cara waras supaya fitur besar tetap bisa direview sebagai layer yang jelas.
Kalau lu pakai AI coding agent seperti Copilot, Claude Code, Cursor, Codex, atau tool sejenis, masalah terbesar biasanya bukan “AI bisa nulis kode atau nggak”. Masalahnya: apakah output itu bisa dicek, diubah, di-rollback, dan dimiliki manusia setelah merge?
Apa itu GitHub Stacked Pull Requests?
Stacked Pull Requests adalah rangkaian pull request yang tersusun berurutan. Tiap PR merepresentasikan satu layer perubahan yang fokus, lalu PR berikutnya dibangun di atas PR sebelumnya.
GitHub mengumumkan fitur ini masuk public preview pada 30 Juli 2026. Dari changelog GitHub, stack bisa dibuat dari terminal atau GitHub.com, direview per layer, lalu digabung dengan alur yang lebih terarah dibanding satu PR raksasa. GitHub juga mencontohkan pola ini dipakai di codebase besar seperti Next.js untuk mengirim perubahan besar sebagai bagian kecil yang tetap reviewable.
Secara sederhana, bedanya kira-kira begini:
- PR besar biasa: semua perubahan masuk satu paket. Reviewer harus paham semuanya sekaligus.
- Stacked PR: perubahan dipecah jadi urutan kecil. Reviewer bisa mengecek foundation dulu, baru logic, test, dan cleanup.
Ini bukan konsep baru di dunia engineering. Banyak tim sudah lama pakai stacked diffs lewat tool seperti Graphite atau workflow internal. Yang menarik sekarang: GitHub mulai membawa pola ini ke workflow pull request mainstream.
Kenapa ini makin penting di era AI coding?
AI menurunkan biaya membuat kode. Tapi AI tidak otomatis menurunkan biaya memahami kode.
Gua sering melihat problem yang sama di workflow AI coding: agent bisa menyelesaikan task dengan cepat, tapi output-nya datang sebagai satu bongkahan. Ada refactor, perubahan business logic, perubahan UI, update test, rename file, dan cleanup kecil dalam satu PR. Secara hasil mungkin jalan. Secara review, itu mimpi buruk.
Di sinilah stacked PR jadi guardrail kecil yang berguna. Bukan karena stacked PR membuat AI lebih pintar, tapi karena dia memaksa perubahan punya batas yang lebih manusiawi.
Masalah utama PR besar dari AI bukan jumlah barisnya
Banyak orang langsung fokus ke angka: “PR ini 2.000 baris, berarti buruk.” Menurut gua, jumlah baris cuma sinyal awal. Masalah yang lebih serius adalah campur aduknya alasan perubahan.
Satu PR jadi sulit direview kalau isinya mencampur:
- rename variable besar-besaran,
- pindah struktur folder,
- ubah kontrak API,
- ubah logic utama,
- nambah test,
- dan format ulang file lama.
Kalau semua itu masuk satu diff, reviewer sulit menjawab pertanyaan paling penting: “perubahan mana yang benar-benar mengubah behavior?”
GitHub punya dokumentasi tentang pull request review karena PR memang tempat tim mendiskusikan perubahan sebelum merge. Tapi review hanya efektif kalau unit perubahan masih bisa dipahami. Kalau diff sudah terlalu lebar, review berubah jadi ritual formal: ada yang approve, tapi nggak ada yang benar-benar yakin.
Cara memecah PR AI jadi layer yang lebih aman
Kalau agent lu menghasilkan perubahan besar, jangan langsung lempar ke reviewer. Coba pecah menjadi stack seperti ini:
1. PR setup: perubahan yang tidak mengubah behavior
Ini tempat untuk menambah dependency, konfigurasi, file struktur baru, atau helper kosong. Idealnya PR ini kecil dan mudah dicek.
Contoh: “siapkan modul payment rules”, “tambahkan interface repository”, atau “buat route kosong tanpa logic bisnis”.
2. PR refactor: rapikan jalur lama sebelum fitur masuk
Kalau fitur baru butuh struktur yang lebih rapi, pisahkan refactor dari fitur. Ini penting banget buat AI coding karena agent sering mencampur refactor dengan behavior change.
Refactor yang sehat harus punya prinsip: setelah PR ini, behavior user tetap sama. Kalau behavior ikut berubah, berarti PR ini bukan refactor murni.
3. PR logic utama: perubahan yang benar-benar membawa fitur
Ini layer yang paling butuh perhatian reviewer. Karena setup dan refactor sudah dipisah, reviewer bisa fokus ke pertanyaan yang lebih penting:
- apakah logic-nya sesuai requirement?
- apakah edge case-nya masuk akal?
- apakah ada permission atau security boundary yang berubah?
- apakah behavior lama tetap aman?
4. PR test: bukti bahwa perubahan bisa dipercaya
Test bisa digabung dengan PR logic kalau kecil. Tapi untuk perubahan besar, test layer terpisah bisa membantu reviewer melihat apa yang dianggap penting oleh developer atau AI agent.
Kalau AI bikin test, jangan cuma cek apakah test pass. Cek juga apakah test membuktikan behavior yang benar. Test yang cuma mengikuti implementasi salah tetap bisa hijau.
5. PR cleanup: hapus sisa, dokumentasi, dan polishing
Cleanup sering terlihat sepele, tapi kalau dicampur ke logic utama, dia bikin diff makin berisik. Pisahkan rename, hapus dead code, dan update docs supaya reviewer tidak kehilangan jejak perubahan penting.
Contoh praktis: agent bikin fitur export invoice
Misalnya lu meminta AI agent bikin fitur export invoice PDF. Cara buruknya: satu PR berisi library PDF, refactor billing service, endpoint baru, UI button, test, dan format ulang folder.
Cara yang lebih waras:
- PR 1: tambah dependency PDF dan wrapper adapter kosong.
- PR 2: refactor billing data supaya invoice punya struktur konsisten.
- PR 3: implement endpoint export invoice.
- PR 4: tambah UI button dan loading/error state.
- PR 5: tambah test untuk invoice paid, unpaid, dan missing customer data.
Apakah ini lebih banyak PR? Iya. Tapi tiap PR punya pertanyaan review yang lebih jelas. Dan kalau ada yang salah, lu bisa diskusi di layer yang tepat, bukan membongkar satu monster diff.
Stacked PR bukan pengganti disiplin engineering
Ini bagian yang perlu jujur: stacked PR tidak otomatis membuat workflow bagus.
Kalau tiap layer tetap isinya campur aduk, stacked PR cuma jadi tumpukan PR kecil yang sama-sama membingungkan. Tooling membantu, tapi disiplin tetap harus datang dari cara lu menulis task, memandu agent, dan mengecek output.
Checklist sederhana sebelum lu submit stack dari hasil AI:
- Satu PR = satu alasan perubahan. Kalau alasan PR lebih dari satu, pecah lagi.
- Label behavior change. Jelaskan PR mana yang mengubah behavior user.
- Pisahkan refactor dan fitur. Jangan bikin reviewer menebak mana yang cuma rename dan mana yang mengubah logic.
- Tulis instruksi review. Kasih tahu reviewer fokus ke apa di tiap layer.
- Pastikan tiap layer bisa dites. Kalau layer tidak bisa diverifikasi, minimal jelaskan cara validasinya.
- Jangan sembunyikan output AI. Kalau agent membantu banyak, tetap lu yang bertanggung jawab atas keputusan merge.
Kenapa ini bagus buat developer solo juga?
Stacked PR sering dibahas sebagai workflow tim. Tapi buat developer solo, prinsipnya tetap berguna.
Lu mungkin tidak punya reviewer manusia setiap hari. Tapi lu punya diri sendiri di masa depan. Saat bug muncul dua minggu lagi, stack yang rapi membantu lu melihat perubahan mana yang memperkenalkan behavior tertentu.
Buat gua, ini nyambung dengan cara kerja builder yang sehat: AI boleh mempercepat eksekusi, tapi jejak keputusan harus tetap kebaca. Kalau workflow cuma “prompt → agent kerja → merge”, lu mungkin cepat hari ini, tapi mahal saat debugging nanti.
Takeaway: review boundary itu fitur produktivitas
AI coding bikin output makin murah. Karena itu, batas review harus makin jelas.
GitHub Stacked Pull Requests menarik bukan karena dia fitur paling glamor, tapi karena dia menyentuh bottleneck yang makin nyata: manusia tetap perlu memahami perubahan sebelum software itu dimiliki bersama.
Kalau lu cuma ambil satu hal dari artikel ini, ambil ini: jangan review perubahan besar sebagai satu bongkahan hanya karena AI bisa membuatnya cepat. Pecah jadi layer. Review per alasan perubahan. Baru merge saat tiap layer punya bukti yang cukup.
FAQ singkat
Apakah stacked PR wajib untuk semua perubahan?
Nggak. Untuk bugfix kecil atau perubahan sederhana, satu PR biasa sudah cukup. Stacked PR paling berguna saat perubahan besar punya beberapa tahap yang bisa dipisah.
Apakah stacked PR membuat code review lebih cepat?
Bisa, tapi bukan otomatis. Review jadi lebih cepat kalau tiap layer fokus dan punya deskripsi yang jelas. Kalau layer tetap berantakan, hasilnya tetap lambat.
Apakah ini khusus buat AI coding agent?
Nggak. Stacked PR berguna untuk perubahan besar apa pun. Tapi di era AI coding, urgensinya naik karena agent bisa menghasilkan diff besar dalam waktu singkat.
Apa risiko terbesar kalau PR AI tidak dipecah?
Reviewer kehilangan konteks. Akhirnya perubahan di-approve karena terlihat jalan, bukan karena benar-benar dipahami.
