Berpikir Kritis di Era AI (Critical Thinking)

• Bahkan di lingkungan ketika AI membuat kode, desain, dan jawaban, berpikir kritis untuk mengajukan pertanyaan yang tepat dan meragukan asumsi adalah kemampuan inti yang menentukan kinerja engineer dan tim
• Dalam seluruh proses pemecahan masalah, perlu memakai enam pertanyaan Who·What·Where·When·Why·How untuk memeriksa orang, masalah, konteks, timing, penyebab, dan cara eksekusi secara sistematis
• Jawaban AI harus diperlakukan sebagai objek verifikasi, seperti draf yang diusulkan oleh intern, dan struktur di mana manusia bertanggung jawab atas definisi masalah, pengumpulan bukti, pemahaman konteks, analisis penyebab, dan komunikasi tetap diperlukan
• Karena tekanan waktu, bias, dan jawaban AI yang terdengar meyakinkan, kita mudah terdorong ke kesimpulan tergesa-gesa dan solusi tambal sulam, sehingga untuk mencegahnya perlu terus mengulang pemikiran berbasis bukti seperti 5 Whys, eksperimen, dan verifikasi data
• Berpikir kritis diperkuat dalam budaya tim yang menjunjung rasa ingin tahu yang rendah hati dan bukti, dan seberapa pun AI berkembang, “memecahkan masalah yang tepat, dengan alasan yang tepat, dan dengan cara yang tepat” tetap menjadi keunggulan khas manusia

---

Gambaran umum berpikir kritis di era AI

• Di era ketika AI membuat kode, desain, dan jawaban, kemampuan berpikir kritis manusia menjadi lebih penting daripada sebelumnya
  • Seberapapun canggihnya otomatisasi, peran untuk mengajukan pertanyaan yang tepat, meragukan asumsi, dan berpikir mandiri tetap menjadi bagian manusia
  • Output AI yang dibangun di atas pertanyaan yang salah dan masalah yang didefinisikan keliru dapat mendorong proyek ke arah yang salah dengan lebih cepat
• Untuk berpikir kritis, tulisan ini menawarkan panduan praktik konkret dengan menggunakan kerangka Who·What·Where·When·Why·How
  • Setiap pertanyaan digunakan sebagai alat untuk memeriksa definisi masalah, pemangku kepentingan, konteks, timing, analisis penyebab, serta cara eksekusi dan komunikasi
  • Dalam lingkungan yang dibantu AI, tidak melewatkan enam hal ini adalah kunci untuk mengurangi kegagalan proyek dan mencegah masalah lanjutan

tl;dr: Checklist berpikir kritis untuk tim AI

• Who: Perlakukan AI sebagai input yang perlu diverifikasi, bukan entitas mahatahu, dan selalu pastikan siapa yang memberi jawaban
  • Diperlukan sudut pandang yang tidak menyamakan jawaban LLM dengan pendapat manusia, serta memisahkan sumber dan tanggung jawabnya
• What: Sebelum berlari ke solusi, perlu memperjelas definisi masalah yang sebenarnya dan kriteria keberhasilan
  • Bukan hanya kebutuhan di permukaan, tetapi masalah nyata yang harus diselesaikan perlu didefinisikan dengan jelas berdasarkan pengalaman pengguna dan data
• Where: Perlu mempertimbangkan konteks dan lingkungan tempat solusi diterapkan (sandbox, production, perangkat pengguna, dll.)
  • Selalu perlu mengingat bahwa solusi yang bekerja baik di satu lingkungan dapat menimbulkan efek samping di lingkungan lain
• When: Perlu membedakan situasi yang cukup ditangani dengan heuristik sederhana dan situasi yang memerlukan analisis mendalam
  • Dengan memisahkan waktu untuk tambalan darurat dan analisis akar masalah, kita bisa menjaga tingkat ketelitian minimum meski dalam batasan waktu
• Why / How: Lacak akar masalah dengan 5 Whys, dan berkomunikasilah berpusat pada data dan bukti, bukan opini
  • Dibutuhkan sikap yang lebih mengutamakan dasar argumen daripada klaim, dan eksperimen serta hasil pengukuran daripada intuisi

