Policy AI di CI yang efektif tidak dimulai dari larangan memakai AI, tetapi dari pemisahan yang jelas antara bantuan cepat dan kode siap rilis. Jika perubahan yang dibantu AI tetap harus melewati ownership, linting, test gate, secret scanning, diff review, dan approval yang konsisten, maka risiko utamanya dapat dikendalikan.

Diskusi yang sering muncul adalah seolah masalahnya berada pada manual vs AI. Padahal, seperti yang sering terlihat di tim nyata, kode buruk bisa lolos baik ditulis tangan maupun dibantu AI jika review lemah, CI longgar, dan aturan merge tidak tegas. Karena itu, fokus terbaik untuk tim engineering adalah membangun guardrail di workflow tooling dan CI/CD, bukan berdebat abstrak soal moralitas alat.

Mengapa fokusnya harus di proses review, bukan asal kode

AI mempercepat pembuatan draft: test awal, query sederhana, refactor mekanis, dokumentasi, bahkan boilerplate. Masalah muncul ketika draft itu diperlakukan seperti hasil final tanpa verifikasi tambahan. Risiko yang umum bukan hanya bug logika, tetapi juga:

  • dependency atau API dipakai secara salah,
  • edge case tidak tertangani,
  • secret atau token ikut terdorong ke repo,
  • perubahan terlalu besar sehingga sulit direview,
  • tidak ada owner domain yang benar-benar memahami implikasi perubahan.

Dengan kata lain, AI tidak otomatis menurunkan kualitas rilis; proses merge yang lemah lah yang melakukannya. Karena itu policy yang berguna harus menjawab pertanyaan berikut:

  • Perubahan seperti apa yang boleh dibantu AI?
  • Kapan perubahan harus ditandai secara eksplisit?
  • Gate apa saja yang wajib lolos sebelum merge?
  • Siapa pemilik teknis yang bertanggung jawab?
  • Bagaimana reviewer membedakan draft cepat dari kode yang benar-benar siap rilis?

Definisikan level penggunaan AI yang mudah diterapkan

Jangan mulai dari policy yang terlalu rumit. Untuk tim kecil, tiga level biasanya cukup. Tujuannya bukan menghukum, tetapi memberi konteks review yang tepat.

Level 0: Tanpa bantuan AI

Perubahan ditulis dan diuji sepenuhnya oleh engineer tanpa bantuan generatif. Level ini tidak perlu perlakuan khusus, tetapi tetap mengikuti quality gate standar.

Level 1: AI sebagai bantuan cepat

AI dipakai untuk mempercepat pekerjaan yang sifatnya mekanis atau berisiko rendah, misalnya:

  • menulis ulang test case,
  • refactor penamaan,
  • membuat regex atau query sederhana yang kemudian diverifikasi,
  • menulis draft dokumentasi,
  • membuat boilerplate endpoint atau komponen dasar.

Pada level ini, penulis PR tetap dianggap memahami perubahan dan harus dapat menjelaskan alasan, asumsi, dan batasannya.

Level 2: AI menghasilkan bagian kode inti

AI digunakan untuk menghasilkan logika aplikasi yang substansial, seperti alur bisnis, integrasi data, perubahan schema, autentikasi, otorisasi, atau perubahan di area sensitif. Level ini tidak harus dilarang, tetapi perlu guardrail tambahan:

  • review oleh owner domain,
  • cakupan test yang memadai,
  • diff lebih kecil dan terpecah bila memungkinkan,
  • penjelasan PR yang lebih rinci,
  • approval minimal dari reviewer yang relevan.

Prinsip praktis: level penggunaan AI tidak menentukan boleh atau tidaknya merge. Level hanya menentukan kedalaman review dan gate yang harus dilewati.

Contoh policy sederhana yang bisa langsung dipakai

Berikut contoh policy ringkas yang realistis untuk tim kecil hingga menengah. Isinya sengaja fokus pada workflow, bukan debat etika umum.

AI Usage Policy for Code Changes

1. Setiap PR harus memilih salah satu label:
   - ai:none
   - ai:assisted
   - ai:generated

2. AI boleh digunakan untuk drafting, refactor mekanis, test awal, dan dokumentasi.

3. Untuk PR dengan label ai:generated:
   - wajib ada penjelasan area yang dihasilkan AI,
   - wajib ada test yang relevan untuk perubahan perilaku,
   - wajib direview oleh code owner atau reviewer domain,
   - tidak boleh merge jika ada check CI yang gagal,
   - tidak boleh squash-merge tanpa deskripsi PR yang memadai.

4. Semua PR, terlepas dari sumbernya, wajib lolos:
   - format/lint,
   - unit/integration test yang relevan,
   - secret scanning,
   - dependency/security checks jika tersedia,
   - review manusia sebelum merge.

