Siapa yang Membuat Kode Ini? Refleksi Identitas Developer di Era AI

Kapan terakhir kali kamu benar-benar merasa membuat sesuatu dari nol? Bukan sekadar mengetik prompt, menunggu hasil, lalu mengklik tombol deploy. Tapi benar-benar merasakan setiap baris kode sebagai hasil dari pikiran, eksplorasi, dan kegagalan pribadi. Di era AI generatif yang makin canggih, pertanyaan ini terdengar naif. Tapi mungkin itulah yang paling penting untuk ditanyakan ulang.

Beberapa tahun terakhir, kita menyaksikan pergeseran yang cepat. Dari autocomplete sederhana di IDE, kini kita punya asisten yang bisa menulis seluruh modul, mendesain arsitektur, bahkan memperbaiki bug yang kita sendiri belum paham. Hasilnya: produk yang lebih cepat rilis, fitur yang lebih banyak, dan bisnis yang lebih senang. Tapi di balik kecepatan itu, ada sesuatu yang mulai hilang secara diam-diam: rasa kepemilikan.

Ketika "Membuat" Tidak Lagi Berarti Membuat

Brian Hall, seorang engineer berpengalaman dan pengajar di Oregon State University, pernah menulis sebuah esai provokatif yang berjudul On Making. Intinya sederhana: dia tidak merasa nyaman mengklaim telah "membuat" kode jika yang menulisnya adalah Claude atau GPT. Bagi Hall, ada perbedaan fundamental antara meminta orang lain membuatkan sesuatu dan benar-benar membuatnya sendiri.

Pikirkan analogi sederhana. Ketika kamu meminta kontraktor membangun teras depan rumahmu, apakah kamu akan bilang "Saya baru saja membangun teras"? Kebanyakan orang tidak. Tapi di dunia teknologi, kita sering mendengar ungkapan serupa: "Saya membuat aplikasi ini dalam satu malam." Padahal 80 persen kode dihasilkan oleh AI. Apakah itu salah? Tidak selalu. Tapi apakah itu membuat kita merasa puas secara personal? Banyak yang mulai meragukannya.

Hall bercerita tentang sebuah proyek kecil yang dia buat untuk istrinya: sistem flash card sederhana untuk belajar bahasa Spanyol. Hanya 177 baris kode. Ia menolak bantuan Claude untuk menulis kode dan hanya menggunakannya untuk mencari tahu cara membaca data dari Google Sheets. Proyek itu butuh waktu 50 kali lebih lama dibanding jika AI yang menulis. Tapi Hall mengatakan dengan jujur: dia jauh lebih bangga pada 177 baris kode itu dibanding ribuan baris yang pernah dihasilkan oleh asisten AI miliknya.

Identitas Developer di Ujung Tanduk

Bagi banyak developer di Indonesia, identitas profesi ini sangat melekat pada kemampuan teknis. Kita bangga bisa menguasai bahasa pemrograman tertentu, memahami algoritma kompleks, atau menyelesaikan bug yang menyebalkan selama berjam-jam. Kemampuan-kemampuan ini bukan sekadar alat kerja: mereka adalah bagian dari narasi diri kita.

Ketika AI mulai mengambil alih tugas-tugas tersebut, apa yang tersisa? Apakah kita kini lebih mirip product manager yang hanya mengelola spek, atau arsitek yang hanya menggambar garis besar sambil menyerahkan detail kepada mesin? Pergeseran peran ini bukan hal buruk secara inheren, tapi bisa menimbulkan kecemasan identitas bagi mereka yang selama ini mendefinisikan diri lewat keahlian teknis spesifik.

Sebuah survei dari Stack Overflow pada 2025 menunjukkan bahwa 62 persen developer merasa produktivitas mereka meningkat signifikan dengan AI. Tapi 41 persen juga melaporkan penurunan kepuasan kerja. Angka ini menggambarkan paradoks modern: kita lebih efisien, tapi kurang bahagia.

Antara Efisiensi dan Kehilangan

