- Semakin cepat menghasilkan output yang tampak meyakinkan, semakin mudah terjebak dalam pengulangan tanpa pemahaman, dan jika melewatkan latihan untuk membangun daya nilai, 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, imitasi dangkal mudah runtuh dan kemampuan nyata pun terlihat
- Insinyur yang kuat menyerahkan pekerjaan mekanis seperti boilerplate, ringkasan, scaffolding pengujian, dan percepatan riset, tetapi tetap memiliki langsung definisi masalah, review, pemilihan, dan pembuangan
- Nilai tinggi dalam rekayasa perangkat lunak lebih terletak pada daya nilai daripada produksi kode; kemampuan melihat batasan tersembunyi, menyadari masalah yang keliru, dan mengubah perdebatan ambigu menjadi trade-off menjadi semakin penting
- Terutama pada awal karier dan dalam pengelolaan organisasi, standar untuk menjaga pemahaman yang nyata menjadi lebih penting; semakin jelas membedakan apa yang didelegasikan dan apa yang ditangani langsung, semakin AI menjadi alat yang meningkatkan nilai manusia
Mode kegagalan saat pemikiran dialihdayakan
- A.I. dapat dengan cepat menangani tugas seperti pembuatan kode, ringkasan rapat, penjelasan konsep, penyusunan draf desain, dan penulisan pembaruan status, tetapi juga mudah membentuk kebiasaan menghasilkan keluaran yang tampak meyakinkan tanpa pemahaman
- Jika Anda mengulang jawaban dari mesin seolah itu adalah pemahaman Anda sendiri, Anda hanya meniru keadaan yang tampak kompeten tanpa benar-benar membangun kemampuan
- Semakin Anda menggantikan pemahaman sendiri dengan hasil yang dihasilkan, semakin Anda melewatkan latihan untuk membangun daya nilai, dan menukar kapabilitas jangka panjang dengan penampilan jangka pendek
- Dalam situasi yang tidak bisa ditangani dengan template, seperti masalah yang asing, kondisi yang ambigu, informasi yang tidak lengkap, atau batasan yang saling bertentangan, imitasi dangkal mudah runtuh
-
Analogi menyalin jawaban ujian
- Anda mungkin bisa mempertahankan nilai bagus dengan menyalin jawaban, tetapi ketika masuk ke situasi yang benar-benar menuntut pemahaman, akan terlihat bahwa fondasinya kosong
- Tanpa intuisi yang dibangun lewat mengerjakan sendiri, akan sulit menalar masalah yang tidak familiar atau merespons perubahan kondisi
- Jika terus memakai jawaban dari A.I. berulang kali, Anda hanya meminjam tampilan kemahiran, bukan membangun kemahiran yang nyata
-
Analogi kalkulator
- Kalkulator adalah alat yang baik untuk menghemat waktu, tetapi jika bergantung padanya tanpa number sense, Anda tidak lagi bisa memeriksa apakah hasilnya masuk akal
- Insinyur yang punya fondasi dapat meninjau output A.I., menyaring kesalahan, lalu memperbaiki atau membuangnya
- Insinyur tanpa fondasi tidak menggunakan A.I., melainkan dibawa oleh A.I., dan ini lebih berbahaya terutama pada peran yang menuntut akurasi dan tanggung jawab atas hasil
-
Analogi mobil swakemudi
- Swakemudi mengurangi kelelahan dan menangani situasi sehari-hari, tetapi jika bergantung padanya sebelum memahami cara mengemudi, Anda menjadi lebih mirip penumpang yang hanya memegang kendali
- Dalam situasi nonstandar seperti jarak pandang buruk, jalan yang rumit, kendaraan lain yang tidak dapat diprediksi, kegagalan sistem, atau bahaya yang muncul tiba-tiba, kemampuan nyata akan terlihat
- A.I. juga kuat pada pola umum dan struktur yang familiar, tetapi rekayasa terus menyimpang ke wilayah seperti perubahan requirement, bug yang halus, kepemilikan yang tidak jelas, tujuan arsitektur yang saling bersaing, data parsial, friksi organisasi, dan trade-off tanpa jawaban sempurna
Cara insinyur unggul menggunakan A.I.
- Insinyur unggul bukan menggunakan A.I. lebih sedikit, melainkan lebih aktif menggunakannya, sambil tidak menyerahkan proses berpikir itu sendiri
- Mereka dengan rela menyerahkan pekerjaan mekanis seperti menulis boilerplate, merangkum dokumen, membuat scaffolding pengujian, memberi saran refactoring, mengeksplorasi kemungkinan kegagalan, mempercepat riset, dan memadatkan pekerjaan berulang
- Sebaliknya, mereka membentuk pertanyaan yang lebih tajam, mendefinisikan masalah yang sebenarnya alih-alih sekadar permintaan yang tampak di depan mata, serta mengutamakan kejelasan dan keringkasan dibanding kalimat mulus yang kosong substansi
- Mereka tidak berhenti pada menyusun ulang pengetahuan yang sudah ada di dalam sistem, tetapi menciptakan pengetahuan baru bernilai tinggi
- Waktu yang didapat lalu diinvestasikan kembali ke pemikiran dan penilaian di tingkat yang lebih tinggi
Sumber nilai yang sebenarnya
- Selama ini, rekayasa perangkat lunak sering disamakan dengan produksi kode, tetapi nilai tertingginya bukan di sana
- Jika inti pekerjaan hanyalah membuat kode yang benar secara sintaksis, maka A.I. memang akan langsung menggantikan porsi besar pekerjaan itu, tetapi inti yang sebenarnya adalah daya nilai
- Insinyur yang bernilai mampu melihat batasan tersembunyi sebelum menimbulkan insiden, menyadari bahwa tim sedang memecahkan masalah yang salah, mengubah perdebatan yang ambigu menjadi trade-off yang jelas, menemukan abstraksi yang hilang, dan men-debug realitas, bukan hanya kode
- A.I. dapat mendukung pekerjaan seperti ini, tetapi tidak bisa mengambil alihnya
- Ke depan, insinyur yang menciptakan nilai lebih besar akan lebih dekat dengan mereka yang menghasilkan prinsip desain, pemahaman domain, pola, konteks, dan framework pengambilan keputusan yang membuat A.I. semakin berguna
- Dalam lingkungan ini, alih-alih digantikan A.I., insinyur memperoleh leverage yang lebih besar dengan bekerja di lapisan di atas output mentah
Risiko yang lebih besar bagi insinyur di awal karier
- Masalah ini terutama lebih penting bagi mereka yang masih di awal karier
- Beberapa tahun pertama adalah masa terbentuknya kapabilitas dasar seperti insting debugging, intuisi sistem, presisi, taste, review yang skeptis, kemampuan mengurai masalah, dan kemampuan menjelaskan mengapa sesuatu bekerja
- Kapabilitas seperti ini dibangun lewat friksi, trial and error, memperbaiki kegagalan, menelusuri akar penyebab, dan pengalaman saat pemahaman diuji oleh realitas
- Jika A.I. menghilangkan semua kesulitan dalam proses belajar, Anda mungkin mendapat efisiensi jangka pendek, tetapi melewatkan tahap ketika kemampuan ditempa
- Selama satu atau dua kuartal Anda mungkin tampak efisien, tetapi bisa diam-diam kehilangan kemampuan yang akan menopang masa depan
- Sistem pendukung bisa membuat sesuatu tampak berfungsi, tetapi tidak bisa sekaligus menciptakan kemampuan nyata sebagai gantinya
Tidak ada jalan pintas menuju daya nilai
- Hanya dengan membaca penjelasan yang dihasilkan, kemahiran tidak berpindah ke kepala Anda tanpa Anda mengerjakan sendiri
- Tidak ada jalan untuk lama-lama mengalihdayakan penalaran lalu pada akhirnya tetap memiliki kemampuan bernalar yang kuat
- Mengalihdayakan pekerjaan mekanis, mempercepat riset, dan memadatkan tugas berulang memang mungkin dan diinginkan
- Namun Anda tidak akan memiliki suatu keterampilan jika proses pembentukan keterampilan itu sendiri dilewati
- Kekeliruan inti dari pemanfaatan A.I. yang paling naif adalah merasa sedang menghemat waktu, padahal sebenarnya hanya menunda tagihan berupa daya nilai yang lemah, pemahaman yang dangkal, dan adaptabilitas yang rendah
Garis pembeda dan implikasinya di tingkat organisasi
- Jika A.I. membantu membangun pemahaman lebih cepat, berpikir lebih dalam, dan bekerja pada level yang lebih tinggi, maka nilai manusia meningkat
- Jika A.I. membantu orang menghindari pemahaman, menghindari kesulitan, dan menghindari kepemilikan atas penalaran, maka nilai manusia menurun
- Satu jalur akan terakumulasi seperti bunga majemuk, sementara jalur lain mengosongkan isi dan mendorong ke keadaan yang mudah menjadi tidak relevan
- Masa depan akan lebih berpihak pada insinyur yang bukan sekadar menggunakan A.I., melainkan yang mampu membedakan dengan tepat apa yang didelegasikan dan apa yang dimiliki langsung, lalu mengubah penghematan waktu menjadi pemikiran yang lebih baik
Mengapa dampaknya lebih besar pada kesehatan organisasi
- Manajemen engineering juga akan berdiri di batas yang sama: membedakan antara penggunaan yang mempercepat pemahaman dan penggunaan yang meniru pemahaman
- Kepemimpinan yang kuat harus mampu membedakan hasil yang mulus dari daya nilai yang nyata, karena jika hanya memberi imbalan pada kecepatan, kelancaran, dan kemampuan presentasi, sinyal kedalaman teknis akan terlewat
- Jika pekerjaan dengan pemahaman rendah namun kefasihan tinggi menyebar, bukan hanya kualitas output individu yang menurun, tetapi seluruh lingkungan pengetahuan organisasi ikut melemah
- Review menjadi lebih lemah
- Diskusi desain menjadi lebih dangkal
- Dokumentasi menjadi lebih mulus tetapi kurang berguna
- Seiring waktu, organisasi kehilangan kemampuan untuk menghasilkan kejelasan dan penilaian teknis yang menjadi sandaran mereka sendiri
- Karena itu, yang utama bukan sekadar adopsi alat A.I., melainkan menjaga kondisi agar pemikiran nyata, pembelajaran, dan craftsmanship tetap hidup
- Sejak tahap rekrutmen, diperlukan cara untuk membedakan pemahaman yang nyata dari kefasihan yang hanya tampak di permukaan
- Interview harus menguji proses penalaran alih-alih polished answer
- Evaluasi harus memberi imbalan pada kejelasan, kedalaman, penilaian yang sehat, dan kontribusi teknis yang bertahan lama, bukan sekadar volume output
- Ini juga sangat memengaruhi desain tim dan budaya
- Jangan sampai insinyur yang kuat menghabiskan terlalu banyak waktu membereskan pekerjaan yang tampak meyakinkan tetapi dangkal yang dibuat oleh orang-orang yang mengalihdayakan pemikiran
- Jika ini tidak dicegah, para high performer akan habis dipakai sebagai penguat untuk semua orang selain dirinya sendiri, dan hasilnya mudah berujung pada frustrasi, turunnya standar, dan hengkangnya orang
- Pada era A.I., kualitas organisasi pada akhirnya semakin ditentukan oleh apakah kepemimpinan dapat terus membedakan leverage dan ketergantungan, percepatan dan imitasi, 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