Sebagian besar pekerjaan kode tetap dimulai dari sebuah kalimat di obrolan grup. "Ekspor CSV menghilangkan baris terakhir." "Bisakah kita menambahkan SSO sebelum demo?" "Prod kembali melempar error 500 saat checkout." Seseorang memberi reaksi jempol, agen coding mungkin diarahkan ke situ, dan tiga hari kemudian tidak ada yang bisa memastikan apakah perbaikan itu sudah dirilis, siapa yang meninjaunya, atau commit mana yang memperbaikinya. Pesannya tergulir hilang. Pekerjaannya berubah jadi cerita rakyat.
Kesenjangan itu adalah masalah struktur, bukan masalah kedisiplinan. Pesan obrolan tidak punya pemilik, status, kriteria penerimaan, atau tautan ke diff yang menyelesaikannya. Arahkan agen coding ke pesan itu dan Anda menciptakan pekerjaan yang tidak bisa dilacak. Situasinya makin buruk begitu Anda menjalankan lebih dari satu agen, karena kini Anda juga tidak bisa memastikan agen mana yang mengerjakannya.
Artikel ini membahas cara mengubah pesan obrolan menjadi tugas kode yang bisa dilacak: apa yang Anda dapatkan dari penyiapan do-it-yourself sederhana, di mana penyiapan itu berhenti berkembang, dan apa yang ditambahkan oleh lapisan tugas bersama. Sharkly adalah workspace untuk versi yang bisa dilacak, karena ia berada di atas agen coding Anda dan menyimpan tujuan, eksekusi, penghambat, diff, dan tinjauan manusia dalam satu catatan. Anda sudah punya agen coding. Tugas Anda adalah mengubah pekerjaan mereka menjadi sesuatu yang bisa diikuti oleh tim.
Mengapa obrolan jadi tempat tugas kode mati
Obrolan grup dioptimalkan untuk kecepatan percakapan, kebalikan dari apa yang dibutuhkan tugas kode. Tugas yang sesungguhnya membawa tujuan yang dinyatakan, pemilik, kriteria penerimaan, status yang bisa ditanyakan, dan tautan balik ke perubahan yang menutupnya. Pesan obrolan tidak membawa satu pun dari itu. Ia hanya membawa stempel waktu dan reaksi.
Pola kegagalannya sangat spesifik. Sebuah permintaan datang, disetujui secara informal di dalam thread, dan thread itu terus berjalan. Dua hari kemudian seseorang bertanya "kita pernah memperbaiki bug ekspor itu tidak?" dan jawabannya membutuhkan pencarian Slack, tebakan, dan menggulir channel di mana frasa yang sama muncul sembilan kali. Bahkan jika Anda menemukan pesannya, itu tidak memberi tahu Anda apakah perbaikannya sudah di-merge. Percakapan dan kode hidup di sistem terpisah yang tidak pernah saling mengenal.
Arahkan agen coding otonom ke pesan itu dan jejaknya justru makin pendek. Agen membaca satu baris Slack, berjalan di terminal di laptop seseorang, mengedit file, dan melapor kembali ke thread yang bergerak cepat yang sama yang menelan permintaan itu. Sekarang Anda punya log eksekusi yang tidak disimpan siapa pun, perubahan yang tidak ditautkan siapa pun, dan keputusan yang tidak dicatat siapa pun.
Pipeline DIY, dan di mana ia berhenti berkembang
Anda tidak perlu produk untuk memulai. Pipeline do-it-yourself yang bisa dijalankan: salin pesan obrolan, tempelkan ke agen coding Anda sebagai prompt, biarkan ia bekerja di Git worktree terisolasi agar tidak bertabrakan dengan checkout utama Anda, dan buka pull request yang menautkan balik ke issue pelacak dengan baris Closes #123. Itu keterlacakan yang nyata, dan untuk developer tunggal yang menangani satu permintaan sekaligus, itu sering kali sudah cukup.
Inilah pasangan keputusan yang jujur. Jika Anda satu orang, menjalankan satu agen, menyelesaikan satu tugas sebelum tugas berikutnya, loop salin-tempel-ke-worktree itu berjalan baik dan Anda tidak perlu menambahkan tooling ke dalamnya. Overhead dari sistem bersama akan lebih mahal daripada hasil yang diberikannya.
Penyiapan itu berhenti berkembang begitu dua hal terjadi bersamaan: dua agen berjalan, atau dua orang mengarahkan pekerjaan, atau dua repositori terlibat. Saat itu pipeline manual mulai berlubang:
| Apa yang rusak | Mengapa loop DIY tidak bisa menanganinya |
|---|---|
| "Agen mana yang memegang bug ekspor?" | Penugasan itu hanya ada di kepala Anda, bukan di sebuah catatan |
| "Ini sudah selesai atau masih berjalan?" | Statusnya adalah terminal yang Anda tutup, bukan field yang bisa ditanyakan |
| "Siapa yang menyetujui perubahan autentikasi?" | Persetujuannya hanya jempol, sekarang sudah tergulir hilang |
| "Di mana diff untuk permintaan Slack itu?" | PR-nya menautkan ke issue, tetapi issue-nya tidak pernah menautkan ke permintaan itu |
| "Apa yang sebenarnya diubah agen?" | Log eksekusinya ada di sesi yang sudah berakhir |
Setiap lubang adalah tempat tugas itu kembali menjadi tidak bisa dilacak. Anda bisa menambalnya secara manual dengan lebih banyak issue, konvensi penamaan, dan kedisiplinan. Itu berhasil sampai tidak lagi berhasil, dan kegagalannya sunyi, cara terburuk bagi sebuah proses untuk gagal.
Apa arti "bisa dilacak" ketika tugas sudah dibagikan
Bisa dilacak bukan soal perasaan. Setiap pertanyaan tentang suatu pekerjaan punya jawaban yang berada di satu tempat dan bertahan melampaui orang-orang yang sedang online saat pekerjaan itu dimulai. Tugas yang bisa dilacak menjaga konteks, penugasan, kemajuan, penghambat, hasil, dan tinjauan manusia tetap terlihat dari permintaan sampai rilis.
Sharkly memodelkan ini sebagai Task, unit kerja utama dalam sistem. Task bukan pesan obrolan dan bukan sesi terminal. Ia adalah catatan bersama yang menjadi wujud pesan obrolan begitu Anda memutuskan untuk menindaklanjutinya. Tujuannya masuk ke deskripsi. Agent atau seseorang menjadi Assignee. Eksekusi Agent, penghambatnya, hasilnya, dan diskusi lanjutannya semuanya kembali ke timeline Task alih-alih menghilang ke terminal pribadi. Ketika perubahannya mendarat, pull request ditautkan berdasarkan ID, sehingga permintaan dan diff akhirnya saling mengenal.
Satu batasan penting untuk diperjelas, karena pembaca bisa salah menyimpulkan. Sharkly bukan pengganti Claude Code, Codex, atau agen coding Anda yang lain. Alat-alat itu yang melakukan eksekusi. Sharkly menambahkan lapisan tugas bersama, konteks, dan tinjauan di sekitarnya. Agent tetap yang menulis kode. Sharkly membuat pekerjaan itu bisa ditugaskan dan dilacak.
Mengubah pesan obrolan menjadi tugas yang bisa dilacak dengan Sharkly
Alur kerjanya cukup singkat untuk diingat. Mulailah dengan pesan sungguhan, misalnya bug ekspor CSV, dan pindahkan dari channel:
- Tangkap pesannya sebagai Task. Buat Task dengan permintaan itu sebagai tujuannya. Jika obrolan Anda ada di Slack, bot Slack untuk agen coding mengubah mention menjadi Task tanpa meninggalkan thread.
- Bentuk agar Agent bisa mengeksekusinya. Laporan bug satu baris bukan spesifikasi yang bisa dijalankan. Tambahkan langkah reproduksi, perilaku yang diharapkan, dan tes penerimaan. Disiplin yang sama seperti manajemen tugas agen AI: Task yang bisa ditutup Agent membutuhkan deskripsi yang bisa ditindaklanjuti Agent.
- Tugaskan dan biarkan Agent berjalan. Agent mengambil Task, bekerja di worktree terisolasi agar pekerjaan paralel tidak bertabrakan, dan mengalirkan kemajuannya kembali ke Task. Anda mengawasi sebuah catatan, bukan terminal.
- Tinjau dan terima. Agent melampirkan ringkasan perubahannya, hasil tes, dan batasan yang diketahui. Seseorang menerima, meminta perubahan, atau mengambil keputusan merge.
Langkah terakhir itulah kontrak yang layak dinyatakan secara gamblang: Agent meneliti, mengeksekusi, menguji, dan melapor. Manusia menetapkan arah, memberikan wewenang, dan menerima hasilnya. Otomatisasi berhenti di titik yang membutuhkan penilaian tim. Tugas yang bisa dilacak membuat serah terima itu mungkin, karena manusia yang meninjau perubahan melihat seluruh jalur dari permintaan sampai diff. Ketika pekerjaannya selesai, Anda bisa melacak apa yang diselesaikan agen tanpa harus merekonstruksinya dari ingatan. Ini adalah tulang punggung yang sama dengan alur kerja dari kebutuhan sampai kode secara penuh, hanya saja dimulai dari secuil obrolan alih-alih tiket formal.
Anda bisa membangun versi ini sendiri dengan issue dan worktree, atau gunakan Sharkly untuk mengelola alur kerjanya agar jejaknya tetap utuh saat volume meningkat.
Checklist yang bisa Anda jalankan hari ini
Jalankan ini terhadap penyiapan Anda saat ini. Setiap kotak yang belum tercentang adalah tempat tugas yang lahir dari obrolan bisa menjadi tidak terlacak:
- [ ] Setiap permintaan obrolan yang ditindaklanjuti menjadi Task dengan pemilik, bukan reaksi emoji.
- [ ] Setiap Task punya deskripsi yang bisa dieksekusi Agent: langkah reproduksi, perilaku yang diharapkan, tes penerimaan.
- [ ] Setiap Agent yang berjalan bekerja di worktree terisolasi, sehingga dua tugas tidak pernah menyentuh file yang sama.
- [ ] Log eksekusi, penghambat, dan hasil Agent kembali ke Task, bukan ke terminal yang tertutup.
- [ ] Pull request ditautkan ke Task berdasarkan ID, sehingga permintaan dan diff hanya berjarak satu klik.
- [ ] Seorang manusia menerima atau menolak hasilnya, dan keputusan itu tercatat di Task.
- [ ] Anda bisa menjawab "apakah ini selesai, siapa yang mengerjakannya, dan di mana diff-nya?" tanpa mencari di obrolan.
Saat menangani satu permintaan sekaligus, loop manual sudah memenuhi sebagian besar poin ini dengan sendirinya. Saat menjalankan beberapa agen di seluruh tim, Sharkly memberi Anda satu tempat untuk mengelola tugas dan hasil mereka. Unduh Sharkly dan pindahkan satu permintaan obrolan nyata menjadi Task sebelum Anda menyerahkan seluruh channel ke sana.
FAQ
Apakah saya perlu Sharkly untuk membuat tugas yang lahir dari obrolan bisa dilacak? Tidak. Developer tunggal yang menjalankan satu agen sudah mendapat keterlacakan nyata dari worktree plus pull request yang menautkan ke issue. Pola inbox agen AI baru layak diadopsi begitu Anda punya banyak agen atau banyak orang dan tautan manual mulai terlewat.
Apa yang membuat pesan obrolan sulit dieksekusi agen coding? Biasanya ia tidak punya langkah reproduksi, hasil yang diharapkan, dan tes penerimaan. Ubah "ekspornya rusak" menjadi "ekspor CSV menghilangkan baris terakhir; diharapkan N baris, ternyata N-1; diperbaiki saat jumlahnya cocok." Kini Agent punya sesuatu yang bisa dijadikan patokan penyelesaian.
Apa bedanya dengan sistem tiket biasa? Tiket melacak pekerjaan yang akan dilakukan manusia. Tugas kode yang bisa dilacak juga membawa log eksekusi Agent, eksekusi terisolasinya, dan diff yang tertaut, sehingga catatannya mencakup keputusan sekaligus perubahannya. Lihat agen coding human-in-the-loop untuk memahami di mana manusia tetap berada dalam alur.
Bisakah Sharkly membaca channel Slack saya langsung? Anda menghubungkan Agent Sharkly ke Slack sehingga sebuah mention menjadi Task. Percakapannya tetap di Slack; catatan pekerjaan yang bisa dilacak tersimpan di Sharkly.
