Apakah Kebersihan Kode Mempengaruhi Agen Coding? Studi Pasangan Minimal yang Terkontrol

 (arxiv.org)
1 poin oleh GN⁺ 3 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Evaluasi agen coding otonom selama ini terutama melihat tingkat keberhasilan tugas pada codebase tetap, tetapi studi ini mengukur secara terpisah apakah kebersihan kode itu sendiri mengubah biaya eksplorasi dan modifikasi
  • Disusun 6 repositori pasangan minimal dan 33 tugas berbasis pengujian tersembunyi, dengan arsitektur, dependensi, dan perilaku eksternal yang sama, tetapi hanya berbeda pada pelanggaran aturan SonarQube dan kompleksitas kognitif
  • Dengan Claude Code dan Claude Sonnet 4.6, tiap tugas dijalankan 10 kali di kedua sisi pasangan repositori, sehingga total dilakukan 660 eksperimen, dan agen tidak mengetahui sedang menangani sisi kode yang mana
  • Kebersihan kode tidak mengubah tingkat kelulusan, tetapi pada kode yang lebih bersih, metrik setara token turun 7~8% dan kunjungan ulang file berkurang 34%
  • Bukan hanya model atau prompt, kondisi codebase juga tetap menjadi variabel praktis yang menentukan biaya komputasi dan efisiensi eksplorasi agen

Pertanyaan riset dan perumusan masalah

  • Agen coding otonom sedang menyebar dengan cepat
    • Dalam survei terhadap 128.018 proyek GitHub pada 2026, jejak aktivitas agen ditemukan di 22~29% proyek bahkan sebelum genap satu tahun sejak peluncuran agen praktis pertama
  • Biaya menjalankan agen juga tidak kecil
    • Di SWE-bench Verified, satu tugas menggunakan rata-rata sekitar 4 juta token berdasarkan LLM frontier
    • Dalam total penggunaan, token input menyumbang porsi terbesar
  • Evaluasi sebelumnya pada benchmark seperti SWE-bench berfokus pada apakah tugas berhasil diselesaikan, dan studi yang lebih baru mulai mengukur penggunaan sumber daya bersama tingkat kelulusan
  • Perbandingan umum selama ini dilakukan dengan menahan codebase tetap lalu mengganti agen atau scaffolding
  • Studi ini melakukan kebalikannya: menahan agen dan tugas tetap, lalu hanya mengubah kebersihan codebase untuk dibandingkan

Kebersihan kode dan konstruksi pasangan minimal

  • Kebersihan kode diperlakukan sebagai kumpulan sifat yang terkait dengan kode yang mudah dipelihara
    • Mudah dibaca
    • Kompleksitas kognitif rendah
    • Helper terpisah dengan baik
    • Penamaan yang jelas
    • Sedikit dead code, logika duplikat, dan coupling yang tidak disengaja
  • Studi ini tidak memakukan kebersihan kode pada definisi formal yang ketat, melainkan memakai jumlah pelanggaran aturan analisis statis SonarQube sebagai proksi longgar
    • Alat yang digunakan adalah SonarQube Cloud Enterprise Edition
    • Set aturan yang dipakai adalah “default quality gate”
  • Repositori pasangan minimal disusun agar hanya kebersihan internalnya yang berbeda, sementara kondisi berikut disamakan
    • Bahasa dan framework yang sama
    • Dependensi yang sama
    • Pengujian yang sama atau cakupan pengujian yang setara
    • Perilaku eksternal yang sama
  • Kesetaraan perilaku dipandang tercapai jika, untuk input yang sama, output yang dapat diamati dari luar dan transisi state juga sama
    • Verifikasi aktual dilakukan dengan meluluskan test suite yang sama pada cakupan yang sama, atau pada pasangan pengujian yang mengoreksi perubahan yang tidak dapat diamati seperti refactoring

