Mengapa Menulis Kode pada 2026

• Peran software engineer telah meluas melampaui produksi kode menjadi membangun dan memelihara pabrik perangkat lunak, tetapi untuk memahami dan memperbaiki sistem, tetap perlu menangani kode secara langsung
• Jika agen dipandu dengan prompt, AGENTS.md, dan basis pengetahuan, lalu hasilnya dijaga dengan pengujian, linting, sistem tipe, dan evaluasi, maka model berperforma rendah pun bisa menghasilkan perubahan yang cukup berguna
• Dengan menulis kode sendiri, kita bisa berpikir di lingkungan eksekusi tanpa melalui bahasa Inggris, sehingga dapat merasakan kerentanan, pengujian yang lemah, dan pengecualian yang tidak perlu yang mudah terlewat bila hanya melakukan tinjauan kode pasif
• Agen lebih dekat ke intern baru daripada compiler, karena secara konservatif mengikuti kode yang ada dan kebutuhan yang tidak akurat, dan bahkan dapat memperbesar kesalahan sekali buat dari manusia menjadi wrapping dan lapisan tidak langsung
• Manusia perlu menguji pendekatan secara langsung, menetapkan pola, lalu membiarkan agen mengulanginya agar bisa mempertahankan rasa memiliki dan penilaian sambil memanfaatkan produktivitas otomatisasi

---

Pabrik perangkat lunak tempat agen bekerja

• Software engineer memelihara bukan hanya perangkat lunak, tetapi juga jalur perakitan yang memungkinkan siapa pun meminta perubahan lewat prompt dan langsung menerapkannya
  • Mereka menyiapkan lebih dulu infrastruktur yang memungkinkan agen berhasil melalui prompt, skill, AGENTS.md, dan basis pengetahuan
  • Mereka melindungi hasil setelahnya dengan pengujian, linting, sistem tipe, evaluasi, dan evaluasi otomatis menggunakan AI lain
• Jika diberi batasan yang memadai dan konteks terbaru, bahkan model dengan kecerdasan lebih rendah pun dapat menghasilkan perubahan yang berguna tanpa keluar jalur, sehingga bisa terlihat seolah manusia tidak perlu membaca atau menulis kode sendiri
• Namun, bahkan jika ada agen dengan tingkat kecerdasan setara Fable, menulis kode secara langsung tetap memungkinkan kita berpikir langsung di lingkungan eksekusi tanpa lapisan perantara berupa bahasa Inggris
• Hanya membaca diff dan patch buatan agen secara pasif membuat kita sulit terhubung secara mendalam dengan arsitektur sistem
  • Dengan menangani kode secara langsung, kita bisa merasakan apa yang akan rusak saat menambahkan fitur di atasnya
  • Jika kita merapikan kode dan mendokumentasikan prinsip arsitektur yang konsisten agar tidak ditempeli banyak pengecualian, pabrik perangkat lunak juga akan berjalan lebih stabil
  • Jika dalam proses debugging kita menemukan dan memperbaiki kelemahan strategi pengujian, kita dapat memblokir seluruh jenis bug baru
• Menulis kode sendiri bukan satu-satunya cara memahami perangkat lunak, dan juga tidak perlu memaksakan kerja manual ekstrem seperti jarum termagnetisasi dan tangan yang tak bergoyang
  • Bahkan jika sebagian besar kode nyata dihasilkan AI, menulis kode sendiri tetap menjadi alat yang berguna

Menjaga daya pikir dan rasa memiliki lewat menulis kode langsung

• Jika hanya bertahan pada peran reverse centaur yang sekadar membaca dan menyetujui kode, konsentrasi dan rasa memiliki akan menurun, kode berkualitas rendah akan lebih mudah lolos review, dan penyesuaian halus pun menjadi lebih sulit
  • Jika tidak memperhatikan detail, kerentanan akan menumpuk, dan dalam jangka panjang kode berkualitas rendah juga berdampak buruk pada agen
  • Jika manusia menguji pendekatan secara langsung lebih dulu lalu membiarkan agen mengulang pola yang sudah ditetapkan, mereka bisa tetap terlibat dan memiliki hasilnya
