Agen coding menggantikan semua framework yang biasa saya pakai

> "Rekayasa perangkat lunak kembali hadir"

• Dengan kemajuan model AI frontier dan agen coding, era pemrograman terotomatisasi telah dimulai; pekerjaan manual mengetik kode baris demi baris menghilang, dan software engineer bisa kembali fokus pada desain dan pemikiran yang esensial
• Sejak akhir tahun lalu, tingkat kematangan alat dan model meningkat drastis, sehingga dalam lingkungan yang tertata baik kini dimungkinkan berfokus pada peran arsitek sambil tetap bisa turun tangan untuk memperbaiki langsung bila diperlukan
• Dalam pengembangan web, mobile, dan desktop, telah lama menumpuk framework dan lapisan abstraksi yang tidak perlu yang bukannya menyelesaikan kompleksitas nyata, malah menambah masalah
• Dari tiga masalah yang diklaim diselesaikan framework—penyederhanaan, otomatisasi, pengurangan biaya tenaga kerja—hanya otomatisasi yang punya nilai yang sah, namun otomatisasi AI kini bahkan dapat menggantikan itu juga
• Kita tidak seharusnya merosot menjadi sekadar operator sistem yang dirancang oleh hyperscaler seperti Google, Meta, dan Vercel, melainkan kembali ke rekayasa sejati: merancang dan membuat produk sendiri

---

Kebangkitan pemrograman terotomatisasi

• Framing "automated programming" yang dinamai Antirez menangkap esensi jauh lebih baik daripada "vibe coding"
  • Seperti mesin cetak, alat tenun, dan lini perakitan, otomatisasi adalah inti inovasi sepanjang sejarah, dan perubahan kali ini adalah kelanjutannya
• Sejak Desember 2025, kemampuan model frontier dan agen coding berubah drastis, sampai-sampai bagi mereka yang mengamati dengan cermat, hal ini sudah sangat jelas

Perubahan peran engineer

• Pekerjaan yang membutuhkan pemikiran mendalam seperti arsitektur, trade-off, keputusan produk, dan edge case masih tetap ada
• Yang hilang adalah pekerjaan manual yang melelahkan dan menguras tenaga untuk mengetik sendiri setiap baris kode
• Dengan memakai model dan alat dalam lingkungan yang bersih dan tersusun rapi, kita bisa berperan sebagai arsitek tanpa harus menyusun bata satu per satu
• Ini perlu ditopang pengalaman 20 tahun menulis kode secara langsung; jika hasilnya tidak memuaskan, kita tetap bisa masuk sendiri, memahaminya, memperbaikinya, lalu memperbarui konfigurasinya
• Karena alat yang dibutuhkan bisa dibuat seketika, kita dapat menghabiskan lebih banyak waktu untuk mewujudkan teknologi yang dibayangkan

Framework dan kompleksitas yang tidak perlu

• Dalam pengembangan web, mobile, dan desktop, selama bertahun-tahun telah menumpuk polusi besar dari framework, library, dan tooling
• Lapisan abstraksi yang tidak mengabstraksikan hal bermakna terus bertumpuk; mengaku menyelesaikan satu masalah tetapi menciptakan sepuluh masalah baru
• Alih-alih menajamkan cara berpikir menghadapi kompleksitas nyata dalam membangun perangkat lunak, seluruh industri memilih cara membeli pola pikir siap pakai
• Ini seperti membungkus kaki yang patah dengan sutra: tampak bagus di luar, tetapi kakinya tetap patah

Tiga masalah yang diklaim diselesaikan framework

• "Penyederhanaan (Simplification)": fenomena ketika engineer takut merancang sendiri lalu menerima struktur milik orang lain secara membabi buta
  • Alih-alih merancang mundur dari tujuan, mereka menerapkan desain one-size-fits-all ke mana-mana
  • Itu bukan penyederhanaan, melainkan penyerahan intelektual (intellectual surrender)
• "Otomatisasi (Automation)": satu-satunya nilai yang benar-benar masuk akal, yaitu menghilangkan boilerplate code
  • Otomatisasi pekerjaan yang berulang namun penting seperti ORM, pengelolaan CRUD, code generation, dan dokumentasi API
  • Namun justru di titik inilah AI sedang mengubah segalanya
• "Pengurangan biaya tenaga kerja (Labour cost)": alasan sunyi yang tidak muncul di slide konferensi
  • Jika Google, Meta, dan Vercel menentukan cara membangun produk dan men-deploy kode, maka perusahaan bisa mempekerjakan "developer React" alih-alih software engineer
  • Tidak perlu pelatihan, plug-and-play, dan mudah diganti seperti komponen (cog)
  • Ini bukan engineering, melainkan operating