Who: pihak yang terlibat, tanggung jawab, dan cakupan dampak

• Titik awal berpikir kritis adalah komposisi orang dan perspektif yang mendefinisikan masalah serta ikut terlibat dalam penyelesaiannya (siapa yang masuk dan siapa yang tertinggal)
  • Pemangku kepentingan seperti engineer, PM, pengguna, dan pakar domain perlu diidentifikasi dan dilibatkan secara tepat dalam proses pengambilan keputusan
  • Karena sebagian besar masalah memengaruhi banyak tim dan pengguna, dibutuhkan sikap yang terlebih dahulu bertanya, “siapa yang perlu diajak berdiskusi, dan siapa yang perlu diberi tahu”
• Untuk mengurangi risiko groupthink (pemikiran kelompok), berbagai sudut pandang perlu sengaja dihadirkan
  • Jika orang dengan pandangan berlawanan atau perspektif berbeda disingkirkan, risiko bahwa sesuatu mengeras menjadi jawaban benar tanpa validasi atas data dan asumsi akan meningkat
  • Menghadirkan sudut pandang luar atau orang dari luar tim untuk melihat masalah dengan “mata baru” juga merupakan cara meningkatkan objektivitas
• Setelah AI hadir, sudut pandang untuk memisahkan “jawaban milik siapa, manusia atau AI” menjadi hal yang esensial
  • Karena LLM hanyalah mesin statistik, yang perlu diperiksa bukan “siapa yang mengatakan” melainkan “berdasarkan apa ia mengatakan itu”
  • Perlakukan kode AI seperti kode intern, dan manusia harus bertanggung jawab atas review, testing, dan verifikasi kesesuaian konteks
• Pada akhirnya, pemikiran ini juga harus mencakup tanggung jawab dan cakupan dampak (siapa yang bertanggung jawab, dan siapa yang terdampak)
  • Patch darurat mungkin langsung memenuhi permintaan manajer, tetapi beban maintenance dan penanganan insiden setelahnya bisa jatuh ke engineer lain atau pengguna
  • Seperti dampak perubahan API terhadap aplikasi mobile dan microservice lain, kita harus selalu mempertimbangkan bersama “siapa yang akan menanggung akibat keputusan ini”

What: definisi masalah yang sebenarnya dan pengumpulan bukti

• Inti berpikir kritis adalah mendefinisikan dengan tepat “apa masalah yang sebenarnya”
  • Jika ada permintaan seperti “mari tambahkan fitur ringkasan AI”, pertama-tama harus ditanyakan apakah tujuannya meningkatkan pemahaman data, mengurangi kelelahan, atau hal lain
  • Tergantung apakah kesulitan pengguna berasal dari kelebihan data, kurangnya visualisasi, atau absennya penjelasan, solusinya bisa sama sekali berbeda
• Seperti yang ditekankan Harvard Business Review, meluangkan cukup waktu untuk definisi masalah mengurangi risiko menggunakan sumber daya pada masalah yang salah
  • Perlu proses menuliskan requirement dan kriteria keberhasilan secara eksplisit, lalu menyepakati “kondisi seperti apa yang berarti masalah telah terselesaikan”
  • Kita perlu secara sadar mewaspadai plunging-in bias (bias langsung terjun), yaitu kecenderungan untuk langsung masuk ke “mode menyelesaikan masalah”
• Penting untuk membuat definisi masalah berbasis bukti yang mengumpulkan fakta konkret, bukan gejala
  • Pernyataan “layanannya lambat” itu ambigu, jadi perlu dipersempit lewat data: halaman mana, query mana, permintaan mana yang lambat
  • Kita perlu memeriksa log dan metrik melalui pertanyaan seperti “apa yang lambat, apa yang berubah sejak kapan, dan apa yang baru-baru ini diubah”
• Untuk solusi atau kesimpulan apa pun, kita perlu berulang kali memastikan “bukti apa yang mendukung kesimpulan ini”
  • Jika AI menunjuk null pointer sebagai penyebab, itu harus diverifikasi langsung melalui log, testing, dan eksperimen reproduksi
  • Saat mengklaim ada peningkatan performa, perlu dipastikan apakah ada peningkatan metrik yang konsisten di berbagai lingkungan dan berbagai eksekusi
