nokode - Jika LLM Bisa Melakukan Semuanya, Mengapa Kita Harus Menulis Kode? (Eksperimen Aplikasi Web)

• Eksperimen membangun server web tanpa logika aplikasi sama sekali, sehingga LLM menangani semua permintaan
  • Server hanya menerima permintaan HTTP lalu bertanya ke LLM “apa yang harus dilakukan?”, dan LLM mengerjakan sisanya
• Server menjalankan fungsi CRUD hanya dengan tiga alat: database, webResponse, dan updateMemory
• LLM secara mandiri melakukan perancangan skema SQL, pembuatan HTML·JSON, hingga penerapan umpan balik, lalu mewujudkan aplikasi manajemen kontak dasar
• Kecepatan respons 30~60 detik, biaya 100~1000 kali lebih tinggi dibanding aplikasi web tradisional, serta ada masalah konsistensi UI dan memori
• Meski begitu, eksperimen ini menunjukkan kemungkinan membuat aplikasi CRUD lengkap yang berjalan tanpa kode, sehingga mengisyaratkan bahwa kode itu sendiri bisa jadi hanyalah konsep transisional

---

Latar belakang

• Berawal dari gagasan khayalan (Shower Thought) bahwa “suatu hari nanti kita tidak perlu lagi menulis kode”
  • Di masa depan, LLM mungkin dapat memproses input secara real-time dan menghasilkan video 120fps, sehingga komputasi murni berbasis niat tanpa aplikasi maupun kode menjadi mungkin
• Dalam kenyataannya ini masih berada di ranah fiksi ilmiah, tetapi sebagai eksperimen akhir pekan, penulis memutuskan untuk menguji langsung sejauh mana hal itu mungkin dengan teknologi saat ini
• Hipotesis eksperimen ini sejak awal memang memperkirakan kegagalan
  • Saat sebagian besar AI berfokus pada arah menghasilkan kode (misalnya Claude Code, Cursor, Copilot, dll.),
    proyek ini dibuat untuk menguji sudut pandang lain: “bagaimana jika pembuatan kode dihilangkan sepenuhnya?”
• Hasilnya, dibuatlah server HTTP tanpa route, controller, maupun business logic sama sekali, yang bekerja dengan menanyakan ke LLM untuk setiap permintaan: “apa yang harus dilakukan?”
• Tujuan eksperimen ini adalah membuktikan “seberapa jauh sebenarnya masa depan itu masih berada”

Ringkasan proyek

• nokode adalah eksperimen yang menguji struktur di mana semua permintaan ditangani oleh LLM, dengan membangun server web tanpa logika aplikasi
  • Server hanya menerima permintaan HTTP lalu bertanya ke LLM “apa yang harus dilakukan?”, dan LLM mengerjakan sisanya
• Tujuannya adalah memverifikasi apakah LLM bisa menjalankan logika aplikasi secara langsung tanpa menghasilkan kode lebih dulu
• Objek eksperimennya adalah aplikasi manajemen kontak (contact manager), yang mencakup fungsi CRUD dasar (input, lihat, ubah, hapus)

Konfigurasi sistem

• Backend hanya terdiri dari 3 alat
  • database: menjalankan SQL di SQLite, dan LLM merancang sendiri skemanya
  • webResponse: menghasilkan respons dalam format yang sesuai seperti HTML, JavaScript, JSON, dan sebagainya
  • updateMemory: menyimpan umpan balik pengguna dalam Markdown untuk dirujuk pada permintaan berikutnya
• Sebagai contoh, permintaan ke /contacts menghasilkan halaman HTML, sedangkan permintaan ke /api/contacts menghasilkan respons JSON
• Setiap halaman menyertakan widget umpan balik, sehingga permintaan seperti “buat tombolnya lebih besar” atau “ganti ke tema gelap” bisa langsung diterapkan

Hasil eksperimen

• Secara fungsional berhasil berjalan
  • Pengiriman formulir, penyimpanan data, tampilan UI, dan respons API semuanya berjalan normal
  • Bahkan tanpa contoh, LLM dapat menghasilkan skema database yang sesuai, SQL yang aman, API bergaya REST, layout responsif, validasi formulir, dan penanganan error
• Masalah performa
  • Membutuhkan 30~60 detik per permintaan, sehingga 300~6000 kali lebih lambat dibanding aplikasi web biasa (10~100ms)
  • Biaya $0.01~0.05 per permintaan, sehingga 100~1000 kali lebih mahal
  • Ada ketidakkonsistenan warna dan layout UI, tidak mampu mengingat status sebelumnya, dan kesalahan langsung terjadi jika SQL yang dihasilkan salah
  • Upaya optimasi prompt seperti “⚡ THINK QUICKLY” justru memperlambat

Kesimpulan dan implikasi

