Policy CI untuk Review Kode: Batasi Klaim AI, Utamakan Bukti Teknis

Policy CI untuk review kode seharusnya mengurangi debat subjektif, bukan menambahnya. Jika sebuah pull request dinilai dari klaim seperti “kode ini bagus karena dibantu AI” atau “jangan merge karena pasti hasil AI”, tim akan kehilangan fokus pada hal yang bisa diverifikasi: apakah perubahan lolos lint, test, type-check, aman, punya langkah reproduksi, dan jelas risiko dampaknya.

Prinsip yang lebih sehat adalah sederhana: terima atau tolak perubahan berdasarkan bukti teknis yang dapat diaudit. Output AI boleh saja dipakai sebagai alat bantu, tetapi status merge tetap ditentukan oleh kualitas perubahan, hasil CI, cakupan verifikasi, dan kejelasan konteks engineering. Artikel ini membahas cara menerjemahkan prinsip tersebut menjadi policy repo, template PR, checklist reviewer, dan gate CI/CD yang bisa langsung diterapkan tim kecil hingga menengah.

Pemicu pembahasan ini sejalan dengan kritik terhadap kebiasaan membesar-besarkan AI dalam proses kreatif: yang perlu dinilai bukan narasi tentang alatnya, melainkan kualitas hasil dan bukti kerja. Dalam konteks rekayasa perangkat lunak, itu berarti fokus pada reviewable evidence, bukan debat generik soal AI.

Mengapa klaim AI perlu dibatasi dalam review PR

Masalah utama dari pembahasan “AI atau bukan AI” adalah ia jarang menghasilkan keputusan teknis yang konsisten. Reviewer bisa terjebak pada asumsi kualitas, padahal dua hal berikut tetap benar:

Kode yang ditulis manusia bisa salah, rapuh, dan tidak teruji.
Kode yang dibantu AI bisa benar jika diverifikasi, diuji, dan dipahami oleh pengusul PR.

Karena itu, policy yang baik tidak perlu mencoba menebak asal ide atau fragmen kode. Yang perlu dilakukan adalah mewajibkan bukti minimum untuk setiap perubahan. Dengan pendekatan ini, tim mendapat beberapa manfaat:

Review lebih objektif: diskusi berpindah dari opini ke hasil pemeriksaan.
Audit lebih mudah: alasan merge atau reject tercatat jelas.
Onboarding lebih cepat: engineer baru tahu standar yang diharapkan.
Risiko lebih terkendali: perubahan berbahaya diperlakukan berbeda dari perubahan rutin.

Trade-off-nya, proses review bisa terasa lebih formal. Namun untuk tim kecil-menengah, sedikit struktur biasanya lebih murah daripada biaya regresi, rollback, dan debat yang berulang.

Prinsip policy: alat bebas, bukti wajib

Kalimat kebijakan inti yang paling berguna biasanya singkat dan operasional. Misalnya:

Semua kontribusi dinilai berdasarkan bukti teknis yang dapat diverifikasi.
Penggunaan AI diperbolehkan sebagai alat bantu, tetapi:
1. pengusul PR tetap bertanggung jawab penuh atas isi perubahan,
2. reviewer tidak menerima atau menolak PR hanya karena klaim penggunaan AI,
3. perubahan harus lolos gate CI yang berlaku,
4. perubahan berisiko tinggi memerlukan bukti tambahan sesuai kategori risiko.

Kalimat ini bekerja karena tidak mencoba mengatur hal yang sulit dibuktikan, seperti seberapa banyak AI terlibat. Sebaliknya, policy langsung mengikat ke artefak yang bisa diperiksa: hasil CI, test, penjelasan desain, dan reproduksi bug.

Apa yang sebaiknya diwajibkan

Deskripsi perubahan dan alasan bisnis/teknis.
Bukti verifikasi: output test, screenshot, log, atau langkah manual.
Penilaian risiko perubahan.
Langkah reproduksi untuk bug fix.
Konfirmasi bahwa pengusul memahami kode yang dia kirim.

Apa yang sebaiknya tidak dijadikan dasar keputusan

“Ini dibuat AI, jadi pasti cepat dan bagus.”
“Gaya penulisannya mirip AI, jadi saya tidak percaya.”
“Saya rasa aman” tanpa test atau langkah verifikasi.
“Sudah jalan di laptop saya” tanpa detail lingkungan atau command.

Template PR yang memaksa bukti, bukan narasi

