Di era AI, ada empat skill yang justru makin relevan: kemampuan breakdown masalah, komunikasi teknis yang presisi, pemahaman konsep dasar, dan code review & debugging mindset.

Tapi tau yang lebih penting dari tahu skill itu penting?

Tau gimana cara melatihnya.

Tulisan ini fokus ke sana — bukan hype, bukan teori. Praktis.

1. Breakdown Masalah: Dari Kabur Jadi Konkret

Kenapa ini sulit?

Kita sering dapat requirement yang samar: "Buatkan fitur notifikasi", "Tambahin filter di halaman ini", "Fix masalah performance-nya." Tanpa kemampuan breakdown, kita langsung loncat ke solusi — dan sering salah arah.

Cara melatihnya:

Latihan "5 Whys" Setiap kali ada masalah atau requirement baru, tanya "kenapa" minimal 5 kali sebelum mulai ngoding. Ini memaksa kamu turun ke akar masalah, bukan hanya permukaan.

Contoh:

• "Fix bug login yang lambat" → Kenapa lambat? → Query database tidak diindeks → Kenapa tidak diindeks? → Skema tidak pernah direview → Kenapa? → Tidak ada proses review skema di tim
• Solusinya bukan sekadar "tambah index" tapi juga memperbaiki proses review

Latihan Decomposition Harian Sebelum mulai task apapun, tuliskan dulu langkah-langkahnya di atas kertas atau Notion. Buat minimal 5-7 langkah konkret. Kalau tidak bisa, berarti kamu belum cukup paham masalahnya.

Rubber Duck Debugging Jelaskan masalah kamu ke "bebek karet" — bisa ke teman, ke AI, atau bahkan ke dinding. Proses verbalisasi memaksa otak menyusun ulang pemahaman. Sering kali solusinya muncul di tengah penjelasan.

Praktik dengan soal sistem desain Coba jawab pertanyaan seperti "Bagaimana kamu mendesain URL shortener?" atau "Bagaimana sistem notifikasi real-time bekerja?" Jawab secara lisan atau tulisan — bukan dengan langsung ngoding.

2. Komunikasi Teknis yang Presisi

Kenapa ini sulit?

Kita seringnya tahu secara intuitif, tapi kesulitan mengucapkannya dengan jelas. Dan di era AI, kejelasan komunikasi = kualitas output yang kamu dapat.

Cara melatihnya:

Tulis PR description yang baik Mulai sekarang, setiap pull request yang kamu buat harus punya deskripsi yang menjawab: apa yang diubah, kenapa diubah, dampaknya apa, dan bagaimana cara test-nya. Ini latihan komunikasi teknis yang paling underrated.

Latihan prompt engineering secara sadar Setiap kali pakai AI (Copilot, ChatGPT, Claude), jangan asal ketik. Coba tulis prompt-nya dulu di draft, review, perbaiki — baru kirim. Perhatikan perbedaan output antara prompt yang kabur vs yang presisi.

Buat "Architecture Decision Record" (ADR) Untuk setiap keputusan teknis yang kamu buat — sekecil apapun — coba tulis: konteksnya apa, opsi yang dipertimbangkan apa, dan kenapa pilih solusi ini. Ini melatih kemampuan mengartikulasikan reasoning teknis.

Ikut atau buat code review yang substantif Jangan cuma tulis "LGTM" di review. Paksa diri untuk menulis minimal satu komentar yang menjelaskan kenapa sebuah pendekatan lebih baik dari yang lain — dengan referensi konsep atau trade-off yang jelas.

3. Pemahaman Konsep Dasar, Bukan Hafalan Syntax

Kenapa ini sulit?

Kita terbiasa googling atau tanya AI untuk hal-hal spesifik. Bagus. Tapi ada bedanya antara tahu cara pakai sesuatu vs tahu cara kerjanya. Yang kedua itulah yang tidak bisa disubstitusi AI.

Cara melatihnya:

Pelajari "satu layer di bawah" yang kamu pakai Kalau kamu pakai React, pelajari cara kerja Virtual DOM dan reconciliation. Kalau kamu pakai Prisma, pelajari cara query SQL yang dihasilkannya. Kalau kamu pakai fetch, pelajari cara kerja HTTP di bawahnya.

Buat implementasi mini dari scratch Coba buat versi sederhana dari tool yang sering kamu pakai: mini router, mini state management, mini promise. Tidak harus sempurna — tujuannya memahami mekanisme dasarnya.

Baca source code library yang kamu pakai Pilih satu library yang sering kamu pakai. Baca source code-nya — tidak harus semua, cukup bagian yang paling sering kamu gunakan. GitHub tersedia, tidak ada alasan untuk tidak.

Terapkan "Feynman Technique" Coba jelaskan sebuah konsep teknis dengan bahasa yang bisa dimengerti orang non-teknis. Kalau kamu tidak bisa menjelaskannya dengan sederhana, berarti kamu belum benar-benar paham.

4. Code Review & Debugging Mindset

Kenapa ini sulit?

Membaca kode orang lain (apalagi kode yang di-generate AI) butuh pola pikir yang berbeda dari menulis kode. Kita harus aktif mencari masalah, bukan hanya pasif membaca.

Cara melatihnya:

Jadikan dirimu "skeptis yang konstruktif" Setiap kali review kode — termasuk kode sendiri — tanya tiga pertanyaan: Apa yang bisa salah di sini? Apakah edge case sudah dihandle? Kalau volume-nya 100x lipat, apakah ini masih bekerja?

Debug tanpa langsung lari ke AI Tantang diri sendiri: sebelum tanya AI atau stackoverflow, coba trace masalah sendiri minimal 15 menit. Baca error message-nya baik-baik. Cek assumptions-mu. Tambahkan log. Isolasi masalah. Proses inilah yang membangun intuisi debugging.

Review kode open source Buka repositori open source yang kamu minati. Baca issue yang dilaporkan, lalu coba trace di kode — di mana masalahnya? Kamu tidak harus fix-nya, tapi proses tracing-nya melatih kemampuan membaca dan memahami kode asing.

Post-mortem personal Setiap kali ada bug yang kamu temukan atau fix, tulis catatan singkat: bug-nya apa, kenapa bisa terjadi, bagaimana kamu menemukannya, dan apa yang bisa dicegah ke depannya. Ini membangun mental model tentang pola kesalahan umum.

Tidak Harus Semuanya Sekarang

Empat skill ini tidak perlu diasah bersamaan. Pilih satu yang paling terasa lemah, fokus selama satu bulan, lalu lanjut ke yang berikutnya.

Yang penting adalah konsistensi, bukan intensitas sesaat.

Programmer yang bertahan di era AI bukan yang paling banyak hafalan syntax-nya — tapi yang paling baik dalam memahami, mendekomposisi, mengkomunikasikan, dan memvalidasi.

Dan itu semua bisa dilatih.