• Jawaban LLM pada umumnya harus diperlakukan sebagai hipotesis yang tampak meyakinkan, tetapi tidak menjamin akurasi
  • Manusia cenderung berhenti menggali lebih jauh saat mendengar jawaban yang “cukup masuk akal”, sehingga kombinasi ini sangat berbahaya
  • Berpikir kritis berangkat dari premis bahwa ide AI, rekan kerja, maupun diri sendiri semuanya adalah “hipotesis yang harus diuji” dan bisa saja salah

Where: kesadaran atas konteks, lingkungan, dan cakupan

• Penting untuk memahami di mana masalah dan solusi yang ingin ditangani muncul, dan di mana ia diterapkan (konteks)
  • Untuk mencegah lonjakan CPU pada microservice tertentu disalahartikan sebagai gangguan seluruh sistem, kita harus menemukan lokasi tepat munculnya isu
  • Bergantung pada lingkungan eksekusi seperti smartphone pengguna, edge device, atau cloud server, kode yang sama bisa memiliki batasan yang sama sekali berbeda
• Saat debugging, kita perlu mempersempit “di mana kegagalan terjadi” dengan mengikuti alur request dan batas antar komponen
  • Harus dipisahkan lewat log dan monitoring apakah masalah muncul di sisi client, API gateway, backend, atau database
  • Bahkan saat mendiskusikan ide fitur, perlu dilihat juga tahap mana dalam user journey yang terdampak, dan di bagian mana frekuensi penggunaan terkonsentrasi
• Dalam eksperimen dan deployment, di mana pengujian dilakukan juga merupakan faktor keputusan yang penting
  • Tingkat kepercayaan dan risiko yang bisa diperoleh berbeda tergantung lokasi eksperimen, seperti staging, lingkungan internal, atau sebagian traffic production
  • Mengekspos A/B test ke sebagian pengguna nyata bisa membantu menemukan isu dunia nyata lebih cepat, tetapi tetap memerlukan pengaman untuk membatasi cakupan dampaknya
• Kemampuan membayangkan lebih dulu “di mana efek samping bisa muncul, dan sejauh mana dampaknya bisa menyebar” adalah ciri engineer berpengalaman
  • Saat mengubah library bersama, perlu dibuat daftar layanan dan tim lain yang menggunakannya, lalu menyiapkan notifikasi dan rencana testing sebelum rilis
  • Perlu juga meninjau dampak sistem secara keseluruhan, misalnya apakah optimasi pada modul tertentu menuntut peningkatan kompleksitas modul lain atau perubahan format data

When: sumbu waktu dan pilihan kedalaman

• Informasi tentang “kapan”, seperti waktu terjadinya masalah dan waktu tindakan, menjadi petunjuk inti dalam analisis penyebab
  • Jika kita menyusun timeline tentang “kapan terakhir kali sistem berjalan normal, dan apa yang berubah setelah itu”, penyebab bisa dipersempit dengan cepat
  • Penting untuk membiasakan diri menghubungkan waktu insiden dengan peristiwa pada slot waktu tertentu, seperti deployment baru, batch malam, atau perubahan konfigurasi
• Dalam pengambilan keputusan, membedakan kapan perlu menggali dalam dan kapan heuristik sudah cukup adalah salah satu sumbu berpikir kritis
  • Jika semua masalah dianalisis secara penuh, jadwal dan sumber daya tidak akan tertangani, sehingga kedalaman analisis harus disesuaikan menurut risiko dan dampak
  • Saat menangani insiden tengah malam, strategi yang realistis adalah memulihkan layanan dulu lewat tindakan mitigasi jangka pendek seperti restart service, lalu menyelidiki root cause pada jam kerja
• Seperti pada kasus NASA, ditunjukkan bahwa dalam stres dan tekanan waktu, kemungkinan kesalahan penilaian manusia meningkat tajam
  • Justru dalam situasi yang menuntut keputusan cepat, penting untuk menandai sebelumnya “sampai titik mana ini tindakan sementara, dan mulai dari mana harus ditinjau ulang”
  • Bahkan hanya dengan meninggalkan catatan atau tiket bahwa “ini solusi sementara, dan nanti analisis penyebab serta tindakan permanen harus dilakukan” sudah membantu kualitas jangka panjang