• Bahasa Inggris adalah bahasa yang kurang spesifik untuk menyatakan komputasi secara presisi
  • Dalam pekerjaan algoritmik, kita perlu membayangkan dan berpikir dalam langkah-langkah yang bisa dieksekusi
  • Bergantung pada situasi, kita dapat memilih bahasa tingkat rendah dengan ruang desain yang besar atau bahasa tingkat tinggi dengan lingkungan komputasi yang lebih terbatas untuk menyesuaikan presisi yang dibutuhkan
• Jika agen coding diperlakukan seperti compiler, hal itu bisa mengarah pada sikap bahwa kode yang ditulis secara buruk pun boleh diterapkan
  • Agen lebih dekat ke intern baru yang baru bergabung daripada compiler
  • Mereka membaca kode yang sudah ada, yang bisa saja tidak lengkap dan berkualitas rendah, lalu membuat perubahan baru berdasarkan penjelasan perubahan yang tidak akurat
  • Karena manusia tidak bisa begitu saja menyerahkan cara berpikir dan selera pada sekelompok intern, kita perlu tetap terlibat langsung dan tidak hanya menjadi konsumen
• Agen sulit secara sukarela mengikuti aturan pramuka untuk meninggalkan kode dalam keadaan lebih baik daripada saat ditemukan, dan membebankan hal itu kepada mereka juga terasa berat
  • Mereka cenderung berat sebelah ke arah membuat perubahan saat ini seaman mungkin, sehingga secara konservatif mempertahankan keputusan lama
  • Dalam satu codebase, ketika seorang manusia tanpa banyak pikir memakai browser local storage untuk sebagian state, sementara state lain disimpan di database backend, agen berusaha mempertahankan keputusan itu dengan menambahkan wrapping dan lapisan tidak langsung, sehingga jumlah baris kode meningkat sekitar 3 kali lipat
  • Konservatisme seperti ini dapat memperbesar keputusan keliru sekali buat yang diambil manusia
• Proses menghapus dan menjelajahi kode secara langsung membantu mencapai arsitektur yang lebih baik dibanding hanya memberi instruksi dalam bahasa Inggris
  • Semakin besar perhatian yang kita berikan pada kode, semakin kuat pula daya pikir, rasa sebagai penulis, dan kemampuan memimpin pabrik perangkat lunak
• Dalam pabrik perangkat lunak, detail itu penting, mulai dari pola arsitektur hingga algoritme dan performa
  • Agen telah meningkatkan kebutuhan akan evaluasi, pengukuran, dan mekanisme perlindungan, serta mendorong bahkan proyek pribadi untuk menambahkan CI sejak awal alih-alih sebagai pekerjaan susulan
  • Dengan demikian, keadaan pengembangan perangkat lunak telah banyak membaik, tetapi setiap jalur perakitan tetap menyisakan kelemahan
• Bahkan di pabrik mobil, ada saat-saat ketika kita perlu membongkar jalur perakitan, menggali detail mesin pembakaran internal untuk meningkatkan 10%, atau mengamati pengujian kampas rem seharian demi mencari tahu mengapa masalah di lapangan tidak terdeteksi lebih awal
  • Dalam perangkat lunak juga, untuk menghubungkan detail dengan struktur keseluruhan, kita tidak boleh menarik batas yang sewenang-wenang atas apa yang boleh ditangani secara langsung

[choijaekyu]

