Skor Confidence Bukan Pagar Pengaman: Merancang Otonomi AI Agent

Ketika AI agent mulai bisa mengubah issue, menjalankan tool, dan mengusulkan perubahan kode, pertanyaan pentingnya bukan lagi “seberapa pintar modelnya?”, tetapi “apa yang tetap aman ketika modelnya salah?”

Pada 23 Juli 2026, GitHub memperkenalkan kontrol otomasi untuk agent di GitHub Issues. Agent dapat menyertakan alasan dan tingkat confidence pada tindakannya. Perubahan dengan confidence tinggi dapat diterapkan otomatis, sementara confidence menengah atau rendah dapat ditahan untuk direview.

Ini perkembangan yang menarik. Bukan karena agent akhirnya “tahu” kapan ia benar, tetapi karena produk mulai memberi kita cara untuk mengatur kadar otonomi.

Namun ada satu detail yang jauh lebih penting daripada label high, medium, atau low: GitHub menegaskan bahwa approval pada fitur tersebut adalah kemudahan workflow, bukan security control. Agent yang memiliki izin mengubah issue tetap dapat melakukan perubahan langsung jika workflow memerintahkannya demikian.

Di sinilah desain sistem perlu mengambil alih. Confidence boleh membantu menentukan prioritas review, tetapi tidak boleh menjadi satu-satunya pagar pengaman.

Confidence Mengukur Keyakinan, Bukan Dampak

Misalnya agent ingin menambahkan label pada issue. Jika salah, dampaknya mungkin hanya antrean triage yang sedikit berantakan. Bandingkan dengan agent yang hendak:

• menutup issue pelanggan,
• mengubah file konfigurasi deployment,
• menjalankan migrasi database,
• mengakses secret,
• atau melakukan tindakan ke sistem produksi.

Agent bisa memiliki confidence tinggi pada semua tindakan itu. Tetapi tingkat keyakinan model tidak menjawab pertanyaan yang paling penting: berapa besar kerugian jika keputusan tersebut salah?

Karena itu, saya lebih suka memisahkan dua sumbu:

Keputusan otomasi seharusnya mengikuti dampak terlebih dahulu. Confidence baru dipakai sebagai sinyal tambahan.

Tindakan berdampak rendah dan mudah dibatalkan bisa berjalan otomatis. Tindakan berdampak tinggi tetap membutuhkan batas teknis atau review manusia, meskipun agent menyatakan confidence tinggi.

Empat Level Otonomi yang Lebih Masuk Akal

Daripada memilih antara “manual” dan “full autonomous”, saya akan memulai dari empat level berikut.

Level 1: Baca dan Jelaskan

Agent boleh membaca issue, kode, log, atau hasil CI, lalu membuat ringkasan dan rekomendasi. Tidak ada perubahan state.

Contoh:

• mengelompokkan penyebab kegagalan test,
• merangkum issue duplikat,
• menjelaskan bagian codebase yang terkait bug,
• membuat draft rencana implementasi.

Ini cocok untuk workflow baru karena risiko operasionalnya rendah. Kualitas agent tetap perlu dinilai, tetapi kesalahan belum langsung mengubah sistem.

Level 2: Usulkan Perubahan

Agent menghasilkan patch, label, assignment, atau keputusan triage sebagai suggestion. Manusia memilih untuk menerima atau menolak.

Fitur approval pada GitHub Issues cocok untuk level ini. Rationale membantu reviewer memahami alasan perubahan tanpa harus menebak proses agent.

Level ini efektif ketika:

• aturan bisnis masih memiliki banyak pengecualian,
• data input berasal dari pengguna publik,
• konsekuensi salah lebih mahal daripada waktu review,
• atau tim masih mengumpulkan baseline kualitas.

Level 3: Terapkan Perubahan yang Mudah Dipulihkan

Agent boleh mengeksekusi tindakan tertentu secara otomatis, tetapi hanya pada area yang sudah dibatasi.

Contohnya:

• menambahkan label non-kritis,
• memperbarui dokumentasi melalui pull request,
• memformat kode,
• membuat draft release note,
• atau membuka issue tindak lanjut.

Kata kuncinya adalah reversible dan scoped. Agent tidak diberi token dengan izin luas hanya karena tugas hariannya sederhana.

Level 4: Eksekusi Berisiko Tinggi

Perubahan produksi, penghapusan data, rotasi secret, merge ke branch terlindungi, dan tindakan eksternal yang sulit dibatalkan masuk level ini.

Di sini, confidence tinggi tidak cukup. Sistem perlu menggunakan kontrol yang tidak bergantung pada interpretasi model: permission minimum, environment terisolasi, branch protection, policy engine, approval server-side, dan audit log.

Jika kontrol deterministik belum tersedia, tindakan sebaiknya tetap berhenti pada level usulan.

Prompt Menjelaskan Niat, Hook Menegakkan Batas

Instruksi seperti “jangan pernah membaca file .env” berguna untuk menyampaikan intent. Namun instruksi tetap diproses oleh model yang bisa salah memahami konteks, mengalami konflik instruksi, atau memilih tool yang tidak kita perkirakan.

Untuk larangan yang benar-benar harus berlaku, gunakan lapisan deterministik.

GitHub Copilot mendukung hooks pada titik tertentu dalam lifecycle agent. Hook preToolUse, misalnya, dapat mengizinkan, menolak, atau memodifikasi pemanggilan tool sebelum dijalankan. Dokumentasi GitHub menyebut penggunaan seperti mencegah kebocoran credential, membatasi akses file, melakukan sanitasi argumen, dan menerapkan approval khusus.

