Otot Keputusan Teknis yang Melemah: Bahaya Menggantikan Intuisi dengan Rekomendasi AI

Kapan terakhir kali kamu membuat keputusan teknis yang benar-benar substantial tanpa bertanya kepada AI? Bukan keputusan sepele seperti memilih nama variabel atau format tanggal. Maksudnya keputusan yang berbobot: memilih arsitektur untuk sistem baru, menentukan apakah suatu library layak diadopsi, atau memutuskan kapan waktu yang tepat untuk refactoring modul krusial. Jika kamu kesulitan mengingatnya, kamu tidak sendirian. Stack Overflow Developer Survey 2024 menemukan bahwa 76% developer kini menggunakan atau berencana menggunakan AI tools dalam proses development mereka, melonjak dari 70% tahun sebelumnya. Angka itu terdengar seperti kemajuan. Tapi di baliknya tersimpan sebuah pertanyaan yang jarang dipertanyakan: jika kita terus menyerahkan keputusan teknis kepada mesin, apa yang terjadi pada otot keputusan kita sendiri?

Artikel ini bukan serangan terhadap AI. Saya sendiri menggunakan Copilot, Claude, dan berbagai tools AI hampir setiap hari. Tapi saya mulai menyadari ada garis tipis antara menggunakan AI sebagai alat bantu dan menjadikannya pengganti intuisi. Garis itu semakin kabur, dan konsekuensinya lebih serius dari yang kita kira.

Intuisi Teknis Bukan Bakat, Otot

Banyak yang mengira intuisi teknis adalah semacam bakat anugerah: beberapa orang dilahirkan dengan insting tajam untuk smell code yang buruk atau arsitektur yang rapuh. Faktanya, intuisi teknis adalah produk dari repetisi yang disengaja. Ini adalah model Dreyfus dalam aksi: developer junior mengikuti aturan secara eksplisit, sementara developer senior beroperasi pada level intuitif karena mereka telah menjalani ratusan skenario serupa. Otak mereka telah membangun pattern recognition yang tidak bisa didapat dari membaca dokumentasi semata.

Bayangkan seorang chef yang telah memasak ribuan steak. Ia tidak perlu termometer untuk tahu kapan daging mencapai medium rare. Ia bisa merasakannya dari tekstur, warna, dan bau. Intuisi teknis bekerja serupa. Developer senior yang telah membangun puluhan sistem distributed bisa merasakan kapan suatu desain akan mengalami race condition, meski belum ada baris kode yang ditulis. Mereka tidak melakukan analisis formal. Mereka hanya tahu. Tahuannya datang dari bekas luka.

AI Sebagai Kruk yang Tidak Pernah Dilepas

Masalahnya, AI coding assistant bekerja dengan cara yang secara fundamental berbeda dari proses pembelajaran manusia. Ketika kamu menghadapi bug yang membingungkan dan AI langsung memberikan solusi, kamu memang menyelesaikan masalah lebih cepat. Tapi kamu melewatkan fase yang paling penting dalam pembelajaran: struggle. Robert Bjork, psikolog kognitif dari UCLA, meneliti fenomena yang ia sebut desirable difficulties: kesulitan yang terkontrol justru memperkuat memory dan pemahaman. Tanpa struggle, pengetahuan tidak pernah benar-benar tertanam.

AI menghilangkan struggle tersebut. Bug yang seharusnya memakan waktu dua jam dan meninggalkan bekas pemahaman mendalam, kini terselesaikan dalam dua menit dengan copy-paste. Developer tidak lagi mengalami frustrasi yang memaksa mereka memahami root cause. Mereka hanya menerima jawaban, mengujinya secara dangkal, lalu melanjutkan tugas berikutnya. Ini bukan learning. Ini adalah delegation tanpa transfer pengetahuan.

Ironisnya, semakin sering kita menggunakan AI untuk keputusan teknis, semakin sering kita membutuhkan AI untuk keputusan teknis berikutnya. Kruk yang seharusnya hanya dipakai saat kaki patah malah menjadi alat berjalan permanen. Otot yang tidak pernah dipakai akan atrofi. Dan otot keputusan teknis tidak terkecuali.

Paradoks Developer Senior di Era AI

Fenomena yang paling menarik adalah paradoks senior developer. Developer dengan pengalaman bertahun-tahun justru sering kali menjadi pengguna AI paling intensif. Mereka punya uang untuk berlangganan Copilot, akses ke Claude Pro, dan budget untuk API berbayar. Dengan AI, mereka menghasilkan kode dengan kecepatan yang belum pernah terjadi sebelumnya. PR yang dulu butuh seminggu kini selesai dalam dua hari.

Tapi kecepatan itu datang dengan harga tersembunyi. Seorang principal engineer yang saya kenal baru-baru ini mengakui sesuatu yang mengejutkan: setelah setahun penuh menggunakan AI assistant, ia menyadari kemampuannya untuk menilai kode tanpa bantuan telah menurun. Ia bisa merasakan bahwa suatu arsitektur terasa salah, tapi ia tidak lagi bisa mengartikulasikan dengan tepat mengapa. Dulu ia bisa menjelaskan dalam lima paragraf yang presisi. Kini ia hanya bisa berkata, Ini terasa aneh. Intuisinya masih ada, tapi kemampuan untuk memvalidasi dan menjelaskan intuisi tersebut telah memudar karena ia terlalu sering membiarkan AI yang melakukan penjelasan.