Karena tidak ada biaya token :(

[GN⁺]

Pendapat Hacker News

• Tampaknya jelas bahwa jika tidak bisa menulis kode, maka tidak bisa meninjaunya juga, tetapi ada orang dan perusahaan yang beranggapan Claude bisa menulis dan Codex bisa meninjau. Namun alasan mereka tetap meminta hasil dalam bahasa tingkat tinggi seperti Python dan Java, bukan assembly atau biner terkompilasi, pada akhirnya adalah karena manusia harus bisa membaca kode.
  Ada kontradiksi dalam sikap yang menginginkan developer membaca, men-debug, dan menalar kode, tetapi justru tidak mau memberikan latihan untuk membangun kemampuan itu.

  • Alasan tidak meminta Claude menulis assembly adalah karena hampir tidak ada materi pembelajaran tentang membuat aplikasi CRUD dengan assembly. Kita mungkin tidak suka LLM menggerus pekerjaan, tetapi kenyataannya model mutakhir memang pandai mengerjakan tugas yang telah diulang dan didokumentasikan berkali-kali di internet, dan benar juga bahwa selama beberapa dekade terakhir sebagian besar pengembangan software adalah produksi aplikasi CRUD yang terstandardisasi.
    Patut dipertanyakan apakah industri bisa terus maju jika semua kreasi diserahkan kepada LLM.
  • Tindakan menulis kode adalah tindakan berpikir, jadi jika berhenti menulis kode, berpikir pun ikut berhenti. Sekalipun berpikir pada tingkat yang lebih tinggi, LLM pada akhirnya akan menjadi lebih baik juga dalam desain tingkat tinggi itu, sehingga keunggulan saat ini hanya sementara.
  • Pada akhirnya ini tampak seperti perbedaan cara kognitif. Bagi sebagian orang, kode lebih akurat dan lebih mudah dibaca daripada penjelasan bahasa Inggris, sehingga developer berpengalaman bisa memahami cara kerjanya hanya dengan membaca sekilas; sementara bagi yang lain, kode sulit dibaca dan bahasa alami terasa lebih nyaman.
    Ini bukan berarti salah satunya lebih baik; orang yang tidak terlalu mementingkan detail bisa saja memimpin dunia, dan tingkat ketelitian yang dibutuhkan bisa berbeda untuk setiap masalah.
  • Sepertinya Casey Muratori dan Demetri Spanos pernah membahasnya dalam video; alasan menghindari biner lebih dekat dengan bahasa mesin dan offset yang berbeda-beda antar-mesin serta sulitnya menafsirkan konteks, bukan semata soal kepercayaan pada LLM. Seperti perbedaan tingkat pemahaman antara kode C hasil dekompilasi Ghidra dan source C yang ditulis developer, bahasa tingkat tinggi bisa memuat maksud dari kode.
    Compiler membantu LLM menulis kode yang benar-benar bisa dikompilasi dan dijalankan, tetapi jika langsung mengeluarkan bahasa mesin, besar kemungkinan hasilnya sama sekali tidak berjalan. Tentu saja, jika seseorang sama sekali tidak bisa menulis kode, meninjaunya akan jauh lebih sulit.
  • Ada juga orang yang sungguh-sungguh berpendapat bahwa Claude seharusnya langsung mengeluarkan assembly atau biner. Namun kemungkinan besar portabilitasnya lebih rendah daripada bahasa tingkat tinggi yang bisa dikompilasi menjadi assembly untuk berbagai mesin.

• “Apa sebutan industri untuk spesifikasi proyek yang cukup komprehensif dan akurat untuk menghasilkan sebuah program? Disebut kode” — CommitStrip
  Jika ditulis dengan benar, inti kode seharusnya menjadi representasi paling sederhana dari business logic yang mendasarinya. Mungkin tidak perlu meninjau seluruh lapisan pendukung, tetapi jika belum membaca kodenya, sulit mengatakan bahwa kita benar-benar memahami business logic-nya.

  • Tautan asli
  • Dalam tulisan lain tentang topik ini, juga disarankan menggunakan kode daripada spesifikasi. Tidak masalah memberi instruksi kepada agent dalam bentuk kode atau membuat contoh yang harus diikuti.
    https://softwaredoug.com/blog/2026/07/04/write-code-not-specs
  • Inilah sebabnya Lisp dibutuhkan. Pertama, buat bahasa pemrograman yang menjadikan elemen dasar business logic sebagai elemen dasar bahasa, lalu tulis program sederhana dalam bahasa baru itu untuk mendeskripsikan apa yang dilakukan bisnis.

• Pertanyaan pentingnya adalah siapa yang akan membayar penulisan kode manual. Pelanggan membayar untuk pemecahan masalah, bukan untuk penulisan atau pembuatan kode itu sendiri, jadi pihak yang menyelesaikannya dengan biaya dan keributan paling sedikit akan mendapatkan bisnis; manfaat tool AI dalam memampatkan jadwal sulit diabaikan.
  Saya sudah berada di industri ini sejak 1990-an, dan pekerjaan developer yang tidak hebat menghasilkan output biasa-biasa saja selalu banyak. Kita terlalu meromantisasi kode buatan tangan, padahal codebase nyata sering makin sulit dirawat seiring waktu dan mudah penuh bug; proyek yang dikerjakan asal-asalan juga sama sekali bukan fenomena baru.

  • Justru saya melihat menulis kode dalam jumlah kecil secara langsung lebih meningkatkan produktivitas. Menghabiskan satu hari untuk menyusun ulang arsitektur secara manual bisa menghemat ribuan dolar biaya token dan beberapa minggu sakit kepala.
    Saat ini rasanya seperti mencoba membangun pabrik software dengan kedua tangan terikat.
  • Developer biasa-biasa saja kini memproduksi hasil biasa-biasa saja 10 kali lebih banyak.
  • Di industri yang kualitas softwarenya penting dan teregulasi seperti medis, penerbangan, dan nuklir, saya berharap mereka tetap membayar untuk penulisan kode manual. Namun pasar ini relatif kecil.

• Untuk bisa fokus dan memahami, tidak cukup hanya mengawasi agent dari jauh dan membaca kode secara pasif; kita harus mengalami kode secara langsung. Pada akhirnya itu berarti harus melatih model mental sendiri.
  Saat coding, alam bawah sadar membuat banyak penilaian seperti “ini terasa benar”, dan kemampuan itu hanya terbentuk lewat pengulangan dan konsentrasi mendalam; code review atau membaca dokumentasi saja ada batasnya. Dengan model mental yang terbentuk seperti ini, seseorang bisa langsung menunjukkan penyebab hanya dari pesan error saat insiden operasional, tetapi pada kode yang dihasilkan, ia harus mencarinya lama dengan pemikiran sadar yang lambat.
  Agar LLM benar-benar berguna, kita harus bisa mengasumsikan bahwa ia menangani seluruh pemeliharaan kode dan berfungsi seperti library eksternal; jika tidak, masalah akan terus muncul.

  • Pada manusia pun pemisahan seperti ini sudah pernah dicoba, dan hasilnya begitu buruk sampai muncul julukan merendahkan arsitek menara gading. Dalam sistem nyata, muncul desain teoretis yang tidak bisa diimplementasikan, tim implementasi atau LLM mengakali arsitektur, dan kecepatan pengembangan melambat drastis sementara arsitek dan implementor terlibat perdebatan yang tidak nyambung.
  • Di bidang observability, jika sulit menemukan penyebab hanya dari perilaku eksekusi dinamis, kesimpulannya adalah sistem harus dibuat lebih transparan dan observable. Prinsip bahwa kita tidak boleh bergantung pada model mental individu hebat karena orang bisa pindah atau pergi sebenarnya sudah valid sejak awal.
    Saya belum tahu pihak mana yang benar dan masih mencari tahu lebih jauh.

• Bahkan pada 2026, kode yang dihasilkan AI masih buruk. Baik Fable maupun harness LeetCode Pi/opencode kustom, hasilnya mengerikan; jika Anda tidak bisa membedakan kualitas kode sendiri dan kode AI, ada kabar buruk.

  • Kode saya dulu atau bahkan sekarang mungkin lebih buruk daripada AI, tetapi setidaknya saya dibayar, jadi kabar buruk itu tidak terlalu penting.

• Saya sudah menetapkan dalam aturan bahwa agent harus menjalankan profil agar mengikuti aturan boy scout, memeriksa code coverage, melakukan tinjauan kritis, serta menulis laporan dan tindak lanjut. LLM mutakhir saat ini jauh lebih baik mengikuti aturan seperti ini dibanding 90% orang yang pernah bekerja dengan saya, dan saya bertanya-tanya apakah itu berarti buruk

  • Agent saat ini cenderung membuat perubahan seaman mungkin. Pernah, sebelum sempat minum kopi, saya tanpa pikir panjang menyuruhnya memakai local storage browser, padahal semua state lainnya ada di database backend; tetapi ia berusaha mempertahankan keputusan keliru itu dengan menambahkan wrapping dan lapisan indireksi, sehingga jumlah baris kode hampir menjadi tiga kali lipat
    Agent bersifat konservatif sehingga bisa memperbesar kesalahan sekali jalan yang dibuat manusia. Ada banyak cara untuk mengatasinya dan cara berpikir tiap orang berbeda, jadi pendekatan yang tidak membaca kode maupun yang membaca dan menulisnya langsung sama-sama mungkin, tetapi manfaat dari presisi kode yang tidak melalui LLM juga besar

• Alasan saya harus menulis kode sendiri adalah, kalau tidak, LLM akan membuat terlalu banyak kode. Kita harus benar-benar memahami dan menggeneralisasi masalah agar “Hello World” tidak berakhir dengan 10 ribu baris dan 5 lapisan abstraksi
  Karena LLM adalah prediktor token, semakin banyak masalah yang harus diselesaikan, semakin besar kecenderungannya menghasilkan token kode

  • LLM lebih suka membungkus kode secara defensif daripada memikirkan keseluruhan secara terpadu, sehingga mudah membengkak. Sebaliknya, developer manusia bisa mengikuti aturan boy scout dengan merapikan kode di sekitarnya sambil bekerja
  • Peter Naur sudah menjelaskan puluhan tahun lalu bahwa pemrograman bukanlah pekerjaan memproduksi source code, spesifikasi, dan dokumentasi secara mekanis, melainkan aktivitas manusia untuk membangun teori mental yang mendalam tentang bagaimana tiap bagian sistem berkaitan dengan masalah dunia nyata. Hasil nyata pemrograman adalah model mental yang dibagikan para developer
    Pihak yang memiliki masalah untuk diselesaikan adalah manusia, jadi jika masalahnya tidak dipahami, LLM bisa menimbulkan masalah X/Y dengan menyelesaikan masalah yang tidak berkaitan dengan kebutuhan sebenarnya. LLM lebih baik mengabstraksikan unsur non-inti seperti library atau bahasa tingkat tinggi, tetapi inti masalah tetap harus diekspresikan secara formal
    Vibe coding yang menambahkan batasan satu per satu sampai mencapai hasil yang diinginkan pun pada akhirnya adalah pemrograman yang longgar dan tidak formal. Lebih baik menyerahkan bagian pinggiran masalah kepada LLM, sementara inti ditulis dan dipahami sendiri
  • 99% pekerjaan saya adalah C#, tetapi berkat LLM saya bisa menyebut diri sebagai programmer low-level yang selama ini saya dambakan tanpa melakukan apa pun
  • Saat saya memintanya menyiapkan proyek yang akan dijalankan di K8s mirip modul lain di perusahaan, LLM bahkan menulis unit test untuk implementasi Hello World
  • Saya memberi model AS terbaru tugas sepele untuk menampilkan informasi sisi klien, lalu ia memodifikasi kode di kedua sisi agar server mengirim informasi ke klien saat handshake awal, dan itu benar-benar berfungsi. Tetapi informasi itu sudah ada di klien, jadi sebenarnya itu pekerjaan yang cukup mengubah satu baris kode klien
    Dari luar, permintaan itu tampak diselesaikan dengan sempurna, tetapi kodenya tidak perlu dan asal-asalan. Perusahaan yang menjual token berbasis pemakaian punya insentif ekonomi untuk membuat solusi ala Rube Goldberg yang memecahkan masalah secara kasar sambil menghabiskan token sebanyak mungkin; bukan hanya saat menghasilkan kode, tetapi juga nanti saat menangani kode raksasa yang bercampur bug baru, token akan makin banyak dipakai
    Lucu melihat orang-orang yang dulu mengejek kode copy-paste kini begitu antusias pada kode yang ditempel secara asal

• Melihat perkembangan sejak ChatGPT 3.5 pada November 2022 hingga sekarang, saya bertanya-tanya apakah empat tahun lagi kita masih akan meninjau kode. Bahkan tanpa menjadi ekstremis AI, jika laju saat ini bertahan, besar kemungkinan software engineering dan development dalam bentuknya sekarang akan hilang dalam 5–10 tahun
  Bagi manusia mungkin hanya tersisa desain UI, sementara sisanya diabstraksikan dan AI menangani pekerjaan nyata

  • Jika ada mesin yang mewujudkan permintaan dalam sekali ucap, satu permintaan mudah ditangani, tetapi software adalah akumulasi ribuan permintaan, dan di setiap sudut harus dibuat keputusan halus tentang menginginkan ini dan tidak menginginkan itu. Dengan pendekatan LLM saat ini, semua keputusan ini masih harus dikelola manusia, tetapi di masa depan mungkin akan muncul cara yang kini belum bisa kita bayangkan
  • Diasumsikan bahwa kemajuan akan terus berlanjut dengan laju yang sama, tetapi tampaknya kita sudah memasuki semacam fase stagnasi. Setiap kali model membesar, biayanya naik secara eksponensial, dan menurut saya sudah cukup terlihat bahwa bisnis melatih model yang terus lebih besar tidak menguntungkan
  • Saya sudah tidak suka membayangkan masa depan ketika kita bahkan tidak bisa langsung menyalahkan manusia tidak kompeten yang membuat website yang membutuhkan JavaScript untuk setiap tindakan dan bahkan tidak bisa menangani pengetikan di kolom input dengan benar. Jika karena eksekutif yang lebih mementingkan tampilan daripada fungsi, serta data latih yang dipenuhi situs seperti itu, LLM memproduksi sampah yang sama dalam skala jauh lebih besar, rasanya akan muncul krisis eksistensial
    Web sudah cukup berantakan, jadi setidaknya untuk keadaan sekarang, izinkan kami tetap bisa menyalahkan manusia tidak kompeten

• Terlepas dari tekanan KPI, saya menulis kode sendiri setiap ada kesempatan, dan dari AI saya hanya mengharapkan semacam autocomplete kode yang lebih pintar

• Saya menulis kode sendiri karena saya mencintai coding dan itu benar-benar membuat saya bahagia. Tidak ada alasan untuk menyerah pada hal yang saya sukai

  • Ada daya tarik seperti sihir saat memerintahkan komputer melakukan pekerjaan dan melihatnya memproses puluhan miliar kali lebih cepat daripada cara lain mana pun
  • Saya masuk ke bidang ini karena senang merancang program dan menulis kode. Saya tertinggal dalam pemanfaatan AI dan perlu lebih mempelajarinya, tetapi saya tidak akan pernah ingin berhenti coding dengan tangan sendiri
  • Jika kebahagiaan itu berasal dari coding sambil tetap dibayar, perusahaan bisa saja menghentikan imbalan tersebut. Jika bergantung pada penghasilan itu untuk mempertahankan visa, sangat besar kemungkinan seseorang akan dipaksa beradaptasi dengan perubahan dan menyerah pada coding