• LLM memang memiliki kemampuan untuk menjalankan logika aplikasi secara langsung
• Permasalahannya terletak pada keterbatasan performa seperti kecepatan, biaya, konsistensi, dan keandalan
• Namun, keterbatasan ini lebih merupakan wilayah perbaikan kuantitatif daripada masalah kualitatif
  • Kecepatan inferensi meningkat sekitar 10 kali setiap tahun
  • Biaya terus menurun
  • Perluasan panjang konteks berpotensi memperbaiki memori
  • Tingkat kesalahan juga menunjukkan tren menurun
• Pada akhirnya, era “AI menulis kode” mungkin justru lebih jauh daripada era “AI mengeksekusi langsung”
• Saat ini yang tersisa hanyalah kode tingkat infrastruktur seperti konfigurasi HTTP, definisi alat, dan koneksi DB,
  yang menunjukkan kemungkinan transisi jangka panjang menuju “komputasi yang hanya terdiri dari niat dan eksekusi”

Cara menjalankan

• Setelah npm install, atur penyedia LLM dan API key di file .env
• Jalankan npm start lalu akses http://localhost:3001 (permintaan pertama membutuhkan 30~60 detik)
• Dengan mengubah prompt.md, jenis aplikasi atau fiturnya dapat diganti
  • Anda bisa mencoba berbagai rute seperti /game, /dashboard, /api/stats
  • Masukkan umpan balik seperti “make this purple”, “add a search box” untuk langsung menerapkannya
• Biaya per permintaan berada di kisaran $0.001~0.05, tergantung model
• Dirilis dengan lisensi MIT

[aer0700]

Persoalannya mungkin sampai sejauh mana komputasi bisa menjadi lebih cepat dan murah.
Jika di masa depan server rata-rata menjadi 100 ribu kali lebih cepat daripada sekarang, tetapi biaya operasional maupun biaya pemasangannya tetap sama, itu juga tampaknya bisa menjadi pendekatan yang tepat.
Seiring komputasi menjadi lebih murah, seperti dulu kita beralih dari bahasa mesin ke C, lalu dari C ke node js atau Python, mungkin ke depannya kita juga akan beralih ke llm.
Banyak hal akan berubah, dan menurut saya itu akan cukup menarik. Akan muncul banyak peluang juga.

[GN⁺]

Opini Hacker News

• Saya juga punya pemikiran serupa

  1. Jika pembuatan kode sepenuhnya diotomatisasi dan setiap pencarian Google menghasilkan halaman kustom secara real-time, bukankah manusia tidak perlu lagi membuat situs web? Pada titik itu, “pengembangan web” mungkin akan lebih mirip perancangan niat (intent-shaping) daripada coding
  2. Saya juga tidak setuju dengan klaim bahwa chat adalah bentuk ideal antarmuka pengguna. Bahasa alami itu fleksibel, tetapi lambat, ambigu, dan membebani kognisi. Mungkin sistem berbasis LLM akan membutuhkan model UI baru yang menggabungkan percakapan dan interaksi terstruktur

• Saya pertama kali memikirkan ini saat ChatGPT 3.5 muncul
  Suatu hari AI mungkin bisa sepenuhnya menggantikan program, tetapi inti sebenarnya adalah menemukan abstraksi (abstraction) yang tepat
  Misalnya, seperti perpindahan dari CVS ke Git yang membuka era microservices, abstraksi yang baik punya kekuatan untuk mengubah masalah secara mendasar
  Agar LLM bisa menemukan abstraksi semacam ini sendiri, ia perlu belajar lewat interaksi jangka panjang dengan dunia nyata

• Jika ditambahkan alat yang memungkinkan LLM mengedit file kode secara langsung, kecepatan respons dan konsistensi tampaknya akan meningkat besar
  Kode pada akhirnya akan berperan seperti penyimpanan memori (memory)
  Mengirim permintaan HTTP langsung ke LLM mirip cache miss, dan mekanisme umpan balik yang memicu pembaruan kode juga bisa dipertahankan

  • Ini hanya eksperimen sederhana, dan tujuannya adalah menunjukkan bahwa masih ada banyak bottleneck
    Masih banyak ruang untuk optimasi, tetapi secara realistis metode coding tradisional sepertinya tetap lebih efisien
  • Struktur seperti ini mirip menanam benih (seed), yaitu mendefinisikan arah pertumbuhan dan batasannya
  • Saya ingin melihat seseorang membangunnya sendiri

• Ini terdengar seperti pertanyaan, “jika perilaku non-deterministik dimungkinkan, mengapa harus bersikeras deterministik?”
  Tetapi kebanyakan orang mungkin tidak menginginkan webapp yang bekerja berbeda setiap saat

  • Sebenarnya, yang diinginkan orang bukanlah “webapp” itu sendiri, melainkan solusi pemecahan masalah (solution)
    Kode deterministik punya keterbatasan dalam menangani masalah yang kompleks, dan pendekatan yang fleksibel seperti manusia mungkin lebih cocok
  • LLM saat ini pada dasarnya masih terbatas pada output teks dan hampir tidak punya memori jangka panjang
    Tetapi di masa depan LLM akan memiliki kemampuan output dan penyimpanan yang lebih kaya
    Misalnya, LLM bisa langsung membuat tautan yang saat diklik akan melakukan kueri ulang secara internal, atau bekerja dengan mengelola database sementara
  • Maksud saya bukan mengatakan bahwa perilaku non-deterministik itu baik, tetapi menunjukkan jarak antara masa kini dan era post-code
  • Sebenarnya, perangkat lunak masa kini juga tidak sepenuhnya deterministik
    Pengalaman pengguna terus berubah karena update otomatis, A/B testing, perubahan UX, dan sebagainya
  • Jika temperature diatur ke 0 dan LLM menyimpan pengaturan ke file lokal, kita juga bisa membuat aplikasi deterministik

