Sebelum lanjut, satu catatan kecil. Tulisan ini tidak menunjuk siapa-siapa. Kita semua pernah menjadi bagian dari pola yang sama — di berbagai titik karier. Kalau ada bagian yang terasa familier, itu bukan kebetulan, dan itu bukan tuduhan. Anggap saja ini cermin: kita lihat bareng-bareng, lalu masing-masing pulang membawa refleksinya sendiri.
Pernah ikut lomba cerdas cermat? Ada bel, ada timer, ada juri. Yang paling cepat menekan bel dan menjawab dengan benar dialah pemenangnya. Semua orang bisa melihat siapa yang menang, dan kapan.
Dunia pengembangan software tidak seperti itu. Tidak ada bel. Tidak ada timer. Tidak ada juri yang mengangkat papan skor di depan mata.
Tapi sejak AI masuk ke dunia coding — baik lewat vibecoding maupun code assist — rasanya semakin banyak di antara kita yang bertingkah seperti sedang berada di lomba itu.
Fenomena: Menjawab Sebelum Memahami
Dulu, "bisa bikin fitur ini?" butuh waktu untuk dipikirkan. Sekarang, pertanyaan itu sering dijawab dengan refleks: "Bisa. Gampang. Bentar."
Dan memang benar — membuatnya gampang. AI bisa menghasilkan ratusan baris kode dalam hitungan menit. Biaya untuk memproduksi sesuatu anjlok drastis.
Tapi ada satu biaya yang tidak ikut anjlok: biaya untuk memahami.
AI mempercepat penulisan, bukan pemahaman. Kalau kita tidak paham masalahnya, AI hanya membuat kita lebih cepat menghasilkan hal yang salah. Lebih cepat, tapi sama jauhnya dari sasaran.
Dan di sinilah jiwa marketer seharusnya bekerja. Marketer tidak pernah bertanya "bagaimana membuat ini?" — ia bertanya "siapa yang akan memakai ini, dan apa yang mereka rasakan?" Ketika pertanyaan itu hilang dari proses kita, kita bukan lagi membangun solusi. Kita hanya memproduksi output. Kode yang tidak lahir dari pertanyaan manusia hanyalah sintaks yang berjalan — bukan solusi yang hidup.
Sebuah Cerita yang Mungkin Terdengar Familier
Bayangkan sebuah halaman dashboard yang harus dibuat dari desain yang sudah disiapkan tim. Ada tabel data, filter, grafik, dan beberapa kondisi yang harus ditangani: loading, kosong, error.
Rasanya mudah banget — tinggal tempel komponen dari AI, rapikan sedikit, selesai. Belum sampai hari yang dijanjikan, kabar sudah terkirim: "sudah jadi."
Dan benar — halamannya jalan. Tidak error di browser. Tampak produktif.
Tapi yang tidak sempat dilakukan: mengecek di layar mobile — ternyata tabelnya amburadul. Tidak mengecek kondisi kosong — ternyata yang muncul teks asal, karena tidak pernah dibayangkan bagaimana halaman itu seharusnya bicara saat tidak ada data. Tidak mengecek kondisi loading — ternyata grafiknya muncul sebelum data siap, dan sempat tampak "mati" beberapa detik. Dan yang paling mendasar: tidak pernah ada pertanyaan ke tim produk, "ketika user tidak punya data, apa yang ingin mereka lihat?" Hanya asumsi.
Padahal jawabannya sudah ada di depan mata — tinggal bertanya. Tapi bertanya artinya mengakui bahwa "sudah jadi" belum benar-benar jadi.
Hasilnya? Tim produk bolak-balik memberi masukan, QA menulis banyak bug, dan hampir separuh halaman dikerjakan ulang. Total waktunya lebih lama daripada kalau sejak awal ditanya dulu, dicek dulu, dipikirkan dulu.
Yang paling membekas dari cerita ini bukan bug-nya, bukan juga revisinya. Tapi perasaan ketika tahu rekan-rekan harus menebak-nebak maksud halaman itu — padahal pertanyaannya bisa diajukan di awal. Kecepatan tanpa pemahaman itu bukan produktivitas. Itu cuma memindahkan biaya — dari kita ke orang lain.
Tanda-tanda Kita Sedang Lomba Cerdas Cermat
Cerita di atas mungkin terasa familier. Coba cek bersama-sama, tanda-tanda ini ada di mana:
- "Sudah jadi" diucapkan sebelum "sudah paham". Pertanyaan belum selesai, jawaban sudah datang.
- Definisi "jadi" = build tidak error. Tidak ada pengujian, tidak ada pengecekan standar, tidak ada verifikasi terhadap kebutuhan sebenarnya.
- Dokumentasi dibuat, tapi tidak diuji. Postman/Apidog sudah diisi, tapi payload tidak dicek benar atau kurang, response tidak dicek apakah sudah standard dengan yang lain. Lengkap di atas kertas, kosong di lapangan.
- Pekerjaan dianggap selesai, lalu dilempar. Diserahkan begitu saja ke tim berikutnya, dengan keyakinan bahwa kalau ada masalah "pasti nanti ketahuan sendiri".
- PRD hasil generate AI, tidak dibaca sendiri. Dokumennya rapi, lengkap, profesional. Tapi ketika ditanya detailnya — "kenapa begini?" — jawabannya: "ini AI yang buat, bisa dihapus kalau tidak cocok." Artinya, dokumen itu tidak pernah benar-benar dibaca oleh orang yang menyerahkannya.
Gejala kelima ini yang paling mengganggu. Bukan karena AI-nya salah — AI memang alat yang luar biasa. Yang mengganggu adalah ketika AI dijadikan alibi untuk berhenti berpikir. Kalau hasilnya salah, salahkan AI. Kalau bagus, saya yang prompt-nya.
Itu bukan "memanfaatkan AI". Itu menyerahkan otak ke AI.
Dampak Domino yang Tidak Terlihat
Inilah bagian yang sering luput. Kode yang lahir dari kecepatan tanpa pemahaman tidak pernah tinggal diam. Dia mengalir.
Ke QC, yang harus menebak-nebak apa maksudnya. Ke FE, yang harus menyesuaikan diri dengan bentuk data yang asal. Ke end-user, yang akhirnya menerima fitur yang terasa "setengah jadi". Dan ke tim bisnis, yang kehilangan kepercayaan pada tim engineering.
Biaya dari semua ini — waktu, energi, kepercayaan — jauh lebih mahal daripada sepuluh menit berpikir di awal.
Marketer akan menyebut ini dengan satu kata: konversi yang mati. Karena pada akhirnya, manusia di ujung sana tidak sedang menilai kecepatan kita — mereka menilai apakah masalahnya selesai. Dan kepercayaan yang hilang itu, sekali jatuh, jauh lebih mahal untuk dibangun kembali daripada sepuluh menit berpikir di awal.
Tapi Tunggu — Mari Kita Bijak Dulu
Sebelum kita menghakimi siapa-siapa, mari berhenti sejenak. Karena tidak semua hal yang terlihat seperti ini otomatis salah. Konteks menyeluruh menentukan benar atau salahnya.
Bisa jadi rekan kita sedang dikejar deadline yang tidak masuk akal. Todo-nya bertumpuk, beban kerjanya berat, atau sedang ada hal-hal dalam hidupnya yang tidak kita ketahui — masalah keluarga, kesehatan, tekanan dari atas.
Mungkin dia bukan malas berpikir. Mungkin dia sedang bertahan hidup.
Jadi jangan buru-buru menyimpulkan. Kritik yang tajam tanpa empati hanya akan menutup telinga, bukan membuka pikiran. Kalau kita ingin berhenti berlomba cerdas cermat, kita juga harus berhenti menghakimi dari kejauhan. Tanyakan, dengarkan, lalu bantu.
Karena justru ketika beban sedang berat itulah, kecepatan dan ketepatan adalah hal yang paling dibutuhkan — dan hal yang paling sulit dihasilkan. Sebagai tim, kita memikul itu bersama.
Sebelum Menulis Kode, Tanya Lima Hal Ini
Baik untuk diri sendiri, maupun untuk tim:
- Masalah apa yang sebenarnya mau diselesaikan? — bukan fiturnya, tapi masalahnya.
- Siapa yang akan merasakan dampaknya? — dan seperti apa rasanya bagi mereka?
- Apa efeknya terhadap sistem yang sudah berjalan? — domino effect, bukan cuma endpoint.
- Bagaimana cara membuktikan ini benar-benar berfungsi? — bukan "tidak error", tapi "memecahkan masalah".
- Apakah aku benar-benar paham, atau cuma bisa menjawab? — pertanyaan terberat, dan paling jarang ditanyakan.
Penutup
Di lomba cerdas cermat, yang menang adalah yang paling cepat menekan bel.
Di dunia nyata, yang bertahan adalah yang paling paham. Orang yang bisa berkata "sebentar, saya pikirkan dulu" — dan itu justru tanda kekuatan, bukan kelemahan.
Kita tidak sedang lomba cerdas cermat. Kita sedang membangun solusi untuk manusia, bukan untuk mesin — dan manusia tidak sedang menghitung detik kita. Mereka menghitung apakah masalahnya benar-benar selesai, dan apakah hidup mereka sedikit lebih mudah karena kode yang kita tulis.
Jadi lain kali, sebelum menjawab "bisa, bentar" — tanyakan dulu pada dirimu: apakah aku sedang menekan bel, atau sedang memahami soal untuk menjawab?