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 yang baru keliatan belakangan: mental model beda buat gimana context dibangun, konvensi beda buat di mana config-nya taruh, workflow yang nggak nyambung mulus. Jadi sekarang ada checklist beneran yang saya jalanin sebelum ngasih sesuatu yang baru nyentuh codebase klien.

Bisa nggak dia baca konvensi yang udah ada?

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. Saya pernah skip adopsi satu tool murni karena cost nulis ulang semuanya ke format baru nggak worth-it dibanding yang bakal saya dapet.

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 generate app Next.js baru dari nol hampir nggak ngasih tau apa-apa soal gimana dia bakal jalan pas disuruh nambahin fitur di codebase 40.000 baris dengan keanehannya sendiri. Jadi test-nya selalu sama: ambil satu ticket beneran yang lumayan nyebelin, kasih ke tool baru di branch yang nggak ada yang gantungin, terus liat apa yang terjadi pas codebase-nya ngelawan dikit.

Data saya diapain, spesifik — bukan yang ditulis di halaman privacy

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, disimpen lewat sesi, atau diproses di yurisdiksi yang penting buat compliance mereka. Saya tanya ini langsung, tertulis, sebelum kode dari repo klien nyentuh tool baru. Lebih dari sekali jawaban jujurnya ngubah data yang beneran saya kasih — fixture yang udah disanitize, bukan yang asli.

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 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 paling makan jam saya, karena output pede-tapi-salah itu persis jenis bug yang lolos dari review cepat.

Bisa nggak saya beneran rollback

Beberapa tool mau megang lebih banyak bagian workflow dibanding yang saya nyaman kasih di hari pertama — branch management sendiri, konvensi commit sendiri, cara sendiri nyusun deskripsi PR. Saya cek: kalau saya pake tool ini dua minggu terus mutusin pergi, repo saya ada di kondisi yang bisa diambil bersih sama tool lain, atau udah ketanem asumsi yang cuma dia sendiri ngerti? Tool yang beneran bagus nggak perlu ngunci saya buat buktiin dirinya.

Biaya, dibanding yang udah saya bayar sekarang — bukan dibanding nol

Halaman pricing tiap tool baru selalu bandingin dirinya sama ngerjain manual, yang 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 buat justify belajar ulang kebiasaan sendiri.” Itu alasan terbesar kenapa saya tetep pake toolset inti yang sama selama berbulan-bulan, sambil nyoba banyak yang lain di samping.

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

Bukan berarti saya jadi anti tool baru — saya masih coba kebanyakan yang dirilis, karena bidang ini gerak cepat dan diem aja punya cost sendiri. Cuma berarti nyoba itu beda sama adopsi, dan gap antara dua hal itu dulu makan waktu saya lebih banyak dari yang saya sadar.