Tentu saja, ada sisi positif yang tidak bisa diabaikan. AI membantu startup bootstrapped menyelesaikan MVP tanpa perlu hire tim besar. AI membantu engineer senior fokus pada desain sistem tingkat tinggi sambil menyerahkan boilerplate. AI membantu programmer pemula belajar lebih cepat dengan melihat contoh yang relevan secara kontekstual.

Tapi ada garis tipis antara memakai alat dan menjadi dependen. Seperti developer yang lupa cara menulis SQL karena selalu menggunakan ORM, atau engineer yang kebingungan saat harus debug tanpa autocomplete, ketergantungan pada AI bisa mengikis fondasi pemikiran komputasional kita. Bukan karena AI jahat, tapi karena otak manusia secara alami akan menghemat energi. Jika ada jalan pintas yang selalu tersedia, mengapa repot-repot memahami mekanisme di baliknya?

Ini bukan prediksi distopia. Ini adalah observasi psikologi kognitif yang sudah mapan. Kita kehilangan apa yang tidak kita latih. Dan latihan di sini bukan sekadar repetisi mekanis, tapi proses berpikir yang melibatkan kebingungan, penjelajahan, dan eureka moment. AI yang terlalu baik dalam memberikan jawaban instan justru bisa mencuri ketiga fase itu dari kita.

Menemukan Kembali "Craft" di Tengah Automasi

Jadi, apa yang bisa dilakukan? Sama seperti penulis tetap menulis tangan meski ada word processor, atau musisi tetap berlatih skala meski ada auto-tune, developer perlu secara sadar mempertahankan ruang untuk craft.

Coba sesekali tulis modul kecil tanpa bantuan AI. Bukan karena itu lebih efisien, tapi karena itu mengingatkanmu bahwa kamu masih bisa. Coba baca dokumentasi asli alih-alih langsung meminta ringkasan dari chatbot. Coba debug secara manual sebelum meminta AI menganalisis stack trace. Tindakan-tindakan ini mungkin terdengar kontraproduktif, tapi mereka adalah investasi dalam kepercayaan diri dan pemahaman mendalam.

Industri teknologi di Indonesia sedang tumbuh pesat. Kita butuh developer yang tidak hanya cepat, tapi juga dalam. Developer yang bisa membedakan kode bagus dan kode yang cukup bagus. Developer yang mengerti why, bukan hanya how. Dan untuk mencapai itu, kita perlu merawat keterampilan dasar yang sering terlupakan di balik gemerlap produktivitas AI.

Lebih jauh lagi, kita perlu mengajukan ulang definisi sukses. Di komunitas tech Indonesia, seringkali yang dipuja adalah kecepatan rilis dan jumlah fitur. Tapi produk yang sustainable dan tim yang sehat mentalnya memerlukan fondasi yang kuat, bukan sekadar tumpukan kode yang ter-generate tanpa konteks bisnis yang jelas. Senior engineer di startup lokal perlu lebih aktif mentransfer pengetahuan fundamental ke junior, bukan hanya mengajarkan cara meminta AI menulis kode dengan benar.

Pertanyaan yang Belum Terjawab

Di akhir hari, AI tidak akan pergi. Ia akan semakin terintegrasi ke dalam workflow kita, dan itu adalah kemajuan yang sehat. Tapi integrasi yang sehat memerlukan kesadaran. Kesadaran bahwa kecepatan bukan satu-satunya metrik kesuksesan. Bahwa produktivitas tanpa kepuasan adalah resep burnout. Dan bahwa identitas kita sebagai maker, builder, dan problem solver tidak bisa sepenuhnya diserahkan kepada mesin.

Ketika kamu melihat aplikasi yang baru saja kamu deploy malam ini, tanyakan pada dirimu sendiri: seberapa besar bagian di dalamnya yang benar-benar berasal dari pikiranmu? Jawabannya mungkin membuatmu tidak nyaman. Tapi ketidaknyamanan itu mungkin justru tanda bahwa kamu masih peduli pada craft yang dulu membuatmu jatuh cinta dengan programming.

Bagaimana denganmu? Apakah kamu masih merasa membuat kode, atau sekadar mengelola proses pembuatannya?