- Agen LLM kuat dalam pembuatan kode dengan spesifikasi longgar, tetapi masih lemah dalam mematuhi kontrak API, arsitektur, DB, dan batasan ORM yang dibutuhkan backend kelas produksi
- Dengan spesifikasi OpenAPI yang sama, kebutuhan fungsional dikunci, lalu pengujian perilaku yang sama diterapkan pada 80 tugas greenfield dan 20 tugas implementasi fitur di 8 framework web
- Batasan nonfungsional dibagi ke dalam 4 dimensi: pemilihan framework, pola arsitektur, backend database, dan integrasi ORM, untuk memisahkan pengaruh kompleksitas struktural
- Constraint decay adalah fenomena ketika kinerja turun tajam seiring akumulasi kebutuhan struktural; pada tugas yang sepenuhnya ditentukan dengan konfigurasi tinggi, assertion pass rate turun rata-rata 30 poin
- Inti kegagalan ada pada cacat lapisan data, di mana penyusunan kueri yang salah dan pelanggaran runtime ORM mencakup sekitar 45% kegagalan logika agen
Masalah inti dan pengaturan evaluasi
- Agen LLM kuat dalam pembuatan kode otonom dengan spesifikasi longgar, tetapi kemampuannya untuk secara ketat mematuhi batasan struktural yang dibutuhkan perangkat lunak backend kelas produksi belum dievaluasi secara memadai
- Backend kelas produksi tidak hanya harus menyediakan endpoint yang mengikuti kontrak API, tetapi juga memenuhi kebutuhan di luar fungsi seperti pola arsitektur, integrasi database, dan lapisan ORM yang ditentukan
- Benchmark yang ada sering memberi penghargaan pada solusi yang benar secara fungsional tetapi arbitrer secara struktural, sehingga belum cukup menangkap kesulitan pengembangan backend multi-berkas yang memiliki batasan
- Penelitian sebelumnya terutama berfokus pada penyelesaian isu tertentu dalam codebase yang sudah ada, generasi tanpa batasan berbasis prompt bahasa alami, solusi satu berkas, atau penyelesaian skeleton code, dan belum membahas efek perubahan tingkat batasan struktural secara sistematis
- Dengan spesifikasi OpenAPI yang sama, kebutuhan fungsional dikunci dan pengujian perilaku end-to-end yang sama diterapkan pada semua kondisi untuk memisahkan pengaruh kompleksitas struktural
- Eksperimen terdiri dari 80 tugas pembuatan greenfield dan 20 tugas implementasi fitur di 8 framework web
- Batasan nonfungsional dibagi ke dalam 4 dimensi: pemilihan framework, pola arsitektur, backend database, dan integrasi ORM
- Pada kondisi dasar hanya diberikan spesifikasi API yang sama, sedangkan pada kondisi berbatasan ditambahkan persyaratan seperti clean architecture, PostgreSQL, dan SQLAlchemy
- Evaluasi menggunakan pengujian perilaku end-to-end bersama validator statis untuk memisahkan akurasi fungsional dan kepatuhan struktural
Hasil utama dan maknanya
- Constraint decay dikonfirmasi sebagai fenomena ketika kinerja agen turun besar seiring bertambahnya kebutuhan struktural
- Bahkan pada konfigurasi berkinerja tinggi, assertion pass rate turun rata-rata 30 poin saat berpindah dari kondisi dasar ke tugas yang sepenuhnya ditentukan; beberapa konfigurasi yang lebih lemah bahkan mendekati 0
- Bahkan dengan kontrak API yang sama, tingkat keberhasilan sangat berbeda menurut framework, dan agen bekerja lebih baik pada framework yang ringan dan eksplisit seperti Flask
- Di lingkungan yang sarat konvensi seperti FastAPI dan Django, kinerja rata-ratanya jauh lebih rendah
- Analisis kesalahan menunjukkan cacat lapisan data sebagai penyebab utama, dengan contoh khas berupa penyusunan kueri yang salah dan pelanggaran runtime ORM
- Cacat lapisan data diklasifikasikan sebagai penyebab inti yang memicu sekitar 45% kegagalan logika agen
- Memenuhi kebutuhan fungsional dan kebutuhan struktural secara bersamaan masih menjadi tantangan penting yang belum terselesaikan bagi agen pemrograman
- Pipeline evaluasi, kumpulan tugas, jejak eksekusi agen, dan skrip analisis tersedia di constraint-decay
1 komentar
Komentar Hacker News
Saya dulu sepenuhnya skeptis terhadap pembuatan kode dengan LLM, tetapi sekarang lebih dari 80% kode yang saya pakai di pekerjaan berasal dari kode hasil generasi
Meski begitu, batasannya juga sudah cukup jelas, mulai terlihat di beberapa proyek, dan tulisan ini tampaknya mengonfirmasi kecurigaan saya
Semakin kompleks tugasnya, semakin sering kita menambahkan spesifikasi Markdown, aturan, batasan pada skill, panduan gaya, kondisi batas, penanganan error, dan petunjuk optimisasi
Pada titik tertentu, ini terlihat seperti memindahkan kompleksitas dari dunia bahasa pemrograman yang lebih formal dan deterministik ke dunia bahasa alami yang informal dan non-deterministik
Peningkatan kecepatan menulisnya memang luar biasa, dan bisnis tentu melihat ini sebagai peningkatan produktivitas, tetapi ada biaya yang jelas, dan banyak orang tampaknya mengabaikannya
Tidak ada yang meninjau 100%-nya, dan bahkan kalau ditinjau pun sifatnya sangat subjektif
Perbedaan antara “ikuti pendekatan RESTful”, “kami memakai REST dan tidak memakai GraphQL”, dan “90% endpoint berorientasi resource tetapi sebagian tampak seperti RPC jadi abaikan saja” itu tidak jelas
Semuanya terlihat cukup konyol
Pada dasarnya kita seperti mengompilasi program yang penuh dengan undefined behavior, tetapi kebanyakan “terlihat seperti bekerja”
Bahwa bisnis menganggap ini sebagai peningkatan produktivitas terasa seperti kembali lagi ke masa ketika “produktivitas” diukur dengan baris kode per detik
Setelah codebase sudah melampaui tingkat yang bisa sepenuhnya diulang hanya dengan satu kali inferensi, karena seluruhnya tidak muat dalam 20% awal jendela konteks, harness eksekusi dan teknik patch kode menjadi jauh lebih penting
Pendekatan apply_patch yang OAI poles ke dalam model tampak sebagai pendekatan terbaik untuk codebase berukuran sangat besar
Pendekatan berbasis rentang baris atau cari-ganti sederhana akan runtuh di bagian tepi, dan untuk menangani kasus rumit seperti file cshtml dibutuhkan beberapa anchor ruang
Operasi prepare/commit ideal untuk mengulang konteks ambigu di banyak file besar sambil menyempurnakan anchor
LLM tidak bisa menciptakan sesuatu yang benar-benar baru
“Penelitian sistematis mengungkap fenomena peluruhan kendala pada agen coding berbasis LLM. Model saat ini unggul dalam generasi tanpa kendala, tetapi performanya menurun ketika harus mengikuti aturan arsitektur yang eksplisit. Bagi pengguna akhir, dikotomi ini berarti agen cukup dapat diandalkan untuk pembuatan purwarupa cepat, tetapi masih sulit dipercaya untuk pengembangan backend tingkat produksi.”
Kelemahan besar penelitian ini adalah karena masalah biaya, model frontier tidak diuji secara memadai, jadi angka performa spesifiknya perlu dibaca dengan hati-hati
Meski begitu, kesimpulan bahwa performa model menurun ketika perilaku dan arsitektur sama-sama harus benar tetap menarik dan layak terus diperhatikan
Jika hanya ada kebutuhan fungsional, ini semacam sintesis program, dan reinforcement learning bisa mengoptimalkannya dengan sangat kuat
Saat kebutuhan fungsional dan non-fungsional bercampur, pada dasarnya kita memberi model spesifikasi yang tidak lengkap, dan model harus menebak maksud pengguna sampai tingkat tertentu untuk mengisi kekosongan
Itulah sebabnya memasukkan contoh gaya kode yang diinginkan ke dalam prompt bisa sangat ampuh
Semakin banyak materi rujukan, semakin bergantung ia pada pengulangan hal-hal yang sudah muncul sebelumnya
Mungkin juga para penulis memberi perhatian lebih sedikit dan mengerahkan lebih sedikit usaha untuk penyuntingan pada bab-bab bagian belakang
Amazon memang dibanjiri volume semacam ini, tetapi LLM masih belum sampai pada tahap bisa menulis dengan baik
Ketika ia mengusulkan solusi yang tidak kompatibel lalu saya menambahkan konteks dan kebutuhan tambahan, ia cenderung terpaku pada arsitektur awal dan sulit beradaptasi
Kadang ia bahkan mencoba diam-diam menyelipkan perubahan demi rencana awalnya
Terasa seperti bagian besar dari ruang solusi yang mungkin menjadi tidak bisa dijangkau
Misalnya sekitar setahun lalu, ketika guardrail diterapkan pada generator gambar, semua orang mulai terlihat mirip, dan generator cerita mulai hanya memakai beberapa nama standar
Saya penasaran apakah hal seperti ini masih terjadi bahkan pada model frontier
Saya tidak terlalu tertarik pada analisis kelemahan model seperti ini. Dari pengalaman saya, saat model makin kuat dan upaya penalarannya ditingkatkan, banyak kelemahan hilang sepenuhnya
Terutama jika perilaku yang diinginkan dijelaskan dengan jelas, dan tidak mengejutkan bahwa tingkat kegagalan naik ketika kriteria penerimaan bertambah
Situasinya lebih buruk. Agen bukan hanya lebih kesulitan di bawah “kendala struktural”, tetapi juga jauh lebih buruk ketika kendala struktural itu sendiri harus diubah
Saat merancang sistem atau komponen, kita menetapkan ide-ide yang menjadi invariant
Sebagian invariant besar, seperti arsitektur utama, dan sebagian kecil, seperti pemilihan struktur data
Namun pada akhirnya akan datang saat kita ingin menambahkan fitur yang bertabrakan dengan invariant tersebut
Pada saat itu biasanya ada tiga pilihan: tidak menambahkan fitur itu, menumpangkan fitur tersebut di atas invariant dengan cara yang tidak elegan atau tidak efisien, atau kembali dan mengubah invariant-nya
Biasanya hanya satu dari ketiganya yang benar, dan setidaknya satu akan sangat salah hingga menghasilkan akibat buruk
Agen sangat buruk dalam mengenali kapan kendala harus diubah, bahkan ketika mereka sebenarnya bisa mengikuti kendala itu sendiri
Ini adalah salah satu batas antara pengenalan pola dan penalaran, dan bertentangan dengan klaim pemasaran tentang proses berpikir, LLM sama sekali tidak benar-benar bernalar
Semua upaya untuk membuatnya tampak seperti bernalar terasa lebih seperti usaha rekursif dari harness untuk memasukkan petir ke dalam botol
Ini mengingatkan pada makalah terbaru yang mendelegasikan tugas penyuntingan dokumen di berbagai bidang kepada LLM https://arxiv.org/abs/2604.15597
Dalam makalah itu, pemrograman dianggap sebagai satu-satunya bidang di mana sebagian besar LLM bisa melakukan tugas berjangka panjang tanpa menumpuk kesalahan dan merusak dokumen
Untuk makalah kali ini, saya baru membaca abstraknya, tetapi tampaknya ia menelaah pemrograman dengan lebih rinci dan menunjukkan fenomena serupa
Hanya saja, ini tampak lebih dekat ke “cakrawala gaya yang panjang” untuk kumpulan kendala struktural yang lebih besar daripada tugas berjangka panjang
Diskusi terkait: https://news.ycombinator.com/item?id=48073246
Makalah yang sangat menarik dan saya sepenuhnya setuju, tetapi menurut saya ini bukan cerita baru
Ekspektasi awal bahwa kita bisa begitu saja menjatuhkan solusi coding bergaya agen ke sebuah proyek dan melemparkan daftar tugas, lalu ia secara ajaib akan mengikuti kendala yang telah didefinisikan sebelumnya oleh proyek, memang agak meleset
Saya tidak percaya ada stack coding bergaya agen mana pun yang dalam kondisi default bisa melakukan ini
Agen tetap memerlukan mekanisme yang tepat agar bisa memahami konteks, kendala, dan tujuan secara stabil, dan melihat lab AI besar terus memperbarui alat, skill, dan proses menunjukkan bahwa ini masih area yang sedang berkembang
Lapisan tambahan ini mungkin jauh lebih menguntungkan daripada model murni dan konsumsi token
Saya rasa bahkan model terbuka seperti yang tampaknya diuji saat ini pun, jika dijalankan dengan benar, sudah bisa menghasilkan kode produksi yang mengikuti kendala yang diinginkan
Saya penasaran seperti apa kode produksi kalian dalam beberapa bulan terakhir
Saya sudah cukup banyak bereksperimen dengan coding bergaya agen berjangka panjang https://medium.com/@vishvananda/i-spent-2-billion-tokens-wri..., dan juga melihat bahwa memaksakan pola arsitektur tertentu justru menurunkan performa agen
Hasilnya sedikit lebih baik jika kendala dimasukkan sambil berjalan daripada ditambahkan belakangan
Ada efek samping yang saya sebut kalsifikasi, yaitu ketika suatu pola mulai muncul di codebase, agen akan terus mengikuti pola itu sampai mendominasi konteks dan menguatkan dirinya sendiri
Dalam codebase yang sudah ada, ini bisa menjadi kekuatan atau kelemahan tergantung kualitas kodenya
Begitu eksekusi codebase baru yang sejak awal menyertakan pedoman arsitektur selesai, sepertinya akan ada lebih banyak wawasan
Selain itu, model cukup lumayan dalam modularisasi jika diberi ruang untuk “merencanakan” implementasi, tetapi jarang sekali ia sendiri memutuskan bahwa abstraksi akan membantu di kemudian hari
Ini особенно terasa setelah beberapa iterasi pada codebase baru atau ketika dimasukkan ke codebase lama, dan sering berujung pada file raksasa
Saat pengguna menunjukkan hal ini, model bisa mengkritiknya dengan tepat, jadi cukup lucu ketika itu sebenarnya kode yang ia tulis sendiri
Ini terdengar seperti versi lain dari “semakin panjang chat, semakin kabur guardrail-nya”
Salah satu alasan kita tidak bisa memakai seluruh context window adalah karena di bagian akhir output tidak lagi mematuhi kendala atau guardrail
Padahal untuk membuat kode tingkat produksi secara andal, model harus punya kesadaran yang luas, dan ini cepat sekali memenuhi context window
Mirip seperti berkata, “ingat semua yang ada di 6 direktori ini lalu buat perubahan ini”, tetapi hanya dengan mengingat semuanya saja context window sudah penuh sehingga kemampuan untuk mengikuti kendala pun hilang
Hanya saja, pola kegagalannya mungkin akan bergeser menjadi terlalu fokus memuaskan linter sambil makin lama makin melupakan requirement
Pengulangan coba/gagal juga sama sekali tidak baik untuk konteks
Dalam riset ini digunakan bahasa bertipe dinamis seperti Python dan JS
Menurut pengalaman saya, codebase bertipe statis lebih mudah dipelihara bahkan bagi manusia, jadi mungkin juga lebih mudah bagi agen
Saat memakai Codex atau Claude Code pada kode Go, saya sudah tak terhitung kali melihat agen melakukan perubahan, menjalankan build untuk menemukan error, lalu memperbaikinya lagi
Model-model sekarang cukup baik dalam menangani tipe Python
Di Python, tipe statis yang kuat sudah menjadi opsi selama beberapa tahun, dan seharusnya itu saja yang jadi default
Disebut sebagai “pekerjaan yang mencakup 8 framework web”, jadi saya penasaran apakah ada yang punya pengalaman bahwa LLM lebih baik membuat HTML+CSS+JS murni daripada bekerja dengan framework yang sudah ada
Kombinasi paling mengesankan yang saya lihat belakangan ini adalah Razor Pages dengan progressive enhancement berbasis JavaScript
Dalam susunan ini, model-model terbaru cukup baik dalam menilai hal apa yang seharusnya terjadi di sisi server (
cshtml) dan apa yang seharusnya terjadi di sisi klien (js)Saya sarankan meluangkan waktu untuk lebih dulu merapikan beberapa bagian codebase ke bentuk yang idiomatis, lalu menandai file-file itu dengan @ sebagai file contoh
Ini bekerja jauh lebih baik daripada mencoba mengendalikannya lewat Markdown
Untuk hal seperti FastAPI hasilnya lumayan bagus, tetapi JavaScript tampak yang paling buruk
Bahkan ketika diberi instruksi dan contoh, ada kecenderungan untuk menulis banyak kode yang tidak perlu secara inline alih-alih memakai API yang sudah ditentukan