Realitas cara kerja baru

• Selama lebih dari 2 tahun, pendekatan ini dipakai untuk membangun hampir tanpa cacat, dan revolusi yang sesungguhnya terjadi sejak Desember tahun lalu
  • Muncul peluang untuk menyingkirkan kompleksitas yang tidak perlu dan fokus pada kompleksitas yang berpusat pada ide
• Biaya menghilangkan boilerplate mendekati nol, sehingga tidak perlu menulis kode yang sama dua kali
• Bisa langsung membangun alat kecil yang spesifik tujuan dan pas untuk masalah yang dihadapi
• Tanpa monorepo manager yang mewah, Makefile sederhana sudah memenuhi 99% use case
• Jika masalahnya benar-benar menjadi sangat kompleks, barulah dipikirkan saat itu; tidak pernah menyelesaikannya lebih dulu sebelum perlu adalah engineering
  • Yang harus diselesaikan bukan masalah yang konon suatu hari akan dialami seseorang di panggung konferensi, melainkan masalah yang ada sekarang

Penemuan kembali Bash dan alat dasar

• Agen sangat mahir menggunakan alat dasar (basic tools) yang sudah ada selama puluhan tahun
• Bash lahir pada 1989, dan kini bahkan model paling biasa pun memahami Bash lebih baik daripada manusia mana pun di dunia
• Ada tren agen coding beralih dari konfigurasi MCP yang kompleks dan mahal ke agent loop sederhana berbasis Bash
• Alat tertua justru menjadi alat yang paling future proof

Biaya ketergantungan pada framework

• Untuk sebagian besar use case, tidak diperlukan framework mahal dan penuh cacat beserta library pendampingnya jika pada akhirnya hanya 10% fungsi yang dipakai
  • Ada biaya tak terlihat yang besar seperti maintenance, security update, dan batasan desain, yang semuanya membatasi kebebasan developer
• Jika trade-off ini terus diterima, kita akan melewatkan peluang terbesar dalam beberapa dekade
• Waspadai struktur yang membuat kita tunduk pada filosofi desain perusahaan besar seperti Google, Meta, dan Vercel
  • Developer harus mempercayai pemikiran dan sense estetika mereka sendiri, lalu membangun alat dan produk mereka sendiri
    > "Jangan bungkus kaki yang patah dengan sutra; buat sesuatu yang benar-benar milikmu sendiri"

[click]

Ini benar-benar metodologi pengembangan yang membuat maintenance jadi sangat sulit. Di era AI, ini orang yang mempraktikkan cara baru untuk menjaga posisinya seumur hidup di era yang baru.

[centell]

Saya benar-benar tidak setuju dengan pernyataan, “framework mahal dan penuh cacat beserta library pendamping yang dalam kebanyakan use case hanya memakai 10% fungsinya”.. Bukankah memilih environment dengan ukuran yang sesuai untuk proyek justru sebuah keutamaan? Kalau sepertinya tidak akan membuat fitur yang banyak, ya pakai saja yang ringan seperti express. Perlukah sampai harus membuat sesuatu dari nol untuk menggantikan express..

Kalau mau dibilang fiturnya banyak tapi yang dipakai cuma sedikit, justru web server seperti Apache atau nginx lebih cocok untuk itu. Tapi apakah karena itu terasa berat lalu orang membuat web server dari nol? Tidak, kan, tinggal dikonfigurasi dan dipakai saja.

[bini59]

Ada framework yang tertata rapi dan punya banyak materi pelatihan untuk AI, jadi rasanya tidak perlu repot-repot membuat sesuatu yang baru versi saya sendiri; malah terasa seperti menurunkan produktivitas.
Saya rasa tidak perlu membuang sesuatu yang sudah membantu mengurangi biaya merancang arsitektur dan membuat kita bisa fokus pada hal yang esensial (layanan).

[khris]

Hmm... praktik seperti ini bukankah lebih cocok saat Cursor menawarkan penggunaan tanpa batas...? Justru, setidaknya untuk sementara ke depan, arahnya tampaknya lebih ke bagaimana menghemat token dan memanfaatkan AI sebagai pendamping dengan baik, bukan?

Bahkan tanpa harga token yang mahal pun kita bisa menghilangkan duplikasi, jadi apa alasan untuk tidak menggunakan framework?

[GN⁺]

Komentar Hacker News