Template PR adalah kontrol pertama yang paling murah. Tujuannya bukan menambah birokrasi, tetapi memastikan informasi penting selalu ada sebelum review dimulai.

Contoh template PR

## Ringkasan
- Apa yang berubah?
- Mengapa perubahan ini diperlukan?

## Jenis perubahan
- [ ] Bug fix
- [ ] Fitur baru
- [ ] Refactor
- [ ] Perubahan dependensi
- [ ] Perubahan konfigurasi/infrastruktur

## Bukti verifikasi
- [ ] Lint lulus
- [ ] Test lulus
- [ ] Type-check lulus
- [ ] Verifikasi manual dilakukan

Command yang dijalankan:
```bash
# contoh
npm test
npm run lint
npm run typecheck
```

Hasil penting:
- Tambahkan ringkasan output, screenshot, atau link artifact bila relevan.

## Reproduksi bug (wajib untuk bug fix)
### Sebelum
1. ...
2. ...
3. ...

### Sesudah
1. ...
2. ...
3. ...

## Risiko dan dampak
- Area terdampak:
- Risiko rollback:
- Perlu migrasi data?: ya/tidak
- Perlu perubahan config/env?: ya/tidak

## Checklist pengusul
- [ ] Saya memahami perubahan yang saya kirim.
- [ ] Saya bisa menjelaskan bagian yang diubah saat review.
- [ ] Saya menambahkan atau memperbarui test bila diperlukan.
- [ ] Jika menggunakan AI, saya telah memverifikasi output dan menghapus saran yang tidak relevan.
- [ ] Saya tidak mengandalkan klaim AI sebagai alasan merge.

Bagian terakhir penting: bukan untuk menghakimi penggunaan AI, tetapi untuk menegaskan tanggung jawab penulis. Ini berguna terutama ketika engineer menyalin output alat tanpa benar-benar memahami query SQL, regex, aturan concurrency, atau perubahan konfigurasi yang dibuat.

Kenapa template ini efektif

Mengurangi review bolak-balik karena reviewer tidak perlu meminta konteks dasar berulang kali.
Memaksa pengusul berpikir soal risiko sebelum merge.
Memisahkan bug fix dari opini karena ada langkah reproduksi sebelum/sesudah.
Membuat output AI menjadi sekunder; yang utama tetap bukti verifikasi.

Checklist reviewer: nilai perubahan, bukan asal usulnya

Reviewer juga butuh panduan yang konsisten. Tanpa checklist, review sering berubah menjadi komentar gaya, preferensi pribadi, atau curiga berlebihan terhadap kode yang “terlihat seperti AI”.

Checklist reviewer yang praktis

Apakah tujuan perubahan jelas dan sesuai deskripsi PR?
Apakah hasil CI lengkap untuk tipe perubahan ini?
Apakah test yang relevan ada, diperbarui, atau sengaja tidak ditambah dengan alasan jelas?
Untuk bug fix, apakah langkah reproduksi sebelum/sesudah masuk akal?
Apakah perubahan menyentuh area berisiko seperti autentikasi, otorisasi, transaksi, migrasi data, cache, atau concurrency?
Apakah ada perubahan API, skema data, atau kontrak yang perlu kompatibilitas mundur?
Apakah rollback memungkinkan jika deploy bermasalah?
Apakah ada indikasi kode disalin tanpa dipahami, misalnya dead code, konfigurasi tak terpakai, query yang tidak sesuai skema, atau error handling yang tidak nyambung?

Contoh aturan reviewer

Reviewer wajib memberi keputusan berdasarkan artefak berikut:
- status CI,
- isi diff,
- test dan bukti verifikasi,
- analisis risiko.

Reviewer tidak boleh menerima atau menolak PR hanya berdasarkan dugaan bahwa kode dibuat dengan AI.
Jika ada bagian yang tampak tidak dipahami pengusul, reviewer meminta penjelasan teknis atau perubahan tambahan.

Aturan ini menjaga diskusi tetap netral. Jika pengusul tidak mampu menjelaskan perubahan yang dikirim, itu masalah nyata terlepas dari apakah AI dipakai atau tidak.

Gate CI minimum: lint, test, type-check

Untuk banyak repository aplikasi, gate minimum yang rasional adalah lint, test, dan type-check bila bahasa atau toolchain mendukungnya. Tiga gate ini tidak menjamin kebenaran penuh, tetapi cukup kuat untuk menyaring banyak error dasar sebelum reviewer menghabiskan waktu.

Kapan masing-masing gate penting

