AI coding agent yang kerja 20 menit, ngubah banyak file, lalu cuma ninggalin chat history itu bukan workflow yang aman. Itu mirip nyuruh orang masuk production, lalu bukti kerjanya cuma “tadi udah gua beresin”.
Artikel ini membahas kenapa AI coding agent butuh observability: trace, logs, metrics, audit trail, dan aturan retensi data. Intinya sederhana: kalau agent bisa membaca repo, menjalankan command, membuka tool, atau mengubah file, lu perlu cara buat melihat apa yang terjadi tanpa bergantung pada ringkasan akhir dari agent itu sendiri. GitHub mulai bergerak ke arah ini lewat enterprise-managed OpenTelemetry export untuk VS Code dan Copilot CLI, sementara Tailscale juga mendorong pola audit akses agent lewat Aperture.
Kenapa chat history bukan audit trail?
Chat history itu catatan percakapan. Audit trail itu catatan kejadian yang bisa dipakai buat investigasi.
Bedanya besar. Chat history biasanya berisi prompt, jawaban, dan ringkasan keputusan. Tapi saat agent bekerja di repo nyata, yang penting bukan cuma “dia bilang apa”. Yang penting juga:
- file apa yang dibaca, dibuat, dan diubah;
- command apa yang dijalankan;
- tool eksternal apa yang dipanggil;
- error apa yang muncul lalu diabaikan;
- berapa lama agent muter di task yang sama;
- apakah ada data sensitif yang ikut masuk log.
Kalau lu cuma punya chat history, banyak detail operasional bisa hilang. Apalagi kalau agent merangkum prosesnya sendiri. Ringkasan bisa berguna buat baca cepat, tapi ringkasan bukan bukti lengkap.
Apa itu observability untuk AI coding agent?
Observability adalah kemampuan melihat kondisi sistem dari sinyal yang dia keluarkan. Di software production, sinyal klasiknya adalah logs, metrics, dan traces. Untuk AI coding agent, konsepnya mirip, tapi objek yang diamati bukan cuma server. Yang diamati adalah sesi kerja agent.
Versi praktisnya begini:
- Logs: catatan event penting, misalnya agent menjalankan test, membaca file konfigurasi, atau gagal akses tool.
- Traces: urutan langkah agent dari satu task sampai selesai, termasuk tool call, command, dan subtask.
- Metrics: angka agregat seperti durasi task, jumlah tool call, token/cost, retry, error rate, atau task success rate.
- Audit trail: catatan yang cukup rapi buat menjawab “siapa/apa melakukan apa, kapan, dan dengan izin apa”.
GitHub Changelog 8 Juli 2026 menarik karena mereka merilis enterprise-managed OpenTelemetry export untuk VS Code dan CLI. Admin enterprise bisa mengatur endpoint collector, protocol, service name, headers, resource attributes, dan sinyal seperti traces, metrics, serta logs. Konfigurasinya berlaku untuk GitHub Copilot Chat extension di VS Code dan agent host process yang menjalankan Copilot CLI.
Ini sinyal penting. AI coding tool mulai diperlakukan seperti software kerja serius, bukan sekadar chatbot yang kebetulan bisa bantu nulis kode.
Kenapa OpenTelemetry relevan di sini?
OpenTelemetry adalah standar open-source untuk mengumpulkan telemetry seperti traces, metrics, dan logs. Banyak tim engineering sudah punya collector, dashboard, alerting, dan pipeline observability berbasis OpenTelemetry atau tooling yang kompatibel.
Kalau AI coding agent bisa mengirim telemetry ke jalur yang sama, tim nggak perlu bikin pulau data baru cuma buat AI. Sesi agent bisa masuk ke sistem observability yang sudah punya kontrol akses, retensi, dan proses investigasi.
Ini bukan berarti semua data agent harus direkam mentah-mentah. Justru sebaliknya: begitu agent masuk workflow kerja, tim harus mikir data apa yang boleh dicatat, data apa yang harus disamarkan, dan siapa yang boleh membaca log itu.
Masalah nyata: agent makin bisa bertindak
Dulu AI coding tool banyak berhenti di saran kode. Sekarang agent bisa membuka file, menjalankan test, menulis patch, memanggil tool, bahkan bekerja cukup lama tanpa interaksi terus-menerus.
GitHub juga sudah punya Copilot agent session streaming, yang arahnya membuat progress agent lebih terlihat saat agent sedang bekerja. Buat developer solo, ini membantu supaya lu nggak cuma nunggu hasil akhir. Buat tim, ini bagian dari pola yang lebih besar: agent harus bisa dipantau saat bekerja, bukan cuma dinilai setelah merge request muncul.
Di sisi akses infrastruktur, Tailscale menulis tentang Aperture untuk audit request, logs, dan akses AI agent. Angle-nya sama: saat agent mulai menyentuh sistem internal, prompt saja bukan guardrail yang cukup. Lu butuh identity, permission boundary, dan log yang bisa diperiksa.
Observability bukan pengganti security boundary
Ini bagian yang sering kebalik. Banyak orang melihat log lalu merasa sistemnya aman. Padahal log membantu lu tahu apa yang terjadi. Log tidak otomatis mencegah kejadian buruk.
Kalau agent punya akses terlalu luas, telemetry cuma membuat lu bisa melihat kekacauan dengan lebih jelas. Guardrail tetap perlu dipasang di tempat yang benar:
- batasi folder dan file yang boleh dibaca agent;
- pisahkan token read-only dan token write;
- pakai sandbox untuk command berisiko;
- jangan kasih secret production ke environment agent;
- wajibkan review manusia untuk perubahan sensitif;
- pastikan akses bisa dicabut cepat saat incident.
Observability bekerja paling bagus saat digabung dengan permission yang sempit. Kalau izin agent sudah rapi, log membantu menjawab pertanyaan lanjutan: agent sudah pakai izin itu buat apa?
Checklist observability AI coding agent
Kalau lu mulai pakai AI agent buat kerja repo serius, ini checklist minimal yang menurut gua layak dipikirkan:
1. Catat perubahan file secara eksplisit
Jangan cuma simpan jawaban agent. Simpan diff, file path, jumlah file berubah, dan alasan perubahan. Kalau agent mengubah konfigurasi, dependency, auth, CI, atau database migration, beri label lebih jelas.
2. Simpan command dan hasil penting
Command seperti test, lint, build, migration, dan package install harus tercatat. Yang dicatat bukan cuma “berhasil” atau “gagal”, tapi juga error utama dan exit code. Ini membantu review cepat tanpa membaca ribuan baris log mentah.
3. Bedakan prompt, tool call, dan aksi nyata
Prompt itu niat. Tool call itu percobaan. Aksi nyata itu efek ke sistem. Tiga hal ini perlu dipisah. Kalau semuanya dicampur jadi satu transcript panjang, investigasi malah capek.
4. Pasang redaction dari awal
Telemetry bisa bocor kalau lu asal rekam semua output command. Token, cookie, private URL, email user, path internal, dan snippet data production bisa ikut masuk log. Jadi redaction bukan fitur tambahan. Itu bagian dari desain awal.
5. Tentukan retention dan akses log
Log agent nggak harus disimpan selamanya. Tentukan berapa lama disimpan, siapa yang boleh baca, dan kapan harus dihapus. Observability yang bagus tapi aksesnya terlalu bebas bisa berubah jadi risiko privacy baru.
6. Ukur useful work, bukan cuma aktivitas
Agent yang banyak tool call belum tentu produktif. Agent yang hemat token belum tentu menyelesaikan task. Metric yang lebih sehat: task selesai, test lewat, review manusia lebih cepat, bug tidak naik, dan rollback tidak bertambah.
Contoh sederhana buat developer solo
Lu nggak perlu langsung punya stack observability enterprise. Untuk side project atau workflow pribadi, versi kecilnya bisa sangat sederhana:
- simpan setiap sesi agent dalam folder tanggal;
- arsipkan prompt awal, diff akhir, dan command verifikasi;
- tulis ringkasan manual 5 baris: problem, solusi, file berubah, test, risiko;
- jangan simpan secret di transcript;
- kalau agent gagal dua kali di area yang sama, stop dan review manual.
Gua suka pola ini karena realistis. Banyak developer gagal bukan karena nggak punya platform mahal, tapi karena semua insight kerja agent hilang di chat. Begitu sesi selesai, nggak ada artefak yang bisa dibaca ulang.
Kenapa ini bagus buat tim kecil?
Tim kecil biasanya belum punya proses governance yang berat. Tapi justru karena kecil, efek agent yang ngawur bisa langsung terasa. Satu PR AI yang mengubah auth, config, atau query database bisa bikin review melelahkan.
Dengan observability sederhana, tech lead bisa lebih cepat melihat pola:
- agent sering gagal di modul tertentu;
- test sering dilewati karena lama;
- task kecil berubah jadi refactor besar;
- biaya token naik karena context berantakan;
- review manusia habis buat membongkar keputusan agent.
Ini bukan anti-AI. Ini cara supaya AI tetap jadi multiplier, bukan sumber chaos baru.
Takeaway: treat agent like a worker, not a magic box
Kalau AI coding agent cuma dipakai buat autocomplete, chat history mungkin cukup. Tapi kalau agent mulai bekerja lama, menjalankan tool, dan mengubah repo, lu butuh telemetry yang lebih serius.
Prinsip utamanya:
- chat history membantu baca konteks, tapi bukan audit trail;
- OpenTelemetry membuat telemetry agent bisa masuk pipeline observability yang sudah dikenal tim;
- logs/traces/metrics harus didesain dengan redaction dan retention;
- observability tidak menggantikan sandbox, permission boundary, dan review manusia;
- developer solo pun bisa mulai dari artefak sederhana: diff, command, hasil test, dan ringkasan risiko.
Menurut gua, ini arah yang sehat. AI coding agent akan makin kuat. Tapi makin kuat alatnya, makin penting juga jejak kerjanya bisa diaudit. Bukan buat memperlambat developer, tapi buat bikin workflow tetap bisa dipercaya saat skalanya naik.
FAQ singkat
Apakah semua tim perlu OpenTelemetry untuk AI coding agent?
Nggak selalu. Tim enterprise lebih masuk akal memakai pipeline OpenTelemetry resmi. Developer solo bisa mulai dari log sesi, diff, command verifikasi, dan catatan risiko.
Apakah observability bikin AI agent otomatis aman?
Tidak. Observability membantu melihat dan menginvestigasi. Security boundary tetap perlu sandbox, least privilege, token yang bisa dicabut, dan review manusia.
Apa risiko terbesar dari logging agent?
Data sensitif ikut terekam. Karena itu redaction, akses log, dan retention harus dipikirkan sejak awal, bukan ditempel belakangan.