• Dalam waktu dekat, banyak developer dan perusahaan tampaknya akan mengalami guncangan besar karena gengsi AI
  Saat ini memang bisa membuat sesuatu dengan AI, tetapi masalah sebenarnya adalah ada hal-hal yang tidak akan dipahami sebelum benar-benar menabraknya sendiri
  Pada akhirnya, orang-orang yang hanya melakukan ‘vibe coding’ akan menabrak batas dunia nyata, dan hanya mereka yang memahami cara kerja sistem yang sebenarnya yang akan bertahan

  • Saya justru berpikir sebaliknya. Dalam sesi yang saya lihat di AWS re:Invent, tiga agen SRE menangani semuanya secara otomatis, dari analisis log sampai perbaikan bug dan pengajuan PR
    Bug bisa diperbaiki dan di-merge dalam 2 menit, dan “memahami sistem” serta “tidak menulis kode secara langsung” bisa berjalan berdampingan
    AWS bertaruh sangat besar pada arah ini, dan seiring alat non-deterministik makin stabil, ada kemungkinan besar kualitasnya melampaui level manusia
  • AI maupun outsourcing sama saja, hanya orang yang memahami keseluruhan pekerjaan secara mendalam yang bisa memanfaatkannya dengan benar
    Jika mendelegasikan tanpa pemahaman, akurasi, maintainability, dan skalabilitas hasilnya tidak bisa dijamin
  • Ada juga orang yang percaya bahwa sistem kompleks bisa dibuat dengan “meminta dengan manis” kepada AI
    Tetapi jika harus bekerja bersama orang seperti itu, saya justru bertanya-tanya kenapa saya harus membayar ratusan ribu dolar untuk mereka sekaligus biaya langganan LLM mereka
  • Terdengar terlalu doomer
    Tentu akan ada contoh aplikasi hasil ‘vibe coding’ yang rusak, tetapi tim yang menjalankan testing, version control, dan dokumentasi justru akan makin berkembang
    Pada akhirnya, pendekatan yang seimbang itulah yang penting
  • Mungkin tidak akan ada keruntuhan besar-besaran, tetapi waktu yang dihabiskan untuk merapikan ampas kode buatan AI (de-slopping) tampaknya akan terus bertambah
    Suatu hari nanti mungkin akan muncul ‘bot de-slopper’

• Alasan memakai framework adalah karena para perancangnya sudah menghadapi lebih banyak masalah dan isu skala daripada saya
  Di awal proyek memang mudah, tetapi saat skala membesar, mendesain ulang jadi menyakitkan

  • Menolak kode yang ditulis manusia dan hanya mempercayai kode LLM menurut saya adalah bentuk kegilaan
    Saat membaca tulisan seperti ini, sering kali rasanya artikel itu sendiri seperti ditulis oleh LLM
    Analogi seperti ‘memotong dan menjahit batu bata’ justru menunjukkan kontradiksinya
  • Sindrom ‘Not Invented Here’ sejak dulu adalah anti-pattern
    Membangun seluruh stack sendiri tetap tidak efisien dan biaya pemeliharaannya besar
    Yang berubah sekarang adalah kita jadi lebih mudah membuat komponen kustom yang sesuai dengan masalahnya
  • Saya banyak memakai LLM, tetapi keunggulan terbesarnya justru bahwa LLM sudah mengenal framework tersebut
    Tidak perlu belajar hal baru; framework yang sudah familiar sudah cukup
  • Hanya dengan melihat API selama satu atau dua jam, biasanya kualitas framework itu sudah bisa dinilai
  • Keterbatasan framework adalah ketika ia tidak mendukung hal yang ingin saya lakukan, akan muncul tiga masalah
    masalah saya, masalah platform, dan masalah mengakali framework

• Tulisan yang membahas penderitaan menulis kode terasa aneh. Coding justru bagian yang mudah
  Jika Tolkien memakai AI, sepertinya ia akan membuang waktu hanya untuk menyempurnakan prompt

  • Saya juga pernah memakai Claude, tetapi pada akhirnya pemahaman saya menurun
    Terutama untuk bagian yang sulit, bantuan AI justru menjadi racun
  • Yang menarik, dalam perdebatan vim/emacs orang sering berkata “mengetik itu tidak penting”, tetapi
    dalam tulisan tentang AI mereka berkata “AI menulis kode menggantikan saya sehingga saya bisa fokus berpikir”
    Jika orangnya sama, itu kontradiktif
  • Menulis kode itu menyakitkan? CI yang gagal itulah penderitaan yang sebenarnya
    Belakangan ini kalau diserahkan ke Claude Code, biasanya selesai dalam beberapa menit
  • Ada orang yang merasa membaca kode orang lain lebih nyaman
    Tetapi saya lebih percaya kode yang saya tulis sendiri. Pada akhirnya, yang penting bukan kecepatan melainkan kedalaman pemahaman
  • Bahkan dalam seni, yang penting bukan proses melainkan kualitas hasil akhirnya
    Seperti Warhol, memanfaatkan alat baru dengan baik juga merupakan seni
    LLM hanyalah alat yang membantu tahap awal penciptaan, dan kejeniusannya tetap berasal dari manusia