5. Penulis PR tetap bertanggung jawab penuh atas kode,
   termasuk bagian yang diusulkan atau ditulis AI.

6. Perubahan besar harus dipecah.
   Jika diff terlalu besar untuk direview efektif, reviewer boleh meminta split PR.

Policy ini bekerja karena tidak mencoba menebak niat penulis. Ia hanya memastikan bahwa perubahan yang lebih berisiko mendapat pengawasan lebih ketat.

Checklist PR untuk membedakan draft cepat dan kode siap rilis

Checklist PR sebaiknya singkat, tetapi memaksa penulis memverifikasi hal penting. Jika terlalu panjang, orang hanya akan mencentang tanpa berpikir.

Checklist minimum untuk semua PR

  • Saya memahami perubahan yang saya kirim dan dapat menjelaskannya.
  • Lint/format sudah lolos.
  • Test yang relevan sudah ditambah atau diperbarui.
  • Tidak ada secret, token, credential, atau data sensitif di diff.
  • Deskripsi PR menjelaskan apa yang berubah dan mengapa.

Tambahan untuk PR berlabel ai:generated

  • Saya sudah membaca ulang seluruh diff, bukan hanya bagian yang saya edit manual.
  • Saya sudah memverifikasi asumsi API, query, atau dependency yang dipakai.
  • Saya sudah menghapus kode berlebih, duplikasi, atau fallback yang tidak diperlukan.
  • Saya sudah menguji jalur gagal dan edge case utama.
  • Saya sudah meminta review dari owner area jika perubahan menyentuh domain penting.

Checklist ini penting karena kesalahan khas dari kode yang dibantu AI sering berada di area “terlihat masuk akal” tetapi salah di detail.

Label commit dan PR: sederhana, konsisten, dapat diautomasi

Label tidak akan berguna jika hanya jadi dekorasi. Gunakan label yang bisa dipakai untuk routing review dan aturan CI.

Label PR yang disarankan

  • ai:none: tidak ada bantuan generatif.
  • ai:assisted: AI membantu sebagian kecil atau drafting non-kritis.
  • ai:generated: bagian substansial kode dihasilkan AI.
  • risk:low, risk:medium, risk:high: tingkat risiko perubahan.
  • area:backend, area:frontend, area:infra, dan sejenisnya.

Apakah perlu label di commit?

Untuk kebanyakan tim, label PR sudah cukup. Menaruh penanda di setiap commit sering menambah beban tanpa banyak nilai. Jika tetap ingin ada jejak tambahan, gunakan template PR atau trailer di commit message secara opsional, misalnya:

feat(auth): tighten session validation

AI-Usage: assisted
Risk: medium

Jangan jadikan metadata ini sebagai satu-satunya mekanisme kontrol. Metadata mudah dipalsukan atau terlupa. Gate utama harus tetap berada di CI dan review.

Ownership: siapa yang bertanggung jawab atas kode hasil AI

Salah satu anti-pattern terbesar adalah menganggap “AI yang menulisnya”, sehingga penulis PR merasa tidak perlu memahami detail implementasi. Dalam tim yang sehat, aturan ownership harus jelas:

  • Author owns the change: penulis PR bertanggung jawab atas seluruh diff.
  • Domain owner approves the risk: reviewer domain bertanggung jawab menilai apakah perubahan layak masuk ke area yang ia jaga.
  • CI validates the baseline: tooling memastikan standar minimum selalu diterapkan secara konsisten.

Jika area penting menggunakan CODEOWNERS, manfaatkan itu untuk memaksa review yang relevan.

# .github/CODEOWNERS

/src/auth/    @team-security @backend-lead
/infra/       @platform-team
/src/billing/ @team-payments

Dengan cara ini, PR yang menyentuh area sensitif tidak bisa lolos hanya karena ada satu approval generik dari reviewer yang tidak memahami domainnya.

Guardrail CI/CD yang wajib ada

Inilah inti dari Policy AI di CI: bukan mendeteksi “bau AI”, tetapi memastikan setiap perubahan melewati pemeriksaan yang relevan. Pilih gate yang konsisten dan murah dijalankan.

1. Linting dan formatting

AI sering menghasilkan kode yang valid secara sintaks, tetapi tidak konsisten dengan style dan konvensi repo. Linting menjaga baseline kualitas dan membuat reviewer fokus ke logika, bukan whitespace atau pola yang dilarang.

2. Test gate

Minimal ada unit test untuk logika lokal dan integration test untuk perubahan perilaku penting. Untuk tim kecil, lebih baik punya sedikit test yang benar-benar relevan daripada banyak test lemah yang tidak melindungi apa-apa.

3. Secret scanning

