- Dari NoCode hingga AI, teknologi yang mengklaim akan menggantikan pengembang terus muncul berulang kali, tetapi pada kenyataannya yang terjadi adalah peran berubah mengikuti perubahan teknologi
- NoCode tidak menghapus pengembang, melainkan melahirkan spesialis NoCode dan tenaga ahli integrasi, sementara cloud menciptakan profesi tingkat lanjut bernama insinyur DevOps
- Alat pengembangan AI saat ini juga menempuh jalur serupa, dan bahkan di era ketika AI menulis kode, kemampuan merancang arsitektur sistem tetap menjadi inti
- AI unggul dalam optimasi lokal, tetapi lemah dalam perancangan sistem secara keseluruhan, dan karena kecepatan generasinya tinggi, ada risiko kesalahan struktural mengakar dengan cepat
- Pada akhirnya, penggantian pengembang hanyalah evolusi dan peningkatan seiring perubahan tech stack, sementara peran dasarnya tetap dibutuhkan
From NoCode to AI-Assisted
- Setiap beberapa tahun, muncul teknologi baru yang diklaim akan menggantikan pengembang perangkat lunak
- Judul-judul serupa dengan ekspektasi berlebihan terus berulang, seperti “akhir dari coding”, “sekarang siapa pun bisa membuat aplikasi”, atau “anak-anak pun bisa coding”
- Eksekutif dan konsultan menaruh perhatian pada arus ini, dan terlihat adanya perpindahan anggaran
- Namun kenyataannya selalu bukan “penggantian”, melainkan “transformasi”
- Berulang kali terlihat kecenderungan lahirnya peran baru dan profesi spesialis yang lebih maju untuk menangani teknologi yang makin kompleks, dan tingkat gaji juga meningkat
- NoCode menciptakan harapan bahwa aplikasi bisa dibuat tanpa tenaga teknis profesional, tetapi pada akhirnya tetap ada masalah kompleks seperti pemodelan data, integrasi, dan pemeliharaan, sehingga lahirlah profesi baru untuk menyelesaikannya
- Cloud memberi kesan bahwa operasional bisa berjalan tanpa administrator sistem, tetapi kenyataannya justru menuntut keahlian tingkat tinggi sebagai insinyur DevOps, dan gajinya pun meningkat
- AI juga sama; tampaknya “AI bisa menulis kode sebagai pengganti”, tetapi dalam praktiknya pentingnya pengembang berpengalaman yang mampu mengelola dan mengorkestrasi AI justru semakin besar
Korsel janji penggantian yang terus berputar (The Endless Carousel of Replacement Promises)
Revolusi NoCode/LowCode
- Muncul revolusi NoCode/LowCode yang menjanjikan bahwa semua orang bisa membuat aplikasi lewat antarmuka intuitif
- Namun di lapangan, muncul masalah baru seperti perancangan model data, integrasi dengan sistem dan database yang sudah ada, penanganan pengecualian, dan pemeliharaan
- Karena itu, yang dibutuhkan bukan sekadar pengembang biasa, melainkan spesialis NoCode yang memahami sekaligus pengetahuan domain dan keterbatasan teknis
- Mereka menerima gaji yang lebih tinggi dibanding pengembang konvensional
Revolusi cloud
- Ada ekspektasi besar bahwa perpindahan ke cloud akan membuat administrator sistem tak lagi diperlukan
- Namun justru kompleksitas dan kebutuhan akan keahlian pengelolaan cloud meningkat
- Administrator sistem lama bertransformasi menjadi insinyur DevOps dengan gaji lebih tinggi, dan level pekerjaannya meningkat ke otomatisasi infrastruktur, pipeline deployment, dan pengelolaan sistem terdistribusi
- Pekerjaan itu tidak hilang, melainkan berevolusi menjadi bentuk kerja baru
- Dalam transisi ke microservices pun kompleksitas membesar, dan pada akhirnya terlihat bahwa peran ahli yang secara mendasar mengelola sistem tetap penting
Gelombang pengembangan offshore
- Muncul keyakinan bahwa biaya bisa dihemat lewat outsourcing ke luar negeri, tetapi muncul kesulitan akibat masalah komunikasi, penurunan kualitas, dan kurangnya pengetahuan domain
- Akhirnya strateginya berubah ke penataan ulang struktur tim terdistribusi, kepemilikan yang jelas, dan arsitektur yang kuat, yang justru menghasilkan total biaya lebih tinggi dari ekspektasi awal
Revolusi asisten coding AI
- Kini, janji bahwa AI akan secara otomatis menghasilkan kode menjadi topik utama
- Pada kenyataan awal, kode yang dibuat AI sering mengandung kesalahan halus dan masalah konsistensi
- Insinyur senior menghabiskan banyak waktu untuk meninjau dan memperbaiki hasil AI, dan semakin berpengalaman seorang pengembang, semakin besar nilai yang bisa ia ciptakan
- Sistem yang dibangun hanya dengan bantuan AI sering kali tidak memiliki arsitektur yang sistematis
- Artinya, teknologi tidak menggantikan teknolognya, melainkan mengangkat keahlian mereka ke lapisan abstraksi yang lebih tinggi
Mengapa siklus kali ini terasa istimewa
- Hal penting yang sering diabaikan orang: kode bukan aset, melainkan utang
- Semakin cepat dan mudah kode dibuat, semakin besar pula beban pemeliharaan, keamanan, dan refactoring
- AI mampu melakukan optimasi di tingkat fungsi, tetapi kurang dalam kemampuan merancang keseluruhan sistem
- Semakin cepat implementasi, semakin besar risiko kesalahan struktural mengakar dengan cepat
- Pada akhirnya, bahkan di era AI, aset yang sesungguhnya adalah kemampuan merancang arsitektur sistem, dan ini adalah sesuatu yang bukan untuk digantikan, melainkan diperkuat
- Klaim bahwa “AI akan menggantikan pengembang” berangkat dari kesalahpahaman mendasar berikut
- Fakta bahwa kode bukan aset, melainkan utang
- Kode membutuhkan pemeliharaan, verifikasi, pengelolaan keamanan, dan penggantian secara berkelanjutan, dan utang bertambah seiring banyaknya baris kode
- Fakta bahwa AI dapat membuat kode dengan cepat pada dasarnya hanya berarti utang juga tercipta secepat itu
- Dengan kata lain, AI bagus dalam optimasi lokal (fungsi, bagian fitur), tetapi kurang dalam desain global dan keputusan arsitektur
- Semakin cepat implementasi, semakin besar risiko desain yang salah menjadi ‘mengeras’ di seluruh sistem
- Ini mungkin tidak masalah untuk pembuatan situs jangka pendek sekali pakai, tetapi fatal untuk sistem yang berkembang dalam jangka panjang
- Pola inovasi teknologi tetap tidak berubah
- Administrator sistem menjadi insinyur DevOps, dan pengembang backend menjadi arsitek cloud
- Namun AI mempercepat semuanya. Keterampilan yang bertahan dan terus berkembang bukanlah menulis kode
- Melainkan merancang sistem (Architecting systems). Itulah satu-satunya hal yang tidak bisa dilakukan AI
19 komentar
Saya termasuk orang yang bekerja cukup konservatif, jadi saya belum pernah mencoba menerapkan tool AI ke pekerjaan penting; paling hanya mengganti kebiasaan mencari di Google atau Stack Overflow menjadi bertanya ke Gemini atau ChatGPT? Saya memang memakainya, tapi...
Saat meminta AI membuat sesuatu, saya berpikir mungkin cukup oke jika dipakai dengan cara meminta pembuatan fungsi pada level fungsi—misalnya fungsi yang menghasilkan output tertentu saat diberi input tertentu—lalu saya sendiri menulis logika untuk memeriksa apakah nilai return dari fungsi buatan AI itu benar-benar keluar dengan semestinya.
Saya skeptis terhadap pertanyaan apakah semua konteks bisa dirapikan ke dalam format yang dapat dipahami AI dengan baik. Manusia memiliki konteks laten selain konteks yang secara permukaan dibutuhkan untuk pengembangan yang sedang dikerjakan saat ini, dan kita mengembangkan sambil mempertimbangkan bagian-bagian semacam itu, tetapi saya masih tidak merasa bahwa manusia bisa menuliskan konteks ini dalam ekspresi yang rapi dengan baik. Menurut saya ini bukan masalah AI, melainkan keterbatasan manusia. Terlebih lagi, saya juga merasa kemampuan menulis orang-orang modern saat ini tidak terlalu baik.
Yang menakutkan bukan momen ini sekarang, melainkan tren itu sendiri..
Sekarang sama sekali berbeda.
Masa depan di mana semua pekerjaan akan tergantikan sudah di depan mata, dan developer hanyalah salah satunya.
Hal seperti ini belum pernah menjadi tren sekalipun.
Kemungkinan besar memang tidak ada perubahan yang persis sama.
Namun ini adalah perubahan yang sudah dialami banyak profesi sejak lama, bahkan sejak era modern awal. Misalnya, perubahan yang dialami para seniman dengan hadirnya fotografi, atau para perajin dengan pabrik yang terotomatisasi. Tampaknya pemrograman pun tidak berbeda.
Saya memperkirakan bahwa ketika inovasi menjadi hal yang biasa dalam kehidupan sehari-hari, pada akhirnya akan dibutuhkan lebih banyak engineer daripada sekarang. Standar ekspektasi pengguna akan semakin tinggi, dan kita harus membuat hal-hal yang lebih besar dan lebih kompleks. Kurang lebih seperti yang dikatakan dalam hipotesis Ratu Merah.
Tentu saja, kemungkinan besar jenis pekerjaannya akan berubah atau tugas tertentu akan hilang. Seperti tukang setting huruf yang entah sejak kapan sudah lenyap. Dalam konteks itu, merancang sistem mungkin akan menjadi metafora atau contoh dari abstraksi yang semakin tinggi.
Menurut saya, itu karena banyak orang ingin menggantikan developer dengan sesuatu.
Sepertinya cukup banyak orang yang berpikir mereka tidak banyak bekerja tetapi dibayar sangat mahal.
Menurut saya, terlepas dari apakah itu benar-benar menggantikan atau tidak, alasan topik seperti itu terus dibicarakan adalah karena sifatnya provokatif.
Sebagian besar headline semacam itu, ketika dibuat dengan sangat mencolok, sejak awal tampaknya bukan hasil dari pemikiran mendalam tentang seperti apa kenyataannya atau bagaimana sebenarnya kita bisa mendefinisikan apa yang disebut sebagai penggantian.
Hasil pemikiran yang benar-benar matang justru akan membahas sampai sejauh mana AI atau alat lain bisa bekerja saat ini dan ke arah mana perkembangannya menuju. Dan judul yang tidak menarik seperti itu tentu tidak akan diklik oleh orang kebanyakan.
Banyak judul yang sensasional..
"Zuckerberg yang memecat 10% tiap tahun: 'Tahun depan AI akan menggantikan separuh developer' [Silicon Valley View oleh Yoon Min-hyuk]"
https://m.sedaily.com/NewsView/2GRQ1RKIYC
"'Hal yang paling dikuasai AI adalah coding'… prioritas pertama restrukturisasi MS adalah 'developer'"
https://n.news.naver.com/mnews/article/009/0005494133
"'Jangan-jangan sampai kehilangan pekerjaan' Kekhawatiran itu jadi 'kenyataan'?… industri diliputi kecemasan"
https://econmingle.com/economy/…
"[Pilihan Yumi] 'Kami tidak merekrut developer software junior'… perusahaan yang sudah merasakan 'AI coding' mulai 'efisiensi organisasi'"
https://v.daum.net/v/20250522162617091
"'AI melakukan analisis, desain, dan coding'… LG CNS memakai 'AI programmer' alih-alih developer"
https://zdnet.co.kr/view/?no=20250528092405
Saya rasa kita harus melihatnya sebagai penggantian yang terjadi secara bertahap.
Memang benar bahwa jumlah orang yang perlu dilibatkan untuk menghasilkan hasil kerja yang sama sedang berkurang.
Bahkan untuk "merancang sistem", jika pekerjaan yang sebelumnya dikerjakan 10 orang bisa diselesaikan oleh 8 orang + dukungan AI,
maka 2 orang itu pada dasarnya sudah tergantikan.
Dari sisi desain sistem juga
Mungkin karena biasanya itu dimasukkan ke dalam prompting tanpa benar-benar dipertimbangkan
Masalahnya sepertinya sulit menangani dampak setelah vibe coding.
Saya setuju berdasarkan pengalaman pribadi. Pada akhirnya AI juga hanyalah alat, jadi dari 1 sampai 99 memang sangat cepat dan bagus, tetapi selalu terasa seperti 1 sisanya tidak ada.
Saya setuju, tetapi saya rasa inti utamanya bukan sekadar "desain sistem", melainkan "pemecahan masalah kompleks melalui desain sistem".
Saya percaya pekerjaan yang mudah akan menjadi lebih mudah, dan pekerjaan yang sulit akan terus menjadi semakin sulit.
Hehe
Opini Hacker News
Dari pengalaman baru-baru ini merevisi pekerjaan lepas seperti "landing page marketing sekali pakai", klien yang sangat ingin mengontrol selalu menambahkan permintaan aneh yang tidak bisa ditangani AI dengan baik, sehingga pada akhirnya saya yang harus membereskan masalahnya; secerdas apa pun AI nantinya, masalah perangkat lunak bukan semata teknis, melainkan manusia terus-menerus menciptakan ‘kompleksitas yang tidak perlu’; pada akhirnya senjata terbesar developer adalah kemampuan untuk “menolak”, tetapi ada kekhawatiran bahwa jika AI saling bersaing, selalu akan ada satu yang berkata ya seperti manusia
Perangkat lunak bisa diimplementasikan dengan sempurna, tetapi jika requirement-nya sendiri tidak mencerminkan realitas teknis, yang muncul pada akhirnya hanyalah kekacauan; ini konsep klasik tentang “bug pada requirement”; AI kini juga bisa menangani batasan dunia nyata seperti format atau dukungan fitur (misalnya gif tidak mendukung transparansi), tetapi manusia akan terus menulis permintaan absurd seperti “tolong buat logo berbentuk persegi sehingga setiap titik berjarak sama dari pusat”; typo jpg juga disebut sebagai humor
Dari pengalaman, di antara ‘tidak’ dan ‘ya’ ada 50 tingkat abu-abu berupa pertanyaan “apakah ini benar”; seseorang pernah mengatakan ingin halaman web “yang bisa mengunduh database”, padahal maksud sebenarnya hanya ekspor csv sederhana; ini menunjukkan pentingnya memahami konteks, dan ada rasa penasaran apakah chatgpt benar-benar bisa menangkap nuansa seperti ini
“Menolak” benar-benar bagian paling sulit dan berat dalam pekerjaan developer; banyak developer sebenarnya tidak menikmati peran ini atau merasa itu bukan bagian dari pekerjaannya; pada akhirnya, keberhasilan nyata proyek ditentukan bukan oleh teknologi melainkan komunikasi ‘manusia dengan manusia’ dengan para pemangku kepentingan, sehingga selalu akan dibutuhkan ‘developer yang pada praktiknya juga merangkap PM’
Semua ini adalah hal yang dibahas dengan baik dalam buku yang disebut ‘Peopleware’; alasan menyukai ucapan “semoga semua masalahmu bersifat teknis”; kenyataannya, masalah yang benar-benar diselesaikan lewat kode hanya sebagian kecil saja, kecuali beberapa edge case yang sangat terbatas
Ada yang menilai ini poin yang bagus, dan AI berpotensi makin unggul dalam memperkirakan kompleksitas serta memberi peringatan; dianalogikan dengan catur, di mana AI sudah jauh lebih baik dari manusia dalam evaluasi/penilaian; AI di sini tidak terbatas pada LLM, tetapi tetap mengakui kemajuan di kategori itu
Ada yang tidak setuju dengan klaim artikel bahwa “AI tidak bisa melakukan architecting sistem”; kenyataannya AI sudah makin mampu di area ini, dan ada fenomena terus menggeser definisi syarat yang dianggap perlu sambil memindahkan pokok perdebatan; hanya saja AI belum bisa menentukan sendiri apa yang harus diinginkan, atau memutuskan motivasi pengguna; tentu AI bisa memberi ide, tetapi agar masyarakat tetap berjalan, seseorang tetap harus bergerak langsung dan ingin menyelesaikan masalah; peran developer akan berubah, tetapi pemecahan masalah tetap menjadi bagian manusia
Dikatakan bahwa arti “developer” sedang berubah, tetapi ada pandangan bahwa esensinya sejak awal tetap sama; pemrograman pada dasarnya adalah mengubah requirement yang samar menjadi kode yang jelas; berbeda dengan masa lalu ketika metodenya berubah dari machine code dan punch card ke framework, GUI, dan alat visual, alasan menulis kode tetap paling efektif adalah karena kejelasan dan daya komunikasinya; LLM kuat dalam mengikuti pola yang sudah ada, tetapi sangat membuat frustrasi untuk pekerjaan yang benar-benar baru atau saat penjelasan dicoba lewat bahasa alami; pasar sedang berada di puncak hype, tetapi pola perubahan parsial seperti ini selalu berulang setiap kali teknologi baru muncul
Sudah terlihat perubahan seperti perusahaan mengurangi perekrutan junior akibat AI; ada kekhawatiran bahwa jika AI melakukan hampir semua hal kecuali architecting, maka pada akhirnya struktur industri akan membutuhkan lebih sedikit engineer
Ada yang menegaskan bahwa AI masih belum bisa melakukan architecting; architecting dan planning berbeda, dan planning adalah kemampuan mengalokasikan batasan, solusi, dan sumber daya serta membuat prediksi; AI dinilai masih jauh dari mampu melakukannya secara efektif; architecting yang sesungguhnya adalah desain kolaboratif dan kompetitif lintas banyak layer, dan jika AI membuat kesalahan di satu layer, seluruh sistem bisa melenceng; sistem seperti ini, menurut mereka, hanya bisa dirancang dan diawasi dengan aman oleh manusia
Ada pendapat bahwa jika diberi konteks yang cukup, AI juga bisa memahami apa yang diinginkan dengan cukup baik; ini sekaligus terhubung dengan peringatan soal pelanggaran privasi; jika organisasi memegang sistem yang kuat dan teknologi yang sadar konteks, justru yang lebih menakutkan adalah AI bisa memprediksi keinginan Anda atau bahkan tindakan Anda berikutnya dengan “cukup” akurat
Ada kritik jujur bahwa AI saat ini bukan melakukan architecting, melainkan hanya simulasi, dan bahkan untuk coding pun sering kali belum mampu dengan baik
Ada klaim bahwa asumsi bisnis menghargai kualitas itu sendiri keliru; perusahaan hanya mempertimbangkan profitabilitas, dan hanya akan memberi kualitas tinggi jika pelanggan menginginkannya; sejujurnya pelanggan pun lebih menyukai barang dengan value terbaik daripada kualitas, sehingga mereka membeli alat termurah di Amazon dan terus memproduksi kode ala vibe code yang sama-sama rapuh; pada akhirnya, kelompok yang benar-benar peduli kualitas hanyalah engineer, sehingga prediksi masa depan yang menganggap kualitas penting dari sudut pandang engineer bisa diabaikan dengan berani
Ada pendapat bahwa kualitas bisa menjadi titik diferensiasi; saat iPhone muncul, meskipun sudah ada banyak pesaing dengan fitur lebih banyak, ketika UI yang lebih mulus dan halus hadir, pasar akhirnya dikuasai olehnya
Diperkenalkan Fractal Audio sebagai perusahaan yang paling disukai karena berfokus pada kualitas; perusahaan kecil ini membuat modeler berbasis hardware untuk gitar (simulator amp dan pedal board), dengan pembaruan inovatif beruntun dan CEO yang sangat obsesif terhadap kualitas pemodelan analog; kualitasnya jauh melampaui perusahaan besar; posisinya dibangun lewat penjualan langsung dan pembaruan algoritme gratis tanpa komisi, langganan, atau pemasaran selebritas; ini disebut contoh hidup bahwa kualitas bisa merebut pangsa pasar, dan bahwa tidak semua bisnis selalu berlomba pada ‘harga termurah dan kualitas terendah’
Ada yang menolak pandangan bahwa pelanggan tidak peduli kualitas; jika kualitas memang tak bermakna, maka semua startup seharusnya cukup membuat produk yang tidak sempurna dan murah lalu meraih penjualan besar serta sukses luar biasa
Disebutkan bahwa sebagian besar produk perangkat lunak yang benar-benar sukses memiliki kualitas yang sangat baik; Google, iPhone, Stripe, Notion, dan produk lain yang bertahan lama di pasar bukanlah produk yang lambat atau penuh bug; justru kualitas dianggap sebagai faktor keberhasilannya, dan muncul pertanyaan mengapa hampir tidak terdengar contoh yang sebaliknya
Ada kekhawatiran bahwa kualitas sampai tingkat tertentu bisa memudar karena komoditisasi, model langganan, dan kebutuhan koneksi internet, tetapi masa depan ketika segala sesuatu runtuh secara drastis tetap mungkin datang; perangkat bisa menjadi brick, situs sederhana pun butuh 12 detik untuk berjalan, infrastruktur sosial dan sistem pemerintah menjadi tidak stabil meski menelan miliaran biaya, dan percakapan sehari-hari berubah menjadi berhadapan dengan LLM; semua ini diingatkan sebagai risiko
Ada kilas balik bahwa revolusi organisasi lama berbasis UML, di mana “arsitek membuat spesifikasi dan developer hanya mengisi bagian kosong”, justru menghasilkan sistem yang terlalu kompleks dan kehilangan kelincahan; setelah itu “agile” juga disalahpahami dan berubah menjadi budaya mikromanajemen developer, ketidakpercayaan, dan organisasi yang tidak kreatif; pada akhirnya, ciri tim yang benar-benar berhasil, terlepas dari alat atau prosesnya, adalah saat orang non-developer sungguh tertarik pada pekerjaan developer dan ikut memecahkan masalah bersama; sebaliknya, upaya menurunkan kompleksitas selalu dinilai gagal
Menanggapi klaim bahwa “architecting adalah keterampilan paling bernilai tetapi tidak bisa digantikan AI”, ada yang berkata bahwa jika kita secara eksplisit meminta AI merancang arsitektur sistem, sering kali hasilnya lebih baik daripada setidaknya 30% perancang yang pernah ditemui di dunia nyata; masalahnya lebih karena pengguna AI jarang meminta hal seperti itu
LLM saat ini terutama dilatih dengan banyak jawaban tingkat menengah berupa best practice, sehingga secara alami hasilnya lebih baik daripada sepertiga perancang manusia pada level itu, yaitu desain yang masuk akal dan aman; namun di bidang yang benar-benar baru, tidak ada di data pelatihan, atau membutuhkan performa tinggi, pemikiran manusia berbasis first principles tetap lebih dibutuhkan; kernel DB yang dirancang LLM pun diperkirakan hanya akan sampai pada tingkat dasar, bukan inovatif
Ada kritik bahwa artikelnya sendiri memakai gaya khas tulisan ChatGPT, seperti kalimat pendek, pengulangan, pola “bukan X melainkan X+1”, “bukan X melainkan anti-X”, dan perangkat ekspresi yang berlebihan; mereka juga heran tulisan seperti ini bisa mendapat banyak upvote di HN
Penulis dianggap sedang melakukan ‘wishful thinking’ yang berasal dari keyakinan atau kesombongan bahwa keahlian dirinya sendiri, yaitu architecting, bersifat tetap dan tak tergantikan; komentarnya, jika penulis lebih unggul di kemampuan lain, mungkin itulah yang akan ia anggap tak tergantikan
Inti seorang arsitek diringkas sebagai kemampuan memahami requirement dan constraint secara akurat lalu mencerminkannya ke dalam sistem; dengan kata lain, kemampuan membuat prompt yang baik, membaca jawaban dengan benar, dan bila perlu membantah dengan tegas
Banyak ‘arsitek’ yang ditemui di dunia nyata sebenarnya kurang punya kemampuan substansial; mereka mengira cukup bisa memakai alat diagram atau Excel tanpa benar-benar memahami infrastruktur TI; terlihat seperti manajer, tetapi kenyataannya hanya sedikit yang bisa menjalankan esensi pekerjaan itu
Ada pendapat bahwa perusahaan yang terlalu bergantung pada AI justru memperbesar risiko terkena gelombang disrupsi inovasi; di era AI, yang terpenting bukan produktivitas menghasilkan kode melainkan pengendalian kualitas kode, tetapi pasar terlalu fokus pada produksi kode otomatis; disebut juga pernyataan Satya Nadella bahwa “30% kode MS ditulis oleh AI”, lalu tren insiden Github yang rata-rata lebih dari 20 kejadian per bulan (tautan referensi: githubstatus.com/history); diperkirakan banyak perusahaan yang mengejar efisiensi akan harus menanggung akibat penurunan kualitas, dan jika bukan perusahaan raksasa seperti MS, UKM justru berisiko runtuh
Ada pendapat tandingan bahwa justru perusahaan yang mengabaikan AI akan lebih kesulitan
Ada klaim bahwa “perusahaan yang terlalu banyak memakai AI justru menanggung biaya besar dalam jangka panjang” beserta pengenalan artikel terkait (AI: Accelerated Incompetence)
Ada yang 100% setuju dengan klaim bahwa “kode bukan aset, melainkan utang”; tujuannya adalah mencapai sasaran dengan kode sesedikit mungkin; AI justru mempermudah produksi kode secara berlebihan, sehingga ada kekhawatiran utang kode akan jauh lebih besar
Dibagikan tautan wiki tentang paradoks produktivitas dalam kemajuan teknologi, yaitu saat produktivitas meningkat tetapi efisiensi nyata terkompensasi oleh naiknya kompleksitas sistem (Productivity paradox)
Era pembuatan kode oleh AI modern dibandingkan dengan masa ketika orang membuat situs memakai MS FrontPage, saat html dipenuhi 90% kode tak berguna, yaitu ‘era cruft’ yang lama
Ada sudut pandang terbalik: jika kode kini begitu mudah digantikan, bukankah perspektif utang jadi kurang bermakna? Ke depan, jika ada error, programmer tinggal meminta AI menulis ulang kodenya, sehingga bebannya mungkin berkurang
Ada juga yang memandang kode sebagai ekspresi kreatif dan artistik; dibagikan pengalaman bisa langsung merasakan keindahan saat melihat kode yang rapi, mudah dibaca, dan elegan
Dibagikan tautan yang mengingatkan bahwa sejak awal peluncuran FORTRAN (1954) sudah ada slogan bahwa “Fortran akan menghapus coding dan debugging itu sendiri” (BackusEtAl-Preliminary Report)
Ada pandangan bahwa asumsi dasar di balik semua diskusi ini adalah harapan bahwa kemajuan teknologi akan segera mencapai batas; jika asumsi itu salah, maka suatu hari AI bisa saja memahami dan merancang bisnis secara menyeluruh dengan mencerna seluruh infrastruktur, log, keuangan, dan dokumen; model AI masih terus bertambah, kemampuannya membaik dan makin murah, sehingga ada yang lebih condong percaya bahwa pada akhirnya penggantian akan menyentuh esensinya juga
Ada pandangan bahwa PHK developer bukan disebabkan kemajuan teknologi, melainkan tindakan lanjutan karena ketidakpastian, dan alasan teknologi/AI hanyalah pembenaran setelah kejadian; dijadikan contoh bahwa lima tahun lalu perusahaan justru rela menambah engineer software demi meningkatkan produktivitas meskipun biayanya besar; karena itu, ada argumen bahwa biaya bukan akar masalahnya
Saya mencari orang yang bisa memeriksa vibe coding AI. Semuanya sudah saya buat, tapi ada error, tolong perbaiki sedikit saja. Permintaan kerja lepas seperti ini sudah mulai bermunculan, padahal biasanya lebih cepat kalau dibuat ulang dari awal.
Saya juga pernah mengalaminya, dan itu benar-benar mengerikan...
Entah mereka benar-benar tidak tahu atau memang tidak peduli, yang jelas ada banyak sekali orang seperti itu...
Terjemahan juga sama... AI memang lumayan bisa dipakai? Tapi sepertinya justru bikin banyak orang kerepotan...
Sekilas memang terlihat masuk akal, tetapi dari sudut pandang orang yang harus memperbaikinya, pekerjaannya malah jadi makin banyak, hiks hiks
Merinding wkwkwk