2 poin oleh GN⁺ 2025-09-14 | 1 komentar | Bagikan ke WhatsApp
  • AI untuk pemrograman memiliki struktur peran yang mirip dengan compiler tradisional
  • Prompt berbahasa Inggris memiliki sifat yang tidak akurat dan tidak efisien sebagai bahasa pemrograman
  • Ada kecenderungan bahwa efek peningkatan produktivitas dari AI sebenarnya dibesar-besarkan atau disalahpahami
  • Alat AI mengubah proses pengembangan, tetapi inovasi sejati kemungkinan muncul dari bahasa dan alat yang lebih baik
  • Adopsi LLM tidak berarti menggantikan developer, melainkan mencerminkan keterbatasan lingkungan pengembangan saat ini

Kemiripan AI dan compiler

  • Penulis mengatakan bahwa seiring bertambahnya usia, ia tidak lagi mencoba meyakinkan orang lain
  • Ditekankan bahwa banyak orang tidak tertarik pada kebenaran dan hanya mengikuti keyakinan yang menguntungkan diri mereka sendiri
  • Disampaikan kritik terhadap orang-orang yang mengklaim bahwa 'Perception is reality (persepsi adalah realitas)'
  • Ditunjukkan bahwa miliaran dolar yang diinvestasikan ke mobil swakemudi merupakan pemborosan akibat keyakinan yang keliru
  • Pandangan bahwa AI bisa menulis kode dianggap mirip dengan sudut pandang bahwa compiler-lah yang melakukan coding

Coding AI sebagai model yang sama dengan compiler

  • Dijelaskan argumen bahwa model terbaik untuk AI pemrograman adalah compiler
  • Pengguna memasukkan prompt (kode), lalu menerima output yang telah dikompilasi sebagai hasilnya
  • Perbedaannya adalah prompt dimasukkan dalam bahasa Inggris, tetapi bahasa Inggris memiliki berbagai kelemahan seperti kurang jelas dan tidak memiliki spesifikasi
  • Saat mengerjakan hal baru atau tugas yang kompleks, pada akhirnya panjang lebar prompt akan bertambah
  • Output AI bersifat non-deterministik, dan perubahan pada sebagian prompt dapat memengaruhi keseluruhan hasil

Pandangan kritis terhadap coding AI

  • Alasan coding AI terlihat positif adalah karena alat, bahasa, dan library saat ini sangat buruk
  • Berkat teknologi "AI", kini dimungkinkan adanya alat pencarian, optimisasi, dan ekstraksi pola yang lebih baik daripada sebelumnya
  • Yang sebenarnya melakukan coding adalah programmer itu sendiri, hanya bahasa untuk tindakan menulis kode yang berubah
  • Jika ada perusahaan tempat LLM bisa menggantikan developer, itu berarti codebase perusahaan dan standar rekrutmennya berada pada tingkat yang sangat rendah
  • AI dapat secara bertahap mengambil alih sebagian pekerjaan seperti compiler atau spreadsheet

AI adalah alat, pada akhirnya dibutuhkan bahasa·library yang lebih baik

  • Ditekankan bahwa banyak pemikiran dan kehati-hatian dibutuhkan dari sudut pandang AI sebagai alat
  • Pemborosan miliaran dolar sedang terjadi karena investasi pada harapan yang keliru atau ilusi
  • Disebutkan reaksi pasar yang berlebihan terhadap alat produktivitas palsu seperti “vibe coding”
  • Ada ilusi bahwa AI benar-benar meningkatkan produktivitas 20%, tetapi dikutip hasil penelitian (makalah) yang menunjukkan bahwa kenyataannya justru melambat 19%
  • Kemajuan sejati dapat muncul dari inovasi bahasa pemrograman, compiler, dan library