Ini adalah versi teknis dari automation bias: kecenderungan manusia untuk mempercayai output mesin lebih dari judgment sendiri. Dalam aviation, fenomena ini telah menyebabkan beberapa kecelakaan fatal ketika pilot terlalu percaya pada autopilot. Dalam software engineering, konsekuensinya lebih lambat tapi tidak kalah merusak: arsitektur yang rapuh, keputusan yang tidak teruji, dan tim yang kehilangan kemampuan untuk berpikir kritis.

Bahaya yang Tersembunyi di Balik Kecepatan

Stack Overflow Survey 2024 mencatat bahwa 79% developer menganggap misinformasi dan disinformasi dalam hasil AI adalah masalah etika terbesar. Tapi ada bahaya lain yang tidak tercatat dalam survei: kehilangan kemampuan untuk mendeteksi misinformasi tersebut. Jika developer telah kehilangan intuisi teknisnya, bagaimana mereka bisa menilai apakah rekomendasi AI benar atau salah?

Saya pernah menyaksikan sebuah tim memutuskan menggunakan database vector untuk fitur yang sebenarnya lebih cocok diselesaikan dengan inverted index sederhana. Alasannya: AI merekomendasikannya. Mereka menghabiskan tiga minggu membangun infrastruktur yang tidak perlu, menambahkan complexity tanpa nilai, dan akhirnya menulis ulang dengan pendekatan yang lebih sederhana. Keputusan itu tidak merusak bisnis, tapi menguras waktu dan energi. Dan yang lebih mengkhawatirkan: tidak ada yang dalam tim tersebut yang berpikir untuk mempertanyakan rekomendasi AI di awal. Mereka telah terlalu terbiasa dengan pola menerima tanpa mempertanyakan.

Bukan berarti AI selalu salah. Tapi keputusan teknis yang baik memerlukan konteks yang AI tidak miliki: budaya tim, kendala budget, appetite untuk technical debt, dan roadmap produk jangka panjang. AI memberikan jawaban yang benar secara teknis untuk pertanyaan yang sering kali salah secara kontekstual.

Menggunakan AI sebagai Sparring Partner, Bukan Orakel

Jadi apa solusinya? Berhenti menggunakan AI sama sekali? Tentu tidak. AI adalah alat yang luar biasa powerful. Tapi cara kita menggunakannya perlu berubah. Alih-alih meminta jawaban, kita harus meminta perspektif. Alih-alih menerima solusi, kita harus menggunakan AI untuk menguji asumsi kita sendiri.

Berikut praktik yang saya terapkan sendiri dan mulai ajarkan ke tim:

• Jangan tanya apa solusinya, tanya apa tradeoff-nya. Ketika menghadapi keputusan arsitektur, saya gunakan AI untuk mengeksplorasi tradeoff dari setiap opsi, bukan untuk memilih satu pemenang. Ini memaksa saya tetap aktif dalam proses evaluasi.

• Tulis solusi sendiri dulu, baru minta AI mengkritik. Jika saya meminta AI menulis kode dari nol, saya kehilangan kesempatan untuk berpikir. Tapi jika saya menulis draf sendiri dan meminta AI mengidentifikasi edge case atau anti-pattern, saya tetap membangun otot keputusan saya.

• Paksa diri untuk menjelaskan jawaban AI sebelum menerimanya. Jika AI memberikan rekomendasi dan saya tidak bisa menjelaskan mengapa rekomendasi itu benar dalam bahasa saya sendiri, saya tolak. Saya telusuri lebih dalam sampai saya benar-benar mengerti.

• Alihkan AI dari tugas berpikir ke tugas mekanis. AI sangat baik untuk boilerplate, refactoring format, dan generate test cases. Tapi keputusan desain, penilaian tradeoff, dan estimasi risiko harus tetap menjadi domain manusia.

Pertanyaan yang Harus Kita Ajukan pada Diri Sendiri

Di akhirnya, ini bukan perdebatan teknis. Ini adalah perdebatan filosofis tentang apa artinya menjadi engineer. Jika software engineering hanya tentang menghasilkan baris kode sebanyak mungkin dalam waktu sesingkat mungkin, maka AI adalah pemenang mutlak dan kita hanyalah operator. Tapi jika software engineering adalah disiplin yang memerlukan judgment, taste, dan tanggung jawab atas keputusan, maka kita harus dengan sengaja melindungi otot-otot yang membuat kita tetap menjadi engineer.

Survey menunjukkan 70% developer profesional tidak menganggap AI sebagai ancaman pekerjaan. Mungkin mereka benar. Tapi ancaman yang sebenarnya bukanlah AI menggantikan pekerjaan kita. Ancaman yang sebenarnya adalah kita secara sukarela menyerahkan kapasitas berpikir yang membuat pekerjaan kita bernilai. Kita tidak dipecat oleh mesin. Kita mengundurkan diri secara bertahap dengan setiap keputusan yang kita serahkan.

Jadi pertanyaannya bukan apakah kamu menggunakan AI. Pertanyaannya adalah: kapan terakhir kali kamu membuat keputusan teknis yang benar-benar menjadi milikmu, bukan milik algoritma yang kamu sewa?