Checklist Saya Sebelum Ngasih Tool AI Baru Deket-Deket Proyek Klien

Sekarang hampir tiap minggu ada tool coding AI baru yang diumumin — agent baru, fork IDE baru, CLI baru yang janjinya bakal bikin yang lain jadi usang. Dulu saya coba hampir semuanya, karena penasaran beneran dan takut ketinggalan kalau ternyata ada tool yang beneran lebih bagus. Kebiasaan itu makan waktu saya lebih banyak dari yang dihemat, karena ganti tool di tengah proyek punya cost beneran yang baru keliatan belakangan: mental model yang beda buat gimana context dibangun, konvensi beda buat di mana config-nya taruh, dan workflow yang nggak nyambung mulus. Jadi saya bikin checklist beneran yang saya jalanin sebelum ngasih sesuatu yang baru nyentuh codebase klien, daripada adopsi cuma karena video demo-nya keliatan keren.

Pertama: bisa nggak dia baca file konvensi yang udah ada tanpa saya harus nulis ulang buat tool barunya? Setiap proyek yang saya maintain punya semacam CLAUDE.md atau yang setara — catatan arsitektur, konvensi naming, hal-hal yang kontributor baru (manusia atau agent) perlu tau biar nggak langsung ngerusak pola codebase-nya. Kalau tool baru butuh format config sendiri yang beda buat dapet context yang setara, itu nggak otomatis bikin gagal, tapi itu cost beneran yang saya timbang dibanding apapun yang diklaim tool-nya lebih bagus. Saya pernah skip adopsi tool murni karena cost migrasi buat nulis ulang semuanya ke format baru nggak worth-it dibanding yang bakal saya dapet.

Kedua: saya test di branch buangan dari proyek beneran, bukan repo mainan. Video demo dan quickstart tutorial dibikin di codebase yang nggak punya keanehan legacy, nggak ada pola setengah-migrasi, nggak ada lima puluh keputusan kecil yang numpuk dua tahun. Proyek beneran saya punya semua itu. Tool yang keliatan brilian pas generate app Next.js baru dari nol itu hampir nggak ngasih tau apa-apa soal gimana dia bakal jalan pas disuruh nambahin fitur di codebase 40.000 baris yang udah ada dengan keanehannya sendiri. Jadi test-nya selalu: ambil satu ticket beneran yang lumayan nyebelin dari proyek beneran, kasih ke tool baru di branch yang nggak ada yang gantungin, terus liat apa yang terjadi pas codebase-nya sedikit ngelawan.

Ketiga: apa yang terjadi ke data saya, spesifik, bukan apa yang ditulis di halaman privacy secara umum. Buat kerjaan klien ini nggak opsional — beberapa kontrak saya punya klausul eksplisit soal di mana kode boleh dikirim, dan “kami pakai praktik keamanan standar industri” di landing page nggak jawab apakah logic proprietary klien tertentu dipakai buat training model lebih lanjut, atau disimpen lewat sesi, atau diproses di yurisdiksi yang penting buat compliance mereka. Saya tanya ini langsung, tertulis, sebelum kode dari repo klien pernah nyentuh tool baru. Lebih dari sekali jawaban jujurnya ngubah data yang beneran saya kasih — fixture yang udah disanitize, bukan yang asli — meskipun akhirnya saya tetep adopsi tool-nya buat kerjaan lain.

Keempat: dia degradasi dengan sopan atau gagal diam-diam? Ini yang paling saya pedulikan dan yang nggak pernah ditunjukin video demo, karena demo nggak nunjukin kasus gagalnya. Saya sengaja kasih tool baru task yang sedikit di luar hal yang jelas dia bisa — requirement yang ambigu, file dengan pola yang nggak biasa — terus liat apa yang dia lakuin pas dia nggak yakin. Beberapa tool nanya klarifikasi atau flag ketidakyakinannya sendiri. Yang lain dengan pede ngehasilin sesuatu yang keliatan masuk akal tapi salah, tanpa sinyal kalau dia lagi nebak. Kategori kedua itu yang makan jam saya belakangan, karena output yang pede-tapi-salah itu persis jenis bug yang lolos dari review cepat — saya udah pernah nulis soal itu jadi risiko beneran dari kode hasil agent, lebih dari output yang jelas-jelas jelek.

Kelima: bisa nggak saya beneran rollback kalau ternyata nggak cocok? Beberapa tool mau megang lebih banyak bagian workflow dibanding yang saya nyaman kasih di hari pertama — branch management sendiri, konvensi commit sendiri, cara sendiri buat nyusun deskripsi PR. Saya cek apa yang terjadi kalau saya pake tool itu dua minggu terus mutusin buat pergi: repo saya ada di kondisi yang bisa diambil bersih sama tool lain atau editor biasa, atau tool-nya udah nanem asumsi ke proyek yang cuma dia sendiri yang ngerti? Tool yang beneran bagus nggak perlu ngunci saya buat buktiin dirinya — yang bikin proses keluarnya sengaja nyebelin itu justru ngasih tau sesuatu soal seberapa yakin mereka sama value mereka sendiri.

Keenam: biaya, diukur dibanding yang udah saya bayar sekarang, bukan dibanding nol. Halaman pricing tiap tool baru selalu bandingin dirinya sama ngerjain manual, yang mana bukan perbandingan yang penting buat saya — saya bukan lagi milih antara tool ini sama nggak pake AI sama sekali, saya milih antara tool ini sama yang udah saya pake dan udah saya bangun kebiasaan workflow di sekitarnya. Bar buat pindah itu bukan “lebih bagus dari nggak ada,” tapi “cukup lebih bagus dari yang udah saya punya buat justify belajar ulang kebiasaan saya sendiri.” Bar itu lebih tinggi dari yang mau dipercayain kebanyakan pengumuman launching, dan itu alasan terbesar kenapa saya tetep pake toolset inti yang sama selama berbulan-bulan sambil nyoba banyak yang lain di samping.

Yang beneran diselametin sama checklist ini: dua tool tahun ini yang keliatan beneran mengesankan di demo mereka sendiri terus ambruk pas step dua — codebase beneran, mess beneran — dalam sejam pemakaian beneran. Kegagalan itu nggak bakal keliatan kalau saya nilai mereka kayak kebanyakan orang nilai tool baru, yaitu nonton demo lima menit orang lain yang mulus terus ngira-ngira dari situ. Demo itu tool di kondisi terbaiknya, di codebase yang dibikin biar dia keliatan bagus. Checklist saya cuma usaha buat liat dia lebih deket ke kondisi terburuknya, di codebase yang mirip kerjaan beneran saya, sebelum saya taruhin jam kerja klien beneran ke situ.

Ini semua nggak bikin saya anti-tool-baru — saya masih coba kebanyakan yang dirilis, karena bidang ini gerak cukup cepat sampai diem aja punya cost sendiri. Ini cuma berarti nyoba itu beda sama adopsi, dan gap antara dua hal itu dulu makan waktu saya lebih banyak dari yang saya sadar sampai saya mulai nge-track itu dengan sengaja.