Ini wajib. Salah satu kegagalan paling mahal dari workflow AI adalah token, URL internal, file konfigurasi sensitif, atau contoh credential ikut masuk ke diff.

4. Security/dependency checks

Jika pipeline Anda sudah punya dependency audit atau SAST dasar, pertahankan. AI bisa saja menyarankan library yang tidak dibutuhkan atau pola implementasi yang rentan.

5. Diff review heuristics

CI tidak harus “menentukan apakah ini ditulis AI”, tetapi bisa menandai PR yang berisiko direview buruk, misalnya:

  • diff terlalu besar,
  • terlalu banyak file berubah,
  • menyentuh area sensitif tanpa label risiko,
  • label AI tidak dipilih,
  • tidak ada test untuk file produksi yang berubah.

6. Approval sebelum merge

Jangan izinkan merge langsung ke branch utama untuk perubahan biasa. Untuk PR berisiko tinggi atau ai:generated, mintalah approval dari code owner atau reviewer senior.

Contoh GitHub Actions untuk checks dasar

Contoh berikut menunjukkan pipeline yang praktis: validasi label AI, jalankan lint dan test, serta secret scan. Sesuaikan command dengan stack Anda.

name: pr-checks

on:
  pull_request:
    types: [opened, synchronize, reopened, labeled, unlabeled]

jobs:
  validate-labels:
    runs-on: ubuntu-latest
    steps:
      - name: Ensure AI label exists
        uses: actions/github-script@v7
        with:
          script: |
            const labels = context.payload.pull_request.labels.map(l => l.name)
            const allowed = ['ai:none', 'ai:assisted', 'ai:generated']
            const found = labels.filter(l => allowed.includes(l))
            if (found.length !== 1) {
              core.setFailed('PR must have exactly one AI label: ai:none, ai:assisted, or ai:generated')
            }

  lint-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Setup runtime
        run: echo "Install project runtime here"
      - name: Install dependencies
        run: echo "Install dependencies here"
      - name: Lint
        run: echo "Run linter here"
      - name: Test
        run: echo "Run tests here"

  secret-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - name: Secret scan
        run: |
          echo "Run secret scanner here"

Contoh di atas sengaja generik agar tidak mengarang command spesifik untuk stack tertentu. Ide utamanya adalah:

  • label AI wajib ada,
  • lint dan test selalu jalan,
  • secret scan selalu jalan,
  • semua status check bisa dijadikan syarat branch protection.

Contoh rule tambahan: PR berlabel ai:generated harus punya approval tertentu

Aturan ini biasanya lebih mudah ditegakkan lewat kombinasi CODEOWNERS dan branch protection daripada menulis logika custom yang rumit. Misalnya:

  • area sensitif wajib code owner review,
  • branch utama butuh minimal satu atau dua approval,
  • dismiss stale approvals ketika diff berubah,
  • wajib resolve conversation sebelum merge.

Pendekatan ini lebih stabil daripada mencoba membangun “detektor kualitas AI” yang rapuh.

Checklist review diff yang efektif untuk reviewer

Reviewer sering kewalahan ketika AI membuat banyak kode sangat cepat. Kuncinya bukan membaca semua karakter dengan tingkat perhatian yang sama, tetapi memeriksa titik risiko yang tepat.

Apa yang harus diperiksa reviewer

  • Benarkah perubahan ini perlu? AI cenderung menambah abstraksi atau helper yang tidak perlu.
  • Apakah perilaku berubah? Jika iya, mana test yang membuktikannya?
  • Apakah ada kode yang terdengar benar tetapi tidak sesuai domain? Misalnya validasi bisnis yang terlalu generik.
  • Apakah dependency baru benar-benar dibutuhkan?
  • Apakah fallback, logging, dan error handling masuk akal?
  • Apakah ada copy-paste pattern yang memperbanyak bug tersembunyi?

Debugging tip saat curiga diff hasil AI salah

  • Jalankan test pada jalur gagal, bukan hanya jalur sukses.
  • Periksa nilai default, null handling, timeout, dan retry.
  • Bandingkan implementasi baru dengan pola lama yang sudah stabil di repo.
  • Cek apakah nama fungsi atau komentar menjanjikan perilaku yang tidak benar-benar terjadi.
  • Lihat apakah PR mengubah terlalu banyak hal sekaligus sehingga bug tersembunyi sulit ditemukan.

Anti-pattern yang sering merusak kualitas rilis

1. Mengira disclosure saja sudah cukup

Menulis “dibantu AI” di PR tidak otomatis membuat perubahan aman. Tanpa test, review, dan ownership, disclosure hanya menjadi catatan administratif.

2. PR terlalu besar karena AI mempercepat produksi diff

