AI agent yang langsung jalan sendiri tanpa jejak itu kelihatan keren, sampai lu harus menjawab pertanyaan sederhana: “dia tadi ngubah apa, kenapa, dan siapa yang sudah ngecek?”
Artikel ini membahas kenapa agentic workflow yang sehat bukan autopilot. Pelajaran utamanya dari GitHub Agentic Workflows: agent boleh membantu kerja repetitif seperti sinkronisasi dokumentasi lintas repo, tapi outputnya tetap harus berupa artifact yang bisa direview manusia, misalnya pull request, diff, log, atau telemetry. Buat developer dan builder, pola ini lebih realistis daripada mimpi “AI langsung publish semua hal”.
Apa itu agentic workflow?
Agentic workflow adalah alur kerja ketika AI agent diberi tujuan, akses tool, dan konteks untuk menjalankan beberapa langkah kerja secara mandiri. Bedanya dengan chatbot biasa: agent tidak cuma menjawab teks, tapi bisa membaca repo, membuat file, menjalankan command, membuka issue, atau membuat pull request.
Masalahnya, begitu agent mulai punya akses ke tool nyata, risikonya ikut naik. Output salah bukan lagi sekadar jawaban ngawur di chat. Output salah bisa jadi PR berantakan, dokumentasi misleading, perubahan config yang sulit dilacak, atau biaya API yang diam-diam naik.
Makanya, pertanyaan yang lebih penting bukan “agent ini bisa apa?”, tapi “agent ini meninggalkan bukti kerja yang bisa dicek nggak?”
Pelajaran dari GitHub: agent buat docs, bukan langsung publish
GitHub menulis tentang penggunaan GitHub Agentic Workflows untuk membantu dokumentasi lintas repo. Use case-nya masuk akal: perubahan produk sering merge duluan, sementara dokumentasi bisa telat karena konteksnya tersebar di beberapa tempat.
Di pola yang mereka jelaskan, agent dipakai untuk menjembatani jarak antara perubahan produk dan update dokumentasi. Agent bisa membaca sinyal perubahan, menyusun update, lalu menghasilkan pull request dokumentasi. Tapi bagian pentingnya ada di sini: hasil akhir tetap masuk ke jalur review. Subject-matter expert masih mengecek sebelum sesuatu benar-benar dipublish.
Ini beda besar dari narasi “AI menggantikan technical writer”. Menurut gua, pola yang lebih menarik justru kebalikannya: AI mengurangi kerja kosong, manusia tetap pegang keputusan akhir.
Kalau lu pernah maintain blog, docs internal, changelog, atau knowledge base, lu pasti tahu problemnya. Bukan selalu karena orang malas nulis. Sering kali karena konteksnya pecah: perubahan ada di repo A, implikasi user ada di repo B, dan dokumentasi hidup di repo C. Agent bisa bantu mengumpulkan jejak itu, tapi tetap perlu manusia buat memastikan narasinya benar.
Automation sehat menghasilkan artifact, bukan keputusan gelap
Automation yang buruk biasanya bekerja seperti kotak hitam. Ada trigger, lalu tiba-tiba ada perubahan. Kalau hasilnya salah, lu harus forensik dari nol: lihat log, nebak prompt, cek commit, cari file mana yang disentuh.
Automation yang sehat meninggalkan artifact yang jelas. Minimal ada:
- Trigger: apa yang memulai agent? Merge, label issue, jadwal cron, atau command manual?
- Scope: folder, repo, atau dokumen mana yang boleh disentuh?
- Diff: perubahan konkret apa yang dibuat?
- Rationale: kenapa perubahan itu dibuat?
- Owner: siapa yang harus review dan approve?
- Log/telemetry: tool apa yang dipakai, berapa lama jalan, dan apakah ada error?
Pull request adalah format yang bagus karena developer sudah paham cara membacanya. Ada diff, komentar, status check, reviewer, histori, dan tombol reject. Buat banyak tim, ini lebih aman daripada bikin UI agent baru yang kelihatan fancy tapi susah diaudit.
Kenapa langsung publish itu bahaya?
Langsung publish menggoda karena terasa efisien. Tapi untuk banyak workflow, terutama yang menyentuh docs, blog, config, release note, atau code, publish otomatis bisa bikin masalah kecil jadi public incident.
Contoh sederhana: agent salah paham perubahan fitur, lalu update dokumentasi dengan instruksi yang tidak valid. Kalau langsung publish, user bisa mengikuti docs yang salah. Kalau lewat PR, reviewer masih punya kesempatan melihat mismatch sebelum damage terjadi.
Di sistem kerja gua sendiri, pola ini kerasa banget. Riset dari Obsidian bisa membantu memilih topik, Hermes bisa bantu menyusun draft Ghost, quality gate bisa ngecek bahasa dan referensi, tapi status akhirnya tetap draft. Bukan published. Kenapa? Karena automation seharusnya mempercepat review, bukan menghapus review.
Ini bukan berarti semua automation harus lambat. Justru dengan gate yang jelas, automation bisa lebih cepat karena jalurnya tidak abu-abu. Agent tahu output yang diharapkan. Manusia tahu bagian mana yang perlu dicek.
Checklist desain agentic workflow yang waras
Kalau lu mau bikin workflow agent buat repo, docs, blog, atau internal tool, mulai dari checklist ini:
- Pilih task yang punya output bisa dicek. Contoh bagus: PR docs, draft artikel, issue triage, ringkasan changelog. Contoh rawan: langsung ubah production config tanpa approval.
- Batasi scope dari awal. Jangan kasih agent akses seluruh repo kalau task-nya cuma update folder docs.
- Paksa output berbentuk diff atau draft. Hindari output final yang langsung memengaruhi user.
- Tulis acceptance criteria. Agent perlu tahu definisi “selesai”, bukan cuma “bantu update docs”.
- Tambahkan human review di titik risiko tinggi. Publish, deploy, delete, revoke, dan migrasi data sebaiknya butuh approval.
- Simpan log yang cukup. Kalau hasilnya aneh, lu perlu tahu tool apa yang dipanggil dan input mana yang dipakai.
- Ukur useful work. Jangan cuma ukur jumlah task selesai. Ukur berapa banyak output agent yang diterima tanpa rewrite besar.
Jangan semua hal dibuat agent
Bagian ini penting: tidak semua workflow butuh agent. Kadang script biasa lebih aman, lebih murah, dan lebih mudah dipahami. Kalau langkahnya deterministik, inputnya jelas, dan outputnya bisa dihitung, lu mungkin cukup pakai script atau CI job.
Agent mulai masuk akal ketika task butuh membaca konteks yang agak berantakan: beberapa file, beberapa repo, changelog, issue, atau dokumen yang tidak selalu rapi. Tapi begitu agent masuk, lu perlu guardrail tambahan karena hasilnya tidak deterministik seperti script biasa.
Menurut gua, cara pikir paling sehat adalah ini: script untuk aturan yang jelas, agent untuk konteks yang fuzzy, manusia untuk keputusan yang berisiko.
Takeaway buat developer dan builder
- AI agent produksi yang sehat tidak harus langsung mengeksekusi keputusan akhir.
- Output terbaik agent sering berupa artifact: PR, draft, diff, checklist, atau log.
- Human review bukan tanda automation gagal. Itu bagian dari desain sistem yang bisa dipercaya.
- Workflow agent perlu scope, owner, acceptance criteria, dan telemetry.
- Kalau agent tidak meninggalkan bukti kerja, lu akan susah audit ketika hasilnya salah.
FAQ singkat
Apakah agentic workflow berarti AI menggantikan developer atau writer?
Tidak selalu. Dalam pola yang lebih sehat, agent membantu pekerjaan repetitif dan context gathering, sementara manusia tetap review keputusan akhir, terutama untuk output yang public atau berisiko.
Kenapa PR cocok untuk output AI agent?
Karena PR punya diff, reviewer, komentar, status check, dan histori. Format ini sudah familiar buat developer dan lebih mudah diaudit daripada perubahan otomatis yang langsung masuk ke main branch.
Kapan automation boleh langsung jalan tanpa review?
Kalau risikonya rendah, scope-nya sempit, output-nya bisa divalidasi otomatis, dan rollback-nya jelas. Untuk publish, deploy, delete, atau perubahan data penting, review manusia masih jauh lebih aman.
Penutup
AI agent yang bagus bukan yang kelihatan paling otonom. Buat gua, agent yang bagus adalah agent yang bikin kerja lebih ringan sambil tetap meninggalkan jejak yang bisa dicek.
Automation bukan autopilot. Automation yang waras itu bikin draft, diff, PR, log, dan checklist yang membantu manusia mengambil keputusan lebih cepat. Kalau lu lagi membangun workflow AI di tim atau project pribadi, jangan mulai dari pertanyaan “seberapa jauh agent bisa jalan sendiri?” Mulai dari pertanyaan yang lebih penting: “kalau hasilnya salah, seberapa cepat gua bisa tahu, review, dan balikin arahnya?”