Pipeline pembuatan pasangan minimal: Slopify dan Vibeclean

  • Pasangan minimal dibuat dua arah
    • Slopify yang membuat repositori bersih menjadi lebih berantakan
    • Vibeclean yang merapikan codebase berantakan

  • Slopify

    • Mengubah codebase bersih menjadi versi yang seolah tumbuh tanpa code review atau linting
    • Targetnya bukan kode yang sengaja dirusak, melainkan versi sejarah alternatif saat analisis statis tidak digunakan
    • Tiga tahap dijalankan masing-masing oleh agen baru
      • Build: membangun repositori dan memastikan pengujian lulus, lalu menetapkan perintah di build instructions.md
      • Explore: menelusuri repositori dan menulis summary.md untuk tiap direktori yang akan dibersihkan
      • Transform: memasukkan pelanggaran aturan SonarQube ke direktori yang ditentukan, lalu menjalankan ulang pengujian setelah tiap pass dan menolak perubahan yang merusak
    • Kompleksitas kognitif ditingkatkan lewat inline helper, duplikasi logika per jalur, penambahan dead code, dan penggabungan beberapa modul ke satu file

  • Vibeclean

    • Merapikan codebase yang secara alami memiliki banyak pelanggaran aturan sambil mempertahankan perilaku eksternal
    • Daftar kerja agen adalah daftar isu yang terdeteksi analis, dan tiap isu terhubung ke cakupan kode
    • Cakupan perbaikan dibatasi pada masalah yang ditandai analis, dan redesain menyeluruh bukan tujuannya
    • Berjalan dalam dua tahap
      • Build: memeriksa perintah build dan pengujian lalu menetapkannya di build instructions.md
      • Clean: merapikan pelanggaran aturan analis secara mekanis per modul, lalu memverifikasi kesetaraan perilaku dengan pengujian setelah modul diproses
    • Melakukan penghapusan duplikasi string literal, penghapusan kode yang dikomentari, penggantian idiom koleksi legacy, dan penghapusan branch mati
    • Saat analis benar-benar menandai struktur besar, ia mengganti dispatch switch lebih dari 200 baris menjadi helper bernama, atau mengekstrak helper persistensi dari class 2.800 baris
    • Namun ekstraksi ini kadang hanya mendistribusikan ulang kompleksitas ke lebih banyak method alih-alih menghilangkannya, dan beberapa struktur terbesar tetap dibiarkan sebagai wontfix

Repositori benchmark dan desain tugas

  • Benchmark dibangun di atas Harbor framework v0.4.0
  • Total digunakan 6 repositori pasangan minimal
    • 3 berfokus pada Java, 3 berfokus pada Python
    • Beberapa repositori menyertakan sedikit kode dalam bahasa lain
    • Terdiri dari 3 repositori open source publik dan 3 codebase privat SonarSource
    • Pasangan privat berfungsi sebagai perlindungan terhadap hafalan jika LLM yang dievaluasi mungkin pernah belajar dari repositori publik
  • Metrik utama sisi bersih dan sisi berantakan untuk tiap repositori adalah sebagai berikut
    • sonar-sca*: isu 94 / 2.825, kepadatan isu 0,73 / 20,66, kepadatan kompleksitas kognitif 30,6 / 56,5
    • sonar-caas-poc*: isu 16 / 855, kepadatan isu 0,61 / 27,16, kepadatan kompleksitas kognitif 179,8 / 218,9
    • sonarcloud-codedatalake*: isu 199 / 1.319, kepadatan isu 4,36 / 34,39, kepadatan kompleksitas kognitif 34,0 / 216,5
    • commons-bcel: isu 694 / 2.711, kepadatan isu 12,60 / 49,46, kepadatan kompleksitas kognitif 102,8 / 108,3
    • genie: isu 152 / 1.262, kepadatan isu 1,28 / 10,81, kepadatan kompleksitas kognitif 22,2 / 23,5
    • ckan: isu 1.006 / 3.632, kepadatan isu 7,54 / 27,50, kepadatan kompleksitas kognitif 69,3 / 76,5
  • Desain tugas mengikuti tiga aturan
    • Melewati hotspot: tugas ditempatkan agar melintasi area kode dengan perbedaan besar dalam kepadatan isu dan kompleksitas kognitif di kedua sisi pasangan
    • Deskripsi yang dapat diamati secara eksternal: hanya memberikan input·output dan skenario contoh, tanpa menyebut nama file, fungsi, atau struktur internal
    • Pengujian permukaan publik: pengujian tersembunyi dijalankan melalui antarmuka yang diberikan aplikasi kepada pemanggil seperti CLI, route HTTP, dan library/API
  • Pembuatan tugas dibagi antara agen dan manusia
    • Agen membandingkan varian bersih dan varian berantakan lalu membuat peta perbedaan
    • Agen lain menulis rancangan tugas dan kelayakan pengujian
    • Manusia memilih, menyunting, dan mengkurasi rancangan yang tampak masuk akal dan menarik
    • Agen ketiga membuat instruksi aktual, pengujian permukaan publik tersembunyi, dan implementasi referensi untuk penggunaan internal
    • Implementasi referensi harus lulus pengujian tersembunyi di kedua repositori
    • Repositori sebelum diperbaiki tidak boleh lulus pengujian tersembunyi
    • Tugas yang masih tidak memenuhi syarat setelah dua iterasi ditulis ulang oleh manusia atau dihapus
  • Jumlah tugas akhir adalah 33, dibagi menjadi tiga trek
    • 13 tugas hotspot kognitif: melewati area kompleks berdensitas tinggi dalam satu method atau satu class
    • 14 tugas multi-modul: memerlukan perubahan lintas dua modul atau lebih
    • 6 tugas kalibrasi: kedua sisi melakukan tugas sederhana pada area yang sama untuk memeriksa apakah ada perubahan yang tidak terkait kebersihan