Semakin besar diff, semakin kecil peluang review yang teliti. Pecah perubahan menjadi beberapa PR kecil jika memungkinkan: refactor, test, dan perubahan perilaku sebaiknya dipisah.

3. Reviewer hanya memeriksa apakah build hijau

Build hijau berarti baseline lolos, bukan berarti logika sudah benar. Ini kesalahan umum pada tim yang terlalu mengandalkan CI tanpa review domain.

4. Menyamakan semua penggunaan AI

AI untuk menulis test scaffold jelas berbeda risikonya dengan AI yang menulis logika billing atau auth. Policy yang terlalu kasar biasanya diabaikan.

5. Tidak ada owner yang jelas

Jika semua orang boleh merge semua area tanpa review domain, maka asal penulis kode tidak lagi penting; prosesnya memang sudah lemah sejak awal.

6. Mencoba membangun deteksi AI yang terlalu agresif

Fokus pada hasil dan guardrail, bukan forensik gaya penulisan. Sistem yang mencoba “menangkap” AI dari pola kalimat atau struktur kode mudah salah dan menciptakan gesekan yang tidak perlu.

Rollout bertahap untuk tim kecil

Tim kecil sering tidak punya waktu membangun policy lengkap sekaligus. Mulailah dari guardrail yang dampaknya paling besar dan biaya operasionalnya rendah.

Tahap 1: Tambah visibilitas

  • Buat tiga label: ai:none, ai:assisted, ai:generated.
  • Tambahkan checklist PR singkat.
  • Tetapkan bahwa penulis PR tetap owner penuh atas perubahan.

Tahap 2: Kencangkan branch protection

  • Wajibkan lint dan test sebelum merge.
  • Wajibkan minimal satu approval.
  • Wajibkan resolve semua conversation.

Tahap 3: Tambah guardrail keamanan

  • Aktifkan secret scanning.
  • Tambahkan dependency/security checks yang sudah tersedia di tool Anda.
  • Gunakan CODEOWNERS untuk area sensitif.

Tahap 4: Terapkan aturan berbasis risiko

  • PR berlabel ai:generated wajib code owner review.
  • PR besar diminta dipecah.
  • Perubahan tanpa test pada area kritis tidak boleh merge.

Tahap 5: Evaluasi dari data review, bukan asumsi

Setelah beberapa minggu, lihat sinyal yang nyata:

  • berapa banyak PR gagal di secret scan,
  • berapa sering reviewer meminta split PR,
  • berapa banyak bug pasca-merge berasal dari perubahan yang tidak punya test memadai,
  • apakah label AI membantu routing review atau justru tidak dipakai dengan jujur.

Dari sini, Anda bisa menyesuaikan policy tanpa membuat proses terlalu berat.

Contoh template PR yang praktis

## Summary
Jelaskan perubahan dan alasan bisnis/teknisnya.

## AI Usage
- [ ] ai:none
- [ ] ai:assisted
- [ ] ai:generated

## Risk
- [ ] low
- [ ] medium
- [ ] high

## Validation
- [ ] Lint passes
- [ ] Tests added/updated where needed
- [ ] No secrets or sensitive data in diff
- [ ] I reviewed the full diff
- [ ] I can explain the logic and trade-offs

## Notes for Reviewers
Area yang perlu perhatian khusus, asumsi penting, atau batasan yang diketahui.

Template seperti ini membantu reviewer memahami konteks tanpa memaksa penulis menulis esai panjang.

Kapan policy perlu diperketat

Tidak semua tim butuh kontrol yang sama. Anda perlu memperketat policy jika:

  • repo menyimpan banyak integrasi sensitif,
  • tim sering mengerjakan auth, billing, permission, atau infra produksi,
  • incident pasca-merge sering disebabkan review dangkal,
  • PR cenderung besar dan sulit ditelaah,
  • rotasi engineer tinggi sehingga pemahaman domain tersebar tipis.

Dalam kondisi seperti ini, perketatan yang paling berguna biasanya bukan larangan AI, melainkan review domain yang lebih ketat, branch protection, dan test gate yang lebih tegas.

Penutup

Policy AI di CI yang sehat tidak mencoba membuktikan apakah kode “cukup manusia”. Ia memastikan bahwa kode yang masuk ke branch utama telah melewati proses yang membuatnya layak rilis. Bedakan AI sebagai alat bantu cepat dari kode siap produksi melalui label, checklist, ownership, dan gate CI yang jelas.

Jika tim Anda harus memilih prioritas, mulailah dari hal yang paling berdampak: wajibkan label PR, aktifkan lint dan test gate, tambahkan secret scanning, gunakan code owner untuk area sensitif, dan pastikan tidak ada merge tanpa review manusia. Dengan guardrail seperti itu, AI bisa meningkatkan kecepatan tanpa mengorbankan kualitas rilis.