- Praktik paling kontraintuitif di era AI adalah mengetahui kapan harus melambat, dan makin murah eksekusi menjadi, makin penting pengambilan keputusan pada tahap sebelumnya
- Kerangka System 1 (pencocokan pola cepat) dan System 2 (pemikiran analitis yang lambat) dari Daniel Kahneman diterapkan pada pengembangan perangkat lunak di era AI
- Requirement atau asumsi desain yang salah akan menyebar lebih cepat lewat AI, sehingga efektivitas biaya dari tahap lambat sebelum eksekusi menjadi maksimal
- AI bisa dimanfaatkan bukan hanya untuk eksekusi, tetapi juga untuk mempercepat tahap perenungan seperti tinjauan awal, pre-mortem, dan eksplorasi edge case
- Untuk menghadapi budaya baru tekanan kecepatan seperti “kan tinggal pakai AI?”, dibutuhkan strategi untuk secara eksplisit menampilkan tahap lambat dan memberi batas waktu padanya
Dua Kecepatan Berpikir
- Dua mode berpikir dari Thinking, Fast and Slow karya Daniel Kahneman diterapkan ke pengembangan di era AI
- System 1: pemikiran cepat, otomatis, dan berbasis pencocokan pola
- System 2: pemikiran lambat, disengaja, dan analitis
- Dalam percakapannya dengan Dwarkesh Patel, Andrej Karpathy mengibaratkan LLM sebagai hantu atau jin, sebuah hasil distilasi statistik dari teks manusia: kata masuk, pola dicocokkan, lalu kata keluar; pada dasarnya entitas yang sangat bercorak System 1
- AI sangat unggul dalam pencocokan pola cepat berskala besar, tetapi pekerjaan untuk menilai apa yang harus dibuat, mengapa itu penting, dan apakah masalah yang diselesaikan sudah benar, tetap berada di ranah penilaian manusia
- Poin kontraintuitifnya: AI tidak membuat tahap lambat menjadi kurang penting, melainkan lebih penting
- Saat eksekusi menjadi murah dan cepat, leverage berpindah ke pengambilan keputusan sebelum eksekusi
- Requirement yang salah, masalah yang disalahpahami, dan asumsi desain yang cacat akan menyebar ke semua hal yang dibangun AI, dan kini menyebar lebih cepat
- Semakin kuat System 1, semakin besar biaya dari System 2 yang dijalankan dengan buruk
Ilusi Kecepatan
- Ada lelucon lama di dunia akademik: “pekerjaan beberapa jam di perpustakaan bisa memakan waktu berminggu-minggu di laboratorium”; versi perangkat lunaknya: “beberapa minggu coding menghemat beberapa jam perencanaan”
- Intinya justru kebalikannya — ketika mulai terburu-buru, kesalahan mendasar baru akan ditemukan belakangan dan diikuti rework yang menyakitkan
- Dalam rekayasa perangkat lunak, ada intuisi yang jelas bahwa kesalahan harus ditangkap sedini mungkin, yakni pada tahap requirement atau desain
- Diagram kotak mudah diubah, requirement yang disalahpahami lebih sulit, dan arsitektur deployment yang cacat secara mendasar bisa berarti menulis ulang
- Masalah dengan AI: ia bisa menciptakan technical debt lebih cepat dari sebelumnya
- Jika keputusan sebelum eksekusi cacat, AI akan mengimplementasikan cacat itu dengan setia dalam bentuk kode fitur lengkap yang tampak meyakinkan
- Ia dapat menghasilkan ribuan baris kode berdasarkan requirement yang salah dipahami, dan dengan senang hati membangun solusi elegan untuk masalah yang salah
- Ilusi kecepatan: terasa seperti sedang membuat kemajuan, padahal sebenarnya sedang menggali lubang yang lebih dalam
- Jawabannya bukan meninggalkan kecepatan, melainkan menempatkannya dengan sengaja — kecepatan AI sebaiknya dilepaskan hanya setelah arah yang benar sudah dipastikan
Saat Kelambatan Menjadi Efektif
- Titik di mana kelambatan yang disengaja memberi dampak besar pada dasarnya tidak berubah
- Requirement murah diubah saat masih berupa kata-kata di dokumen, dan mahal saat sudah menjadi kode yang di-deploy untuk melayani pengguna nyata
- Keputusan desain mudah direvisi di diagram, tetapi sulit di sistem produksi
- AI tidak mengubah fisika dasarnya, tetapi meningkatkan leverage ketika dilakukan dengan benar
- Protokol Thinking First: titik termurah untuk menangkap kesalahan adalah meluangkan waktu sebelum menyerahkan pekerjaan ke AI untuk memperjelas apa yang sebenarnya diinginkan
- Ada paradoks menarik bahwa AI bisa dipakai bukan hanya untuk mempercepat eksekusi, tetapi juga untuk mempercepat proses berpikir itu sendiri
- Memperjelas requirement sebelum coding: luangkan 10 menit untuk menuliskan masalah yang ingin diselesaikan, kriteria sukses, dan batasan, lalu minta AI meninjau tulisan itu sebelum mulai menghasilkan sesuatu
- Menjalankan pre-mortem: sebelum memfinalkan desain, tanyakan ke AI, “apa yang bisa salah dari pendekatan ini?” untuk memunculkan risiko yang belum terpikirkan
- Membalik masalah (Invert): tanyakan ke AI, “apa yang akan membuat proyek ini gagal?” untuk menyingkap asumsi tersembunyi
- Membangun prototipe yang akan dibuang: buat dalam hitungan jam dengan AI, tunjukkan ke stakeholder, lalu validasi pemahaman sebelum berinvestasi — investasi kecepatan demi kelambatan
- Membangun alat internal sederhana: sebelum mengeluarkan biaya untuk produk nyata, buat versi kasar dulu dengan AI agar bisa melihat apa yang benar-benar dibutuhkan dan apa yang tidak
- Menggali edge case lebih awal: sebelum implementasi dimulai, minta AI menghasilkan edge case dan failure mode dari desain agar bisa ditangani saat masih di tahap diagram
Angin Sakal Budaya yang Baru
- “Kan tinggal pakai AI?” adalah bentuk baru dari tekanan kecepatan, dan sangat berbahaya karena mencampuradukkan tampilan produktivitas dengan throughput yang nyata
- AI bisa menghasilkan kode dalam hitungan detik, tetapi menghasilkan kode dan menyelesaikan masalah yang benar bukanlah hal yang sama
- Strategi merespons:
- Bagikan secara eksplisit sedang berada di tahap apa: jika sedang berada di tahap lambat, jelaskan bahwa Anda sedang memperjelas requirement, memikirkan edge case, atau memastikan masalah yang diselesaikan memang benar
- Libatkan stakeholder: biaya memasukkan masukan stakeholder sekarang murah, nanti akan mahal
- Bagikan proses kerja: dokumentasi requirement, sketsa desain, hasil pre-mortem, dan artefak tahap lambat lainnya perlu dibuat terlihat untuk menunjukkan bahwa pekerjaan sedang berlangsung
- Beri timebox pada tahap lambat: buat batas yang jelas seperti “2 hari untuk memperjelas requirement sebelum menulis kode” agar kelambatan yang disengaja terasa terencana, bukan tanpa batas
- Bagikan apa yang dipelajari: update singkat tentang edge case yang ditemukan atau asumsi yang terbukti salah akan mengubah tahap lambat menjadi aliran nilai yang terlihat
- Demonstrasikan quick win: buat prototipe buang atau mockup lebih awal untuk menunjukkan bahwa tim bisa bergerak cepat, sekaligus membangun kepercayaan untuk pekerjaan yang lambat dan hati-hati
- Ini mirip dengan konsep Hill Chart dalam metodologi Shape Up dari Basecamp
- Menanjak: tahap lambat dengan ketidakpastian tinggi dan proses menemukan bentuk nyata pekerjaan
- Menurun: tahap cepat ketika jalur sudah jelas dan tinggal dieksekusi
- Ini bukan alasan untuk menunda, melainkan penjelasan tentang bagaimana pekerjaan yang baik benar-benar terjadi — dalam jangka panjang, tim yang paling cepat meluncurkan produk sering kali adalah tim yang tahu kapan harus melambat pada momen yang tepat
Cara Mempraktikkannya
- Coba lakukan ini sebelum pekerjaan berbantuan AI berikutnya:
- Tulis selama 10 menit masalah yang benar-benar ingin diselesaikan, definisikan seperti apa keberhasilan itu, dan apa yang berada di luar cakupan
- Sebelum mulai membangun, minta AI menjalankan pre-mortem atas pendekatan yang dipilih
- Jika pekerjaannya cukup besar, bangun prototipe yang akan dibuang terlebih dahulu untuk memvalidasi arah
Kesimpulan
- Kecepatan dan kelambatan bukan lawan, melainkan alat untuk tahap yang berbeda
- AI efektif untuk keduanya: eksekusi cepat ketika arah sudah jelas, dan perenungan yang dipercepat ketika arah masih kabur
- Kemampuan kuncinya adalah mengetahui sedang berada di tahap yang mana dan menerapkan tempo yang tepat
4 komentar
Ada ungkapan pelan-pelan itu cepat, lho.
Ini kata-kata yang sering saya dengar dari profesor saat masih kuliah pascasarjana,
rasanya PTSD muncul lagi setelah sekian lama.
Saya mendengarnya saat di militer.
Saya membacanya di partitur
allegro non troppo (cepat, tetapi tidak tergesa-gesa)