- Semakin cepat AI membuat hasil yang tampak meyakinkan, semakin mudah kita terjebak dalam pengulangan tanpa pemahaman, dan jika latihan membangun daya nilai dilewati, kapabilitas jangka panjang akan melemah
- Dalam pola yang sudah familiar AI sangat membantu, tetapi pada masalah yang asing, kondisi yang ambigu, informasi yang tidak lengkap, dan batasan yang saling bertentangan, tiruan dangkal mudah runtuh dan kemampuan nyata pun terlihat
- Engineer yang kuat menyerahkan tugas mekanis seperti boilerplate, ringkasan, scaffolding test, dan percepatan riset, tetapi tetap memiliki langsung definisi masalah, peninjauan, pemilihan, dan pembuangan
- Nilai tertinggi dalam software engineering bukan pada produksi kode, melainkan pada daya nilai; kemampuan melihat batasan tersembunyi, menyadari masalah yang salah, dan mengubah perdebatan yang kabur menjadi trade-off menjadi semakin penting
- Khususnya pada awal karier dan dalam operasional organisasi, standar yang menjaga pemahaman nyata menjadi lebih penting; semakin jelas kita membedakan apa yang didelegasikan dan apa yang ditangani sendiri, semakin AI menjadi alat yang meningkatkan nilai manusia
Mode kegagalan saat pemikiran dialihdayakan
- A.I. dapat dengan cepat menangani tugas seperti menghasilkan kode, merangkum rapat, menjelaskan konsep, membuat draf desain, atau menulis pembaruan status, tetapi juga mudah membentuk kebiasaan menghasilkan keluaran yang tampak meyakinkan tanpa pemahaman
- Jika kita hanya mengulang jawaban mesin seolah itu pemahaman kita sendiri, kita hanya meniru kondisi tampak kompeten tanpa benar-benar membangun kemampuan
- Semakin kita mengganti pemahaman sendiri dengan hasil generatif, semakin kita melewatkan latihan untuk membangun daya nilai, dan menukar kapabilitas jangka panjang dengan tampilan jangka pendek
- Dalam situasi yang tidak bisa ditangani dengan template—seperti masalah baru, kondisi ambigu, informasi tidak lengkap, atau batasan yang saling bertentangan—tiruan dangkal akan mudah runtuh
-
Analogi menyalin jawaban ujian
- Menyalin jawaban mungkin bisa mempertahankan nilai bagus, tetapi saat masuk ke situasi yang benar-benar membutuhkan pemahaman, akan terlihat bahwa fondasinya kosong
- Tanpa intuisi yang dibangun dari mengerjakan sendiri, akan sulit menalar masalah yang tidak familiar atau merespons perubahan kondisi
- Jika terus mengambil dan memakai jawaban dari A.I., kita hanya meminjam bentuk kemahiran, bukan membangun kemahiran yang sesungguhnya
-
Analogi kalkulator
- Kalkulator adalah alat yang baik untuk menghemat waktu, tetapi jika bergantung padanya tanpa sense angka, kita tidak akan bisa memeriksa apakah hasilnya masuk akal
- Engineer yang punya fondasi dapat meninjau keluaran A.I., menyaring kesalahan, lalu memperbaiki atau membuangnya
- Engineer tanpa fondasi bukan memakai A.I., melainkan terseret oleh A.I.; ini menjadi lebih berbahaya terutama dalam peran yang menuntut akurasi dan tanggung jawab atas hasil
-
Analogi mobil otonom
- Mobil otonom mengurangi kelelahan dan menangani situasi sehari-hari, tetapi jika kita bergantung padanya sebelum memahami cara mengemudi, kita akan lebih mirip penumpang yang hanya memegang kendali
- Dalam situasi nonstandar seperti jarak pandang buruk, jalan rumit, kendaraan lain yang tak terduga, kegagalan sistem, atau bahaya mendadak, kemampuan nyata akan terlihat
- A.I. juga kuat pada pola umum dan struktur yang familiar, tetapi engineering terus keluar dari itu: perubahan requirement, bug yang halus, kepemilikan yang tidak jelas, tujuan arsitektur yang saling bersaing, data parsial, gesekan organisasi, dan trade-off tanpa jawaban sempurna
Cara engineer hebat menggunakan A.I.
- Engineer hebat bukan memakai A.I. lebih sedikit, melainkan lebih aktif memakainya, tanpa menyerahkan proses berpikir itu sendiri
- Mereka dengan senang hati menyerahkan tugas mekanis seperti menulis boilerplate, merangkum dokumen, membuat scaffolding test, mengusulkan refactor, mengeksplorasi kemungkinan kegagalan, mempercepat riset, dan memadatkan pekerjaan berulang
- Sebaliknya, mereka membentuk pertanyaan yang lebih tajam, mendefinisikan masalah yang sebenarnya alih-alih hanya permintaan yang terlihat, dan lebih mengutamakan kejelasan dan keringkasan daripada kalimat licin yang kosong substansi
- Mereka tidak berhenti pada mengombinasikan ulang pengetahuan yang sudah ada dalam sistem, tetapi menciptakan pengetahuan baru bernilai tinggi
- Waktu yang diperoleh lalu diinvestasikan kembali ke pemikiran dan penilaian pada level yang lebih tinggi
Sumber nilai yang sebenarnya
- Selama ini software engineering sering disamakan dengan produksi kode, tetapi nilai tertingginya bukan di sana
- Jika inti pekerjaan hanya membuat kode yang benar secara sintaks, maka A.I. memang akan langsung menggantikan bagian besar dari pekerjaan itu, tetapi inti yang sesungguhnya ada pada daya nilai
- Engineer yang bernilai dapat melihat batasan tersembunyi sebelum menjadi insiden, menyadari bahwa tim sedang memecahkan masalah yang salah, mengubah perdebatan kabur menjadi trade-off yang jelas, menemukan abstraksi yang hilang, dan melakukan debug bukan hanya pada kode, tetapi pada realitas
- A.I. bisa mendukung pekerjaan semacam ini, tetapi tidak bisa mengambil alihnya
- Engineer yang akan menciptakan nilai lebih besar ke depan lebih dekat dengan pihak yang menghasilkan prinsip desain, pemahaman domain, pola, konteks, dan framework pengambilan keputusan yang membuat A.I. menjadi lebih berguna
- Dalam lingkungan seperti ini, engineer bukan digantikan oleh A.I., melainkan memperoleh leverage lebih besar dengan bekerja di atas level output mentah
Risiko yang lebih besar bagi engineer di awal karier
- Masalah ini menjadi sangat penting terutama bagi mereka yang masih di awal karier
- Beberapa tahun pertama adalah masa pembentukan kapabilitas dasar seperti naluri debugging, intuisi sistem, ketelitian, selera teknis, telaah skeptis, kemampuan memecah masalah, dan kemampuan menjelaskan mengapa sesuatu bekerja
- Kapabilitas semacam ini dibangun melalui gesekan, trial and error, memperbaiki kegagalan, menelusuri akar penyebab, dan pengalaman berbenturan langsung dengan realitas
- Jika dalam proses belajar A.I. menghapus semua kesulitan, kita memang mendapat efisiensi jangka pendek, tetapi melewatkan tahap saat kemampuan ditempa
- Selama satu atau dua kuartal mungkin terlihat efisien, tetapi diam-diam kita bisa kehilangan kemampuan yang seharusnya menopang masa depan
- Sistem pendukung mungkin bisa membuat semuanya tampak berjalan, tetapi tidak bisa menggantikan kemampuan nyata
Tidak ada jalan pintas menuju daya nilai
- Hanya dengan membaca penjelasan yang dihasilkan, kemahiran tidak akan berpindah ke dalam kepala tanpa kita mengerjakannya sendiri
- Tidak ada jalan untuk lama mengalihdayakan penalaran lalu pada akhirnya tetap memiliki kemampuan bernalar yang kuat
- Mengalihdayakan tugas mekanis, mempercepat riset, dan memadatkan pekerjaan berulang itu mungkin dan bahkan diinginkan
- Namun kita tidak akan memiliki keterampilan itu jika proses pembentukan keterampilannya sendiri dilewati
- Kekeliruan inti dari pemakaian A.I. yang paling naif adalah merasa sedang menghemat waktu, padahal sebenarnya hanya menunda tagihan berupa daya nilai yang lemah, pemahaman dangkal, dan kemampuan adaptasi yang rendah
Garis pemisah dan implikasi pada level organisasi
- Jika A.I. membantu kita membangun pemahaman lebih cepat, berpikir lebih dalam, dan bekerja di level yang lebih tinggi, maka nilai manusia meningkat
- Jika A.I. membantu kita menghindari pemahaman, menghindari kesulitan, dan menghindari kepemilikan atas penalaran, maka nilai manusia menurun
- Satu jalur akan menumpuk seperti bunga majemuk, sedangkan jalur lain mengosongkan isi dan mendorong kita ke kondisi yang mudah menjadi tidak relevan
- Masa depan akan lebih menguntungkan engineer yang secara akurat membedakan apa yang didelegasikan dan apa yang tetap dimiliki sendiri, lalu mengubah penghematan waktu menjadi pemikiran yang lebih baik, dibanding engineer yang sekadar menggunakan A.I.
Mengapa dampaknya lebih besar pada kesehatan organisasi
- Manajemen engineering juga akan berdiri di batas yang sama: membedakan penggunaan yang mempercepat pemahaman dari penggunaan yang hanya meniru pemahaman
- Kepemimpinan yang kuat harus mampu membedakan hasil yang terlihat mulus dari daya nilai yang nyata; jika yang dihargai hanya kecepatan, kefasihan, dan presentasi, sinyal kedalaman teknis akan terlewat
- Jika pekerjaan dengan pemahaman rendah dan kefasihan tinggi menyebar, bukan hanya kualitas output individu yang turun, tetapi lingkungan pengetahuan organisasi itu sendiri ikut melemah
- Review menjadi lebih lemah
- Diskusi desain menjadi lebih dangkal
- Dokumen menjadi lebih mulus tetapi kurang berguna
- Seiring waktu, organisasi kehilangan kemampuan untuk menghasilkan kejernihan dan penilaian teknis yang selama ini mereka andalkan
- Karena itu, inti persoalannya bukan pada adopsi alat A.I. semata, melainkan pada menjaga kondisi agar pemikiran, pembelajaran, dan craftsmanship yang nyata tetap hidup
- Sejak tahap rekrutmen, dibutuhkan cara untuk membedakan pemahaman nyata dari kefasihan yang hanya tampak di permukaan
- Wawancara harus menguji proses penalaran, bukan jawaban polished
- Evaluasi harus memberi penghargaan pada kejelasan, kedalaman, penilaian yang sehat, dan kontribusi teknis yang bertahan lama, bukan sekadar volume output
- Ini juga sangat memengaruhi desain tim dan budaya
- Engineer yang kuat tidak boleh menghabiskan terlalu banyak waktu untuk membereskan pekerjaan yang tampak meyakinkan tetapi dangkal hasil dari orang yang mengalihdayakan pemikirannya
- Jika ini tidak dicegah, para high performer akan habis dipakai sebagai penguat bagi semua orang selain dirinya sendiri, dan akibatnya mudah berujung pada frustrasi, turunnya standar, dan keluarnya orang-orang terbaik
- Pada akhirnya, kualitas organisasi di era A.I. akan lebih ditentukan oleh apakah kepemimpinan terus mampu membedakan leverage dan ketergantungan, percepatan dan tiruan, serta kapabilitas nyata dan output yang terdengar meyakinkan
1 komentar
Pendapat Hacker News
Semakin sering membaca argumen ini berulang kali, semakin terasa kehalusan ungkapannya membaik, tapi rasanya masih belum sampai tahap aforisme
Agar bisa menjadi kalimat pendek yang langsung mengena bagi banyak orang seperti "the medium is the message", "you ship your org chart", atau "9 mothers can't make a baby in a month", butuh waktu bertahun-tahun hingga puluhan tahun untuk memangkas makna sampai tinggal intinya
Dan kita bahkan belum tahu cara menangani pembentukan makna dengan RL, jadi AI tidak bisa menggantikannya
Aslinya yang benar adalah "9 women can't make a baby in one month"
Belajar dengan melakukannya langsung. Kalimat ini tampak lebih dekat ke aforisme
Intelligence amplification, not artificial intelligence terdengar cukup bagus
Jika disingkat jadi IA, not AI, dan kalau diterjemahkan ke bahasa Spanyol jadi "AI, no IA", jadi terasa lebih lucu
Selera dan daya menilai tidak bisa dilahirkan oleh AI
Jika bertanya kepada 100 orang Amerika apa arti aforisme ini, mungkin hampir tidak ada yang bisa menangkap makna asli yang dimaksud McLuhan dengan tepat
Menurut saya, AI pada dasarnya bisa dipakai dengan dua cara
Satu adalah sebagai pendamping untuk menulis kode yang saya miliki dan pahami, dan yang lain adalah memakai AI sebagai semacam lapisan abstraksi yang menangani penulisan dan pemeliharaan kode
Yang kedua cocok untuk prototipe, contoh, atau referensi yang umurnya pendek dan di mana kualitas kode atau tingkat pemahaman saya tidak terlalu penting
Masalah muncul ketika orang memakai 2 untuk pekerjaan yang sebenarnya butuh 1, sambil menipu diri sendiri dan orang lain
Kelihatannya cepat dan mudah, tapi pada akhirnya itu seperti menggadaikan codebase, dan sejak saat itu penyusutan kemampuan pun mulai terjadi
Fitur terus dikirim dan dari luar tampak baik-baik saja, tapi saat sesuatu meledak, kita sadar bahwa kita bahkan tidak bisa men-debug kode sendiri tanpa bertanya lagi ke model
Banyak engineer juga tidak bisa bekerja tanpa IDE modern, bahasa dengan manajemen memori, atau library dari GitHub maupun package manager
Karena itu, ketergantungan pada AI juga tidak terasa sangat berbeda secara mendasar bagi saya
Makna kata Engineer pun bisa berubah, dan kenyataannya sudah ada juga "web developer" yang hanya memakai Webflow atau WordPress
Jika memakai definisi yang ketat, di bidang Software Engineering hampir tidak ada engineer bersertifikat resmi yang benar-benar sesuai, dan di beberapa negara ada kualifikasi serta gelar khusus untuk itu
Di awal karier, kalau punya cukup waktu mungkin saya melakukan hampir apa pun, tapi sekarang daftar hal yang sebenarnya bisa saya lakukan namun tidak saya lakukan karena tidak menarik sudah sangat panjang
Kita tidak tahu apakah AI akan berbiaya seperti langganan Slack, seperti biaya satu anggota tim, atau apakah layanannya akan hilang sehingga kita harus merekrut orang khusus yang punya akses AI
Jadi bergantung pada AI cukup berbeda dari bergantung pada IDE yang bisa saja lokal atau open source
Orang dengan pengalaman sekitar 10 tahun bisa memahami alur dan logika kode, jadi walaupun memakai AI mereka tetap bisa membuat kode dan memperbaiki caranya sendiri
Sebaliknya, pemula cenderung tidak paham alur atau logika dan hanya menyalin-tempel begitu saja, jadi rasanya AI tidak akan memberi lebih banyak ruang untuk berpikir bagi orang-orang seperti itu
Cara memakai AI saat ini terasa lebih melelahkan daripada 20 tahun terakhir pemrograman
Proses melempar masalah, mengevaluasi usulan, memilih arah yang tepat, membuang usulan aneh, lalu menghaluskannya lagi hingga hampir benar terasa sangat menguras tenaga
Setelah itu saya bisa menjalankan proses coding selama 1 sampai 5 jam, dan kadang menghasilkan sesuatu yang jika saya kerjakan sendiri setidaknya akan memakan 2 sampai 3 minggu
Tapi bekerja sekitar 5 jam dengan fokus pada perencanaan seperti ini membuat saya benar-benar kelelahan, dan rasa lelahnya berbeda dari saat hanya melakukan pemrograman murni
Rasanya seperti belajar sesuatu, tapi sejujurnya juga terasa lebih mirip pekerjaan manajer
Untuk mendefinisikan masalah pelan-pelan bersama LLM dan menemukan solusi yang masuk akal, saya harus terus mempertahankan keadaan fokus, jadi alur tenggelam dalam pekerjaan seperti dulu jadi sulit muncul
Kita harus terus memproses output yang menumpuk dan berulang kali memilah inti persoalannya, dan meskipun secara umum bagus, hampir selalu ada sedikit bagian yang meleset sehingga cukup mengganggu
Karena error aneh dan cacat penalaran khas LLM, tingkat kewaspadaan tinggi juga harus terus dijaga, dan menafsirkan gaya komunikasi yang tidak manusiawi itu sendiri juga melelahkan
Tetapi saya juga berpikir pacing atau procrastination mungkin justru bisa menjadi semacam katup pelepas tekanan bagi manusia
Sejak awal memang banyak engineer yang tidak pandai berpikir, dan AI tidak bisa mengubah fakta itu sendiri
Itu salah satu alasan mengapa ranah Software Engineering banyak rusak, dan AI mungkin tidak menyelesaikannya, hanya menunda kekacauan yang lebih besar
Bahkan orang yang bertahan di kampus dengan menyontek pun tetap membutuhkan berpikir kritis agar tidak ketahuan dan bisa lolos
Mungkin orang tidak suka mendengarnya, tapi bahkan pandai menyontek pun membutuhkan cukup banyak daya pikir
Saya rasa orang yang pada level apa pun menyerahkan proses berpikir kepada AI sejak awal memang tidak pernah terlalu menghargainya
Seperti pepatah "use it or lose it", makin banyak riset yang mendukung hal ini, tetapi tulisan yang mengatakan bahwa memakai LLM dalam pengembangan perangkat lunak tidak apa-apa dan nilai kita tetap ada pada kemampuan berpikir masih terus bermunculan
Salah satu keindahan pekerjaan ini adalah saat solusi tiba-tiba muncul ketika saya sedang tenggelam dalam hal lain
Sekarang AI menjadi alat untuk cepat mengubah pikiran itu menjadi tindakan
Dulu saya kadang kehilangan alurnya sebelum sempat menangkap benang merahnya, tetapi sekarang dalam hitungan menit lewat ponsel saya bisa mewujudkan sebagian gagasan itu ke dunia nyata lalu kembali ke pekerjaan semula
Yang paling besar adalah saya tidak perlu takut kehilangan ide hanya karena mengalihkan pandangan sebentar
Saat ini saya sedang membuat ulang numba, dan sulit membayangkan melakukan ini hanya dengan tangan
Saat mencoba beberapa tahun lalu, prosesnya sangat menyakitkan, lambat, dan berantakan
Itu makin terasa karena ada begitu banyak hal kecil yang terus ditumpuk di atas abstraksi yang terkumpul selama bertahun-tahun
Kali ini saya mengerjakannya lagi dengan LLM, dan pekerjaan yang tadinya akan butuh beberapa minggu kadang selesai dalam semalam
Meski begitu, saya tetap melihat langsung kodenya, memeriksa output C yang dihasilkan, dan terus memegang kendali arsitektur agar ke depan saya dan LLM lebih mudah menanganinya bersama
Saya tidak yakin apakah ini menggantikan pemikiran saya
Jika saya bertahan menulis dan memperbaikinya secara manual selama berbulan-bulan, mungkin saya akan belajar lebih banyak tentang compiler atau transpiler, tetapi berarti saya juga hanya akan terpaku pada ini saja
Sebagai gantinya, sekarang saya bahkan punya waktu untuk menulis dukungan server NFS untuk filesystem kustom dengan Golang
Sekarang saya sudah membangun sistem di mana agen-agen dapat menemukan perubahan yang dibutuhkan untuk seluruh fitur, menguraikannya sangat rinci pada tahap perencanaan, lalu menyelesaikan implementasinya hampir benar sejak awal
Selama setahun terakhir, frekuensi saya membaca kode sendiri makin berkurang, dan saya sering bertanya pada diri sendiri apakah rasa nyaman saya terhadap sistem saat ini sudah berlebihan
Saya sudah terlalu sering melihat tingkat akurasi dan keberhasilan yang sangat tinggi sehingga sekarang secara naluriah saya tidak lagi meragukannya
Saya terus menunggu suatu hari akan terkena masalah besar, tapi anehnya momen itu tak kunjung datang
Tentu ada kelalaian kecil dan rollback, tetapi itu juga dulu ada
Bedanya, dulu saya punya hubungan yang jauh lebih pribadi dengan kode itu karena saya menulisnya dengan susah payah
Sekarang ketika ada masalah, alih-alih menyalahkan kodenya, saya justru menggali lagi mengapa sistem tidak bisa menemukan jawaban sendiri, atau mengapa pada tahap perencanaan ia gagal menampakkan keseluruhan gambar sebelum implementasi
Keunggulan terbesar AI dalam software adalah kita bisa membuat kode lebih cepat
Kekurangan terbesarnya adalah ia menggoda kita untuk ingin membuatnya jauh lebih cepat lagi
Karena itu saya tidak memakai AI untuk proyek pribadi
Karena saya ingin menjaga pikiran tetap tajam
Jika itu proyek yang memang melibatkan AI, mungkin ada pengecualian, tetapi saya tidak memakai AI untuk menulis kodenya
Sebaliknya, untuk pekerjaan kantor saya tidak terlalu peduli
Jika manajer ingin melakukan vibe coding sepenuhnya dengan Claude, ya saya ikut saja, karena bukan saya yang menanggung biaya utang teknis yang muncul karenanya