Pengaturan eksperimen dan metrik pengukuran

  • Semua eksperimen dilakukan dengan Claude Code menggunakan set alat default
  • Angka yang dilaporkan berasal dari eksekusi Claude Sonnet 4.6
    • Claude Haiku 4.5 juga dicoba pada set tugas yang sama, tetapi tingkat kelulusannya terlalu rendah sehingga sulit membaca perbedaan footprint dengan jelas, sehingga dikeluarkan dari hasil utama
  • Agen hanya membaca deskripsi tugas
    • Tidak menerima priming tambahan tentang kebersihan kode
    • Tidak mengetahui sedang bekerja pada sisi mana dari pasangan minimal
  • Tiap tugas dijalankan 10 kali di kedua sisi pasangan
    • Total eksperimen adalah 33 × 2 × 10 = 660
  • Tiap eksekusi dilakukan dalam sandbox terkontainerisasi
    • CPU, memori, penyimpanan, dan waktu dinding dibatasi
    • Akses ke registry paket publik diizinkan
    • Image dasar mencakup toolchain per repositori, cache build, dan layanan
    • Di dalam pasangan, yang berbeda hanya source tree yang di-mount ke /app
  • Ada 10 metrik yang dicatat
    • Tingkat kelulusan: proporsi eksekusi yang lulus pengujian tersembunyi pada status akhir
    • Token input: jumlah token yang dibaca model di semua turn, dengan isi file dan pengiriman ulang percakapan sebelumnya sebagai porsi terbesar
    • Token output: seluruh keluaran dari model dan subagen, termasuk prosa, kode, jejak penalaran, dan pemanggilan alat
    • Jumlah karakter penalaran: karena API Anthropic tidak mengekspos token penalaran secara terpisah, yang dihitung adalah karakter teks biasa dalam blok konten penalaran
    • Jumlah turn percakapan: total pertukaran agen-alat
    • Turn sebelum edit pertama: jumlah turn hingga modifikasi file pertama
    • Jumlah karakter sebelum edit pertama: jumlah karakter percakapan pada rentang yang sama
    • Jumlah file dibaca: jumlah file unik yang dibuka selama eksekusi
    • Kunjungan ulang file: jumlah pembacaan ulang file yang sebelumnya sudah dibaca dan diedit
    • Jumlah baris diubah: jumlah baris source yang diubah oleh patch akhir
  • Kunjungan ulang file muncul dalam alur seperti baca → edit → kemungkinan kerja lain → baca lagi
    • Studi ini menafsirkannya sebagai sinyal ketidakpastian terhadap edit sebelumnya, bukan sekadar eksplorasi yang luas
  • Karena metrik footprint agen bisa sangat bervariasi walau tugas yang sama diulang pada temperatur tetap, filter outlier diterapkan
    • Dalam tiap kombinasi (tugas, sisi), eksekusi yang menyimpang lebih dari 50% dari median 10 pengulangan dihapus sebelum dihitung rata-ratanya
    • Dalam praktiknya, 9,7% dari seluruh eksekusi dihapus
  • Angka tingkat dataset di-micro-average untuk 33 tugas
    • Untuk tiap metrik, rata-rata sisi bersih dan sisi berantakan per tugas dijumlahkan lalu dihitung perbedaan rasionya
    • Tingkat kelulusan, sebagai pengecualian, dilaporkan sebagai selisih absolut dalam poin persentase antara sisi bersih dan sisi berantakan