Lint: menangkap masalah konsistensi, anti-pattern tertentu, import yang tak terpakai, dan sebagian bug sederhana.
Test: memverifikasi perilaku yang diharapkan dan mencegah regresi.
Type-check: sangat berguna pada codebase bertipe statis atau bertipe opsional, terutama untuk perubahan kontrak data.

Kesalahan umum adalah mengandalkan hanya satu gate. Misalnya, lint lulus bukan berarti perilaku benar. Test lulus juga bukan berarti kontrak tipe aman jika ada perubahan interface yang tidak tercakup. Kombinasi ketiganya memberi sinyal kualitas yang lebih baik.

Contoh GitHub Actions singkat

name: pr-checks

on:
  pull_request:
    branches: [main]

jobs:
  verify:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Setup runtime
        uses: actions/setup-node@v4
        with:
          node-version: '20'
      - name: Install dependencies
        run: npm ci
      - name: Lint
        run: npm run lint
      - name: Type check
        run: npm run typecheck
      - name: Test
        run: npm test -- --runInBand

Contoh di atas sengaja sederhana. Intinya bukan tool tertentu, melainkan jadikan hasil verifikasi sebagai syarat merge. Jika tim Anda menggunakan bahasa atau runtime lain, prinsipnya sama: setup environment, install dependency secara deterministik, lalu jalankan pemeriksaan minimum yang disepakati.

Contoh GitLab CI singkat

stages:
  - verify

verify:
  stage: verify
  image: node:20
  script:
    - npm ci
    - npm run lint
    - npm run typecheck
    - npm test -- --runInBand
  only:
    - merge_requests

Jika pipeline terlalu lambat, jangan langsung menghapus gate. Lebih baik optimalkan cache, split job, atau jalankan subset berbasis path untuk perubahan tertentu. Mengurangi bukti verifikasi biasanya lebih mahal dalam jangka panjang.

Deteksi perubahan berisiko: tidak semua PR perlu perlakuan sama

PR kecil yang mengubah teks UI tidak perlu melewati prosedur yang sama dengan PR yang mengubah autentikasi, migrasi database, atau aturan otorisasi. Karena itu, policy review perlu mengenali kategori risiko.

Contoh kategori perubahan berisiko tinggi

Perubahan pada modul login, session, otorisasi, token, atau permission.
Migrasi skema database, query kompleks, atau perubahan indeks.
Perubahan pada integrasi pembayaran, webhook, atau proses finansial.
Perubahan concurrency, queue worker, retry, locking, atau transaction boundary.
Perubahan dependency inti atau konfigurasi production.
Perubahan yang menyentuh data pribadi, audit log, atau kontrol keamanan.

Aturan tambahan untuk perubahan berisiko

Wajib ada test tambahan atau bukti verifikasi yang lebih kuat.
Minimal dua reviewer untuk area sensitif.
Wajib menjelaskan strategi rollback.
Wajib menyebut dampak kompatibilitas dan migrasi.
Bila perlu, wajib melampirkan rencana deploy bertahap atau feature flag.

Contoh policy repo untuk risk gate

Perubahan dianggap high-risk jika menyentuh salah satu area berikut:
- auth/, permissions/, billing/, migrations/, infra/
- file konfigurasi deployment
- dependency lockfile bersama perubahan dependency utama

Untuk high-risk PR:
1. CI standar wajib lulus.
2. Tambah bukti verifikasi spesifik area.
3. Minimal 2 approval reviewer.
4. Sertakan rollback plan.
5. Untuk bug kritis, sertakan langkah reproduksi dan bukti sesudah perbaikan.

Anda bisa mulai dengan aturan berbasis path karena mudah diterapkan. Ini memang kasar dan tidak sempurna, tetapi cukup berguna sebagai sinyal awal. Nanti, jika dibutuhkan, aturan bisa diperhalus dengan label otomatis atau analisis diff yang lebih spesifik.

Requirement reproduksi bug: syarat mutlak untuk bug fix

Salah satu cara terbaik menghindari debat generik adalah mewajibkan reproduksi bug. Tanpa itu, bug fix sering berubah menjadi tebak-tebakan: apakah masalah benar-benar ada, apakah fix benar, dan apakah ada regresi terselubung.

Yang sebaiknya diminta dalam PR bug fix

Langkah sebelum perbaikan untuk memicu bug.
Perilaku aktual yang salah.
Perilaku yang diharapkan.
Langkah sesudah perbaikan yang menunjukkan bug hilang.
Test otomatis bila bug layak ditulis sebagai test regresi.

