15 poin oleh GN⁺ 2026-02-26 | 1 komentar | Bagikan ke WhatsApp
  • Realitas bahwa biaya menulis kode turun drastis sedang mengguncang kebiasaan engineering secara menyeluruh
  • Di masa lalu, produksi kode berbiaya tinggi sehingga terbentuk budaya pengembangan efisien yang berpusat pada desain, estimasi, dan perencanaan
  • Dengan munculnya coding agent, satu developer kini bisa menangani beberapa pekerjaan sekaligus secara bersamaan (implementasi, refactoring, testing, dokumentasi)
  • Namun, membuat "kode yang baik" tetap memerlukan standar kualitas tinggi dan penilaian dari developer
  • Karena itu, tantangan untuk membangun kebiasaan pengembangan baru di tingkat individu maupun organisasi pun muncul

Perubahan biaya penulisan kode

  • Dulu, menulis ratusan baris kode yang rapi dan telah diuji bisa memakan waktu lebih dari sehari
    • Karena itu, developer menilai nilai dan prioritas fitur berdasarkan keterbatasan waktu dan biaya
    • Desain proyek, estimasi jadwal, dan perencanaan fitur semuanya berpusat pada "penggunaan waktu coding yang efisien"
  • Dengan adopsi coding agent, biaya memasukkan kode turun drastis dan menggoyahkan standar penilaian lama
    • Seorang engineer dapat menjalankan beberapa agent secara paralel untuk melakukan pekerjaan pengembangan simultan
    • Perubahan ini mendorong peninjauan ulang atas struktur penilaian nilai terhadap waktu yang selama ini digunakan

"Kode yang baik" tetap mahal

  • Produksi kode baru kini nyaris gratis, tetapi membuat "kode yang baik" tetap membutuhkan biaya besar
  • Syarat kode yang baik adalah sebagai berikut
    • Berfungsi dengan tepat dan mencapai tujuannya tanpa bug
    • Melalui prosedur verifikasi untuk membuktikan bahwa kode tersebut dapat dipercaya
    • Berfokus pada penyelesaian masalah yang tepat, serta menangani kondisi error secara dapat diprediksi
    • Menjaga struktur yang sederhana dan minimal untuk meningkatkan maintainability dan kemudahan dipahami
    • Testing dan dokumentasi harus selalu mutakhir
    • Mempertimbangkan kemungkinan perubahan di masa depan tanpa menambah kompleksitas yang tidak perlu
    • Memenuhi atribut kualitas nonfungsional seperti aksesibilitas, keamanan, skalabilitas, dan maintainability
  • Coding agent dapat membantu sebagian dari proses ini, tetapi tanggung jawab akhir atas jaminan kualitas tetap ada pada developer

Perlunya kebiasaan pengembangan baru

  • Dalam lingkungan agentic engineering, kebiasaan pengembangan lama tidak lagi berlaku
  • Baik individu maupun organisasi harus membentuk cara kerja dan standar penilaian baru
  • Saat ini, best practices tersebut masih sedang dibentuk di seluruh industri
  • Pendekatan yang diusulkan adalah mencoba bereksperimen dengan menjalankan sesi agent asinkron, bahkan ketika terasa seperti "membuang waktu"
    • Dalam skenario terburuk, Anda hanya mengeceknya 10 menit kemudian dan hasilnya sekadar pemborosan token

Posisi dalam panduan Agentic Engineering Patterns

  • Tulisan ini merupakan bagian dari bab pertama panduan Agentic Engineering Patterns, yaitu "Principles"
  • Bab berikutnya melanjutkan topik pemahaman kode (Understanding code) dengan Linear walkthroughs
  • Setelah itu, di bagian Testing and QA akan dibahas topik seperti Red/green TDD dan First run the tests
  • Ke depannya akan ditambahkan 1~2 chapter per minggu; bentuknya mirip buku, tetapi disusun sebagai sebuah "panduan"

