Issue Tracker Mulai Jadi Control Plane AI Agent

Issue yang ambigu dulu cuma bikin developer salah paham. Sekarang, issue yang ambigu bisa bikin AI agent salah kerja, buka pull request yang nggak relevan, atau nutup task tanpa konteks yang cukup.

Artikel ini ngebahas kenapa issue tracker seperti GitHub Issues dan Linear mulai berubah dari tempat nyimpan tiket jadi control plane buat AI coding agent. Intinya: kalau agent mulai kerja dari issue, maka issue description adalah prompt kerja yang harus jelas, terukur, dan bisa diverifikasi. Buat developer dan tim kecil, skill baru yang makin penting bukan cuma “prompting”, tapi menulis task yang bisa dikerjakan manusia dan AI tanpa bikin noise baru.

Apa maksudnya issue tracker jadi control plane AI agent?

Control plane adalah lapisan yang mengatur apa yang boleh jalan, kapan jalan, siapa yang review, dan bukti apa yang harus ditinggalkan. Dalam konteks software development, issue tracker mulai jadi tempat AI agent menerima instruksi, menjalankan workflow, update status, lalu mengirim hasil kerja balik ke manusia.

GitHub baru merilis beberapa sinyal yang arahnya cukup jelas. Copilot cloud agent for Linear sudah generally available: issue di Linear bisa di-assign ke Copilot, lalu Copilot menganalisis isi issue, membuka draft pull request, bekerja di ephemeral development environment berbasis GitHub Actions, stream progress balik ke timeline Linear, dan meminta review saat kerja selesai.

Di sisi GitHub Issues, agent automation controls mulai masuk public preview. Automation bisa memberi label, type, assign, atau close issue dengan alasan yang tercatat. Ada approval mode, confidence level, dan rationale supaya perubahan yang dilakukan agent bisa ditahan untuk review, bukan langsung dipercaya mentah.

GitHub Mobile juga mulai memberi tombol untuk meminta Copilot coding agent menyelidiki failed Actions check dan membuka PR perbaikan di atas PR yang gagal. Ini kecil kelihatannya, tapi secara workflow artinya agent makin sering bekerja dari sinyal yang ada di sistem kerja tim, bukan dari chat kosong.

Masalahnya: issue jelek akan jadi prompt jelek

Selama ini banyak tim menulis issue dengan gaya “fix login bug”, “UI broken”, atau “tolong rapihin dashboard”. Buat manusia yang sudah tahu konteks, mungkin masih bisa ditebak. Buat AI agent, ini rawan banget.

AI agent nggak baca pikiran. Dia membaca teks, file, logs, komentar, diff, dan instruksi yang tersedia. Kalau issue terlalu kabur, agent akan mengisi celah pakai asumsi. Kadang asumsi itu benar. Kadang dia bikin perubahan terlalu luas, memperbaiki gejala yang salah, atau menambahkan abstraction baru yang sebenarnya nggak diminta.

Menurut gua, ini salah satu bentuk prompt engineering yang lebih realistis buat developer: bukan bikin prompt panjang penuh trik, tapi bikin issue yang rapi. Karena issue yang rapi bukan cuma membantu AI. Dia juga membantu junior developer, reviewer, maintainer open source, dan diri lu sendiri dua minggu setelah lupa konteks.

Template issue yang lebih ramah buat AI agent

Kalau lu mulai memakai AI coding agent di GitHub, Linear, Cursor, Claude Code, atau workflow internal, coba bikin issue dengan struktur seperti ini:

  • Context: jelaskan problem bisnis atau teknis dalam 2–4 kalimat.
  • Current behavior: apa yang terjadi sekarang, termasuk error message atau screenshot kalau ada.
  • Expected behavior: hasil yang lu mau, ditulis spesifik.
  • Scope: file, area, route, endpoint, component, atau modul yang kemungkinan relevan.
  • Non-goals: hal yang jangan disentuh supaya agent nggak terlalu rajin.
  • Acceptance criteria: checklist selesai yang bisa diverifikasi manusia.
  • Test command: command minimal buat memastikan perubahan nggak merusak flow penting.
  • Review note: area risiko yang wajib dicek reviewer sebelum merge.

Contoh issue yang kurang aman:

Fix checkout bug. Kadang total price salah.

Contoh yang lebih bisa dikerjakan:

Context:
User melihat total checkout berbeda antara cart page dan payment page saat memakai voucher percentage.

Current behavior:
Cart page menghitung diskon sebelum tax, payment page menghitung diskon setelah tax.

Expected behavior:
Voucher percentage harus dihitung sebelum tax di dua halaman.

Scope:
Cek modul pricing, cart summary component, dan payment summary component.

Non-goals:
Jangan ubah rule fixed-amount voucher. Jangan redesign UI checkout.

Acceptance criteria:
- Cart page dan payment page menampilkan total yang sama untuk voucher percentage.
- Existing fixed voucher test tetap pass.
- Tambahkan test untuk voucher percentage + tax.

Test command:
npm test -- pricing
npm run build

Bedanya besar. Issue kedua memberi agent pagar kerja. Kalau agent tetap keluar jalur, reviewer juga lebih gampang melihat penyimpangannya.