Pemisahannya sederhana:

• Prompt/instructions: menjelaskan cara kerja yang diinginkan.
• Hook/policy: menolak tindakan yang tidak boleh terjadi.
• Permission: memastikan agent memang tidak memiliki kemampuan di luar tugasnya.
• Sandbox: membatasi blast radius ketika kontrol lain gagal.

Keempatnya tidak saling menggantikan.

Pola Minimum untuk Workflow Agentic

GitHub Agentic Workflows, yang masuk public preview pada 11 Juni 2026, menunjukkan pola yang layak diperhatikan: akses read-only secara default, eksekusi di sandbox, dan write operation melalui safe outputs yang sudah disetujui. Ini bukan jaminan bahwa semua hasil agent benar, tetapi arsitekturnya mengurangi dampak kesalahan.

Untuk workflow agentic di platform apa pun, saya akan memulai dengan checklist berikut.

1. Default ke read-only

Mulai dengan hak baca. Tambahkan izin tulis per tindakan, bukan per agent secara luas.

2. Pisahkan analisis dari eksekusi

Agent pertama dapat menganalisis dan menghasilkan rencana terstruktur. Eksekusi dilakukan oleh tahap lain yang memvalidasi schema, target, dan permission.

3. Gunakan allowlist

Lebih aman mendefinisikan tindakan yang boleh dilakukan daripada mencoba memblokir seluruh tindakan berbahaya satu per satu.

Contoh: agent triage hanya boleh menambah label dari daftar tertentu. Ia tidak boleh membuat label baru, menutup issue, atau mengubah assignee kecuali kemampuan itu diberikan secara eksplisit.

4. Validasi input dan output

Konten issue, komentar, dokumentasi, dan halaman web adalah input yang tidak tepercaya. Output agent juga perlu dianggap tidak tepercaya sampai lolos validasi bentuk, target, dan policy.

5. Sediakan jalur pemulihan

Catat state sebelum perubahan, identitas agent, tool yang dipanggil, alasan tindakan, dan hasil akhirnya. Untuk tindakan otomatis, pastikan ada mekanisme undo atau rekonsiliasi.

6. Ukur error berdasarkan dampak

Jangan berhenti pada angka akurasi agregat. Salah memberi label dan salah menutup issue tidak punya biaya yang sama.

Metrik yang lebih berguna antara lain:

• persentase suggestion yang diterima reviewer,
• jumlah tindakan otomatis yang harus di-rollback,
• false positive pada tindakan berdampak tinggi,
• waktu review yang benar-benar dihemat,
• dan insiden yang lolos dari guardrail.

Cara Naik Level Tanpa Bertaruh Terlalu Besar

Otonomi sebaiknya menjadi hasil observasi, bukan keputusan sekali jadi.

Mulai dari mode suggestion. Kumpulkan keputusan agent dan reviewer selama periode tertentu. Kelompokkan berdasarkan jenis tindakan, bukan hanya berdasarkan agent atau model. Setelah terlihat bahwa satu kategori memiliki kualitas stabil dan dampak salahnya rendah, pindahkan kategori itu ke auto-apply.

Jika error meningkat, turunkan lagi levelnya.

Dengan pendekatan ini, confidence score berfungsi sebagai alat routing:

• confidence rendah → minta informasi tambahan atau hentikan,
• confidence menengah → antrekan review,
• confidence tinggi + dampak rendah → boleh otomatis,
• confidence tinggi + dampak tinggi → tetap melalui kontrol ketat.

Tidak ada aturan bahwa sistem harus terus bergerak menuju otonomi penuh. Untuk sebagian tindakan, level terbaik memang selalu “agent mengusulkan, manusia memutuskan.”

Penutup

AI agent membuat software engineering bergerak dari percakapan menuju tindakan. Itu berarti kualitas prompt saja tidak lagi cukup. Kita perlu mendesain permission, batas eksekusi, approval, observability, dan recovery sebagai bagian dari produk.

Confidence dan rationale adalah tambahan yang berguna karena membuat keputusan agent lebih mudah ditinjau. Tetapi keduanya adalah sinyal, bukan pagar.

Prinsip yang saya pegang sederhana:

Berikan otonomi berdasarkan dampak yang bisa ditanggung sistem, bukan berdasarkan seberapa meyakinkan agent menjelaskan dirinya.

Agent yang baik tetap bisa salah. Sistem engineering yang baik sudah mengantisipasi kesalahan itu sebelum agent menekan tombol.

Sumber dan Referensi

• GitHub, “Agent automation controls in GitHub Issues in public preview”, dipublikasikan 23 Juli 2026 (diperbarui 24 Juli 2026).
• GitHub, “GitHub Agentic Workflows is now in public preview”, dipublikasikan 11 Juni 2026.
• GitHub, “Introducing Copilot CLI and agentic capabilities enhancements in JetBrains IDEs”, dipublikasikan 2 Juni 2026.
• GitHub Docs, “About hooks for GitHub Copilot”, tanggal publikasi tidak dicantumkan; diakses 27 Juli 2026.
• GitHub Docs, “GitHub Copilot hooks reference”, tanggal publikasi tidak dicantumkan; diakses 27 Juli 2026.

Catatan Review

• Verifikasi kembali status preview/GA dan detail dukungan platform pada dokumentasi GitHub saat artikel akan diterbitkan karena informasi tersebut dapat berubah.
• Contoh arsitektur di artikel adalah rekomendasi engineering, bukan klaim bahwa pola tersebut sudah diterapkan pada project pribadi di repository ini.