1 komentar

 
GN⁺ 2026-02-26
Komentar Hacker News
  • Saya tidak yakin frasa “kode selalu mahal” itu tepat
    Yang sebenarnya mahal bukanlah kode itu sendiri, melainkan semua proses di sekitarnya — memastikan akurasi, pemeliharaan, koordinasi antar tim, dukungan jangka panjang, dan sebagainya adalah faktor biaya yang sesungguhnya
    Jika pengujian atau prosedur persetujuan dilakukan berlebihan, justru proses itulah yang mengambil sebagian besar biaya
    Dalam jangka pendek, LLM sangat menurunkan biaya untuk menghasilkan kode yang berjalan, tetapi dalam jangka panjang bisa jadi beban pemeliharaan, keamanan, dan pengujian malah membesar
    Pada akhirnya, apakah benar ada perubahan besar hanya bisa diketahui dari data jangka panjang

    • Saya setuju dengan pernyataan bahwa “yang mahal adalah semua hal di sekitar kode”
      Dulu bahkan menulis beberapa ratus baris kode pun biayanya besar
      Saat saya memasukkan 256 baris JavaScript ke alat SLOCount gaya 2000-an (versi WebAssembly), estimasi biayanya sekitar $6.461 menurut standar saat itu
      Tentu saja angka itu cuma untuk lucu-lucuan
    • Dari pengalaman saya, bukan hanya coding, tetapi DevOps, analisis data, pekerjaan dukungan, dan area lain juga semuanya diperkuat oleh AI
      Sekarang saya terasa lebih seperti manajer bagi diri sendiri yang mengelola pekerjaan saya, alih-alih mengerjakannya langsung
      Produktivitas saya terasa naik sekitar 2,5 kali dibanding dulu
    • Jika melihat software development lifecycle (SDLC), coding hanyalah satu tahap
      Pengumpulan kebutuhan, perancangan, pengujian, deployment, dan pemeliharaan tetap diperlukan, dan sebagian besar biaya tetap muncul pada tahap pemeliharaan
      Seperti hukum Amdahl, sekalipun biaya coding mendekati 0, biaya tahap lain akan menjadi batasnya
    • Penghematan biaya yang sesungguhnya datang dari mengetahui dengan tepat apa yang “benar-benar diinginkan” pengguna
      Masalahnya, itu sulit karena sifat dasar manusia
    • Kode itu mahal di masa lalu, mahal sekarang, dan akan tetap mahal di masa depan
      Unsur kualitas seperti akurasi, kemudahan pemeliharaan, dan performa adalah biaya tersembunyi yang hanya bisa dipahami lewat pengalaman
  • Saya tidak setuju dengan klaim bahwa “kode selalu mahal”
    Sebenarnya kode mahal karena kita berusaha menulis ‘kode yang bagus’
    Jika standar diturunkan, kode hasil generasi memang cepat dan murah, tetapi usaha untuk mengembalikannya menjadi kode yang bagus tetap sama
    Jika ingin membela agent coding, harus memakai logika lain

    • Dari pengalaman saya, saat memakai agen AI justru lebih sulit mendapatkan kode yang bagus
      Saat menulis sendiri, saya paham alasan tiap baris, tetapi kode buatan AI membuat saya harus memverifikasi setiap sintaks
      Selama sebulan terakhir sebagian besar pekerjaan saya dikerjakan dengan agen, dan terus muncul bug edge case yang tidak akan dibuat manusia
      Pada akhirnya biaya review membesar sehingga keuntungan jangka pendek hilang
    • Saya sengaja mengungkapkannya dengan hati-hati sebagai “kode yang bagus tetap memerlukan biaya”
      Namun berkat agen coding, biaya itu jauh lebih turun
      Perbaikan detail bisa dikerjakan agen, jadi kita bisa membuat kode dengan kualitas lebih baik lebih cepat
    • Kode sederhana memang murah, tetapi kode yang kompleks tetap mahal
      Kompleksitas bersifat akumulatif, jadi menanganinya dengan hati-hati saat pertama kali menulis adalah opsi termurah
      Sekarang keuntungan jangka pendek memang besar, tetapi dalam jangka panjang noise bisa meningkat 10 kali lipat
    • Intinya adalah bahwa pemrograman itu murah, tetapi rekayasa perangkat lunak itu mahal
    • Ini mengingatkan pada konsep tactical vs strategic programming dari Ousterhout
      LLM unggul dalam tactical programming, yaitu implementasi fitur dengan cepat
      Karena itu, pengelolaan kompleksitas di tingkat sistem menjadi semakin penting
  • Pembuatan kode memang semurah yang orang katakan, tetapi kemampuan mengubahnya menjadi hasil yang bernilai adalah keahlian yang sesungguhnya
    Agentic engineering pada akhirnya adalah keahlian mengubah input murah menjadi output bernilai

    • Saya sepenuhnya setuju dengan gagasan “mengubah input murah menjadi hasil yang bernilai”
      Agentic engineering bukan sekadar menulis software, melainkan membuat alat untuk menyelesaikan masalah tertentu dengan cepat
      Tetapi setelah masalahnya terselesaikan, AI itu sendiri sudah tidak menarik
      Banyak orang menjadikan AI sebagai tujuan itu sendiri, padahal nilai sejatinya ada pada penyelesaian masalah
      Seperti kata Alan Watts, setelah menerima pesannya, kita harus menutup telepon
    • Memiliki ekskavator tidak berarti Anda bisa menggali lubang sembarangan lalu menjadi kaya
      Hanya karena alat menjadi murah bukan berarti nilai otomatis tercipta
    • Tindakan mengetik kode itu sendiri sebenarnya bukan nilai
      Kemampuan merancang dan menyusun struktur itulah nilai yang sesungguhnya
    • Jika output berasal dari otak yang sama, entah didapat lewat instruksi sangat rinci atau kebetulan langsung jadi sekali, kualitasnya mirip
      Pada akhirnya yang penting adalah kualitas pengambilan keputusan
    • Menggalang dana $100 juta tidak berarti idenya bagus
      Pendanaan bukan bukti adanya nilai
  • Saya meragukan klaim “kode selalu mahal”
    Definisi kode yang bersih dan teruji pun kabur
    Jika pengujian dilakukan berlebihan, biaya meledak, dan prosedur persetujuan organisasi juga merupakan faktor biaya besar
    LLM menurunkan biaya jangka pendek, tetapi bisa menaikkan biaya pemeliharaan jangka panjang

    • Kode memang selalu mahal
      Saat saya masih magang, saya bekerja murah di startup, tetapi gangguan, kerusakan data, dan technical debt menumpuk
      Dari luar tampak murah, tetapi biaya tersembunyinya besar
      Berkat LLM sekarang seolah kita bisa mendapatkan kode berkualitas dengan murah, tetapi saya sendiri masih beradaptasi
    • Dari sudut pandang startup, dulu untuk meluncurkan produk perlu mempekerjakan developer selama lebih dari 6 bulan
      Sekarang membuat v1 itu murah, tetapi keputusan kompleks pada produk yang matang tetap mahal
  • Nilai ekonomi software ada pada informasi yang terkandung di dalam kode
    Menulis kode hanyalah proses memetakan informasi itu, dan kualitas informasi itulah yang menentukan nilai sebenarnya
    Menulis kode dengan cepat tidak otomatis meningkatkan kualitas informasi
    Sama seperti dalam konsultasi, membuat slide lebih cepat tidak serta-merta menciptakan nilai

    • Konsep ini selaras dengan topik yang belakangan ramai, yaitu cognitive debt
      Jika kecepatan implementasi terlalu tinggi, model mental developer menjadi tidak selaras dengan kode
      Tulisan terkait: Cognitive Debt by Simon Willison
    • Saya juga punya pengalaman bahwa saat memakai agen coding, kualitas pemetaan antara informasi dan kode justru membaik
      Karena saya bisa mengulang refactoring dengan cepat
    • Pada akhirnya bottleneck ada pada proses menyampaikan niat kepada mesin
      AI mungkin akan semakin memahami konteks, tetapi itu juga berarti kita harus melepaskan lebih banyak penilaian manusia
      Jika suatu hari mesin sepenuhnya memahami niat, manusia akan terdorong keluar dari loop
  • Inti dari semua metodologi pengembangan adalah fakta bahwa requirements selalu berubah
    Karena itu, kode yang bagus adalah “kode yang mudah diubah”
    Masih diragukan apakah agen LLM saat ini mampu membuat kode seperti itu
    Sampai benar-benar dapat dipercaya, sepertinya ia akan tetap berada di level prototipe

    • Bottleneck sebenarnya bukan menulis kode, tetapi biaya untuk menyampaikan niat dengan jelas
      Jika spesifikasi tidak jelas, maka pengujian dan verifikasi nilai sama-sama sulit
    • Insinyur manusia pun tidak bisa melakukan perubahan dengan aman 100%
      Bahkan dengan pengujian, tingkat keyakinannya hanya sekitar 70%
    • Saya mengelola LLM dengan rinci dan sering memintanya mengubah fitur serta memperbaiki bug
      Ini lebih cepat daripada coding langsung, dan hasilnya juga berupa kode yang dapat dipelihara
    • Semua commit saya sekarang sudah 100% dihasilkan agen
      Jika kita menyatakan dengan jelas clean code dan praktik yang baik, hasilnya cukup bisa dipelihara
      Pada akhirnya tetap Garbage in, garbage out
    • Namun ada juga yang merasa LLM bagus sampai level demo, tetapi runtuh bahkan untuk modifikasi kecil
  • Seperti yang saya tulis di artikel saya (The Final Bottleneck),
    kecepatan penulisan kode memang naik, tetapi tahap setelahnya tidak mampu mengikuti
    Ini bukan sekadar soal kebiasaan; struktur tanggung jawab, desain bahasa, dan keseluruhan struktur sistem juga harus berubah

    • Tidak semua perusahaan mudah bekerja dengan cara baru
      Jika produktivitas benar-benar naik 10 kali lipat, startup pasti sudah mengguncang pasar
    • Jika LLM menjadi cukup kecil dan murah, akan datang era ketika ia tertanam di aplikasi dan menyesuaikan kode untuk tiap pengguna
    • Ada juga pertanyaan, “mengapa kita harus menulis kode secepat itu?”
      Hanya karena sesuatu bisa dilakukan bukan berarti itu harus dilakukan
    • Para developer open source harus memimpin era ketika bahkan non-developer bisa menjadi builder
      Pendekatan seperti AI evals (measure-first-optimize-last, ai-evals.io) mengarah ke sana
    • “Apakah kita harus terus deploy secepat itu?”
      Ledakan fitur bukan sesuatu yang diinginkan siapa pun
  • Setiap baris kode adalah liability
    Di era ketika LLM bisa memuntahkan kode dalam jumlah besar, liability itu meledak
    Alatnya sendiri tidak buruk, tetapi struktur di mana program tanpa tanggung jawab menulis ulang codebase itu berbahaya

    • Selama puluhan tahun kita telah membangun sistem verifikasi, review, dan rollback untuk deployment kode
      “Kode itu murah” berarti hanya proses pembuatannya yang menjadi murah; biaya persetujuan deployment tetap besar
      Jika tahap penilaian dilewati, hasilnya bukan peningkatan produktivitas melainkan control gap
      Memberikan master key hanya karena sesuatu lebih cepat itu berbahaya
    • Penulisan maupun pemeliharaan tetap mahal
      Keduanya sama-sama tidak murah
  • Saya hampir sepenuhnya setuju dengan pendapat ini
    Menulis kode memang menjadi lebih murah, tetapi biaya review dan verifikasi tetap besar
    Terutama pada monorepo dengan jutaan baris kode, meningkatkan testability adalah kuncinya
    Saya merasa berterima kasih karena diskusi seperti ini memberi keseimbangan di tengah suasana Twitter yang terlalu panas

    • Saya juga melihat hal yang sama
      Code churn memang menjadi lebih mudah, tetapi verifikasi kualitas menjadi tantangan baru
      Perubahan dalam jumlah besar yang dibuat LLM memunculkan kegagalan halus, dan arus itu tidak berhenti
  • Kode tidak murah
    Ada juga biaya token, dan struktur biaya yang sebenarnya masih belum jelas
    Situasi ketika startup yang belum menghasilkan laba memonopoli rantai pasok GPU membuat data masih kurang

    • Penulisan memang menjadi lebih murah, tetapi pemeliharaan tetap sama
      Semakin banyak LOC, semakin besar pula utangnya
      Jarak dari pikiran ke eksekusi memang memendek, tetapi kode itu sendiri tetaplah tanggung jawab
    • Model lokal menunjukkan batas bawah biaya
      Saat ini murah karena ada subsidi, tetapi bisa jadi akan lebih murah lagi jika biaya hardware, listrik, dan tenaga kerja turun