Contoh format ringkas

Bug: endpoint mengembalikan 500 saat field `email` null.

Reproduksi sebelum fix:
1. Jalankan seed data tertentu.
2. Kirim request POST /users/sync dengan payload X.
3. Amati error null dereference pada service Y.

Perbaikan:
- validasi input null sebelum mapping.
- tambah test untuk payload tanpa email.

Verifikasi sesudah fix:
1. Jalankan test terkait.
2. Ulangi request yang sama.
3. Endpoint mengembalikan 400 dengan pesan validasi yang sesuai.

Kenapa ini penting untuk policy AI? Karena output AI sering tampak meyakinkan untuk bug fix, tetapi bisa saja hanya menutupi gejala, bukan akar masalah. Requirement reproduksi memaksa perubahan dibuktikan terhadap kasus nyata.

Aturan kapan output AI boleh dipakai

Larangan total biasanya tidak realistis dan sulit diawasi. Pendekatan yang lebih berguna adalah membolehkan dengan batasan. Tujuannya bukan memberi legitimasi khusus pada AI, tetapi memastikan penggunaannya tidak merusak standar engineering.

Output AI boleh dipakai jika

Pengusul memahami kode yang dihasilkan dan mampu menjelaskannya.
Output telah diverifikasi melalui CI, test, atau langkah manual yang relevan.
Tidak menyalin rahasia, data sensitif, atau konteks internal yang dilarang ke alat eksternal.
Tidak digunakan untuk menggantikan analisis desain pada perubahan berisiko tinggi.
Perubahan tidak disetujui hanya karena “AI merekomendasikan demikian”.

Output AI sebaiknya tidak dipakai langsung untuk

Query atau migrasi database yang tidak diuji pada skema nyata.
Perubahan keamanan seperti middleware auth, sanitasi input, atau aturan otorisasi tanpa review mendalam.
Perubahan concurrency, retry, transaction, atau locking tanpa validasi skenario gagal.
Konfigurasi infrastruktur atau deployment yang pengusul tidak pahami.

Contoh kebijakan ringkas penggunaan AI

AI-assisted code diperbolehkan sebagai alat bantu penulisan, refactor awal, atau eksplorasi.
Namun setiap kontribusi harus memenuhi aturan yang sama dengan kontribusi lain.
Pengusul bertanggung jawab untuk:
- meninjau dan memahami kode,
- menghapus saran yang salah atau tidak relevan,
- menjalankan verifikasi yang diwajibkan,
- tidak memasukkan data sensitif ke layanan pihak ketiga tanpa izin.

Klaim "dibantu AI" bukan alasan untuk merge.
Dugaan "terlihat seperti AI" juga bukan alasan untuk reject.

Kebijakan ini cukup netral. Ia mengakui realitas penggunaan alat bantu, tanpa mengubah standar mutu repository.

Metrik yang bisa diaudit, bukan kesan subjektif

Jika tim ingin tahu apakah policy berjalan, ukur hal yang bisa diperiksa kembali. Hindari metrik yang mendorong perilaku buruk, seperti hanya menghitung jumlah PR merged per minggu.

Metrik yang berguna

Pass rate CI per PR: seberapa sering PR lolos di percobaan pertama.
Waktu dari buka PR ke merge: untuk melihat bottleneck review.
Persentase bug fix dengan langkah reproduksi.
Persentase PR high-risk dengan rollback plan.
Jumlah regresi pasca-merge yang terlacak ke PR tertentu.
Distribusi alasan gagal CI: lint, test, type-check, build, atau verifikasi lain.
Persentase PR yang memerlukan revisi setelah review pertama.

Dengan metrik ini, tim bisa mengevaluasi apakah masalahnya ada pada kualitas perubahan, kualitas test, atau kekurangan policy. Misalnya, jika banyak PR lolos lint tetapi gagal production karena perubahan konfigurasi, berarti gate Anda belum cukup mencakup area itu.

Yang sebaiknya tidak dijadikan KPI utama

“Berapa banyak kode dibuat AI?”
“Berapa banyak reviewer menduga output AI?”
“Berapa cepat merge tanpa melihat tingkat regresi?”

Metrik tersebut mudah disalahartikan dan tidak membantu pengambilan keputusan teknis.

Contoh policy repo yang bisa langsung dipakai

# Repository Review Policy

## Prinsip umum
Semua perubahan dinilai berdasarkan bukti teknis yang dapat diverifikasi.
Alat yang digunakan untuk menulis kode, termasuk AI, tidak mengubah standar penerimaan PR.