1 komentar

 
GN⁺ 2025-09-14
Komentar Hacker News
  • Saya hampir 50 tahun, dan sudah menulis kode secara profesional sejak akhir 90-an. Saya bisa langsung membayangkan proyek di kepala dan tahu persis apa yang harus dibuat. Gaji saya juga cukup tinggi. Dari luar, saya mungkin terlihat seperti tipikal orang yang anti-AI, tapi sebenarnya tidak. Saya bisa membuat apa pun, tetapi sering jenuh dengan segala macam pekerjaan dasar. Karena itu saya sangat suka bisa memakai AI untuk melewati bagian yang membosankan dengan cepat dan fokus pada pekerjaan inti yang saya sukai. Pengembangan dengan AI mirip seperti menyuruh developer yang berada di antara level junior dan menengah mengerjakan satu jam pekerjaan hanya dengan beberapa kalimat instruksi. Namun, fakta bahwa junior sungguhan jadi tidak bisa berkembang dan kumpulan calon senior di masa depan bisa menyusut memang masalah yang perlu dipikirkan serius, tapi itu isu yang terpisah

    • Saya bilang saya memakai AI untuk membereskan bagian yang membosankan dengan cepat, tetapi di antara senior yang berpengalaman ada juga yang justru negatif terhadap AI karena takut pada bagian yang berat. Banyak developer merasa aman secara psikologis di bagian yang mudah dan membosankan, tetapi ketika AI masuk, pekerjaan bisa berubah menjadi rangkaian kesulitan tanpa henti. Jika ada senior yang hanya punya banyak pengalaman tetapi kemampuan sebenarnya kurang, diberi tantangan terus-menerus bisa cepat burnout. Perusahaan mengadopsi AI hanya untuk mempercepat segalanya, tetapi mengabaikan fakta bahwa manusia butuh jeda kognitif. Kalau yang tersisa hanya pekerjaan yang berat, itu tidak baik untuk manusia. Tentu saja, developer yang bosan dengan pekerjaan berulang dan mudah bisa seperti terlahir kembali bersama AI. Pada akhirnya, pendekatannya memang harus berbeda untuk tiap orang

    • Saya sedikit lebih muda dari Anda, tetapi pandangannya hampir sama persis. Mungkin malah lebih ekstrem. Saya merasa yang menyenangkan bukan menulis kode untuk mewujudkan ide menarik, melainkan memunculkan ide dan bereksperimen itu sendiri. Jadi, saya menulis kode karena memang harus, bukan karena itu yang pada dasarnya ingin saya lakukan. Kalau saya ingin mewujudkan ide saya, mau tak mau saya harus menulis kode. AI sangat hebat sebagai mitra brainstorming. Kalau diminta untuk tidak menjilat, AI benar-benar jujur memberi tahu saat saya melakukan overengineering. AI juga sangat bagus untuk debugging. Jadi saya menjelaskan ke komputer dengan bahasa biasa sambil brainstorming arsitektur dan pendekatan, membuat spesifikasi, lalu menyerahkan implementasinya ke AI. Kalau pemikiran saya salah, saya iterasi cepat bersama AI. Siklus iterasinya begitu cepat sampai salah pun tidak masalah. Desain yang salah dulu sering saya biarkan karena harus mengubah seluruh kode, tetapi berkat alat agentic coding, mengubah seluruh codebase pun tidak jadi masalah. Saya juga masuk ke bidang teknis baru yang sebelumnya bukan keahlian saya, dan berkat AI saya bisa masuk dengan efektif lalu cepat berkembang. Sejujurnya, sekarang adalah masa paling menyenangkan dalam hidup saya sebagai programmer. Alat-alat ini membaik tiap minggu, kadang beberapa kali dalam seminggu

    • Ini sangat cocok dengan pengalaman saya juga. Lama pengalaman saya mirip. Saya memakai AI secara aktif baik untuk proyek pribadi maupun pekerjaan kantor. Pertama, AI berperan sebagai partner diskusi ide yang lebih minim bias. Loop umpan balik yang cepat dan validasi arah kerja terasa benar-benar esensial. Kedua, AI menghemat pengetikan dan waktu. Untuk ‘pekerjaan dasar’, sekali instruksi bisa menyelesaikan setidaknya 80% dengan sempurna. Memang bukan 100% selesai, tetapi waktu yang dihemat jauh lebih besar, jadi jelas menguntungkan. Saat memakai AI, saya selalu memasang guardrail, memberi instruksi sejelas dan sedetail mungkin, dan selalu membiasakan diri meninjau hasilnya sendiri

    • Saya punya pengalaman sekitar 10 tahun lebih sedikit, tetapi posisinya mirip. Tapi saya kurang bisa relate. Begitu suatu bagian mulai terasa membosankan, tantangan untuk langsung mengotomatiskan atau menggeneralisasikannya justru sangat menarik, jadi pekerjaan benar-benar membosankan hampir tidak pernah ada. Malah sering lebih cepat kalau saya mengetik sendiri. Saat menulis kode sendiri di bagian yang tidak menengah dan tidak sederhana, saya justru memikirkan struktur yang lebih baik atau ide otomatisasi baru. Akibatnya, hampir tidak ada kode yang ingin saya limpahkan. Dan saya bisa punya cara pandang ini mungkin karena sudah lama berada di satu perusahaan. Kalau saya harus terus-menerus mengerjakan kode baru, mungkin pandangan saya akan berbeda

    • Saya juga sudah 50-an dan menulis kode sejak 90-an, serta sudah menghasilkan cukup banyak uang sampai rasanya bisa dipakai hidup lebih dari tiga kali. Dalam 30 tahun karier, ada satu ciri yang sama pada developer terbaik: ‘kemalasan yang sempurna’. Kedengarannya aneh, tetapi satu-satunya sifat yang benar-benar sama pada engineer hebat adalah malas. Aneh sekali bagaimana kemalasan bisa berubah menjadi produktivitas. Alasannya karena mereka pasti mengotomatiskan pekerjaan berulang. Saya belajar prinsip bahwa kalau melakukan hal yang sama dua kali, maka untuk ketiga kalinya harus diotomatisasi. Dengan hadirnya AI, tingkat otomatisasinya berubah total. Sekarang bahkan pekerjaan yang dulu tidak mungkin pun bisa diotomatisasi. Saya menemukan tak terhitung banyaknya cara memakai AI, dan bukan cuma saya, rekan-rekan saya yang malas pun memakainya dengan sangat baik. Sekarang saya bahkan sulit membayangkan bekerja tanpa AI. Bukan karena AI itu ‘sihir’, tetapi karena bagi orang malas seperti saya, AI menggantikan semua pekerjaan yang bisa diotomatisasi

  • Menurut saya ini contoh yang sangat ekstrem dari groupthink soal AI yang sering terlihat di Hacker News. Geohot memang developer papan atas 99,999%, tetapi 99,999% developer yang tidak dia pahami tetap mengerjakan hal-hal yang lebih dasar. Ini paradoks pakar. Kalau semua orang sudah setingkat pakar, mereka tidak akan disebut pakar lagi. Saya sudah melihat banyak developer yang bertindak seperti AI. Mereka bahkan tidak bisa menjelaskan codebase yang mereka buat sendiri, dan tidak bisa merawatnya secara konsisten. Ini seperti insinyur dirgantara mengejek orang yang membuat mainan Kinder Surprise karena tidak paham simulasi fluida

    • Saya justru kaget ada orang yang menganggap HN negatif terhadap AI. Dari komentar dan postingan populernya, menurut saya HN secara keseluruhan sangat optimistis terhadap teknologi

    • Fakta bahwa orang yang mendirikan perusahaan mobil swakemudi mengambil posisi seperti ini juga terasa sangat tidak konsisten. Jika model AI tidak bisa menulis kode, saya ragu ia bisa menggantikan pekerjaan mengemudi yang jauh lebih sulit

    • Bagian ini sebenarnya sudah dijelaskan di awal tulisan. Intinya, banyak workflow pemrograman umum bisa dilakukan karena sudah sangat umum, sedangkan untuk pekerjaan baru Anda harus menjelaskannya sedetail tingkat bahasa itu sendiri

    • Saya bekerja di bidang dirgantara, dan engineer di sini juga tidak lebih baik. Tapi tidak perlu terlalu khawatir. Di perusahaan, orang seperti ini biasanya dipindahkan ke posisi yang tidak menimbulkan kerusakan, dan kebanyakan akhirnya jadi manajer

    • Saya tidak yakin Geohot benar-benar developer top 99,999%. “Model terbaik untuk AI pemrograman adalah compiler. Diberi prompt (=kode), ia mengeluarkan kode hasil kompilasi. Dibandingkan gaya interaktif dengan umpan balik seperti kebanyakan IDE, pendekatan ubah prompt → kompilasi ulang lebih baik.” Saya ragu itu benar

  • Salah satu inti diskusinya adalah bahwa kita perlu mendefinisikan dengan lebih spesifik “jenis pemrograman” yang dibicarakan. Sama seperti tidak ada gunanya bertanya “apakah robot baik atau buruk?” untuk urusan robot membuat sesuatu, diskusinya baru maju kalau ada pertanyaan lanjutan: “untuk objek seperti apa?”

  • Saya melihat ada banyak masalah dalam tulisan ini. Pertama, klaim bahwa “AI coding adalah compiler”. Compiler mengubah bahasa secara deterministik sesuai spesifikasi, sedangkan alat coding berbasis LLM adalah penyintesis program yang secara iteratif mencari, menghasilkan, dan memperbaiki kode di bawah berbagai kendala seperti test/type/linter/CI. Faktanya, alat-alat ini bisa menyelesaikan isu open source skala besar secara end-to-end seperti di SWE-bench Verified. Kedua, klaim bahwa “bahasa pemrograman adalah bahasa Inggris”. Kenyataannya, yang ada adalah kombinasi kode, test, spesifikasi, API, skema JSON, diff, alat IDE, dan lain-lain; bahasa Inggris hanya berperan sebagai perekat. Penulis memilih antarmuka yang paling lemah lalu menyerangnya. Ketiga, klaim bahwa nondeterminisme adalah masalah. Di dunia nyata, banyak hal seperti fuzzing dan SAT/SMT mengandung unsur probabilistik, tetapi determinisme dan ketepatan hasil akhirnya datang dari spesifikasi eksternal seperti test, type system, dan CI. Dan anggapan bahwa LLM populer karena bahasa atau library buruk adalah dikotomi palsu. Misalnya, sekalipun bahasa seperti Rust dan TypeScript makin baik, LLM tetap membantu untuk pencarian API, penelusuran repo, penulisan kode berulang, migrasi, pembuatan test, dan refactor. Terakhir, tulisan ini hanya menawarkan alternatif “buat bahasa atau compiler yang lebih baik”, padahal tim modern sudah mendapatkan nilai besar dari kombinasi dengan AI. Karena itu, jauh lebih realistis memakai AI coding dan LLM bukan sebagai “compiler bahasa Inggris ajaib yang dikendalikan prompt”, melainkan seperti “pair programmer junior” yang membantu berdasarkan kendala saya sendiri seperti type, test, CI, dan sebagainya

    • (Penulis asli) Saya setuju dengan pendapat ini. Kalau saya menulis posting blog seperti itu, mungkin tidak akan populer. Penjelasan bahwa “alat coding LLM adalah penyintesis program berbasis pencarian” menurut saya pada dasarnya sangat dekat dengan definisi compiler. Hanya saja, kebanyakan compiler tidak banyak melakukan pencarian dan lebih mengandalkan heuristik karena tidak terintegrasi dengan runtime. Bahwa “banyak alat engineering bersifat nondeterministik” itu benar, tetapi misalnya pada SAT solver, pengenalan unsur acak bisa mengubah waktu penyelesaian tanpa memengaruhi kebenaran jawabannya. Fuzzer digunakan untuk tujuan testing, jadi secara hakikat memang tidak diharapkan sempurna. Saya belum pernah melihat fuzzer dipakai di production. Saya juga sepenuhnya setuju dengan argumen bahwa “determinisme datang dari test atau spesifikasi eksternal”. Yang saya impikan adalah bahasa di mana yang dinyatakan sebagai spesifikasi hanya perilakunya, bukan cara implementasinya. Rasanya seperti generalisasi lebih luas dari konsep schedule di Halide. Komputerlah yang mencari sendiri cara implementasinya. Saya pikir AI bisa menyediakan alat seperti itu. Tidak harus LLM, tetapi spesifikasi yang ketat pasti diperlukan. Pada akhirnya itu sendiri adalah pemrograman. Dari sudut pandang ini, saya menolak melihat AI sebagai “compiler bahasa Inggris ajaib”. Jika dipakai sebagai alat bantu kerja sambil memahami kekuatan dan batasannya, ini benar-benar workflow yang bagus

    • Balasan yang luar biasa. Saya sepenuhnya setuju

    • Tidak mengherankan ada tulisan bermasalah seperti ini. Penulisnya George Hotz, alias Geohot

  • Saya sering memakai Openpilot dan claude code. Saya menempatkan keduanya hampir sejajar. Openpilot mengemudi dengan sangat baik selama berjam-jam di situasi sederhana seperti jalan tol. claude code bisa menangani refactor yang intuitif, boilerplate, scaffolding, git bisect, dan pekerjaan berulang lain tanpa banyak input dari saya. Keduanya tetap tidak menggantikan ‘pengemudi’. claude code itu seperti autonomous driving level 2 untuk pemrograman

  • Riset METR menjadi sangat populer karena judulnya. Mungkin tidak banyak yang benar-benar membacanya tuntas—karena memang cukup panjang. Tetapi di datanya, hanya satu orang dengan pengalaman paling tinggi menggunakan Cursor atau AI yang terlihat mengalami peningkatan kecepatan 50%. Ini mengisyaratkan bahwa hasilnya baru menonjol setelah terbiasa. Di sampel kecil, fluktuasi statistik juga besar. Belakangan, selisih kecepatan dari satu peserta lain dikoreksi karena sebelumnya tercatat keliru, tetapi itu justru makin menimbulkan pertanyaan tentang arti hasilnya. Faktor-faktor inefisiensi yang diukur dalam riset itu tampaknya cukup bisa diatasi dengan teknologi yang lebih maju seperti LLM yang lebih baik atau agen paralel. Saat penelitian dilakukan, yang dipakai masih era Claude 3.7 lama, sebelum Claude Code. Dan rasa subjektif seperti “terasa bekerja 20% lebih sedikit” juga cukup bernilai. Kalau bekerja sambil menikmati, waktu terasa cepat berlalu

  • Masalahnya adalah lab AI selama ini menjual AI dengan terlalu berlebihan. Slogannya sering seperti “AI benar-benar berpikir, bukan sekadar pattern matching”. Dari sudut pandang saya yang membuat dan memakai alat AI, justru lebih berguna memperlakukannya sebagai ‘prediktor token berikutnya’ berbasis pattern matching. Jika terlalu banyak informasi yang tidak perlu dimasukkan ke konteks, AI sering gagal melakukan generalisasi. Pada akhirnya ini memang pattern matching dan prediksi token berikutnya. Saya percaya bahwa “teknologi AI bisa berkontribusi pada alat yang sangat bagus saat ini”, tetapi itu adalah hasil dari eksplorasi/optimisasi skala besar dan daur ulang pola yang sudah ada. Misalnya, kalau saya menyuruh Claude code menulis CRUD API sederhana, dalam satu menit sudah jadi dan menghemat satu jam waktu saya. Kalau saya meminta algoritme yang sudah diimplementasikan ratusan ribu kali, AI langsung mengeluarkan kode yang tepat. AI bekerja sangat baik kalau dipakai di domain keahlian kita sendiri. Di luar itu, hasilnya kurang bagus

    • Ini soal perbedaan tingkat intelligence. Bukan soal pengetahuan, tetapi perbedaan kemampuan berpikir yang mendasar. Kita sering meremehkan upaya kognitif yang dibutuhkan untuk pekerjaan tertentu. Namun, kadang AI juga menunjukkan perilaku yang lebih ‘penuh pertimbangan’ dari perkiraan. Pada saat seperti itu, rasanya benar-benar seperti sihir

    • CRUD atau boilerplate sebenarnya sampai batas tertentu juga bisa diatasi dengan tooling. Tetapi banyak hal yang hanya bisa dilakukan dengan AI. Misalnya, ketika saya harus menguji dan menganalisis seluruh trace-level log, melihat ratusan baris dengan mata sendiri memakan waktu besar, tetapi kalau saya bilang ke AI “jalankan tes dan cari penyebabnya”, hasilnya cukup berguna. Sekarang ini hampir selalu jadi langkah pertama saya

  • Saya rasa ada sebagian kebenaran dalam pendapat Anda juga. Tetapi dunia bisnis punya hasrat yang sangat kuat untuk melakukan penataan ulang. Sangat banyak modal ingin imbal hasil tinggi dalam waktu singkat, dan fund manager bisa dipecat kalau tidak mengikuti tren. CIO dan CEO juga begitu. Perlombaan adopsi AI sudah seperti perlombaan senjata nuklir dan tidak bisa dihentikan lagi. Pada dasarnya ini bukan hal yang baik bagi siapa pun. Tetapi karena semua orang masuk, saya juga tidak bisa tidak ikut. Sebelum mobil ada, manusia juga sudah cukup bahagia. Tetapi ketika mobil datang, kota-kota ditata ulang, jarak antarbangunan makin jauh, dan komuter menjadi hal biasa. AI juga akan mengubah konteks kerja kita dengan cara yang sama. Kini ada ekspektasi bahwa semua orang harus memakai AI, dan pada suatu titik akan terasa seperti syarat dasar. Lebih jauh lagi, hampir tidak ada produk sains dan teknologi yang benar-benar menjadi “kebutuhan” manusia sejak awal. Teknologi menciptakan masalah lalu menjual dirinya sebagai solusi. Masalah itu awalnya tidak ada; baru setelah solusinya muncul, hal itu dianggap masalah. Itulah mesin penggerak utama bisnis

  • Banyak tulisan opini tentang AI coding tampaknya ditulis dari sudut pandang software engineer yang sangat berpengalaman, semacam sudut pandang ‘ivory tower’. (Penelitian yang dimaksud juga hanya meneliti “16 developer open source berpengalaman”.) Tetapi bagi nonprofesional, alat seperti ini sangat bernilai. Saya sendiri punya sedikit pengalaman coding, tetapi itu bukan pekerjaan utama saya—saya seniman visual. Pekerjaan yang dulu butuh beberapa hari, sekarang bisa selesai dalam satu sore. Dua bulan lalu saya berhenti kerja dan fokus mengembangkan game. Budget saya tidak longgar, tetapi saya tetap memastikan langganan Claude dan ChatGPT aktif. Dan rasanya benar-benar ajaib bisa menuliskan ide jam 1 pagi di tempat tidur, langsung melemparkannya ke Codex, lalu bangun pagi dan menjalankannya. Dulu saya sering ragu memulai karena khawatir “apa ini benar-benar cara terbaik?”, tetapi sekarang kekhawatiran itu hilang karena refactor menjadi mudah. Jadi bukan cuma membantu dalam menulis kode, tetapi juga menurunkan hambatan psikologis. Tentu saja, saya paham bahwa sebagian besar kritik sebenarnya ditujukan pada pemasaran berlebihan dari alat ini dan narasi “sekarang semua engineer akan dipecat”

  • Saya berusia 72 tahun dan sudah bekerja sebagai developer selama 40 tahun. Saya sudah tidak bisa fokus seintens dulu, tetapi berkat AI saya masih terus membuat sesuatu. Saya menyusun spesifikasi proyek, lalu agen menangani implementasi dan testing. Sekarang saya coding murni untuk kesenangan

    • Saya juga suka cara AI memungkinkan pembuatan prototipe cepat. Dulu saya ingin membuat browser extension, lalu dengan Claude saya bisa membuat versi sederhananya dalam 10 menit. Setelah itu saya rapikan sendiri UI-nya sedikit demi sedikit, dan menghabiskan pagi akhir pekan untuk menyelesaikan extension yang lebih ringan, lebih mudah diprediksi, dan lebih matang. Extension saya menampilkan daftar respons berulang dan memungkinkan saya menyalakan atau mematikan respons mana yang akan dikirim ke localhost API. Dari sana ada pemrosesan work queue, pembaruan sqlite db, analisis informasi utama dengan LM Studio GPT-OSS 20b, dan pada akhirnya ringkasan juga dikirim ke Telegram. Saat ide di kepala saya sudah jelas, sangat berguna bahwa tahap eksperimen atau PoC bisa dipangkas menjadi hitungan menit. Bagi developer yang cukup kompeten seperti saya, ini membuat saya bisa menyelesaikan lebih banyak hal sendirian daripada sebelumnya