• Untuk menjaga ketelitian dalam waktu terbatas, kita perlu memanfaatkan prioritas dan triangulasi (triase)
  • Waktu harus dibagi dengan cara menguji asumsi paling berisiko terlebih dahulu, lalu menunda keputusan yang kurang penting
  • Jika dalam desain fitur baru validitas algoritme dan risikonya lebih besar, maka waktu sebaiknya lebih dulu dipakai untuk memverifikasi algoritme daripada detail UI
• Berpikir kritis juga terhubung dengan kemampuan mengenali “waktu untuk meminta bantuan” dan “waktu untuk berhenti dan meninjau ulang”
  • Jika tidak ada kemajuan setelah jangka waktu tertentu, perlu menarik pandangan orang lain, dan menetapkan titik henti untuk peninjauan secara sengaja, misalnya menjelang penutupan sprint atau sebelum rilis
  • Di antara analysis paralysis dan kesimpulan tergesa-gesa, penting membiasakan diri memeriksa apakah informasi yang ada sudah cukup untuk keputusan saat ini

Why: menggali motivasi, penyebab, dan dasar

• Berulang kali bertanya “mengapa kita melakukan ini” berfungsi sebagai filter untuk menyaring tren kosong atau peniruan, dan fokus pada nilai yang nyata
  • Dalam adopsi alat AI baru atau permintaan penambahan fitur, perlu dibedakan dengan jelas apakah itu demi mengejar kompetitor atau benar-benar menyelesaikan masalah pengguna
  • Harus ada jawaban yang meyakinkan untuk “mengapa ini penting”, agar banyak keputusan detail selama implementasi bisa tetap konsisten
• Saat masalah terjadi, penting menuruni lapisan dari penyebab permukaan ke penyebab yang lebih dalam dengan teknik 5 Whys
  • Misalnya untuk penurunan akurasi model, perlu menelusuri secara bertahap rangkaian penyebab seperti perubahan distribusi data, penambahan sumber data baru, ketiadaan validasi, atau kurangnya monitoring
  • Jika penyebab akhirnya adalah kurangnya validasi pipeline data dan absennya monitoring, menjadi jelas bahwa retraining saja tidak akan menyelesaikan masalah secara mendasar
• Dalam pertanyaan “why”, manusia mudah terjebak pada confirmation bias dan kesimpulan tergesa-gesa
  • Jika pikiran terpaku pada penyebab yang familier seperti memory leak yang pernah dialami sebelumnya, kemungkinan lain seperti perubahan konfigurasi baru atau perubahan data mudah diabaikan
  • Agar tidak puas pada penjelasan pertama yang muncul, dibutuhkan sikap bertanya pada diri sendiri: “adakah penyebab lain yang mungkin, dan adakah bukti yang menyangkalnya?”
• Seperti dalam kasus-kasus perusahaan di masa lalu, pemahaman “why” yang salah dapat membuat penurunan pangsa pasar atau kegagalan strategi tidak kunjung diperbaiki dalam waktu lama
  • Jika semuanya hanya disalahkan pada faktor eksternal dan masalah proses internal, kualitas, atau budaya tidak terlihat, maka resep yang keliru akan terus diulang
• Engineer yang baik mempertahankan rasa ingin tahu yang rendah hati untuk bertanya “why”, sambil tetap terbuka bahwa asumsinya sendiri bisa salah
  • Bahkan saat percaya idenya akan berhasil, ia memisahkan lebih dulu “mengapa saya berpikir begitu, apakah ini data atau intuisi”, lalu menentukan arah verifikasinya
  • Setelah keputusan dibuat, alasannya didokumentasikan dan dibagikan agar ketika situasi berubah nanti, dasar pertimbangannya bisa diperiksa ulang terlebih dahulu

How: cara praktik dan komunikasi

