Pagi ini Anda menjalankan empat agen. Satu me-refactor modul auth, satu menulis tes, satu mengejar job CI yang flaky, dan satu masih berpikir. Menjelang sore, Anda hanya punya kesan samar bahwa sesuatu sudah terjadi, tumpukan tab terminal, tiga worktree yang setengah Anda ingat pernah dibuat, dan dua pull request yang belum Anda baca. Pekerjaannya selesai. Tapi Anda tidak bisa melihat apa yang sebenarnya dikerjakan.
Melacak pekerjaan yang diselesaikan oleh agen coding AI adalah soal mengubah serakan itu menjadi sebuah catatan: apa yang diubah tiap agen, apakah perubahannya bertahan, dan di mana hasilnya berakhir. Ini masalah nyata karena agen selesai lebih cepat daripada kemampuan Anda memeriksanya, dan bukti dari apa yang mereka kerjakan tersebar di tempat-tempat yang dirancang untuk satu orang yang bekerja sendirian. Panduan ini membahas setup manualnya terlebih dahulu, menyebutkan di mana ia rusak, lalu menunjukkan alur kerja yang dipakai Sharkly untuk menjaga setiap hasil tetap terikat pada tugas yang memintanya.
Versi singkatnya: Anda bisa melacak beberapa agen secara manual dengan git dan terminal. Di luar itu, Anda butuh tempat bersama di mana hasil kembali dengan sendirinya, karena hambatan utamanya bukan lagi soal coding, melainkan kemampuan Anda untuk me-review-nya.
TL;DR
Melacak pekerjaan agen yang sudah selesai berarti menjawab tiga pertanyaan untuk setiap eksekusi: apa yang berubah, apakah sudah benar, dan di mana hasilnya mendarat. Riwayat git dan pull request menjawab pertanyaan pertama untuk satu atau dua agen. Begitu beberapa agen bekerja secara paralel, catatannya terpecah ke berbagai worktree, terminal, dan antrean PR, dan Anda kehilangan kaitan antara tugas dan hasilnya. Papan tugas mengatasi ini dengan membuat eksekusi, hambatan, hasil, dan review manusia kembali ke satu tugas, sehingga pekerjaan yang selesai bisa diperiksa alih-alih direkonstruksi.
Apa artinya melacak pekerjaan yang sudah selesai
Melacak bukanlah log aktivitas. Ini adalah kemampuan untuk menjawab tiga pertanyaan tentang eksekusi yang sudah selesai tanpa harus merekayasa balik.
- Apa yang berubah. Diff-nya, file-file yang disentuh, dan alasan di balik masing-masing.
- Apakah sudah benar. Typecheck, tes, build, dan ringkasan tentang apa yang sudah diverifikasi agen.
- Di mana hasilnya mendarat. Branch-nya, PR-nya, tugas yang terkait, dan siapa yang menerimanya.
Agen yang selesai secara senyap secara teknis sudah menyelesaikan pekerjaan, tapi Anda tidak bisa menindaklanjutinya. Status selesai yang penting bagi Anda adalah yang bisa diperiksa dan diterima oleh manusia. Itulah sebabnya "tes lulus" tidak sama dengan "pekerjaannya terlacak."
Model human-in-the-loop untuk agen coding menarik garis batasnya: agen meneliti, mengeksekusi, menguji, dan melapor; manusia menetapkan arah dan menerima hasilnya. Pelacakan adalah mesin yang memungkinkan bagian kedua itu terjadi.
Setup DIY, langkah demi langkah, dan di mana setiap langkahnya gagal
Untuk satu agen di satu branch, alat bawaan sudah cukup. Berikut versi jujurnya, dengan mode kegagalan disebutkan di setiap langkah.
Langkah 1: Lihat apa yang berubah. Setelah eksekusi, Anda membaca diff-nya.
git log --oneline -10
git diff main...HEAD --stat
Gagal ketika: dua agen berbagi satu branch, atau seorang agen tidak melakukan commit dan meninggalkan perubahan di working tree pada worktree yang Anda lupakan. Diff yang Anda baca bukan diff yang benar-benar dirilis.
Langkah 2: Isolasi pekerjaan tiap agen. Anda memberi setiap agen git worktree-nya sendiri agar mereka tidak bertabrakan.
git worktree add ../auth-refactor -b auth-refactor
git worktree list
Gagal ketika: daftarnya bertambah melebihi apa yang bisa Anda ingat di kepala. git worktree list memberi tahu Anda path-nya, bukan agen mana yang ada di masing-masing, tugas apa yang dilayaninya, atau apakah sudah selesai. Lihat dokumentasi resmi git-worktree untuk mekanismenya; dokumentasi itu berhenti pada pencatatan administratif.
Langkah 3: Periksa apakah hasilnya sampai ke PR. Anda mengandalkan GitHub.
gh pr list --author "@me" --state open
gh pr view 214 --json title,statusCheckRollup
Gagal ketika: PR-nya ada tapi tidak ada yang menuliskan alasannya, atau check-nya hijau padahal perubahannya salah, atau PR-nya tidak punya tautan balik ke permintaan yang memulainya. Referensi gh pr list menunjukkan PR yang terbuka, bukan niatnya.
Langkah 4: Ingat apa yang Anda minta. Langkah ini tidak punya perintah. Kebutuhan aslinya hidup di pesan Slack, sebuah catatan, atau ingatan Anda. Saat Anda me-review PR-nya tiga hari kemudian, Anda hanya menebak-nebak kriteria penerimaannya.
Setiap langkah berjalan. Masalahnya ada pada sambungan antar langkah. Diff, isolasi, PR, dan niatnya hidup di empat sistem yang tidak saling mengenal, dan Anda satu-satunya yang menghubungkan semuanya.
Di mana setup manual berhenti bisa diskalakan
Titik rusaknya bukan sebuah momen. Ini sebuah lereng, dan Anda bisa menyebutkan posisi Anda di atasnya.
| Agen yang berjalan paralel | Biaya pelacakan | Apa yang rusak lebih dulu |
|---|---|---|
| 1 | Membaca satu diff, satu PR | Tidak ada |
| 2 sampai 3 | Berpindah konteks antar worktree | Anda lupa agen mana mengerjakan apa |
| 4 sampai 6 | Merekonstruksi niat per PR | Hasil melampaui kapasitas review Anda |
| 7+ | Koordinasi penuh waktu | Pekerjaan selesai menganggur tanpa di-review selama berhari-hari |
Biaya sebenarnya diukur dari kapasitas review, bukan dari kecepatan agen. Agen menghasilkan pekerjaan selesai lebih cepat daripada kemampuan satu orang memeriksanya, jadi setelah beberapa eksekusi saja, throughput Anda dibatasi oleh seberapa cepat Anda bisa menjawab tiga pertanyaan tadi, bukan oleh seberapa cepat agen menulis kode. Menambah lebih banyak agen justru memperburuk masalah pelacakan, bukan memperbaiki masalah pengiriman.
Apa yang ditambahkan papan tugas
Solusinya adalah berhenti memperlakukan eksekusi yang selesai sebagai sekadar diff, dan mulai memperlakukannya sebagai sesuatu yang kembali ke sebuah tugas.
Di Sharkly, tugas adalah catatan bersamanya. Anda menugaskan sebuah tugas ke agen atau Crew, dan eksekusinya berjalan di worktree yang terisolasi, sehingga agen-agen paralel tidak pernah menyentuh file yang sama. Saat selesai, eksekusi, hambatan, hasil, dan tindak lanjut kembali ke timeline tugas. Ringkasan perubahan, hasil verifikasi, dan batasan yang diketahui menempel pada tugas itu sendiri, bukan pada terminal yang harus masih Anda buka.
Itulah perbedaan antara log dan catatan. Log memberi tahu Anda bahwa sesuatu terjadi. Catatan memberi tahu Anda apa yang berubah, apakah sudah benar, dan di mana hasilnya mendarat, semuanya di satu tempat, terhubung ke permintaan yang memulainya. Anda me-review pekerjaan yang selesai langsung dari tugasnya, menerimanya atau mengembalikannya, dan keputusan itu tercatat atas nama Anda.
Di sinilah sambungan-sambungan DIY tertutup. Niat, diff, check, dan penerimaannya berada pada satu objek. Anda tetap memakai alat yang sudah dipakai agen Anda; Claude Code dan Codex tetap menjalankan eksekusinya, dan Sharkly menambahkan lapisan tugas, konteks, dan review di sekitarnya. Menugaskan pekerjaan ke agen AI pun terasa seperti menugaskannya ke rekan tim, dan hasilnya kembali ke tempat yang bisa Anda temukan.
Anda bisa mengunduh Sharkly dan menghubungkan satu Computer untuk mencobanya pada satu tugas nyata sebelum menskalakannya.
Kapan Anda tidak membutuhkan semua ini
Bersikaplah jujur soal ambang batasnya. Jika Anda menjalankan satu agen coding, di satu repo, dan Anda membaca setiap diff sebelum di-merge, git dan terminal Anda sudah cukup untuk melacak pekerjaan yang selesai. Papan tugas hanya akan menambah formalitas yang tidak Anda butuhkan. Tampilan proyek bawaan di Claude Code sudah mencakup banyak hal untuk alur kerja satu agen.
Persamaannya berubah ketika tiga hal menumpuk: lebih dari sekadar beberapa agen sekaligus, pekerjaan yang tidak bisa Anda review di hari yang sama saat selesai, dan hasil yang perlu sampai ke orang lain selain Anda. Saat itulah catatan tugas bersama berhenti menjadi beban tambahan dan mulai menjadi satu-satunya cara agar pekerjaan yang selesai terlihat sejak permintaan hingga rilis.
Checklist yang bisa Anda jalankan hari ini
Sebelum menambah agen lain, pastikan Anda bisa menjawab ya untuk setiap poin berikut bagi agen yang sudah berjalan:
- [ ] Untuk eksekusi apa pun yang sudah selesai, bisakah Anda menemukan diff-nya dalam waktu kurang dari satu menit tanpa membuka terminal?
- [ ] Apakah setiap eksekusi yang selesai membawa ringkasan tentang apa yang sudah diverifikasi agen, bukan hanya check yang hijau?
- [ ] Bisakah Anda melacak sebuah PR kembali ke kebutuhan yang memulainya?
- [ ] Apakah ada satu tempat yang menunjukkan agen mana mengerjakan apa, apa yang sudah selesai, dan apa yang perlu di-review?
- [ ] Apakah penerimaan pekerjaan yang selesai memiliki nama orang yang tercantum di dalamnya?
- [ ] Saat agen selesai, apakah hasilnya datang kepada Anda, atau Anda harus mencarinya sendiri?
Jawaban "tidak" apa pun adalah sambungan yang akan makin melebar seiring Anda menambah agen. Memperbaikinya lebih awal lebih murah daripada merekonstruksi seminggu eksekusi yang tidak terlacak di kemudian hari.
FAQ
Bagaimana cara melacak apa yang diubah oleh agen coding AI? Baca diff-nya, bukan ringkasan agen tentang diff itu. Untuk satu agen, git diff dan PR-nya sudah cukup. Untuk beberapa agen, simpan setiap eksekusi di worktree-nya sendiri dan arahkan diff beserta ringkasan verifikasinya kembali ke tugas bersama agar Anda tidak perlu merekonstruksinya dari scrollback.
Bisakah saya melacak pekerjaan agen AI hanya dengan GitHub? Untuk satu atau dua agen, ya. GitHub menunjukkan PR yang terbuka dan status check. Tapi GitHub tidak memberi tahu Anda agen mana yang menghasilkan sebuah PR, tugas apa yang dilayaninya, atau apakah perubahannya sesuai dengan niat aslinya, jadi kemampuannya cepat menipis begitu beberapa agen berjalan paralel.
Berapa banyak agen yang bisa saya jalankan sebelum membutuhkan papan tugas? Kebanyakan orang mulai merasakan sambungan-sambungannya di sekitar tiga hingga empat agen paralel, saat merekonstruksi niat per PR mulai memakan lebih banyak waktu daripada review-nya sendiri. Pemicunya adalah kapasitas review, bukan angka yang pasti. Lihat catatan kami tentang mengelola agen coding paralel.
Apakah papan tugas memperlambat agen yang bergerak cepat? Tidak. Agen tetap mengeksekusi di worktree yang terisolasi dengan kecepatan penuh. Papan tugas menambahkan jalur kembali agar pekerjaan mereka yang selesai mendarat di tempat yang bisa Anda review, yang justru menghilangkan langkah rekonstruksi manual alih-alih menambahkannya.
