AI menuntut lebih banyak, bukan lebih sedikit, disiplin rekayasa
(charitydotwtf.substack.com)- Meningkatnya kualitas pembuatan kode oleh AI bukanlah sinyal untuk membuang code review, melainkan menuntut validasi dan disiplin operasional yang lebih kuat dalam lingkungan di mana kode bisa diregenerasi dengan murah dan cepat
- Setelah Opus 4.5 pada akhir 2025, AI menjadi mampu menghasilkan kode yang mendekati kualitas software engineer tingkat menengah untuk pola-pola umum dengan lebih cepat dan murah, dan transisi ini ditopang oleh agentic harness, penggunaan alat, function calling, dan MCP
- Ketika biaya produksi kode mendekati nol, baris kode tidak lagi menjadi aset berharga yang harus dipertahankan, melainkan lebih mirip cache yang bisa diregenerasi yang mematerialkan pemahaman saat ini
- Seperti immutable infrastructure yang membuat server yang sedang berjalan diganti alih-alih diperbaiki, kode aplikasi di era AI juga membuat validasi perilaku, characterization test, capture/replay, pemisahan trafik, dan observabilitas menjadi lebih penting daripada perubahan itu sendiri
- Sistem nondeterministik menuntut disiplin rekayasa seperti trace, eval produksi, dan loop umpan balik cepat, alih-alih bertahan dengan manusia sebagai quality gate, dan AI tidak menghapus fakta bahwa software tetap membutuhkan teknolog dan disiplin
Ekonomi produksi kode yang berbalik pada 2025
- Selama sebagian besar 2025, pandangan bahwa kode buatan AI adalah “slop” dan mungkin akan tetap begitu adalah penilaian yang masuk akal dan arus utama
- Setelah Opus 4.5 pada November 2025, AI setidaknya untuk pola-pola umum menjadi mampu menghasilkan kode dengan kualitas setara software engineer tingkat menengah dengan jauh lebih cepat dan murah
- Opus 4.5 lebih dekat ke sebuah tipping point daripada penyebab tunggal
- agentic harness adalah struktur kode yang menempatkan LLM di dalam loop bersama alat
- Harness semacam ini menjadi realistis pada pertengahan 2025, dengan tanda-tandanya sudah terlihat sejak akhir 2024
- tool use, function calling, dan MCP terakumulasi sepanjang 2025 lalu berujung pada kegunaan umum di akhir tahun
- Pada perubahan pertama, skeptisisme “saya percaya kalau sudah melihatnya” masih bisa diterima, tetapi ketika perubahan dengan kecepatan yang sama muncul lagi, sulit mempertahankan sikap yang sama
Kode berubah dari aset berharga menjadi keluaran yang bisa diregenerasi
- Perubahan inti yang terjadi pada 2025 adalah ekonomi produksi kode berbalik
- Dari kondisi di mana menghasilkan kode itu sulit, lama, dan mahal, menjadi kondisi yang pada praktiknya instan dan murah
- Baris kode bergeser dari sesuatu yang dipakai ulang dan dipelihara menjadi sesuatu yang bisa dibuang dan dibuat lagi
- Ada juga sudut pandang yang melihat keluaran nyata tim software engineering sebagai pemahaman bersama
- Pemahaman itu disimpan seperti cache di kepala orang-orang, lalu dituliskan ke disk melalui commit GitHub dan deployment produksi
- Namun ingatan manusia mudah lupa, menjadi tumpul terhadap pengulangan, dan mudah melewatkan detail kecil
- Model mental di kepala terus menyimpang dari dunia yang benar-benar ditemui pengguna
- Dari sudut pandang SRE, keluaran nyata tim software yang baik ada di produksi
- “Only prod is prod”
- Produksi seharusnya diperlakukan bukan sebagai tempat setelah development, tetapi sebagai salah satu tahap development
Kemiripan antara Phoenix Architecture dan immutable infrastructure
- Honeycomb mengeluarkan AI mandate pada Agustus 2025 dan menilai bahwa sebagai perusahaan devtools, mereka harus menangani masalah sulit dari teknologi terbaru
- Phoenix Architectures karya Chad Fowler menghubungkan era kode AI dengan immutable infrastructure
- Chad Fowler adalah orang yang mencetuskan istilah “immutable infrastructure” pada 2013
- Relocating Rigor adalah tulisan yang disebut Martin Fowler dalam ringkasan meetup Thoughtworks
- Inti dari The Death and Rebirth of Programming adalah prinsip untuk tidak memperbaiki sesuatu yang sedang berjalan, tetapi menggantinya
- immutable infrastructure, stateless services, containers, blue-green deployments, dan infrastructure as code semuanya berbagi asumsi yang sama
- AI memperluas asumsi ini dari infrastruktur ke kode aplikasi
- Ketika biaya menulis ulang turun, perbaikan di tempat menjadi lebih berisiko, mutation menumpuk entropi, dan replacement meresetnya
- The Deletion Test mengajak kita membayangkan menghapus seluruh implementasi
- Alasan penghapusan terasa menakutkan bukan karena kode itu sendiri, melainkan karena kita tidak tahu perilaku apa yang dibutuhkan, kegagalan apa yang tidak bisa diterima, invariants apa yang harus selalu dijaga, dan dengan standar apa akurasi versi baru dinilai
- Tidak tahu bug mana yang memperbaiki edge case yang sudah terlupakan juga merupakan masalah yang sama
- Ini bukan masalah kode, melainkan masalah evaluasi
- Ketika kode adalah satu-satunya tempat pengetahuan tinggal, kode menjadi berharga
- Di masa lalu, karena tenaga untuk membuat kode adalah bottleneck, masuk akal memperlakukan kode seperti aset yang persisten
- Ketika regenerasi menjadi mudah, kode berfungsi lebih seperti view pemahaman yang terwujud yang berguna saat ini tetapi bisa dibuang ketika usang
Kode harus bisa diregenerasi seperti server diregenerasi
- Pengalaman berpindah dari server pets buatan tangan ke cattle immutable infrastructure meninggalkan pelajaran bahwa mutability adalah musuh pemahaman
- Ketika keluaran yang sedang berjalan diperbaiki di tempat, drift akan muncul
- Drift membuat pemeliharaan sistem menjadi lebih sulit
- Honeycomb setiap hari Selasa menjalankan cron untuk mematikan node Kafka yang paling tua
- Cara ini memberi keyakinan bahwa proses bootstrapping dan balancing mereka bisa diulang
- Data bisa diregenerasi, dan janji yang penting berada di tempat lain
- Jika kode tidak bisa diregenerasi dengan cara yang sama, itu adalah sinyal bahwa kode tersebut belum cukup dipahami
- Tidak tahu janji apa yang telah dibuat
- Tidak tahu dependensi apa yang akan rusak
- Sebagian besar baru ditemukan dengan cara sengaja merusaknya
- Migration, rewrite, penggantian legacy code, dan strangler fig yang memakan waktu lama dan menyakitkan adalah contoh ketika terlalu banyak tanggung jawab dibebankan pada baris kode
- Di dalam kode terikat bersama niat developer, ekspektasi pengguna, perilaku implisit dan eksplisit, serta jejak bug masa lalu
Yang perlu direview bukan hanya baris kode
- Karena biaya memelihara dan mengubah baris kode tinggi, keluaran lain tidak berkembang cukup jauh
- Kurang ada artefak untuk memahami dan mendiskusikan bagaimana arsitektur berubah
- Arsitektur itu sendiri pun sering hanya bisa diinferensikan samar-samar dari kode
- Arah yang ideal lebih dekat ke mendiskusikan dan menyepakati diagram arsitektur, lalu meregenerasi kode dari perubahan tersebut
- Tidak bisa dipastikan bahwa semua kode akan dihasilkan AI berdasarkan spesifikasi sambil melewati pemahaman manusia
- Cakupan kemungkinannya bergantung pada apa itu spec, atau apa yang dapat menjadi spec
- Siapa pun yang pernah mengalami migration database yang menyakitkan seharusnya tahu bahwa mengekstrak dan memformalkan ekspektasi pengguna ke bentuk yang bisa diputar ulang dan diotomatisasi itu sulit
- Alatnya belum ada, tetapi ide-ide yang terkait sudah ada
- behavioral test, characterization test, capture/replay, dan traffic splitter dari operasi dan QA termasuk di sini
- Teknik-teknik ini lebih dekat ke mengamati dan mengodekan apa yang benar-benar terjadi, ketimbang menentukan apa yang seharusnya benar
- Observability dalam arti yang baik juga termasuk di sini
Manusia tidak cocok sebagai quality gate untuk validasi
- Kode nondeterministik di produksi memaksa kita melakukan hal-hal yang seharusnya sudah dilakukan sejak dulu
- instrumentasi trace
- test dan eval di produksi
- memperlakukan produksi bukan sebagai sesuatu setelah development, tetapi sebagai tahap development
- Otak manusia tidak cocok untuk validasi
- Manusia lebih lemah daripada mesin dalam terus-menerus memeriksa perbedaan kecil yang repetitif dan sepele
- Jika peran manusia dibatasi pada kemampuan sebagai quality gate, kualitas software menjadi rapuh
- Manusia mungkin masih akan lama berperan dalam kreativitas, inspirasi, lompatan logis, dan hal serupa, tetapi sulit menjadikan manusia pihak yang mengalahkan mesin dalam validasi
Kesimpulan era AI adalah kembalinya disiplin
- Alasan wacana AI dua tahun terakhir terasa asing dan menakutkan bagi banyak engineer adalah karena sebagian suara AI tampak mengatakan bahwa software bukan lagi persoalan engineering
- “SaaS is dead”
- “Making AI great at coding was the strategy that unlocks everything else”
- Adam Jacob diperlakukan sebagai sosok yang memperkirakan perubahan besar pada pekerjaan software
- Jika 2025 adalah tahun vibe coding, maka 2026 tampak seperti kembalinya disiplin
- Ketika AI menghasilkan baris kode setara software engineer tingkat menengah, rentang masa depan yang mungkin menjadi melebar secara tidak stabil
- Pengetahuan di kepala tidak bisa digunakan AI sampai pengetahuan itu dikodekan ke dalam sistem
- Sangat sedikit tim software yang bekerja dengan loop umpan balik yang cepat dan pendek
- Proporsinya disebut sekitar 5%, dan jelas di bawah 10%
- Alat AI bisa membawa cara kerja ini lebih dekat daripada sebelumnya
- Situasi di mana AI saja menghasilkan ROI besar tanpa disiplin engineering bukan hal yang perlu dikhawatirkan dalam waktu dekat
- Banyak tim akan mencobanya, tetapi hal yang bernilai didukung bukan oleh disposability melainkan oleh durability
- Pengguna tidak ingin tombol dan menu di Slack berubah-ubah secara halus setiap kali login setiap hari
- Mereka juga tidak ingin transaksi keuangan hanya selesai pada sebagian besar kasus
- determinism tidak akan hilang
- AI bukan sihir, dan software tetaplah engineering
- Teknologi membutuhkan technologist
- Ke depan, artefak yang perlu ditinjau akan meluas bukan hanya baris kode, tetapi juga jenis artefak engineering lainnya
1 komentar
Pendapat Hacker News
Sekarang jauh lebih sulit membedakan siapa yang benar-benar memahami sistem dan menggunakan AI secara efektif, dan siapa yang tidak paham apa-apa lalu hanya menebar hasil copy-paste dari LLM
Sebelum 2025, orang yang berkinerja rendah atau sekadar bertahan biasanya relatif terlihat karena kontribusinya kecil, tetapi sekarang semua engineer membanjiri PR, code review, dokumen desain teknis, dan sebagainya dengan format yang tampak meyakinkan
Dampaknya juga besar karena level C sangat menekan agar AI dipakai semaksimal mungkin, dan dari sudut pandang tiap engineer, menghasilkan sebanyak mungkin juga merupakan respons teori permainan yang menguntungkan
Kita sedang tenggelam total dalam dokumen dan kode yang tampak meyakinkan, lalu kembali bergantung pada AI untuk memproses volumenya
Efek balik dari masa ini tampaknya akan menjadi bentuk utang teknis yang aneh dan sangat menonjol dari sisi skala
LLM suka menghasilkan banyak hal dan menambahkan sesuatu, tetapi engineer yang benar-benar kompeten menghasilkan lebih banyak hasil bisnis dengan kode yang lebih sedikit dan lebih sedikit komponen bergerak
Aku sering mendengar, “Kami ingin memakai AI untuk mengotomatisasi proses, tetapi dokumentasi prosesnya tidak lengkap, jadi kami berharap AI bisa membantu”
Walau sudah dijelaskan bahwa hasil tidak bisa muncul dari ketiadaan, semua diskusi soal AI akhirnya kembali ke arah yang sama
Solusinya bahkan jadi memakai AI untuk membuat dokumen yang akan dimasukkan ke otomatisasi AI itu, jadi rasanya seperti ouroboros: AI membuat dokumen, AI merangkumnya untuk dimasukkan, lalu AI menjelaskannya
Hal yang sama akan terjadi pada kode: AI membuat ribuan baris, lalu AI juga yang menjelaskannya
Sekarang, berkat LLM, terlihat rajin hanya dari jumlah output menjadi terlalu mudah
Bedanya sekarang adalah orang yang tidak kompeten secara harfiah bisa menghasilkan output beberapa orde magnitudo lebih banyak daripada engineer yang hati-hati dan berpengalaman
PR memang bukan gerbang yang sempurna, tetapi itu salah satu dari sedikit gerbang yang kita punya sekarang, dan cukup jelas siapa yang benar-benar berusaha dan siapa yang tidak
Bukankah pertanyaan algoritma di tahap wawancara pasti sudah menyaring habis orang-orang yang pura-pura punya pengetahuan sistem?
Aku setuju dengan pernyataan “itu bukan masalah kode, melainkan masalah evaluasi” dan “kode menjadi berharga ketika pengetahuan hanya hidup di dalam kode”
Membaca kode yang ditulis AI sepanjang hari itu menyakitkan, dan merupakan cara menguras otak yang mengerikan tepat pada saat manusia seharusnya paling kompeten
Dalam pemrograman manual ada loop umpan balik yang produktif dan memuaskan: membaca kode, menulisnya, lalu memperbaikinya sampai bisa dikompilasi, dijalankan, atau berperilaku seperti yang diinginkan
Kode AI bukan cuma mengambil alih setengah dari proses itu, tetapi juga membuat momen “klik” di akhirnya terasa kurang memuaskan. Karena kita tidak pernah benar-benar yakin apakah kita tidak sedikit curang di suatu titik demi sampai ke momen itu
Menjadikan kode hasil AI sebagai satu-satunya keluaran permanen dari pemrograman adalah jalan buntu bagi industri
Hal yang Charity tunjuk sebagai ruang kerja yang menarik, dan yang benar untuk dibuang, adalah diagram arsitektur dan spesifikasi
Dugaan saya adalah sesuatu yang lebih dekat dengan prompt, rencana Markdown, dan prompt pengarah yang memang ditulis manusia sendiri
Kita harus berfokus pada apa yang benar-benar dibuat langsung oleh manusia, karena itulah fondasi dari loop inti “apakah AI mengikuti instruksiku”, dan itu juga memberi leverage lebih tinggi dalam code review
Pada saat mencapai PR, mestinya kita sudah cukup memberi masukan ke Claude sehingga kodenya bisa dihasilkan ulang, tetapi default industri saat ini adalah membuang seluruh sesi itu dan hanya menerapkan kodenya. Ini terbalik
Gumpalan kode besar pada dasarnya tidak bisa direview manusia, tetapi ketika LLM terlibat, banyak orang tampaknya lupa fakta itu
Setiap hari datang tumpukan kode besar untuk direview, dan itu benar-benar melelahkan
Meski begitu, AI terasa lebih baik karena jika aturan ditulis jelas, setidaknya AI cenderung mengikutinya
Banyak developer offshore mengulangi kesalahan yang sama setiap hari
Mungkin perusahaan kami memang perlu merekrut developer offshore yang lebih baik
Dulu sebagian dari model mental tentang sistem dibangun lewat proses coding, tetapi sekarang itu semakin dibentuk dengan bergantung pada code review
Menjadi lebih sulit memahami dan mengingat detail sistem, dan itu tidak mengejutkan jika mengingat bahwa informasi yang “dihasilkan” sendiri biasanya lebih mudah diingat daripada informasi yang hanya dibaca
Aku sedang menerapkan pelajaran dari pedagogi ke perluasan code review, dan kalau ini terasa nyambung, aku ingin membicarakannya
Sebagai solusi sementara, mungkin kita bisa meminta Claude menulis ringkasan sesi sebagai bagian dari commit message, tetapi aku ingin tahu apakah ada alat yang lebih terstruktur dan tingkat tinggi
Jika yang diinginkan adalah kode yang bisa diverifikasi dan sesuai dengan rencana yang dirancang baik, pada praktiknya kita harus menulis pseudocode lalu membiarkan AI menerjemahkannya
Kalau begitu, muncul pertanyaan kenapa sejak awal kita membiarkan AI menulis kodenya
Secara pribadi, aku lebih menikmati merencanakan, menulis, dan debugging sendiri. Itulah bagian yang sejak awal membuatku menyukai pemrograman
Akhir-akhir ini saya sangat sering memikirkan hal ini
Sebagian besar intuisi saya tentang pengembangan perangkat lunak dibangun dari pengalaman selama 25 tahun tentang “berapa lama waktu yang dibutuhkan untuk menulis kode tertentu”
Saat mempertimbangkan apakah perlu menambahkan validasi edge case yang tidak akan merusak keseluruhan, tetapi akan menjadi sedikit berantakan jika seseorang menginjaknya, saya mungkin akan melewatkannya jika itu berarti tambahan beberapa jam penulisan kode
Tapi kalau cukup dengan satu prompt, kenapa tidak?
Agar fitur baru lebih mudah dipahami, akan bagus jika ada API explorer khusus, tetapi dulu investasi seperti itu mungkin tidak bisa dibenarkan
Namun kalau dengan Codex hanya butuh 10 menit, ceritanya jadi berbeda, dan memang begitu: https://tools.simonwillison.net/datasette-extras-explorer#ur... juga ditautkan di catatan rilis https://docs.datasette.io/en/latest/changelog.html#extra-sup...
Dalam skala yang lebih besar, ada juga proyek yang dulu sama sekali tidak akan saya pertimbangkan. Saya memang membutuhkan library parser kueri
SELECTSQLite kustom, tetapi tidak sampai layak menghabiskan lebih dari semingguTapi sekarang itu jadi mungkin: https://github.com/simonw/sqlite-ast
Mengatakan bahwa kemampuan menghasilkan baris kode lebih cepat itu bernilai sering membuat orang sangat marah dan meremehkannya
Tentu saja, mengukur output dengan “jumlah baris kode” itu bodoh
Tetapi mengukur jumlah baris kode terverifikasi yang benar-benar memberikan nilai itu tidak bodoh, dan sekarang kita bisa melakukannya lebih cepat
Alasan Google bernilai adalah karena ia menyedot data dan mengubahnya menjadi pendapatan iklan, sementara pengeluarannya kecil dibanding pendapatannya
Semua “taruhan” itu? Lucu juga, memangnya bagaimana hasilnya?
Rekayasa demi rekayasa tidak punya nilai bagi ekonomi, artinya tidak bermakna
Kebenaran pahit yang tidak ingin didengar siapa pun adalah bahwa yang bisa ada dalam ekonomi pada titik waktu tertentu itu terbatas, dan hanya yang bernilai serta berkelanjutan secara ekonomi yang akan bertahan
Banyak yang tidak peduli, tetapi ada juga yang peduli
Saya menyukai tulisan ini, dan karena banyak komentar lain tampaknya tidak demikian, saya menuliskan pendapat saya.
Saat mulai masuk ke codebase baru, bagaimana cara menjadi kontributor yang berguna secepat mungkin? Saya langsung menuju dokumentasi yang ditulis manusia.
Saya mencari tahu masalah apa yang awalnya ingin diselesaikan sistem ini, seperti apa desain awalnya, apa masalah terbesarnya, dan siapa yang memakainya sekarang.
Dengan mengetahui itu, saya bisa menebak mengapa sistem ini dibuat dengan cara seperti itu, sehingga membaca kode menjadi jauh lebih mudah.
Tulisan blog ini juga populer: https://blog.gpkb.org/posts/just-send-me-the-prompt/
Charity tampaknya melihat masalah yang sangat lama lalu berharap teknologi baru akan menghasilkan solusi baru.
Saya rasa dia juga tidak menganggap alat generasi saat ini sebagai akhir dari kisah pengembangan perangkat lunak AI.
Ini juga bukan berarti cukup lempar dokumen desain ke Claude code lalu pergi. Dokumen desain juga tidak lengkap, jadi saat onboarding kita tetap perlu bicara dengan orang lain dan membaca tiket lama serta postmortem.
Di production, kita melakukan infrastructure as code sekarang karena kita tidak suka sulitnya mengetahui mengapa infrastruktur sampai berada pada keadaan saat ini.
Codebase juga pada dasarnya selalu berada dalam kondisi “sulit mengetahui mengapa ia menjadi seperti sekarang”, dan ini adalah masalah yang sudah diamati bahkan sejak sebelum “Programming as Theory Building”.
Jadi, mirip seperti infrastruktur, saya menduga pengembangan perangkat lunak juga akan bergeser ke alat yang membuat “mengapa kode menjadi seperti sekarang” lebih jelas.
Saat masuk ke codebase baru, memang benar sebaiknya mulai dari orang dan dokumentasi yang ditulis manusia, tetapi banyak tim engineering sama sekali tidak punya dokumentasi seperti itu.
Keputusan diambil di kepala seorang engineer atau di chat yang tidak tersimpan, spesifikasi hanya berupa beberapa baris catatan di tiket yang kemudian dihapus saat perapian, atau hilang ketika alat pelacakan diganti.
Tidak ada peta codebase atau fitur, tidak ada ADR, dan observability pun sangat minim.
Yang tersisa hanya kode, jadi kita harus membaca kode untuk mencari tahu apa yang terjadi, lalu bertanya ke engineer yang paling baru commit di area itu apakah mereka masih ingat mengapa itu dilakukan.
Saat seseorang membuat perubahan, sisi berlawanan dari codebase yang sama sekali dikira tidak terkait bisa ikut rusak.
Memang benar AI membutuhkan lebih banyak disiplin, tetapi secara teori disiplin itu jauh lebih mudah dipelajari daripada menjadi engineer yang hebat.
Dua puluh tahun lalu, untuk menulis kode C yang bagus dan skalabel, Anda harus jenius atau benar-benar mendedikasikan diri pada teknologinya.
Anda harus sangat menguasai banyak alat seperti ASan, LSan, UBSan, TSan, GDB, dan akan jauh lebih buruk lagi jika Anda harus membaca file DWARF langsung.
Secara realistis itu sulit dikuasai dalam waktu singkat, dan pada saat yang sama Anda juga harus belajar desain sistem, yang merupakan kemampuan terpisah dan hampir ortogonal.
Sekarang cukup mengetahui titik-titik berbahaya dari bahasa dan framework yang Anda pakai, menyuruh LLM mengujinya, memiliki infrastruktur untuk memastikan apakah pengujiannya sudah cukup, lalu membaca pengujian dan implementasinya yang sebenarnya.
Membaca dan memahami Rust jauh lebih mudah daripada men-debug error yang terasa seperti sihir saat mengembangkan dengan Rust.
Juga lebih mudah untuk mengenali bahwa skenario tertentu memerlukan Loom test, lalu membuat alat untuk mendeteksi apakah itu benar-benar sudah ditulis.
Bahkan jika Anda tetap memakai C atau Zig, jauh lebih mudah mengetahui kapan setiap alat harus dipakai dan mendeteksinya daripada mempelajari masing-masing alat secara mendalam satu per satu.
Membaca SQL tidak sulit, dan hampir separuh orang bisnis pun bisa melakukannya. Python hanya sedikit lebih sulit, dan Rust juga bisa dipahami jika membaca panduan 50 halaman, yang merupakan harga yang sangat kecil dibanding biaya menghabiskan 10 tahun dalam trial and error.
Jalur dari “LLM bekerja dengan cara yang tidak bisa diketahui” ke “karena itu dibutuhkan lebih banyak disiplin” lalu ke “semuanya baik-baik saja” tidak terasa jelas.
Saya setuju bahwa semuanya baik-baik saja, tetapi saya tidak melihat proses berpikir itu sebagai jalur yang gamblang.
Siapa pun yang punya kemauan untuk membuat sesuatu benar-benar bekerja, dan mau meluangkan sedikit waktu untuk memahami apa yang membuatnya gagal, bisa menghasilkan hal-hal luar biasa dengan memanfaatkan LLM.
Karena LLM membuat biaya membangun hal yang kompleks nyaris gratis, justru situasinya akan menjadi jauh lebih kompleks.
Engineering selalu tentang disiplin dan membuat sesuatu bekerja, tetapi dulu untuk menjadi bernilai Anda memerlukan sekumpulan keterampilan prasyarat.
Sebagian besar itu sekarang sudah hilang, dan semuanya menjadi jauh lebih mudah daripada sebelumnya.
Disiplin tetap dibutuhkan, tetapi dibanding berguling di dalam api selama 10 tahun, menurut saya disiplin itu murah.
Baru saja saya menghabiskan seminggu untuk meninjau PR sekitar 200 baris ini: https://github.com/ncruces/wasm2go/pull/37
PR itu diajukan oleh pengguna berpengalaman dan kemungkinan besar sudah bertanya ke LLM terdepan.
Tetapi tetap saja ada sesuatu yang terasa salah. Saya tidak memahaminya, dan saya juga tidak berniat merge sesuatu yang tidak saya pahami.
Saya juga curiga itu salah dengan cara yang akan menimbulkan masalah di masa depan.
Jadi saya meninjaunya dengan empat cara: memahaminya dan memperbaikinya, mengerjakannya dengan algoritme yang lebih baik, menghindarinya dengan memperbaiki masalah di upstream, atau menulis ulang dari nol agar sesuai dengan cara pikir saya.
Saya menduga jawabannya akan yang kedua atau ketiga, tetapi yang kedua meski merupakan jawaban yang benar mengharuskan proyek dikerjakan ulang dari awal, dan yang ketiga sangat saya harapkan berhasil tetapi ternyata tidak.
Akhirnya saya mencampur cara pertama dan keempat, dan meski saya masih belum sepenuhnya yakin, sekarang saya memahami masalah dan solusinya.
Tentu saja saya menganggap pendekatan saya lebih baik.
Tetap saja, setelah menghapus komentar di kedua versi, saya menyuruh LLM me-review keduanya.
LLM menjawab bahwa PR asli jelas lebih baik, dan ketika saya menjelaskan mengapa tidak demikian, ia menjawab bahwa saya yang benar.
Jika komentar dimasukkan lalu dicoba lagi, LLM-LM mengatakan versi saya lebih baik. Itu karena saya memang menemukan masalah yang sebenarnya.
Tetapi saya tidak tahu apakah ia mengatakan versi saya lebih baik karena saya benar-benar lebih baik, atau karena saya mengarahkan ia untuk berkata begitu.
Setelah membaca ini, rasanya penulis lupa pada pepatah, “semua model itu salah”
Ini juga kesalahan yang sering dibuat orang yang menyukai RPG “simulasi” yang “realistis”
Jika suatu objek dimodelkan dengan cukup komprehensif, model itu pada dasarnya menjadi objek itu sendiri
Untuk membuat model lokasi yang mencakup semua detail tempat nyata, Anda memerlukan model berskala 1:1, dan itu pada akhirnya hanyalah salinan tempat tersebut
Prompt terhadap model yang cukup lengkap untuk mereproduksi 100% fungsi sistem secara andal kemungkinan besar adalah source code sistem itu sendiri
Saya sering bertanya-tanya apakah sebagian besar IT dan pemrograman sebenarnya hanya soal menyatukan potongan-potongan yang sudah dipahami dengan baik
Delapan tahun lalu saya sempat memikirkan kenapa LLVM tidak diganti dengan sistem yang jauh lebih sederhana, dan optimasi manual diganti dengan “optimizer” AI yang sederhana
Saya pikir cukup melatihnya untuk mengubah kode hasil kompilasi sederhana menjadi kode yang “dioptimalkan”, tetapi konsensus saat itu adalah bahwa sistem AI sulit membuat kode yang benar dengan cukup andal untuk benar-benar dipakai
Jika AI bahkan tidak bisa menggantikan kode tingkat rendah seperti itu, maka masalah tingkat tinggi seharusnya jelas jauh lebih sulit
Namun orang-orang justru memakai AI untuk masalah tingkat tinggi
Hipotesis saya adalah bahwa banyak bagian dari rekayasa digital modern bersifat plug and play
Saya ingat sebelum 2023, di HN semua orang memuja pengurangan jumlah baris kode sebagai indikator senioritas yang paling kuat
Hanya saja arus banjir baris kode dari LLM terlalu kuat untuk dilawan dan dimenangkan
Dan saya juga tidak setuju dengan asumsi tulisan ini bahwa LLM bisa menulis kode yang bagus
Mereka menulis kode yang berjalan, tetapi terlihat seperti ditulis oleh demogorgon, jadi rasanya agak bikin mual saat dilihat
Buruk, tetapi buruknya dengan cara yang tidak akan pernah dilakukan manusia
Ini berbeda dari rasa tidak enak saat membaca kode spageti buatan developer junior; ini jenis jijik yang terasa seperti telur Cthulhu menetas di suatu tempat dalam perut
Saya ingat di perusahaan lama, ada seorang senior yang sejak masuk sampai menjadi manajer kerjanya hanya menghapus kode
Tulisan ini tidak menyenangkan untuk dibaca
Kalimat-kalimatnya sendiri maupun tiap paragrafnya cukup oke, tetapi sebagai keseluruhan terasa berantakan dan, berani saya bilang, tidak bermakna
Kata-katanya memang sangat banyak, tetapi yang benar-benar disampaikan terasa sangat sedikit
Misalnya, ungkapan bahwa ekonomi produksi kode terbalik pada 2025 itu tidak tepat
Kalau dulu proses produksinya ketat bersifat aditif seperti 3D printing, sekarang lebih mirip ditambah pendekatan subtraktif seperti CNC milling
“Bentuk” yang dibutuhkan tidak banyak berubah, dan jika Anda peduli pada toleransi tertentu, upaya manusia juga tidak berubah
Produk tetap perlu dihargai, digunakan kembali, dirawat, dan dikurasi sejauh yang dituntut pasar
Saya juga tidak setuju dengan pernyataan bahwa “baris kode bukan artefak yang ideal untuk direview”
Apa arti “ideal” di sini?
Waktu kecil, di setiap ujian aturannya selalu “tunjukkan langkah pengerjaanmu”
Alasannya karena yang ingin ditingkatkan bukan hanya produk yang dirilis besok, tetapi juga model mental dan proses berpikir generasi berikutnya
Bahasanya benar-benar sulit diikuti dan inti tulisannya juga tidak terlihat jelas
Saat melihat tulisan seperti ini, saya justru makin meragukan klaim bahwa pekerjaan software engineer akan hilang
Pekerjaan software engineer pada 2026 berbeda dari 2020, apalagi dari 1990, jadi kenapa kita harus percaya pada dikotomi palsu bahwa pekerjaan pada 2026 entah akan tetap sama persis atau hilang seluruhnya?
Waktu dulu sekali bekerja di Google, gagasan bahwa semua kode direview terasa baru bagi saya
Sebelumnya di MS, kodenya dibakar ke CD dan dimasukkan ke dalam boks, jadi sebagian besar tidak direview sampai titik berisiko tinggi di akhir proyek
Antara 2000 dan 2004, cara software engineer menghabiskan waktu berubah drastis, dan menurut saya menjadi lebih baik karena meningkatkan pemahaman bersama dan mendorong kolaborasi
Jika AI menulis kode dan manusia menghabiskan lebih banyak waktu untuk review, itu belum tentu buruk
Tetapi jika kode AI menjadi cukup bagus, orang akan menganggap review yang menyeluruh sebagai sesuatu yang opsional
Maka pekerjaan software engineer akan sangat berbeda dari sebelumnya, dan mereka tidak akan banyak menulis kode maupun menghabiskan banyak waktu untuk review
IDE mungkin bisa lenyap seperti burung dodo
Fokusnya bisa bergeser ke penetapan tujuan dan pengaturan pengujian agar tim coding AI tidak keluar jalur dari tugasnya
Software engineer yang sangat paham ke mana arah proyek mungkin akan menghabiskan lebih banyak waktu pada arsitektur, karena ketika titik tujuan berubah secara masuk akal, Anda tidak ingin AI menulis ulang ini itu
Mereka juga bisa menghabiskan lebih banyak waktu untuk eksplorasi: membuatnya dengan satu cara, lalu cara lain, lalu cara lain lagi, kemudian membandingkannya dan menghasilkan ide baru dari pendekatan yang berbeda-beda
Saya tidak punya prediksi yang lebih baik daripada orang lain, tetapi saya sangat menolak gagasan bahwa peran ini akan hilang, dan mendukung gagasan bahwa ia akan berevolusi, seperti yang sudah berkali-kali terjadi sampai sekarang. Hanya saja mungkin belum pernah secepat ini
Saya rasa pernyataan “kita memperlakukan kode sebagai sesuatu yang permanen karena tenaga kerja untuk memproduksi kode adalah bottleneck” itu tidak benar
Kode diperlakukan sebagai sesuatu yang permanen karena dianggap sebagai single source of truth
Komputer tidak mengeksekusi dokumen, melainkan mengeksekusi kode
Jika dokumen requirement bertentangan dengan kode, asumsi dasarnya adalah dokumen requirement yang salah
Kode tidak bisa dipisahkan dari spesifikasi. Kode adalah spesifikasi itu sendiri