• Menganggap patch keamanan Node.js sebagai hal yang merepotkan adalah kesalahpahaman
  Itu adalah privilege. Solusi buatan sendiri tidak punya komunitas keamanan dan punya lebih banyak kerentanan
  Developer React mudah dicari, tetapi tidak ada developer untuk “framework eksklusif buatan AI”

  • Pada akhirnya AI hanya mereplikasi framework open source yang sudah ada dengan tingkat kecanggihan lebih rendah
    Itu bukan sesuatu yang luar biasa
  • Sulit menghindari React. Ia sudah menjadi standar industri

• Ada titik tengah antara agen coding dan framework
  Saya masih memakai alat yang sama, tetapi pekerjaan berulang dikerjakan agen, dan
  saya fokus pada arsitektur serta edge case
  Mengabaikan agen maupun mempercayainya secara membabi buta sama-sama ekstrem
  Keahlian yang sebenarnya adalah mengetahui kapan harus mengambil alih kemudi

• Masalah tulisan ini adalah ia melihat framework dan ‘rekayasa yang sesungguhnya’ sebagai sesuatu yang saling berlawanan
  Platform seperti Vercel, Next.js, dan Firebase memungkinkan deploy instan dan CI/CD
  Jika mengingat masa ketika semuanya harus disetel sendiri dengan Jenkins, ini terasa revolusioner
  Rekayasa yang sesungguhnya bukan soal ‘menciptakan ulang’, melainkan mengirimkan ke pelanggan dengan cepat

  • Dalam pengembangan mobile juga, framework dan library membuat hidup jauh lebih mudah

• Tidak efisien jika AI mengimplementasikan ulang framework yang ada tanpa battle-tested
  Tanpa ekosistem dan pola umum, kolaborasi menjadi sulit

  • Pada akhirnya itu hanya versi AI dari copy-paste StackOverflow
    Developer yang kurang berpengalaman salah memakai AI bukanlah hal baru
  • Ekosistem dan pola idiomatik dari framework adalah nilai intinya
    Jika membuat sendiri, dokumentasi, middleware, dan pemeliharaan semuanya ikut hilang
  • Para pemimpin AI saat ini sedang menemukan ulang pengetahuan yang sudah ada
    Mereka baru sampai pada tahap menyadari bahwa “API bisa dihubungkan”
    Tetapi penemuan semacam ini tidak otomatis disertai pemahaman tentang trade-off

• Selama 6 bulan terakhir saya mengerjakan pengembangan embedded dengan Cursor + Opus 4.x
  LLM membantu bukan hanya software tetapi juga desain sirkuit, CAD, dan CNC
  Misalnya, saya menyelesaikan fungsi wrapper untuk display berbasis ST7789 hanya dengan tiga prompt
  Sekarang saya hampir tidak memakai library selain LVGL, TinyUSB, kompresi, dan enkripsi
  Fungsi spesifik tujuan yang dibuat LLM kecil, cepat, dan tidak punya abstraksi yang tidak perlu
  Saya rasa banyak library kini memang sudah waktunya tersingkir

  • Mungkin istilah library lebih tepat daripada framework
    Hal seperti .NET tidak tergantikan, tetapi kumpulan fungsi serbaguna jelas bisa diganti
  • Saya hanya berkata kepada Claude (Opus 4.1), “tolong buat driver Rust untuk ESP32 + ST7789”, lalu
    ia langsung memberi kode lengkap yang bahkan mencakup double frame buffer
  • Ada juga pendapat bahwa jika library dari pabrikan hanya berupa wrapper tipis, bukankah lebih baik langsung dipakai saja

• Bagian paling berat dari coding bukan mengetik, melainkan kolaborasi dengan orang, testing, dan pemikiran desain
  Hal tersulit yang baru-baru ini saya kerjakan adalah merancang struktur data lock-free

  • Tetapi AI juga bisa membantu proses berpikir yang kompleks seperti ini

• Di era LLM, nilai framework justru makin besar
  Berkat data latihannya, LLM kuat pada pola yang familiar seperti React
  Fakta bahwa manusia masih bisa ikut campur untuk debugging juga penting
  Bahkan jika AGI datang, tidak ada alasan untuk tidak mempelajari ulang framework yang efisien

  • Saat benar-benar saya tanyakan ke Claude, ia menjawab, “daripada framework, lebih baik menulis kode SVG langsung”
    Percakapan seperti ini sendiri merupakan eksperimen yang menarik