• Cara mempraktikkan berpikir kritis dalam keseharian dapat diringkas ke tiga sumbu: cara bertanya, verifikasi bukti, dan penataan komunikasi
  • Alih-alih pertanyaan samar seperti “bagus atau buruk”, kita perlu mengajukan pertanyaan yang konkret dan terbuka seperti “kebutuhan pengguna apa yang ditangani, dan di mana ini bisa gagal”
  • Penting membiasakan diri memisahkan daftar hal yang diketahui dan tidak diketahui, lalu merencanakan bagaimana hal yang belum diketahui itu akan diuji atau diukur
• Saat menangani bukti, kita juga perlu memeriksa kemungkinan interpretasi alternatif dan apakah ada bias yang masuk
  • Hasil satu kali performance test harus diperiksa silang: apakah itu kebetulan atau dapat diulang, dan apakah ia bertentangan dengan metrik lain
  • Kita perlu sengaja mencari bukan hanya data yang mendukung teori kita, tetapi juga data yang dapat membantahnya
• Pada level tim, diperkenalkan pula metode seperti premortem untuk mengasumsikan skenario kegagalan lebih dulu
  • Dengan mengandaikan proyek telah gagal lalu menuliskan alasannya, kita dapat mengungkap risiko dan asumsi tersembunyi yang terlewat pada tahap perencanaan
• Saat menyampaikan solusi, efektif untuk menyusun logika dalam urutan definisi masalah (What·Why) → solusi yang diusulkan (How) → data dan asumsi pendukung
  • Jika premis dan trade-off dinyatakan jelas, orang lain akan lebih mudah memverifikasi dan melengkapi ide, dan kita sendiri juga lebih mudah menemukan celah logika
  • Sikap yang mendahulukan fakta terukur daripada opini, seperti “waktu muat halaman membaik rata-rata 25% berdasarkan dashboard”, meningkatkan kepercayaan
• Dalam lingkungan tempat berpikir kritis bekerja dengan baik, akan terbentuk budaya komunikasi yang menyambut pertanyaan dan sanggahan
  • Setelah mengajukan usulan, kita secara aktif bertanya kepada rekan kerja apakah ada bagian logika yang terlewat atau hal yang dikhawatirkan, lalu mematangkan ide tersebut
  • Bukan presentasi satu arah, melainkan proses banyak orang bersama-sama memverifikasi logika itulah yang menjadi mekanisme untuk meningkatkan kualitas solusi
• Pada level individu, perbaikan cara berpikir yang berkelanjutan melalui retrospektif dan pembelajaran itu penting
  • Jika bug muncul karena keputusan yang diambil tergesa-gesa, setelahnya perlu dilakukan mini-retrospektif untuk merangkum “di mana dan apa yang terlewat, dan apa yang akan dilakukan berbeda lain kali”
  • Membaca postmortem perusahaan lain dan materi tentang bias kognitif juga membantu, karena kita bisa mempelajari lebih dulu jebakan berpikir yang perlu dihindari di masa depan

Kesimpulan: berpikir kritis sebagai keunggulan khas manusia

• Semakin tinggi pemanfaatan AI, berpikir kritis menjadi bukan lagi pilihan, melainkan kemampuan yang wajib
  • Melalui Who·What·Where·When·Why·How, kita perlu memeriksa secara sistematis orang, masalah, konteks, timing, penyebab, dan cara eksekusi
• Dalam budaya tim yang sehat, berpikir mandiri dan sikap gemar bertanya diterima sebagai sesuatu yang wajar
  • Semua orang harus bisa bertanya, “apakah ini benar-benar solusi atau hanya tambalan?”, “apakah pengguna benar-benar menginginkan fitur ini?”, dan “apakah data benar-benar menunjukkan perbaikan?”
• Berpikir kritis berperan melindungi tim dari godaan solusi cepat yang tambal sulam
  • Daripada sekadar menutupi masalah saat ini, memeriksa akar penyebab dan memverifikasinya sebelum bertindak adalah jalan yang menghemat waktu dan biaya dalam jangka panjang
• Bahkan di era ketika AI dan otomatisasi menangani pekerjaan berulang dan draf awal, “memecahkan masalah yang tepat, dengan alasan yang tepat, dan dengan cara yang tepat” tetap menjadi peran manusia
  • Tim yang mempertahankan rasa ingin tahu yang rendah hati dan pemikiran berbasis bukti akan menjadi tim yang terus menghasilkan hasil baik bahkan di era AI