Hasil: berdampak pada biaya eksplorasi, bukan tingkat keberhasilan

  • Kebersihan kode tidak menghasilkan perubahan berarti pada tingkat kelulusan agen
  • Pada kode yang lebih bersih, metrik setara token turun 7~8%
  • Kunjungan ulang file turun 34%, menunjukkan bahwa kode yang lebih bersih dapat mengurangi biaya membaca ulang untuk tugas yang sama
  • Karena itu, kebersihan kode dapat dipandang sebagai sumbu tersendiri yang memengaruhi biaya eksekusi agen, bersama pilihan model, harness, dan prompt

Bacaan terkait

1 komentar

 
GN⁺ 3 jam lalu
Opini Hacker News

  • Ini pertanyaan yang menarik untuk diteliti, tetapi saya sangat skeptis terhadap desain eksperimennya
    Dalam eksperimen, mereka menggunakan Opus 4.6 untuk menyintesis codebase yang “diturunkan kualitasnya” atau “dirapikan”, lalu memakainya untuk perbandingan relatif
    Yang lebih buruk, mereka tidak mengontrol apakah pengujian aplikasi menjadi rusak
    “Tingkat kelulusan menilai status akhir agen berdasarkan kriteria pengujian tersembunyi yang kami tulis untuk setiap tugas. Kami tidak memeriksa apakah agen merusak pengujian yang tidak terkait yang sudah ada di repositori, dan meskipun solusi di sisi bersih maupun berantakan sama-sama lulus pengujian tersembunyi, keduanya bisa berbeda pada pengujian yang tidak dinilai”
    Jika kualitas keluaran akhir tidak dikontrol, kesimpulan tentang konsumsi token hampir tidak bermakna

    • Jika membandingkan proyek berantakan dan proyek yang terstruktur baik berdasarkan jumlah pengujian yang gagal, tingkat keberhasilan bisa condong ke codebase berantakan yang sejak awal kemungkinan besar memiliki cakupan pengujian dan ketangguhan yang lebih rendah
      Agar perbandingannya adil, perlu ditulis satu kumpulan pengujian yang berjalan pada kedua proyek dalam tiap pasangan
      Bukan berarti penelitiannya bagus, tetapi karena lulus pengujian tidak selalu berkorelasi dengan efektivitas agen, keputusan seperti itu bisa dipahami
    • Bahkan jika kesimpulannya valid, paling-paling itu hanya skenario terbaik untuk kode yang diturunkan kualitasnya
      Itu hanya menunjukkan situasi ketika secara fungsional tampak baik-baik saja, tetapi membutuhkan biaya token lebih besar untuk menyelesaikan pekerjaan
    • Jika kerusakan pengujian aplikasi tidak dikontrol, pada dasarnya ini penelitian yang tidak bernilai
      Kelelahan terhadap AI sudah lama membosankan, dan sekarang rasanya hanya menyakitkan

  • Dari pengalaman saya, perbedaan performa agen cukup besar antara codebase yang dipenuhi dead code, kode duplikat, jalur alternatif yang tidak terjangkau, abstraksi bocor, dan pola desain yang belum matang, dibandingkan codebase dengan alur data yang jelas serta enkapsulasi dan struktur yang bersih
    Pada kode buruk, semua model frontier harus melewati beberapa putaran code review, pemeriksaan kualitas, dan perbaikan; pada kode bagus, saya melihat hasilnya sering langsung tepat pada percobaan pertama atau kedua

    • Masalah seperti penghapusan dead code, duplikasi kode, dan kode yang tidak terjangkau yang disebut di atas sudah lama ditangani dengan linter deterministik di sebagian besar ekosistem bahasa
      Kita bisa meminta LLM menjalankan skrip yang memeriksa hal-hal ini, lalu memberlakukan skrip yang sama sebagai hook pre-commit
      Memasukkan konfigurasi semacam ini secara ketat ke semua codebase yang saya kerjakan adalah hal yang paling berdampak dalam coding berbasis agen
      Tulisan yang merinci beberapa linter yang saya pakai ada di sini: https://www.balajeerc.info/Use-Deterministic-Guardrails-for-...
    • Saya sudah cukup lama memakai alat-alat seperti ini, dan setiap kali diperlakukan seperti manusia, performanya tampak lebih baik
      Menurut saya agen memang pasti bekerja lebih baik pada codebase yang bersih daripada pada codebase besar yang kacau
      Sama seperti mereka bekerja lebih baik ketika punya spesifikasi yang tersusun baik dan akses ke dokumentasi
    • Saya juga merasakan hal serupa saat bekerja pada codebase yang berantakan
      Pada titik tertentu, pola-pola buruk itu mulai menular ke saya juga
    • Saya membacanya sambil mengangguk setuju, tetapi setelah memikirkan mengapa ini terasa seperti komentar yang buruk, saya sadar bahwa pernyataan anekdotal semacam ini berada di sisi berlawanan dari diskusi ilmiah
      Di sini ada makalah yang berusaha menjawab pertanyaan tersebut, sementara kesaksian anekdotal hanya memberi bias kepada pembaca dan tidak menambah nilai untuk menarik kesimpulan objektif tentang masalahnya
      Diskusi yang paling berguna adalah jika semua orang membaca makalahnya lalu mengkritik metodologi atau hasilnya
    • Ini juga lebih terasa seperti intuisi, tetapi karena saya sangat khawatir dan sering melakukan pass refactoring serta pembersihan kode, dan tidak pernah melewatkannya, sulit bagi saya untuk mengatakan dengan pasti apakah memang ada perbedaan performa
      Namun orang yang mengeluh bahwa LLM tidak begitu bagus umumnya tampak seperti tipe yang memiliki codebase berantakan

  • Trik yang menurut saya berhasil adalah, untuk Python, memberi instruksi refactoring seperti berikut
    “Refactor kode Python agar lebih Pythonic. Misalnya, kurangi class dan singleton, terutama jika itu meningkatkan kecepatan. Kode Python harus mengikuti standar organisasi kode yang diharapkan dari kode paket Python open-source populer tanpa regresi performa benchmark”
    Untuk kode Rust, saya pernah memakai variasi ini
    “Codebase Rust di /src sudah membengkak menjadi beberapa file yang masing-masing lebih dari 1.000 baris. Refactor codebase Rust agar sesuai dengan standar organisasi kode yang diharapkan dari kode Rust open-source populer tanpa regresi performa benchmark”
    Prompt seperti ini tampaknya meningkatkan performa agen karena a) kode ditata ulang secara logis dan b) nama file memberi petunjuk semantik tentang lokasi kode terkait
    Dalam file gemuk berisi 5.000 baris, agen harus membaca banyak potongan untuk mencari kode terkait, sehingga tidak efisien
    Performa benchmark juga biasanya membaik setelah refactoring; terutama pada Rust yang dikompilasi, mungkin itu kebetulan, tetapi tidak ada yang perlu dikeluhkan

    • Benar. Banyak perbaikan mudah muncul hanya dengan meminta alat coding berbasis agen merapikan codebase, melakukan refactoring terarah, dan menerapkan prinsip SOLID serta praktik baik
      Pada dasarnya, alat coding berbasis agen cenderung enggan menghapus kode. Bahkan ketika diminta menghapus, ia sering berusaha keras meninggalkan kode lama atau menambah kompleksitas agar kode itu tetap bisa dipanggil
      Jika sekadar sedang membuat prototipe, ini sangat menyebalkan, karena akhirnya banyak dead code menumpuk dan menimbulkan kebingungan saat nanti ingin menambahkan fitur
      Setelah menyadari ini, kita cukup memintanya menyingkirkan legacy
      Menjaga codebase tetap bersih mendorong AI melakukan hal yang benar. Jika ada banyak pengujian, ia akan menambahkan lebih banyak saat membuat fitur baru; jika ada dokumentasi, ia akan memperbaruinya tanpa perlu diminta
      Seiring membaiknya code harness, hal-hal seperti ini akan makin terintegrasi, dan orang yang kurang berpengalaman dalam prompting pun akan lebih mudah mendapatkan hasil yang layak
    • Meminta penerapan prinsip YAGNI juga tampaknya efektif untuk mengecilkan codebase
      Biasanya saya minta ia meninjau dulu dan membuat daftar item tinjauan, lalu saya menelusuri tiap item bersamanya untuk memutuskan ya/tidak atau mengusulkan perbaikan tambahan
    • Saya sangat memahami pendekatan bertahap, tetapi melakukan ini sekaligus pada seluruh codebase produksi apa pun tampak sangat berbahaya
      Terutama jika tidak ada pengujian end-to-end yang cermat untuk seluruh sistem
    • Sekadar mengatakan “refactor codebase ini” juga bekerja cukup baik
      Lagi pula, aturan gaya kode sudah saya masukkan ke CLAUDE.md
    • Kata yang Anda cari adalah idiomatis

  • Pendekatan berupa “pipeline agen yang merapikan repositori berantakan” terlihat buruk, dan itu saja sudah cukup untuk membantah keseluruhan riset ini
    Sepertinya separuh dari pasangan minimal dalam pekerjaan ini dibuat dengan cara seperti itu
    Saya sama sekali tidak akan memercayai kesimpulan yang harus berasumsi bahwa repositori yang “dirapikan” oleh AI benar-benar mewakili codebase yang baik

    • Saya penulis pertama. Ada satu hal yang ingin saya perjelas
      Di sini, “bersih” bukan berarti kami sekadar meminta agen menulis kode yang lebih baik
      Kami memberikan daftar 50–100 pelanggaran aturan static analyzer beserta jumlah baris kode, lalu meminta pelanggaran itu dihapus
      Setelah itu kami memeriksa apakah pelanggaran aturan tersebut sudah terselesaikan
      Menulis ulang kode dengan LLM untuk menghapus pelanggaran semacam ini adalah praktik yang cukup diterima
      Pendekatan one-shot berbasis LLM milik Sonar yang sudah ada [1] telah beroperasi lebih dari setahun, dan pendekatan agentic terbaru [2] juga melakukan tugas yang sama dengan cukup baik
      [1] https://www.sonarsource.com/solutions/ai/ai-codefix/
      [2] https://www.sonarsource.com/products/sonarqube/remediation-a...
    • Kalau repositori bersih yang diacak-acak oleh AI, apakah Anda akan memercayainya?

  • Saya rasa tentu saja pasti berpengaruh
    Tidak ada model yang bisa memuat seluruh codebase nyata ke dalam konteks, dan ia harus menelusuri kode seperti manusia
    Caranya adalah mencari dan membaca file
    Jika file berada di lokasi yang diperkirakan dan dinamai dengan nama yang kemungkinan pertama kali dicari oleh model atau manusia, maka ia akan ditemukan pada percobaan pertama; jika tidak, dibutuhkan pencarian lebih dalam dan beberapa kali percobaan

    • LLM tidak perlu membawa seluruh codebase di dalam konteks
      Cukup melihat semua path, mengabaikan area yang sudah ditangani, lalu berpindah ke path berikutnya
      Ini cukup mirip dengan cara developer bekerja

  • Saya juga melihat hasil serupa dalam pekerjaan sejenis yang sedang berlangsung di NJIT. Kami menyebutnya penularan kualitas kontekstual
    Bagian yang menarik di sini adalah situasi nyata yang umum di industri: codebase dengan kualitas campuran, codebase yang mencampur pola kode legacy dengan pola “baik” yang lebih baru sehingga agen bingung memahami konvensinya, dan semacamnya
    Desain pasangan minimal sebenarnya merupakan salah satu kekuatannya, karena berusaha memisahkan faktor kebersihan dari faktor lain seperti struktur, dependensi, dan pengujian, dibanding sekadar membandingkan antar-repositori
    Namun penggunaan kode “dibuat berantakan” oleh LLM agak patut dipertanyakan, karena bukan cara mekanis atau dipandu manusia
    Kritik terbesar, seperti sudah ditunjukkan dengan tepat oleh orang lain, adalah pilihan untuk tidak memeriksa seluruh rangkaian pengujian. Klaim “kesetaraan perilaku” hanya sevalid pengujian dan cakupannya
    Hipotesis ini meyakinkan karena dua hal. 1) LLM meniru apa yang dilihatnya di codebase, jadi masuk akal bahwa sampah masuk, sampah keluar 2) Ini cocok dengan intuisi yang dirasakan banyak engineer selama 1–2 tahun terakhir saat menggunakan model-model ini
    Greenfield hampir selalu lebih mudah daripada bergabung ke codebase yang sibuk, dan kekacauan muncul dari integrasi kompleks serta pemeliharaan sistem dengan tujuan legacy

  • Sekalipun agen belajar menavigasi stub dan kode WET yang ditinggalkannya sendiri, apakah kita benar-benar menginginkan codebase yang tidak bisa diikuti manusia untuk memahami apa yang sebenarnya terjadi?

    • Sekalipun agen menangani semuanya, bahasa Inggris menjelaskan apa yang dilakukan kode secara tidak akurat
      Karena itu, secara pribadi saya setidaknya ingin kode bercerita lewat kode tentang apa yang dilakukannya
    • Saya justru pernah melihat DRY didorong terlalu jauh
      Meski ada logika di dua fungsi kecil yang bisa diekstrak menjadi helper bersama, programmer manusia terkadang tidak melakukannya karena tahu abstraksi itu akan berantakan dan mudah rusak begitu salah satunya perlu sedikit diubah

  • Menarik melihat hal ini dikuantifikasi
    Struktur yang bersih tampaknya menurunkan beban kognitif baik bagi manusia maupun agen, sehingga ini menjelaskan mengapa penamaan dan modularisasi lebih penting daripada yang mungkin kita kira

    • Menurut saya kualitas kode pada akhirnya harus didefinisikan dari seberapa mudah kode dapat diubah dengan benar
      Sulit dikuantifikasi, tetapi itulah yang pada akhirnya coba ditangkap oleh semua metrik kualitas kode
      Dilihat dari standar itu, selama metrik kualitas kode yang digunakan masuk akal, kesimpulannya tidak terlalu mengejutkan
      Jika metrik kualitas itu baik dalam konteks agen coding, maka hasil yang diharapkan memang seperti ini

  • Banyak token dipakai untuk menjelajahi kode: mencari kode atau mengikuti titik pemanggilan, dalam proses membangun konteks yang cukup untuk menyelesaikan tugas
    Jika agen diberi suatu bentuk akses LSP, dan untuk monorepo disediakan panduan hierarkis lewat file seperti AGENTS.md, penggunaan token untuk eksplorasi bisa sangat dikurangi
    Namun codebase yang tersebar pada akhirnya tetap membutuhkan suatu bentuk eksplorasi untuk menyelesaikan setiap tugas
    Dan eksplorasi ini bukan sekadar penggunaan token. Di setiap langkah, latensi LLM, prefill, decoding, output yang diparsing agen, pemanggilan tool, respons tool, lalu perjalanan pulang-pergi kembali ke LLM berulang terus
    Sebagian bisa dilakukan paralel, tetapi dalam praktiknya kebanyakan bersifat sekuensial sehingga tugas menjadi cukup lambat
    Untuk menggunakan agen secara efisien, lokalitas dan struktur adalah kuncinya. Context window selalu terbatas, dan perhatian di dalamnya juga tidak selalu konsisten

  • Dari pengalaman saya, semua hal yang memengaruhi engineer juga memengaruhi agen
    Abstraksi yang baik, metode berukuran wajar, penamaan yang baik, struktur internal layanan dan antarlayanan yang berprinsip, unit test, semuanya termasuk
    Hal-hal ini secara historis merupakan pekerjaan engineer, dan ditujukan agar orang lain lebih mudah berkontribusi pada kode
    Sekarang, bukan hanya orang lain, tetapi agen lain juga menjadi lebih mudah berkontribusi pada kode