Belajar Menjadi Software Engineer Kembali di Era AI

10 September 2025

Refleksi

Ada perasaan aneh yang mungkin tidak pernah kita duga sebagai software engineer di tahun 2025.

Bukan rasa takut. Bukan pula rasa antusias.

Melainkan kesadaran perlahan bahwa menulis kode bukan lagi bagian yang sulit.

LLM kini bisa menghasilkan kode yang berfungsi dalam hitungan detik (API, komponen UI, pengujian, bahkan refactoring). Hal itu memaksa kita untuk mengajukan pertanyaan yang tidak nyaman:

Jika kode sekarang begitu murah, apa sebenarnya nilai kita sebagai seorang software engineer?

Tulisan ini adalah upaya untuk menjawab pertanyaan tersebut, sekaligus obrolan dan pengingat bagi kita semua ke depan.

Kode Dulu Adalah Keahlian Utama. Sekarang Hanyalah Alat.

Dulu di awal perjalanan karier kita, menjadi engineer yang handal berarti memahami framework secara mendalam, menulis kode yang bersih, dan merilis fitur dengan cepat. Keterampilan tersebut tetap penting, tetapi tidak lagi langka.

LLM dapat membuat fondasi seluruh service, menerjemahkan requirements menjadi kode, dan merefaktor sistem lawas tanpa mengeluh. Namun apa yang tidak bisa mereka lakukan adalah memiliki rasa tanggung jawab terhadap suatu sistem (system ownership). Mereka tidak dibangunkan pukul 2 pagi saat sistem down. Mereka tidak hadir dalam rapat postmortem. Mereka tidak merasakan perihnya akumulasi technical debt selama bertahun-tahun.

Nilai kita bukanlah pada baris kodenya. Nilai kita ada pada tanggung jawab yang kita ambil terhadap sistem tersebut.

Dari Pembuat Kode Menjadi Pemilik Sistem

LLM sangat mahir menjawab “bagaimana cara membangun ini?” Namun mereka sangat buruk dalam menjawab:

“Apakah hal ini layak dibangun?”
“Apa yang terjadi jika ini gagal?”
“Bagaimana kondisi sistem ini 3 tahun ke depan?”
“Siapa yang menanggung biaya dari abstraksi ini?”

Itu adalah pertanyaan manusia. Itu adalah pertanyaan esensial dari rekayasa perangkat lunak (engineering).

Pekerjaan kita bukan lagi sekadar mengimplementasikan fitur. Melainkan menentukan apa yang harus ada, apa yang sebaiknya tidak dibuat, dan di mana kompleksitas diperbolehkan berada.

Memperlakukan LLM Seperti Junior Engineer (Dengan Energi Tanpa Batas)

Model mental yang paling membantu kita:

LLM adalah junior engineer dengan stamina tanpa batas dan nol konteks.

Mereka bekerja cepat, terdengar sangat percaya diri, terkadang berhalusinasi, dan sering melewatkan edge cases. Jadi kita tidak perlu merasa “tergantikan” oleh AI; kita cukup mendelegasikan pekerjaan kepadanya. Tugas kita beralih menjadi mendefinisikan batasan (constraints) yang jelas, memberikan spesifikasi yang baik, meninjau hasil secara teliti, dan mendeteksi kesalahan konseptual sejak dini.

Jika kita tidak bisa membedakan apakah kode yang dihasilkan AI itu baik atau buruk, itulah masalah sebenarnya, bukan AI-nya.

Batasan (Constraints) Adalah Kekuatan Super yang Baru

Di era AI, menulis solusi itu murah. Merancang batasan (constraints) itu mahal.

Alih-alih bertanya “Bagaimana cara mengimplementasikan ini?”, kita sekarang perlu bertanya “Apa yang tidak boleh rusak dalam kondisi apa pun?”

Batasan yang baik—seperti batasan service yang tegas, kepemilikan data yang eksplisit, alokasi performa, mode kegagalan sistem, dan model keamanan—memberi AI ruang kerja yang terarah dan bermakna. Begitu batasan tersebut jelas, AI menjadi luar biasa kuat karena ia bekerja di dalam ruang yang telah kita rancang.