Approval, confidence, dan rationale itu bukan birokrasi

Banyak developer alergi sama approval karena terdengar memperlambat. Tapi buat AI agent, approval bukan sekadar birokrasi. Itu cara menjaga batas antara automation dan autopilot.

GitHub Issues mulai menampilkan rationale: alasan kenapa agent memberi label, assign, type, atau close issue. Ini penting karena perubahan metadata terlihat kecil, tapi dampaknya bisa besar. Issue yang salah ditutup bisa bikin bug hilang dari radar. Label yang salah bisa mengubah prioritas. Assignment yang salah bisa bikin ownership kabur.

Confidence level juga masuk akal. High-confidence action mungkin boleh otomatis. Medium dan low sebaiknya jadi suggestion. Ini mirip cara gua mikir soal AI coding: biarkan agent mengerjakan hal yang bisa diverifikasi murah, tapi tahan hal yang punya blast radius besar.

Checklist sebelum lu kasih issue ke AI agent

Sebelum assign task ke AI agent, pakai checklist singkat ini:

  1. Problem-nya spesifik? Hindari task seperti “rapihin”, “improve”, atau “fix bug” tanpa konteks.
  2. Definition of done jelas? Agent harus tahu kapan harus berhenti.
  3. Non-goals ditulis? Ini penting supaya agent nggak refactor separuh repo.
  4. Test command ada? Minimal ada satu command yang bisa dijalankan agent atau reviewer.
  5. Risiko disebutkan? Misalnya area payment, auth, database migration, atau permission.
  6. Hasilnya reviewable? Output idealnya PR, diff, log, atau draft; bukan perubahan diam-diam.

Kalau enam poin ini belum ada, kemungkinan besar masalahnya bukan di model. Masalahnya di task framing.

Kenapa ini penting buat developer kecil dan indie builder?

Tim kecil sering nggak punya project manager, QA dedicated, atau proses formal. Justru karena itu, issue yang rapi bisa jadi leverage besar. Lu bisa menulis satu task yang jelas, lalu AI agent bantu bikin draft PR, sementara lu tetap pegang judgment terakhir.

Ini juga relevan buat personal branding developer. Kalau lu sering build in public, issue yang rapi bisa jadi bukti cara kerja. Orang nggak cuma lihat hasil akhir, tapi juga lihat cara lu memecah problem, menulis acceptance criteria, dan menjaga quality bar.

Buat gua, AI agent paling berguna saat dia masuk ke workflow yang sudah punya struktur. Kalau workflow-nya masih berantakan, agent cuma mempercepat berantakannya. Tapi kalau issue, test, review, dan ownership lu jelas, agent bisa jadi multiplier yang lumayan waras.

Takeaway praktis

  • Issue tracker mulai jadi tempat AI agent menerima instruksi kerja, bukan cuma tempat nyimpan tiket.
  • Issue description adalah prompt kerja. Semakin ambigu issue lu, semakin besar ruang agent buat menebak.
  • Acceptance criteria, non-goals, dan test command lebih berguna daripada prompt panjang yang terdengar pintar.
  • Approval, confidence, dan rationale membantu tim membedakan automation yang aman dari autopilot yang berisiko.
  • Skill menulis issue yang jelas akan makin mahal di era AI coding agent.

FAQ singkat

Apakah AI agent bisa menggantikan developer kalau issue sudah jelas?

Nggak. Issue yang jelas cuma membuat kerja agent lebih terarah. Developer tetap perlu review, testing, product judgment, dan ownership atas hasil akhirnya.

Apakah semua issue harus super detail?

Nggak juga. Task kecil bisa tetap singkat. Tapi kalau task menyentuh auth, payment, data user, dependency, atau refactor besar, detail itu bukan hiasan. Itu guardrail.

Apa bedanya issue template dengan prompt engineering?

Issue template lebih tahan lama. Prompt sekali pakai bisa hilang di chat. Issue yang rapi jadi artefak kerja: bisa dibaca tim, reviewer, agent, dan diri lu di masa depan.

Kalau tim belum pakai AI agent, tetap perlu issue serapi ini?

Tetap berguna. Issue yang jelas bikin handoff lebih murah, review lebih cepat, dan scope lebih aman. AI cuma membuat manfaatnya makin kelihatan.

Penutup

AI agent yang masuk ke Linear, GitHub Issues, dan GitHub Mobile bukan berarti developer tinggal duduk nunggu PR jadi. Justru sebaliknya: cara lu menulis task, membatasi scope, dan meminta bukti jadi makin penting.

Kalau lu mau mulai sederhana, jangan langsung bikin automation kompleks. Ambil satu issue minggu ini, tulis context, expected behavior, non-goals, acceptance criteria, dan test command. Lihat apakah manusia dan agent sama-sama lebih gampang memahami task itu.

Follow rafli.dev kalau lu mau insight tech yang jujur, praktis, dan nggak cuma ikut hype.

Referensi / Bacaan Lanjut

Tags:
#AI#Developer Tools#Software Engineering#GitHub Copilot#Developer Productivity