Home | Blog | Guide

Pencarian Lintas Alat: Kode Bukan Tempat yang Tepat

Sebagian besar keputusan developer berada di luar kode. Cara membangun pencarian lintas alat di Slack, Linear, GitHub, dan Notion.

By Ellis Keane · 2026-03-17

Codebase Anda adalah tempat yang paling tidak berguna untuk mencari alasan di balik sebuah keputusan.

Saya tahu itu terdengar terbalik. Kita menghabiskan bertahun-tahun mempelajari flag ripgrep, mengonfigurasi pencarian IDE, menghafal pola regex – dan tidak ada yang membantu ketika pertanyaannya bukan "di mana fungsi ini?" melainkan "mengapa kita memilih pendekatan ini dibanding tiga alternatif yang kita diskusikan?" Jawaban untuk pertanyaan kedua itu hampir tidak pernah ada di dalam kode. Jawabannya ada di utas Slack empat bulan lalu, komentar Linear yang terkubur di bawah pembaruan status, dokumen Notion yang seseorang mulai tapi tidak pernah selesaikan, dan review PR di mana perdebatan nyata terjadi dalam balasan dari balasan dari balasan.

Itulah masalah pencarian lintas alat bagi developer – konteks keputusan tersebar di berbagai alat tanpa jalur kueri yang terpadu. Kita punya pencarian yang bekerja dengan baik di dalam setiap alat – pencarian Slack cukup baik, pencarian kode GitHub sangat baik, Linear punya filter untuk segalanya – tapi tidak ada yang mencari di semua alat sekaligus. Keputusan yang membentuk arsitektur Anda tersimpan di lima tempat berbeda, dan Anda diharapkan ingat di mana harus mencarinya.

Oke – begini cara membangun pencarian lintas alat dengan apa yang sudah Anda miliki. Tidak perlu alat baru (yah, hampir – saya akan menyebut satu di bagian akhir, tapi ini bekerja tanpanya).

Anatomi Sebuah Keputusan yang Tersebar

Mari saya bahas sesuatu yang konkret. Tahun lalu, kami sedang memutuskan apakah akan menggunakan BullMQ atau Temporal untuk job queue kami. Begini di mana keputusan itu sebenarnya berada:

Slack (#engineering): Tiga utas terpisah selama dua hari. Yang pertama adalah tautan yang seseorang bagikan ke posting blog Temporal. Yang kedua adalah perdebatan tentang apakah kami membutuhkan durable execution. Yang ketiga (seminggu kemudian, kanal berbeda) adalah seseorang yang bertanya "tunggu, sudahkah kita memutuskan soal queue?"
Linear: Sebuah isu berjudul "Evaluate job queue options" dengan enam komentar, termasuk tabel perbandingan yang salah satu insinyur kami habiskan satu sore untuk menulisnya.
GitHub: Deskripsi PR untuk implementasi BullMQ yang bertuliskan "as discussed" tanpa satu pun tautan ke tempat diskusinya.
Notion: Architecture decision record yang setengah jadi yang mencakup kelebihan Temporal tapi tidak pernah diperbarui dengan pilihan akhir.
Google Docs: Catatan rapat dari panggilan di mana kami benar-benar membuat keputusan, terkubur dalam poin-poin di antara dua agenda yang tidak berkaitan.

Lima alat. Satu keputusan. Dan jika Anda mencari di satu alat mana pun, Anda hanya akan menemukan fragmen – tidak pernah gambaran lengkapnya. PR memberi tahu Anda apa yang kami pilih. Utas Slack memberi tahu apa yang kami pertimbangkan. Isu Linear memberi tahu trade-off-nya. Dokumen Notion memberi tahu setengah alasannya. Catatan rapat memberi tahu momen keputusan itu difinalkan.

Ini bukan hal yang tidak biasa. Inilah, entah bagaimana, keadaan terkini dari cara tim rekayasa melacak keputusan pada tahun 2026. Kita punya AI yang menghasilkan kode dan mesin pencari yang mengindeks seluruh internet, tapi mencari tahu mengapa tim Anda memilih BullMQ daripada Temporal membutuhkan pengecekan lima aplikasi dan berharap ingatan seseorang tetap kuat.

Apa yang Membuat Pencarian Lintas Alat Sulit bagi Developer

Ini bukan masalah API – setiap alat yang kita gunakan memiliki API pencarian yang sangat baik. Masalahnya lebih aneh dari itu:

Bentuk data yang berbeda. Slack mengembalikan pesan dengan timestamp dan ID kanal. Linear mengembalikan isu dengan status dan label. GitHub mengembalikan commit, PR, dan kecocokan kode dalam format respons yang sama sekali berbeda. Menggabungkan semua ini ke dalam linimasa yang koheren memerlukan normalisasi yang tidak ada yang repot-repot membuatnya (karena, jujur saja, itu jenis pekerjaan yang tidak muncul dalam demo sprint).

Fragmentasi konteks. Pesan Slack yang bertuliskan "ayo pakai opsi B" tidak ada artinya tanpa utas yang mendefinisikan opsi A, B, dan C. Tapi pencarian Slack mengembalikan pesan individual, bukan lengkung percakapan. Anda menemukan kesimpulan tanpa alasannya.

Peralihan konteks temporal. Proses pengambilan keputusan sering kali berlangsung berhari-hari atau berminggu-minggu, dengan jeda di mana tidak ada yang terjadi karena semua orang sedang fokus pada pekerjaan lain. Pencarian kata kunci mungkin memunculkan awal dan akhir percakapan sambil melewatkan bagian tengah yang krusial, hanya karena kata-kata berbeda digunakan pada tahap yang berbeda.

Pencarian lintas alat untuk developer bukan masalah API – setiap alat memiliki endpoint pencarian yang sangat baik. Ini masalah konteks: keputusan tersebar di berbagai alat dalam bentuk yang tidak kompatibel, terfragmentasi oleh lengkung percakapan, dan dipisahkan oleh pergeseran temporal. Pencarian kata kunci menemukan fragmen; hanya konteks yang terhubung yang menemukan gambaran lengkapnya.

Membangun Pencarian Lintas Alat dengan Yang Anda Miliki

Inilah bagian praktisnya. Untuk tiga atau empat alat dengan pencarian hanya-baca, perkirakan setengah hari untuk mendapatkan MVP yang berfungsi – sebagian besar dihabiskan untuk penyiapan autentikasi dan normalisasi respons, bukan logika pencarian itu sendiri.

Siapkan Akses API

Anda memerlukan token untuk setiap alat:

Slack: Token pengguna dengan scope search:read (metode pencarian Slack memerlukan token pengguna, bukan token bot – buat melalui halaman aplikasi API Slack)
Linear: Kunci API pribadi dari Pengaturan, lalu API
GitHub: PAT berbutir halus dengan akses baca ke repositori Anda
Notion: Token integrasi internal dari Pengaturan, lalu Koneksi

Skrip Kueri Fan-out

Polanya sangat sederhana – tembakkan kueri pencarian yang sama ke setiap API dan kumpulkan hasilnya:

```typescript interface SearchResult { source: 'slack' | 'linear' | 'github' | 'notion'; title: string; snippet: string; url: string; timestamp: Date; }

async function crossToolSearch(query: string): Promise<SearchResult[]> { const results = await Promise.all([ searchSlack(query), searchLinear(query), searchGitHub(query), searchNotion(query), ]);

return results .flat() .sort((a, b) => b.timestamp.getTime() - a.timestamp.getTime()); } ```

Setiap fungsi search* membungkus API yang bersangkutan. Untuk Slack, itu adalah search.messages. Untuk Linear, itu kueri GraphQL terhadap field pencarian mereka. Untuk GitHub, itu endpoint pencarian REST. Untuk Notion, itu endpoint pencarian dengan parameter query.

Normalisasi dan Deduplikasi

Bagian yang rumit bukan pencariannya – melainkan membuat hasilnya berguna. Anda perlu:

Normalisasi timestamp di semua alat (Slack menggunakan epoch Unix, Linear menggunakan string ISO, GitHub menggunakan ISO dengan offset zona waktu)
Kelompokkan hasil terkait – jika utas Slack yang sama muncul tiga kali karena tiga pesan cocok, satukan menjadi satu hasil dengan URL utas
Peringkatkan berdasarkan relevansi – sebagian besar API mengembalikan skor relevansi mereka sendiri, tapi tidak bisa dibandingkan antar alat. Heuristik sederhana: kecocokan kata kunci tepat di judul mengungguli kecocokan di isi, dan hasil yang lebih baru mengungguli yang lebih lama dengan relevansi yang sama

Bungkus dalam CLI

Saya menggunakan Commander.js untuk ini (sebagian besar karena kebiasaan, tapi apa saja bisa digunakan):

```bash $ cross-search "bullmq vs temporal"

Found 14 results across 4 tools:

[Slack] #engineering – 2025-11-14 "I've been comparing BullMQ and Temporal for the job queue..." https://myteam.slack.com/archives/C0X.../p17318...

[Linear] ENG-342 – 2025-11-15 "Evaluate job queue options – BullMQ vs Temporal" https://linear.app/myteam/issue/ENG-342

[GitHub] PR #289 – 2025-11-22 "feat: implement BullMQ job queue (as discussed)" https://github.com/myorg/myrepo/pull/289

[Notion] Architecture Decisions – 2025-11-13 "Job Queue Evaluation: Temporal vs BullMQ" https://notion.so/myteam/abc123... ```

Empat belas hasil, diurutkan berdasarkan waktu, dari empat alat. Anda bisa melihat keseluruhan lengkung keputusan di satu tempat: dokumen Notion dimulai lebih dulu, kemudian diskusi Slack berlangsung, lalu isu Linear dibuat untuk pelacakan, dan akhirnya PR mendarat seminggu kemudian.

Membuatnya Benar-Benar Baik

Versi dasar di atas berfungsi, tetapi ada beberapa sudut yang menjengkelkan. Cara memperbaikinya:

Ekspansi utas untuk Slack. Saat menemukan pesan yang cocok, ambil seluruh utasnya dengan conversations.replies. Pesan yang cocok mungkin "oke, pakai BullMQ" – tidak berguna tanpa 40 pesan perdebatan sebelumnya. Tampilkan cuplikan utas, bukan hanya pesan yang cocok.

Komentar review PR. API pencarian GitHub tidak memunculkan komentar review saat Anda mencari PR – Anda perlu panggilan terpisah ke endpoint review pull request untuk mengambilnya. Di situlah diskusi teknis nyata berada.

Backlink. Saat menemukan isu Linear, periksa apakah ada pesan Slack yang memuat URL isu tersebut. Pencarian Slack mendukung filter has:link yang dikombinasikan dengan kata kunci. Ini memunculkan diskusi informal yang terjadi di sekitar pelacakan formal.

Caching. Jika tim Anda menghasilkan banyak konten (dan tim mana yang tidak), Anda akan cepat mencapai batas kecepatan. Cache hasil secara lokal dengan TTL 30 menit – sebagian besar keputusan historis tidak berubah secepat itu.

Saat Pencarian Teks Gagal

Di sinilah saya akan jujur tentang keterbatasannya. Pencarian kata kunci lintas alat membawa Anda cukup jauh, lalu menabrak tembok.

Tembok itu adalah ini: keputusan berkembang. Utas Slack tentang "job queue" mungkin tidak pernah menyebut "BullMQ" – sebaliknya, seseorang membagikan tautan, orang lain berkata "saya suka opsi yang berbasis Redis," dan orang ketiga berkata "setuju, pakai itu." Pencarian Anda untuk "BullMQ" melewatkan seluruh utas karena kata itu tidak pernah digunakan. Orang-orang dalam utas tahu apa yang dimaksud dengan "opsi berbasis Redis." Pencarian Anda tidak.

Ini pada dasarnya adalah masalah grafik, bukan masalah teks. Yang benar-benar Anda inginkan adalah: "tunjukkan saya semua yang terhubung dengan keputusan yang menghasilkan PR #289." Itu berarti memahami bahwa PR mereferensikan isu Linear, yang dibuat setelah diskusi Slack, yang dimulai karena seseorang membaca dokumen Notion. Koneksinya implisit – manusia membuat koneksi tersebut dengan menyalin URL dan berkata "as discussed" – dan pencarian kata kunci tidak bisa merekonstruksinya.

Anda bisa sebagian menyelesaikannya dengan mengikuti tautan. Parsing URL dari pesan Slack, deskripsi PR, dan komentar Linear. Bangun daftar adjacency sederhana: utas Slack ini menautkan ke isu Linear ini, yang direferensikan dalam PR ini. Kemudian saat seseorang mencari, Anda bisa memperluas hasil untuk menyertakan item yang ditautkan meskipun tidak cocok dengan kata kunci.

Pendekatan daftar adjacency tersebut pada dasarnya adalah grafik pengetahuan rudimenter – dan di situlah nilai nyata pencarian lintas alat untuk developer berada. Bukan dalam menemukan pesan individual, melainkan dalam mengikuti benang merah suatu keputusan di setiap alat yang disentuhnya. Ini kurang tentang "pencarian" dan lebih tentang manajemen pengetahuan developer – memahami bagaimana informasi mengalir di antara alat-alat Anda sehingga Anda bisa merekonstruksi konteks saat dibutuhkan.

Masalah Pemeliharaan (dan Jalan Pintas)

Pendekatan skrip bekerja luar biasa selama sekitar tiga bulan, kemudian seseorang mengubah workspace Slack, atau Linear memperbarui skema GraphQL mereka, atau Anda menambahkan alat baru dan tidak ada yang ingat memperbarui skrip pencarian. Saya telah membangun persis hal yang sama dua kali dan meninggalkannya dua kali (yang mungkin lebih banyak berbicara tentang komitmen saya terhadap pemeliharaan daripada tentang pendekatannya sendiri).

Jika Anda menginginkan pencarian lintas alat untuk developer yang tetap terkini tanpa pengawasan terus-menerus, itulah yang dibangun alat seperti Sugarbug – ia memelihara grafik pengetahuan secara otomatis dan menjaga koneksi tetap hidup seiring perubahan alat Anda. Tapi versi DIY di atas sungguh berguna jika Anda bersedia memeliharanya.

Berhenti mencari di lima alat secara terpisah. Sugarbug membangun grafik pengetahuan sehingga Anda bisa menemukan keputusan, diskusi, atau commit apa pun di satu tempat.

Q: Bagaimana cara mencari di beberapa alat developer sekaligus? A: Anda bisa membangun pencarian lintas alat ringan dengan menggabungkan API setiap alat – search.messages Slack, issueSearch Linear, dan endpoint pencarian kode GitHub – menjadi satu skrip yang menyebarkan kueri dan menggabungkan hasil berdasarkan timestamp. Contoh kode di atas akan membantu Anda memulai dalam satu sore. Tantangan utamanya bukan pencariannya sendiri melainkan menormalisasi format respons yang berbeda-beda ke dalam linimasa yang koheren.

Q: Apakah Sugarbug menyediakan pencarian lintas alat untuk developer? A: Ya. Sugarbug menyerap sinyal dari Linear, GitHub, Slack, Figma, Notion, dan alat lainnya ke dalam grafik pengetahuan, sehingga Anda bisa mencari keputusan atau diskusi dan menemukan setiap utas, isu, dan commit yang terhubung di satu tempat. Ia menangani normalisasi, deduplikasi, dan pengikutan tautan secara otomatis – bagian-bagian yang membuat pendekatan DIY rapuh seiring waktu.

Q: Mengapa saya tidak dapat menemukan keputusan arsitektur di codebase saya? A: Karena sebagian besar keputusan terjadi di utas Slack, komentar Linear, dokumen Notion, dan review PR – bukan di kode itu sendiri. Kode mencatat hasil suatu keputusan (fungsi ada, perpustakaan dipilih), tetapi alasan, trade-off, dan alternatif yang didiskusikan tersebar di seluruh alat komunikasi Anda. Sebuah git blame memberi tahu Anda siapa yang mengubah baris dan kapan, tapi tidak mengapa mereka memilih pendekatan itu daripada alternatifnya.

Q: Bisakah Sugarbug menggantikan dokumen ADR untuk pelacakan keputusan? A: Sugarbug tidak menggantikan ADR, tetapi menangkap keputusan yang tidak pernah masuk ke ADR. Kebanyakan tim menulis ADR untuk mungkin 10% pilihan arsitektur mereka – sisanya larut ke dalam utas Slack dan komentar PR. Sugarbug memunculkannya dengan menghubungkan percakapan ke perubahan kode yang dihasilkannya, sehingga Anda mendapatkan pelacakan keputusan untuk 90% sisanya tanpa mengubah alur kerja siapa pun.