## Syarat minimum merge
- CI wajib lulus.
- Deskripsi PR harus menjelaskan tujuan dan dampak perubahan.
- Bug fix wajib menyertakan langkah reproduksi sebelum/sesudah.
- Perubahan yang memengaruhi perilaku wajib memiliki test atau alasan tertulis mengapa test tidak ditambah.

## High-risk changes
Perubahan pada area auth, billing, migration, infra, atau data sensitif memerlukan:
- 2 approval reviewer,
- rollback plan,
- bukti verifikasi tambahan.

## Aturan penggunaan AI
- Boleh digunakan sebagai alat bantu.
- Pengusul tetap bertanggung jawab penuh atas correctness dan keamanan kode.
- PR tidak boleh diterima hanya karena "dibantu AI".
- PR tidak boleh ditolak hanya karena dugaan "hasil AI".
- Reviewer dapat meminta penjelasan teknis atas bagian yang tidak jelas.

## Enforcement
Branch protection mengharuskan seluruh check wajib lulus sebelum merge.

Policy seperti ini cukup singkat untuk dibaca, tetapi cukup operasional untuk diterapkan. Kunci utamanya adalah enforcement. Jika aturan hanya ada di dokumen tanpa branch protection atau kebiasaan review yang konsisten, hasilnya lemah.

Anti-pattern yang perlu dihindari

Menerima PR hanya karena “dibantu AI”

Ini anti-pattern paling jelas. Alat bantu tidak mengurangi kebutuhan akan test, review, dan pemahaman kode. Bahkan kadang justru meningkatkan kebutuhan review jika perubahan menyentuh area sensitif.

Menolak PR hanya karena gaya kodenya “terlihat seperti AI”

Ini sama buruknya. Yang relevan adalah apakah ada bug, risiko, atau kekurangan bukti. Menebak asal usul teks atau kode adalah dasar keputusan yang rapuh.

Checklist terlalu panjang dan tidak dijalankan

Checklist yang baik harus realistis. Jika setiap PR kecil diminta artefak yang terlalu banyak, engineer akan mengisinya asal-asalan. Bedakan syarat untuk low-risk dan high-risk change.

CI wajib, tetapi tidak relevan

Menjalankan lint tanpa test untuk codebase yang rawan regresi hampir tidak memberi perlindungan. Sebaliknya, test yang mahal tetapi tidak stabil juga akan membuat reviewer mengabaikan sinyal penting. Pilih gate yang benar-benar mewakili risiko utama sistem Anda.

Tidak ada aturan data sensitif saat memakai alat eksternal

Jika tim membolehkan AI, tambahkan kebijakan dasar tentang rahasia, token, data pelanggan, dan kode internal yang tidak boleh dikirim ke layanan eksternal tanpa izin. Ini aspek yang sering terlupakan ketika diskusi hanya fokus pada produktivitas.

Urutan implementasi untuk tim kecil-menengah

Jika tim Anda belum punya proses yang rapi, jangan mulai dari sistem yang terlalu kompleks. Terapkan bertahap.

Buat template PR dengan ringkasan, bukti verifikasi, risiko, dan reproduksi bug.
Aktifkan branch protection dan wajibkan status check minimum.
Tambahkan CI dasar: lint, test, type-check.
Definisikan high-risk area berbasis path atau komponen.
Terapkan aturan reviewer agar keputusan selalu mengacu ke bukti.
Tambahkan kebijakan penggunaan AI yang netral dan singkat.
Audit metrik bulanan untuk melihat bottleneck dan regresi.

Urutan ini efektif karena dimulai dari perubahan dengan biaya rendah tetapi dampak tinggi. Template PR dan branch protection biasanya memberi hasil paling cepat tanpa investasi tooling yang berat.

Penutup

Policy CI untuk review kode yang baik tidak perlu memusuhi AI, tetapi juga tidak boleh memberi status istimewa pada klaim AI. Standar merge harus tetap sama: bukti teknis, hasil verifikasi, analisis risiko, dan akuntabilitas pengusul. Dengan template PR yang tepat, checklist reviewer yang konsisten, serta gate CI yang relevan, tim bisa menghindari debat generik dan kembali fokus pada kualitas perubahan yang benar-benar bisa diuji.

Jika Anda hanya ingin mengambil satu prinsip dari artikel ini, ambil yang ini: alat boleh beragam, tetapi alasan menerima PR harus selalu dapat diaudit.

Quick Search

shopping_cart Keranjang