Penilaian (Judgment) > Sintaks. Interface > Internals.

Dulu, sintaks adalah dinding penghalang masuk. Sekarang, kemampuan penilaian (judgment) adalah penentunya.

Judgment adalah tahu kapan harus menambahkan abstraksi dan kapan harus menghindarinya. Tahu kapan harus segera merilis dan kapan harus melambat. Kapan tidak perlu membangun apa pun sama sekali. Judgment lahir dari insiden produksi, keputusan keliru yang tak bisa ditarik kembali, dan sistem yang menua dengan buruk. AI tidak memiliki bekas luka kegagalan. Engineer memilikinya.

Engineer dengan dampak besar tidak hanya berkutat di dalam basis kode. Mereka hidup di interface—di antara tim, service, manusia, dan sistem. AI dapat membuat bagian internal. Manusia tetap yang merancang interface.

Mengukur Dampak dan Mendefinisikan Ulang Senioritas

Dulu kita mungkin sering mengukur diri dari banyaknya fitur yang dirilis dan tiket yang diselesaikan. Sekarang, coba kita ukur dari: sistem yang disederhanakan, insiden yang berhasil dicegah, tim yang terbantu melangkah, dan beban kognitif yang berkurang.

Jika AI membantu kita menulis kode 10 kali lebih banyak namun meninggalkan sistem yang tidak dipahami siapa pun, artinya kita telah gagal.

Semakin tinggi level kita, semakin sulit posisi kita digantikan oleh AI. Seorang junior bisa merilis kode dengan bantuan AI. Namun tidak ada AI yang bisa mencegah pemilihan arsitektur yang buruk sejak awal, atau memandu bagaimana banyak tim membangun sesuatu secara selaras. Itu tetap merupakan peran manusia.

Apa yang Bisa Kita Lakukan

Bukan lagi soal mengejar bahasa pemrograman tertentu, framework, alat bantu, atau trik prompt baru. Berikut beberapa hal praktis yang bisa kita lakukan:

Pegang kepemilikan sistem secara end-to-end: Ambil tanggung jawab penuh atas siklus hidup dan keandalan sistem, bukan sekadar menyelesaikan tiket.
Ambil keputusan yang tepat di tengah ketidakpastian: Latih kemampuan menimbang trade-off saat tidak ada jawaban yang serba pasti.
Rancang batasan (constraints) yang scalable: Bangun batas arsitektur dan guardrail yang jelas agar sistem serta AI dapat bekerja dengan aman.
Kurangi kompleksitas bagi orang lain: Sederhanakan arsitektur, rapikan dependensi, dan turunkan beban kognitif rekan satu tim.
Ubah masalah yang ambigu menjadi arah yang jelas: Terjemahkan kebutuhan yang masih mentah menjadi solusi teknis yang terarah dan terstruktur.

AI membuat kode menjadi murah, yang berarti keputusan buruk akan menumpuk lebih cepat. Engineer yang bertahan dan terus bertumbuh adalah mereka yang bergerak mendekati pengambilan keputusan, arsitektur, dampak nyata, dan tanggung jawab.

Satu Kalimat yang Perlu Selalu Kita Ingat

Software engineering bukanlah tentang menulis kode.
Ini tentang membuat keputusan yang tepat di tengah ketidakpastian, dengan kode sebagai alatnya.

LLM tidak menggantikan engineer. Mereka hanya menyingkap siapa saja yang selama ini hanya sekadar mengetik kode.

Catatan untuk Kita Semua

Jangan bersaing dengan AI dalam hal kecepatan; bersainglah dalam hal penilaian (judgment)
Biarkan AI menulis kode, tetapi jangan pernah biarkan ia menentukan arah keputusan
Optimalkan untuk daya ungkit (leverage), bukan sekadar volume output
Tetaplah dekat dengan sistem nyata dan kegagalan nyata di produksi