• Menariknya, pendekatan seperti ini bisa berjalan hanya dengan context window tanpa alat tambahan
  Pada Juli 2025 saya sempat membuat POC

• Eksperimen ini dengan baik menunjukkan bagaimana konsep kode boilerplate bisa berubah
  Jika beberapa instance dijalankan bersamaan di sandbox dan hasil terbaik dipilih lewat evaluasi internal, itu menjadi semacam meta reinforcement learning
  Namun menerjemahkan niat pengguna ke output deterministik itu sulit, dan sebaliknya aplikasi tradisional kurang fleksibel
  Pada akhirnya, kuncinya adalah bagaimana mengimplementasikan evaluasi niat (intent evaluation) secara stabil

  • Tetapi ada risiko model menjadi overfit terhadap metode evaluasi internal
    Membuat metode evaluasi yang baik sendiri sama rumitnya dengan membuat model AI

• Menangani permintaan dengan cara tradisional jauh lebih hemat biaya daripada langsung memakai LLM
  Secara kasar, menghasilkan 10 token dengan model 7 miliar parameter memerlukan lebih dari 100 GFLOPs
  Pemborosan listriknya besar

  • Tetapi saya jadi berpikir, bukankah biaya energi dari tenaga kerja manusia juga perlu dimasukkan ke perhitungan?
    Jika bekerja di enterprise IT, inefisiensi manusia juga tidak kalah besar
  • Arah industri tidak selalu sejalan dengan optimasi
    Bahkan inefisiensi pun bisa menjadi tren
  • Meski begitu, pendekatan membuat prototipe cepat (V1) dengan LLM, lalu setelah product-market fit terkonfirmasi mengoptimalkannya dengan kode tradisional, tetap valid

• Mungkin saja cukup menaruh LLM di port 443 lalu menyuruhnya, “kamu adalah server HTTPS sekaligus app server” ;)

• Apakah kita benar-benar perlu webapp? Bukankah cukup berbicara dengan komputer lewat suara?
  “Tunjukkan foto yang kuambil saat liburan tahun lalu, hapus awannya, lalu kirim ke temanku”
  “Setel timer olahraga, tapi jangan masukkan jumping jack”
  “Buatkan beat techno gaya Detroit”
  “Carikan pasangan kencan untuk malam ini, saya lebih suka rambut hitam”
  Saya membayangkan dunia di mana semua hal diproses lewat ucapan seperti itu

  • Tetapi otomatisasi semacam ini bisa melemahkan agensi manusia
    Pada akhirnya umat manusia mungkin akan terbelah antara mereka yang menerimanya dan mereka yang menolaknya
    Tanda-tandanya sudah terlihat, misalnya pada kebangkitan kembali piringan hitam vinyl
  • Antarmuka suara bukan jawaban untuk semua komunikasi
    Bahkan antarmanusia pun sering kali teks lebih disukai
  • Minggu ini saya juga membuat aplikasi manajemen pengetahuan pribadi dengan WebSpeech yang menerima input suara lalu membaca dan mengedit file org-mode dan logseq
    Bisa untuk to-do, belanja, sampai manajemen jadwal, dan sepenuhnya dikustomisasi sesuai kebutuhan saya
  • Masa depan seperti ini sering dibahas dalam fiksi ilmiah
    Tugas kompleks bisa cukup diekspresikan lewat suara, tetapi untuk pekerjaan sederhana yang berulang UI lebih efisien
    Misalnya saat mengatakan “belikan saya celana”, untuk memilih satu dari 30 hasil pada akhirnya tetap diperlukan antarmuka visual

• Saya juga mengunggah PoC serupa ke GitHub
  Pada tahap awal, model ‘desain’ yang lambat digunakan untuk membuat tema aplikasi dan skema DB, lalu model yang lebih cepat menangani respons setelahnya
  Saya mencoba menaruh logika di DB dengan PostREST, tetapi kegagalan pembuatan skema dan kueri yang salah terlalu sering terjadi
  Saya menjaga konsistensi UI dengan library CSS, dan membuatnya mengingat halaman sebelumnya
  Pendekatan seperti ini tampaknya bisa dimanfaatkan sebagai App Bench untuk mengevaluasi apakah LLM mampu membuat aplikasi lengkap dalam sekali jalan