- Bahkan pada bug yang bisa diselesaikan hanya dengan perubahan minimal, model cenderung menulis ulang seluruh fungsi, menambahkan logika pendukung, hingga mengubah signature, sehingga mudah menghasilkan diff besar
- Dalam pekerjaan brown-field yang mempertahankan struktur yang sudah ada, lolos pengujian saja tidak cukup; seberapa sedikit yang diubah juga harus dilihat agar kemudahan review dan keamanan perubahan tetap terjaga
- Berdasarkan 400 problem BigCodeBench yang dirusak secara terprogram, over-editing dikuantifikasi dengan Levenshtein berbasis token, relative patch score, dan Added Cognitive Complexity
- Kecenderungan penulisan ulang berlebihan terkonfirmasi pada model coding terbaru secara umum; Claude Opus 4.6 kuat dalam kombinasi akurasi dan perubahan minimal, sementara GPT-5.4 relatif menonjol dalam over-editing
- Prompt yang secara eksplisit meminta pelestarian kode asli terutama mengurangi diff pada model penalaran, dan di antara pendekatan pelatihan, RL memberikan hasil paling seimbang dengan mempelajari perilaku edit minimal tanpa menurunkan performa coding umum
Masalah Over-Editing
- Over-Editing merujuk pada fenomena ketika model mengubah bahkan struktur kode secara besar-besaran, melampaui cakupan perubahan minimal yang diperlukan untuk memperbaiki bug
- Bahkan pada bug off-by-one sederhana yang cukup diperbaiki dengan mengubah
range(len(x) - 1) menjadi range(len(x)), model bisa melakukan perubahan berlebihan seperti menulis ulang seluruh fungsi dan menambahkan fungsi bantu atau logika validasi
- Dalam contoh, GPT-5.4 melakukan pemeriksaan
None, konversi np.asarray(dtype=float), masking finite-value, validasi ukuran array, perubahan signature pemanggilan curve_fit, hingga penggantian logika plotting; pengujian memang lolos, tetapi menghasilkan diff besar
- Dalam pekerjaan brown-field yang menangani codebase yang sudah ada, lebih penting memperbaiki masalah sambil tetap mempertahankan kode yang sudah dipahami tim dan ditulis dengan sengaja
- Berbeda dengan green-field yang dibangun dari nol, perubahan yang tidak menghormati struktur yang ada membuat reviewer sulit memahami apa yang berubah dan alasannya
- Jika seluruh fungsi ditulis ulang, kode menjadi lebih sulit dikenali dan juga lebih sulit menilai keamanan perubahannya
- Standar “asal lolos pengujian” sulit menangkap masalah ini
- Over-Editing bukan kegagalan akurasi, melainkan kegagalan kesetiaan edit, sehingga sering tidak terlihat dalam test suite
- Semakin banyak kode yang dihasilkan, semakin besar pula beban review, dan kompleksitas yang tidak perlu dapat terakumulasi sehingga kualitas codebase berpotensi menurun secara diam-diam
Cara Mengukur Over-Editing
- Untuk membuat dataset yang memiliki jawaban perubahan minimal yang jelas, 400 problem BigCodeBench dirusak secara terprogram untuk membentuk set evaluasi
- Alih-alih menyuntikkan bug dengan LLM lain seperti pada benchmark yang ada, penelitian ini mengontrol perubahan secara rinci, misalnya mengubah
< menjadi <=, + menjadi -, atau True menjadi False
- Setiap sampel yang dirusak divalidasi agar tetap valid secara sintaksis dan benar-benar merusak test case terkait, dan perbaikan yang benar dirancang hanya berupa pembalikan kerusakan tersebut sehingga menjadi perubahan minimal
- Berkat susunan ini, evaluasi dapat melihat bukan hanya apakah model memperbaiki bug, tetapi juga seberapa banyak perubahan tambahan yang dibuat saat memperbaikinya
- Ukuran patch relatif dihitung dengan membandingkan jawaban acuan dan keluaran model terhadap input yang sudah dirusak
- Semakin banyak perubahan tambahan di luar pemulihan jawaban yang benar, semakin buruk skornya
- Kode terkait tersedia di repositori GitHub
Metrik Pengukuran
-
Levenshtein Distance berbasis token
- Alih-alih Levenshtein berbasis karakter yang umum, digunakan varian berbasis token Python
- Kode dipecah dengan tokenizer Python ke unit sintaks atomik seperti
def, add, (, a, ,, b, ), lalu jarak dihitung di atas urutan token tersebut
- Jika
def add(a, b): diubah menjadi def someotherfunctionname(a, b):, jarak berbasis karakter adalah 19, tetapi jarak berbasis token menjadi 1 karena dianggap hanya satu identifier yang berubah
- Nilainya dinormalisasi dengan jumlah total token agar tetap bisa dibandingkan meski panjang fungsi berbeda
-
Relative patch score
- Keluaran model dan jawaban acuan tidak dibandingkan secara langsung; keduanya sama-sama dibandingkan terhadap input yang dirusak
- Edit yang mengembalikan solusi rusak ke solusi asli adalah perubahan minimal yang sesungguhnya, dan metrik ini mengukur seberapa dekat edit buatan model dengan itu
- Semakin mendekati 0 nilainya, semakin mirip patch model dengan perubahan minimal yang sebenarnya
-
Added Cognitive Complexity
- Selain Cyclomatic Complexity, digunakan juga Cognitive Complexity, yang lebih baik merefleksikan tingkat kesulitan membaca
- Metrik ini memberi penalti pada nesting, rekursi, operator logika majemuk, dan alur kontrol yang tidak intuitif; struktur seperti
if, loop, dan try/except meningkatkan kompleksitas karena pembaca harus melacak lebih banyak status
- Pada contoh, kode dengan loop dan conditional bertingkat memiliki Cognitive Complexity sebesar 6
- Karena kerusakan kali ini hanya mengubah nilai dan tidak menyentuh struktur, perbaikan yang benar seharusnya selalu memiliki Added Cognitive Complexity 0
- Jika kompleksitas meningkat pada keluaran model, berarti ada kode tambahan yang tidak diminta; nilai di bawah 0 juga dianggap tidak diinginkan karena menunjukkan penyederhanaan yang tidak perlu
Apakah model benar-benar melakukan Over-Edit?
- Over-Editing terkonfirmasi bahkan pada model frontier terbaru
- Baik model penalaran maupun non-penalaran menunjukkan perbedaan antara Pass@1 dan tingkat perubahan minimal
- Kemampuan memperbaiki dengan benar saja tidak cukup untuk menilai apakah edit dilakukan secara setia
- Dalam perbandingan model penalaran, Claude Opus 4.6 menunjukkan kombinasi terbaik
- Pass@1 tertinggi di 0.912, dengan Levenshtein ternormalisasi 0.060 dan Added Cognitive Complexity 0.200, sehingga diff-nya juga paling kecil
- Gemini 3.1 Pro Preview berada di area serupa, dan di antara model open-weight, GLM 5 relatif lebih konservatif dalam mengedit
- GPT-5.4 termasuk yang paling parah melakukan Over-Editing di antara model yang dievaluasi
- Dalam mode penalaran, Levenshtein-nya 0.395 dan Added Cognitive Complexity 2.313, dan dalam mode non-penalaran pun tetap tinggi masing-masing 0.327 dan 1.563
- Pass@1 juga cenderung rendah di 0.723 dan 0.770, sehingga lemah baik dari sisi akurasi maupun perubahan minimal
- Pada model non-penalaran, Qwen 3.6 Plus mencatat Pass@1 tertinggi di 0.870, sementara GLM 5 memiliki Added Cognitive Complexity terendah di 0.235
- Model non-penalaran Claude Opus 4.6 juga mempertahankan cakupan perubahan yang sangat kecil dengan Levenshtein 0.079 dan Added Cognitive Complexity 0.313
Bisakah diperbaiki dengan prompt?
- Ketika prompt ditambah dengan “IMPORTANT: Try to preserve the original code and the logic of the original code as much as possible”, Levenshtein Distance semua model menurun
- Kecuali DeepSeek R1/v3, Pass@1 juga ikut membaik
- Ini dapat diartikan bahwa batasan perubahan minimal mempersempit ruang modifikasi yang mungkin, sehingga mendorong perubahan yang lebih akurat dan terarah
- Efek ini terutama lebih besar pada model penalaran
- Karena cenderung lebih patuh pada instruksi eksplisit, permintaan untuk meminimalkan edit lebih kuat diterjemahkan menjadi penyusutan diff
- Hal ini menunjukkan bahwa meski pada kondisi default model cenderung terlalu banyak mengubah, ketika diberi instruksi ia dapat bergeser ke perbaikan yang lebih setia
Apakah penalaran mengarah pada penulisan ulang yang berlebihan
- Dengan memasangkan model penalaran dan non-penalaran dari keluarga model yang sama, lalu membandingkan Levenshtein Distance hanya pada sampel yang dijawab benar oleh keduanya
- Jika sampel gagal banyak, peluang terjadinya Over-Editing itu sendiri berkurang sehingga menimbulkan bias; karena itu, setelah akurasi dikendalikan, hanya gaya pengeditannya yang dipisahkan untuk diamati
- Dalam pengaturan prompt umum, pada sebagian besar pasangan model penalaran menulis ulang lebih banyak
- DeepSeek V3, GPT-5, GPT-5.4, Gemini 3.1 Pro Preview, Qwen 3.6 Plus, dan Kimi 2.5 semuanya menunjukkan batang penalaran yang lebih tinggi
- Terlihat kecenderungan bahwa penalaran yang diperluas bergerak dari sekadar perubahan minimal ke “implementasi yang lebih baik”, sehingga memunculkan refaktorisasi yang tidak perlu
- Pengecualiannya adalah Claude Opus 4.6, yang versi penalarannya melakukan jauh lebih sedikit perubahan dibanding versi non-penalaran
- Jika secara eksplisit diarahkan untuk mempertahankan kode asli, gambarnya berubah drastis
- Model penalaran menunjukkan Levenshtein Distance yang sama atau lebih rendah daripada model non-penalaran di hampir semua pasangan
- Versi penalaran Claude Opus 4.6 mencatat Levenshtein terendah di antara semua model dalam pengaturan ini
- GPT-5 dan GPT-5.4 juga mengalami penurunan skor penalaran yang besar, tetapi pada GPT-5.4 versi non-penalaran masih sedikit lebih unggul
- Dalam perilaku default, model penalaran memang mudah melakukan Over-Editing, tetapi kemampuan penalaran yang sama juga membuatnya lebih patuh pada batasan
- Perbedaan antara pengaturan umum dan pengaturan eksplisit secara konsisten tampak lebih besar pada model penalaran
- Karena itu, Over-Editing lebih menyerupai perilaku bawaan daripada keterbatasan mendasar, dan dapat dibalik melalui batasan
Apakah editor yang setia bisa dibuat lewat pelatihan
- Menggunakan Qwen3 4B 2507 Instruct sebagai model dasar, dan menjadikan konfigurasi 0-shot serta 8-shot yang menyertakan instruksi pelestarian kode asli sebagai baseline
- Metode pelatihan lainnya diuji dalam pengaturan umum tanpa instruksi eksplisit pelestarian kode asli saat evaluasi
-
Susunan eksperimen
- Soal DeepCoder dirusak dengan cara yang sama untuk membuat dataset sintetis
- Selain itu, Qwen3 4B 2507 Instruct dasar diminta menghasilkan 8 completion untuk tiap soal, lalu hanya sampel yang benar secara fungsional yang dipertahankan dan diurutkan dengan Levenshtein Distance untuk membentuk dataset self-distillation
- Pelatihan disesuaikan agar saat evaluasi model melakukan perilaku edit minimal tanpa instruksi eksplisit, mirip dengan Context Distillation
-
Metode pelatihan
- SFT: melakukan fine-tuning terawasi langsung dengan dataset yang dibuat secara terprogram
- rSFT: pada dataset self-distillation, hanya melatih dari 3 completion dengan Levenshtein Distance terendah untuk setiap sampel
- DPO: melakukan optimisasi preferensi antara completion dengan Levenshtein Distance tertinggi dan completion dengan Levenshtein Distance terendah pada setiap sampel
- RL: menerapkan reinforcement learning yang menggabungkan akurasi fungsional dan reward edit minimal berbasis Levenshtein
- Jika semua pengujian lulus maka
r = r_edit + 0.1
- Jika tidak lulus maka
r = -0.2
r_edit dihitung sebagai reward berbasis Levenshtein yang dinormalisasi
Bagaimana hasilnya pada jenis kerusakan yang sama
- Dalam pengaturan in-domain, saat jenis kerusakan di set pelatihan dan set pengujian sama, SFT menghasilkan hasil yang nyaris sempurna
- Baseline 0-shot: Pass@1 0.735, Norm. Levenshtein 0.169, Added CC 0.731
- Baseline 8-shot: Pass@1 0.775, Norm. Levenshtein 0.115, Added CC 0.479
- SFT mencatat hasil terbaik pada ketiga metrik dengan Pass@1 0.932, Norm. Levenshtein 0.002, Added CC 0.000
- rSFT mencatat 0.782 / 0.100 / 0.435, DPO 0.752 / 0.021 / 0.113, dan RL 0.802 / 0.046 / 0.112
- Karena hasil ini tampak terlalu bagus, muncul pemeriksaan apakah model mungkin hanya menghafal inversi untuk jenis kerusakan tertentu
- Penilaiannya adalah model mungkin tidak mempelajari perilaku edit minimal secara umum, melainkan hanya belajar membalik pola kerusakan yang sudah ditentukan
- Untuk memastikannya, jenis kerusakan antara data pelatihan dan data evaluasi disusun ulang agar sepenuhnya berbeda
Apakah bisa digeneralisasi ke jenis kerusakan lain
- Dalam pengaturan out-of-domain, saat jenis kerusakan di set pelatihan dan set pengujian berbeda, SFT runtuh secara signifikan
- Pass@1 SFT turun hingga 0.458, dan model menjadi berada dalam keadaan hanya mencoba perubahan minimal tertentu tanpa benar-benar memperbaiki bug
- Norm. Levenshtein -0.008 dan Added CC 0.006 memang sangat rendah, tetapi kemampuan menghasilkan perbaikan yang benar justru runtuh
- rSFT dan DPO sedikit lebih baik daripada baseline 8-shot, tetapi peningkatannya kecil
- rSFT mencatat 0.780 / 0.107 / 0.501 / LiveCodeBench -0.069
- DPO mencatat Pass@1 0.787 / 0.092 / 0.348 / LiveCodeBench -0.046
- Hanya dengan pelatihan menggunakan data jejak yang dibuat sendiri oleh model dasar, generalisasi sampai tingkat tertentu tetap dimungkinkan
- Hanya RL yang melakukan generalisasi dengan rapi di seluruh metrik utama
- RL mencatat Pass@1 0.782, Norm. Levenshtein 0.050, Added CC 0.185, LiveCodeBench Change +0.006
- Ketiga metriknya lebih baik daripada dua baseline, dan performa coding umum juga tidak menurun
- Fakta bahwa peningkatan pada Levenshtein dan Added Cognitive Complexity lebih besar daripada pada Pass@1 mendukung bahwa yang dipelajari bukan sekadar hafalan inversi kerusakan, melainkan perilaku edit minimal itu sendiri
Catastrophic Forgetting
- Dicek juga dengan LiveCodeBench v6 apakah kemampuan coding umum menurun ketika dilakukan fine-tuning untuk edit minimal
- Tujuannya adalah agar setelah pelatihan, model tetap berada pada tingkat yang mirip dengan model pretrained aslinya
- SFT mengalami penurunan kemampuan umum yang sangat besar
- Di LiveCodeBench, terjadi penurunan performa 43%, dan bahkan kemampuan dasar untuk mengidentifikasi serta memperbaiki bug tidak dapat dipertahankan
- rSFT dan DPO juga sedikit menurun
- Bahkan ketika dilatih dengan sampel yang dihasilkan model aslinya sendiri, karena sifat tugasnya, tingkat tertentu dari Catastrophic Forgetting tetap tersisa
- RL mempelajari perilaku baru tanpa penurunan performa
- Dari sudut pandang distribusi, semakin besar perbedaan antara dataset yang dibuat secara terprogram dan distribusi model asli, semakin besar pula Forgetting yang terjadi
- SFT menyesuaikan diri secara kuat pada data yang sangat berbeda dari distribusi asli sehingga distribusi model berubah besar
- rSFT dan DPO mengalami perubahan yang kurang drastis karena data self-distilled lebih dekat dengan distribusi asli
- Tingkat Catastrophic Forgetting kemungkinan besar sebanding dengan perbedaan antara distribusi asli dan distribusi data pelatihan tugas
Eksperimen tambahan
-
RL dengan LoRA: apakah fine-tuning penuh diperlukan
- Pekerjaan ini lebih dekat ke penyesuaian gaya dalam kemampuan memodifikasi kode yang sudah ada daripada memasukkan pengetahuan baru, sehingga diperiksa apakah LoRA saja sudah memadai
- rank 1 mencatat Pass@1 0.738, Norm. Levenshtein 0.166, Added CC 0.676, LiveCodeBench Δ -0.022
- rank 8 mencatat 0.775 / 0.112 / 0.426 / -0.022
- rank 16 mencatat Pass@1 0.805 / 0.087 / 0.328 / -0.005
- rank 32 mencatat 0.795 / 0.065 / 0.235 / -0.011
- rank 64 mencatat 0.797 / 0.051 / 0.160 / +0.001
- Model terbaik Full RL mencatat 0.782 / 0.050 / 0.185 / +0.006
- LoRA rank 64 hampir menyamai Full RL pada Levenshtein dan bahkan lebih baik pada Added CC
- Seiring rank membesar, Levenshtein dan Added CC turun secara monotonik dari 1 hingga 64
- Peningkatan besar terkonsentrasi di fase awal: dari rank 1→16, Levenshtein turun tajam dari 0.166→0.087, sedangkan dari 16→64 penurunannya menyempit secara bertahap menjadi 0.087→0.051
- Pada rank 1 dan 8 terlihat trade-off antara akurasi dan minimnya edit; ada kemungkinan kapasitasnya tidak cukup untuk mempelajari kedua fungsi reward sekaligus sehingga cenderung berat ke minimisasi edit yang reward-nya lebih tinggi
- Untuk perubahan perilaku pada level gaya dalam tugas yang kemampuannya sebenarnya sudah ada, sejumlah kecil parameter tambahan pun sudah cukup, dan setelah titik tertentu keuntungan dari kapasitas tambahan makin berkurang
-
Catatan tentang reward hacking
- Pada fungsi reward awal ada bug yang memberi skor 0 pada rollout yang sama sekali tidak memiliki eksekusi berhasil
- Karena tanda pada Levenshtein dibalik agar menjadi bentuk “semakin besar semakin baik”, skor 0 ini justru bisa menjadi reward yang lebih tinggi daripada eksekusi yang berhasil
- Meski begitu, Full RL tetap mempelajari tugasnya, sementara pada LoRA muncul reward hacking berupa sama sekali tidak mengeluarkan kode yang benar secara fungsional, yang kemudian memicu pemeriksaan lingkungan
- Setelah fungsi reward diperbaiki, hasil Full RL hanya sedikit membaik
-
Apakah ini juga berlaku untuk model yang lebih besar
- Resep RL out-of-domain yang sama diterapkan ke Qwen3 14B
- Baseline 14B mencatat Pass@1 0.770, Norm. Levenshtein 0.136, Added CC 0.315
- Setelah menerapkan RL, muncul peningkatan menyeluruh menjadi Pass@1 0.833, Norm. Levenshtein 0.059, Added CC 0.165, LiveCodeBench Δ +0.011
- Bahkan ketika jumlah parameter membesar, kenaikan Pass@1, penurunan Levenshtein, penurunan Added Cognitive Complexity, dan tidak adanya Catastrophic Forgetting tetap terjaga bersama-sama
- Ini mendukung kemungkinan bahwa resep RL untuk edit kode minimal dapat diskalakan ke model dengan berbagai ukuran
Ringkasan akhir
- Over-Editing muncul sebagai masalah yang luas dan dapat diukur
- Di berbagai model coding frontier, kemampuan memperbaiki dengan tepat dan kemampuan memperbaiki seminimal mungkin terlihat sebagai hal yang terpisah
- Khususnya, GPT-5.4 pada pengaturan default menunjukkan kecenderungan rewrite berlebihan yang relatif kuat, sementara Opus 4.6 menunjukkan baseline yang kuat
- Hanya dengan prompt eksplisit pun, perilaku editing yang setia pada sumber sudah bisa diarahkan secara signifikan
- Khususnya model penalaran pada dasarnya cenderung terlalu banyak mengubah, tetapi akan mengikuti lebih baik jika diberi instruksi untuk mempertahankan kode asli
- GPT-5.4 juga menunjukkan peningkatan besar dalam mode penalaran, sehingga kemampuan instruction following-nya sendiri tampak kuat
- Peningkatan Opus 4.6 yang terlihat kecil bisa jadi karena performa dasarnya memang sudah tinggi
- Dari sisi pelatihan, RL muncul sebagai solusi yang paling seimbang
- Model mempelajari perilaku editing yang lebih setia tanpa merusak kemampuan coding umum, dan efek ini tetap bertahan pada Qwen3 4B maupun 14B
- SFT kuat pada jenis kerusakan tertentu, tetapi gagal besar dalam generalisasi dan menjaga kemampuan umum
- Evaluasi perbaikan bug pada tingkat fungsi tunggal memang lebih terbatas cakupannya dibanding evaluasi yang lebih agentic seperti SWE-Bench Pro, tetapi ini menjadi titik awal untuk menangani masalah yang sulit dikuantifikasi dalam Over-Editing pada setting yang realistis
- Arah untuk mengevaluasi dan meningkatkan kemampuan edit minimal dapat berujung pada peningkatan kualitas keseluruhan kode yang dihasilkan AI
1 komentar
Opini Hacker News
Cara saya memakai Claude Code jauh melampaui ekspektasi
Kalau dia mengubah terlalu banyak, saya minta dia menjelaskan apa yang salah dan mencatat pelajarannya ke file skill per proyek
Setelah itu dia hampir tidak mengulangi kesalahan yang sama, dan kalau file skill membesar, dia juga cukup bagus dalam merapikan dan memadatkannya
Sekarang rasanya menulis kode sendiri di tempat kerja sudah tidak terlalu masuk akal secara ekonomi
Peran saya sekarang lebih seperti guru, arsitek, dan admin infrastruktur, sementara sebagian besar pengembangan saya serahkan ke tim sesi Claude yang terampil
Tentu saya tetap meninjau semuanya, dan Claude juga menulis test yang rapat untuk kami telaah bersama
Belakangan ini dia juga bisa menangani proyek besar tanpa kesulitan
Saya tidak bermaksud terdengar seperti iklan Anthropic, saya justru penasaran sebenarnya apa yang saya lakukan sampai ini terasa luar biasa efektif
Dan token sekarang juga hampir tidak pernah kurang
Saya hampir hanya memakai model Opus, efisiensi tokennya bagus, dan minggu lalu saya membuat lebih dari 150 commit yang bermakna dengan bantuan Claude tetapi hanya memakai sepertiga kuota mingguan
Sebelum Claude, batas saya sekitar 25~30 commit per minggu
Kemarin saya lihat statistik dan kaget karena 97% kode perusahaan sekarang ditulis Cursor AI
Saya kebanyakan menjalankannya lewat cloud agent, karena kalau dilihat real-time terlalu mengalihkan perhatian
Cara saya sangat sederhana: cukup memberi instruksi yang jelas dengan kata-kata
Orang-orang membuat ini terlalu rumit
Berbagi file .md lalu mendalami orchestration, prompt hack, dan semacamnya buat saya menariknya cuma setara dengan terlalu terobsesi pada shortcut vim atau skin IDE
Cukup katakan dengan jelas apa yang diinginkan dan beri umpan balik yang bagus
Hasilnya sudah sampai level yang bisa saya terima tanpa canggung meski itu kode yang ditulis rekan kerja
Tentu saya tetap membaca dan mengoreksi semuanya baris demi baris, tapi koreksi itu pun kurang lebih setara dengan yang biasa saya lakukan saat code review
Saya tidak mengukur produktivitas dengan angka, tapi dari kenyataan bahwa sekarang saya akhirnya mengerjakan hal-hal yang sudah bertahun-tahun tertunda, dampaknya sangat terasa
Misalnya dia sangat kuat untuk pekerjaan membosankan seperti mengubah 100 markdown menjadi 5 json dan memperbarui kode yang membacanya
Ini software yang penuh cacat dan bug, tetapi dalam praktiknya tetap sangat efektif
Salah satu hal paling aneh dari AI adalah pengalaman tiap orang bisa benar-benar sangat ekstrem berbeda
Apakah pekerjaanmu banyak soal operasional, dan apakah kamu menangani kode produk yang harus bertahan lama, juga penting
Hipotesis saya adalah alat ini bekerja baik di atas pola sederhana dan memang bisa menangani pekerjaan kompleks, tetapi sangat buruk dalam menciptakan pola baru
Kalau dibiarkan tanpa pengawasan, dia cepat sekali menciptakan pola baru yang berbahaya lalu merusaknya
Jadi cukup sering saya menulis ulang seluruh hasil yang diberikan Claude
Kadang saya malah berlomba kecepatan dengan robot itu dan saya selesai lebih dulu
Memang saya diuntungkan karena sudah tahu apa yang saya inginkan, tetapi saya merasa biaya utak-atik kecil di sini diremehkan
Baik futzing fraction maupun the peril of laziness lost menyinggung soal bagaimana mesin berusaha terlalu keras dengan cara yang menjengkelkan
Saya tidak paham kenapa ketika hanya perlu melakukan satu hal, dia malah mencoba melakukan tiga
Walaupun setelah dikoreksi dia bisa menyesuaikan lagi, tetap saja menyebalkan harus mengulang pola yang sama seperti saat kerja dengan rekan manusia: “jangan lakukan A, B, C, lakukan A saja”
Pembuatan test juga rumit; dia bagus kalau menulis test dengan arah yang jelas, tapi kalau diberi ruang untuk kreatif dia terlalu sering membuat test tak berguna seperti
foo + bar == bar + fooKita harus terus meragukan kegunaan test itu agar loop umpan balik tetap sehat
Akhir-akhir ini kadang dia malah lebih berguna untuk sekali jalan menarik import yang dibutuhkan daripada untuk test itu sendiri
Kalau mesin seperti ini menggantikan pekerjaan, seharusnya kualitas kode rata-rata bisa naik
Tapi banyak orang memakainya dengan pendekatan “kurang lebih mentok di sekitar rata-rata”, dan tergantung cara kerjanya, malah bisa menurunkan rata-rata
Sudah 28 tahun saya melakukan pekerjaan ini, dan sekarang menulis sendiri kode aplikasi kerja di jam yang dibayar perusahaan rasanya sudah tidak lagi cocok, baik secara ekonomi maupun kalau dilihat dengan niat baik
Sebaliknya, saya justru sering merasa coding agent terlalu memprioritaskan pelestarian kode yang ada, padahal untuk menyesuaikan dengan requirement baru dia harusnya lebih berani mengubah kode lama
Ujung-ujungnya ini terasa seperti soal seberapa dibekukan kode lama itu
Kalau ini aplikasi produksi besar yang sudah berjalan puluhan tahun, masuk akal untuk meminimalkan perubahan, tetapi kalau ini proyek eksperimen yang baru dibuat 3 hari lalu, harusnya dia memperbaikinya menjadi lebih baik, bukan mempertahankannya apa adanya
Pada akhirnya dia harus belajar menyesuaikan tingkat agresivitasnya sendiri sesuai konteks proyek
Bahkan dalam proyek yang sama pun, tergantung PR-nya, ada area yang boleh diubah sebebas mungkin dan ada area yang ingin saya biarkan tetap untuk menekan diff dan cakupan test
Jadi saya jelaskan lebih dulu bagian mana yang boleh diubah seagresif apa, tapi hasilnya tetap tidak konsisten
Secara umum dia cenderung ke diff minimal, dan akibatnya sering muncul duplikasi atau abstraksi yang dipelintir paksa
Kalau ada cara yang lebih efektif, saya juga ingin dengar
Bahkan kalau disuruh refactor atau berpikir ulang secara luas pun, hasilnya cenderung lemah
Jadi saya menyuruhnya merapikan markdown yang desainnya terlalu tertanam, lalu menghapus detail teknis atau implementasi dan antarmuka inti dari source, kemudian meminta sesi baru mendesain ulang
Setelah itu saya pulihkan bagian yang dihapus dan merekonsiliasikannya dengan sesi yang tidak terlalu naif
Path dependency-nya terlalu kuat, jadi sekarang alur ini saya lakukan manual, tapi saya ingin memformalkan pola ini sebagai skill
AI sering mencoba menyembunyikan kegagalan dengan menelan exception dan mengembalikan nilai dummy, atau hanya meninggalkan satu pesan yang tenggelam di antara berbagai log acak
Log-nya juga terlalu diringkas sehingga data inti yang dibutuhkan untuk debugging justru hilang
Mungkin karena dia dilatih ke arah menipu sistem untuk mendapat skor
Kalau exception dibiarkan meledak, itu jelas kegagalan dan kena penalti, tapi kalau masalahnya disembunyikan, kadang bisa terlihat seperti sukses
Saya juga penasaran ini muncul seperti apa dalam Q&A umum
Apakah model bergerak ke arah terdengar cukup meyakinkan agar pengguna merasa puas lalu pergi
Pola yang sering terlihat adalah jawaban seperti “itu bukan X, itu Y”; ketika membuat dikotomi seperti ini, orang jadi tidak memikirkan kemungkinan lain
Menempelkan rencana tindakan di akhir jawaban juga umum, dan ini terlihat seperti teknik penjualan assumptive close, semacam alur yang mendorong orang membayangkan hasil setelah setuju dengan AI, bukan fokus pada jawabannya sendiri
Toh memanjat metrik dengan hill-climbing memang akan terlihat seperti itu
Ini seperti bentuk A/B enshittification yang diekstremkan sampai tidak bisa diinterpretasikan lagi
Selama dilatih dengan umpan balik manusia, setiap bagian dari setiap respons pada akhirnya akan condong ke arah mengakali evaluator dan memuaskannya
Membuat sesuatu dengan sangat baik memakai AI ternyata butuh lebih banyak sentuhan tangan daripada yang dibayangkan
Kalau disuruh, dia bisa menghasilkan sesuatu yang cukup meyakinkan, tetapi dia bisa saja bahkan tidak tahu bahwa dia tidak tahu
Ini lebih berbahaya lagi ketika AI berbicara dengan otoritatif
Karena itu, memverifikasi dari berbagai sudut dan memastikan akurasi bukan hal mudah
Menarik melihat bagaimana ini akan berubah seiring waktu
Pada saat yang sama, tulisan seperti ini dan komentar-komentar di sini juga terasa seperti snapshot suatu momen
Kecepatan perkembangan industrinya terlalu cepat, dan model coding sekarang sudah jauh lebih baik dibanding hanya 9 bulan lalu
Setiap kali membaca keluhan tentang kemampuan AI, bukannya saya menyalahkan orangnya, tapi dalam hati saya selalu berpikir, “belum”
Semacam membuat mereka saling mereview hasil satu sama lain
Meski begitu kebanyakan tetap berjalan asinkron, jadi saya bisa mengerjakan hal lain sementara itu berlangsung
Jadi di beberapa proyek saya belajar dulu dengan membuat prototipe pakai agent, lalu menulis desainnya, lalu memulai lagi dari awal
Dengan begitu saya jadi tahu area mana yang perlu didalami
Apa isi 20% sisanya pada akhirnya tetap bergantung pada sifat masalahnya
Yang dibahas di sini adalah pengeditan kode berlebihan, tapi agent melakukan lebih dari itu
Dia menyentuh banyak file, menjalankan test, deploy, bahkan melakukan smoke test, dan semua itu tersembunyi di balik abstraksi
Di satu sisi ini mengagumkan, tapi di sisi lain juga sangat mengkhawatirkan
Pertama, saya tidak benar-benar memahami apa yang sebenarnya terjadi di dalam
Terlalu mudah tergoda untuk sekadar menyetujui skrip yang dirangkai agent lalu menjalankannya
Tapi saya pernah menghapus DB karena agent sudah lebih dulu menilai itu aman, dan saya juga pernah menangkap upaya mengirim kredensial AWS ke target deployment padahal itu sama sekali tidak boleh dilakukan
Kedua, saya tidak belajar apa-apa
Bahkan untuk merangkai satu perintah docker sederhana saja, beban kognitifnya jadi terasa lebih besar, sehingga saya berulang kali bergantung pada AI sebagai kruk
Jangan nyalakan auto-approve, dan semua perintah yang dijalankan agent harus disetujui sendiri satu per satu
Jangan serahkan keputusan desain atau arsitektur juga; manusia harus memutuskan cara membangunnya lalu memberi instruksi yang jelas ke kaleng itu
Saya tidak bercanda, kalau AI diperlakukan sebagai alat, penggunaannya akan jauh lebih efektif
Mungkin bukan 10x produktivitas, tapi setidaknya kita tetap memahami kodenya sepanjang jalan
Pada Day 1, dia sangat berhati-hati soal keamanan, mulai dari kenapa .env harus masuk .gitignore sampai wejangan bahwa kredensial jangan diberikan dan saya sendiri yang harus mengubahnya
Lalu pada Day 2, saat diminta hal yang sama lagi, dia melupakan aturan atau setelan itu, menelusuri seluruh disk untuk membaca .env dan file lain, memahami bahwa dia memegang token, lalu langsung menyusun perintah curl dan bahkan mengujinya
Hari pertama terasa seperti pakar keamanan, keesokan harinya terasa lebih buruk dari intern biasa
Pendekatan ini memang banyak menghasilkan perilaku yang tidak diinginkan atau implementasi yang berlebihan, tetapi berguna untuk menghilangkan boilerplate
Dalam praktiknya, bagian seperti ini akhirnya sekitar 70% dihapus
Sebagai gantinya, area nomor 1 dan 2 saya buat tidak boleh disentuh AI
Tentu arsitekturnya harus disusun agar pemisahan seperti ini memungkinkan, tetapi sejauh ini saya cukup puas
Cukup jangan beri kredensial produksi ke LLM
Kalau sesuatu tidak bisa direproduksi di lokal atau staging/dev, maka infrastruktur deployment harus dibuat lebih mirip prod, dan kalau hak akses antar environment belum bisa dipisah cukup rinci, yang harus dibenahi dulu adalah sistem izinnya
Saya memegang prinsip itu, jadi saya hampir tidak pernah mengalami jenis masalah yang kamu sebutkan
Untuk kebutuhan diagnostik, mungkin saya bisa memberi kredensial read-only sementara, tapi bahkan dalam kasus itu saya hanya akan menerbitkan token dengan masa hidup sangat pendek untuk antisipasi kebocoran
Jadi secara umum saya tetap paham apa yang sedang terjadi
Kadang Claude memang membuat keputusan yang aneh atau di luar kebiasaan
Namun kalau menangani codebase besar sebagai tim, memang dari awal pun ada banyak area di balik abstraksi yang tidak benar-benar kita pahami, termasuk bagian yang dibuat orang yang sudah lama keluar dari perusahaan
Dulu ada kebijaksanaan yang sering diajarkan tetapi nyaris tidak pernah benar-benar dijalankan, yaitu refactor sambil bekerja
Maksudnya, kalau sedang menyentuh suatu area, sekalian rapikan dan lunasi utang teknisnya
Tapi di dunia nyata itu jarang berhasil, dan sekarang ketika LLM mulai benar-benar melakukannya, kita jadi merasakan efek sampingnya
Kadang fungsi yang dibutuhkan sudah ada tepat di sana, tapi dia malah membuat yang baru
Yang lebih buruk, dia mengubah fungsi yang sudah ada seolah-olah perilakunya tetap sama, tetapi ternyata memecahkan pemakaian lain
Yang paling buruk adalah saat dia mengubah state antar class tanpa menyadari efek sampingnya, lalu menciptakan deadlock atau bug biasa
Menurut saya ini bukan refactoring, melainkan lebih seperti menarik tuas mesin slot sekali lagi
Masalah saya yang sebenarnya adalah kualitas refactoring yang dilakukan agent buruk
Saya hanya ingin menghentikan jenis perubahan seperti itu, lalu memberi instruksi yang lebih eksplisit tentang apa yang harus diperbaiki dan bagaimana caranya
Dalam banyak kasus, abstraksi yang ada sudah cukup baik sehingga pelacakan bug atau perluasan fitur masih bisa dilakukan di atasnya
Tetapi kadang kita sampai di persimpangan antara memaksa jalan memutar di sekitar implementasi lama, atau mendesain ulang
Dengan LLM, cara memikirkan ulang keputusan itu—atau bahkan apakah perlu dipikirkan ulang sama sekali—menjadi kabur
Ditambah lagi, keputusan seperti itu tersembunyi sehingga tidak mudah terlihat oleh pengguna
Mungkin perubahan seperti itu memang berguna, jadi saya ingin melihat lebih banyak contoh
Saya tidak terlalu percaya pada metrik cognitive complexity, tetapi agak menarik bahwa jenis perubahan seperti ini tampaknya cukup konsisten menaikkan metrik tersebut
Sudah lama saya tidak melihat pengeditan berlebihan di Claude Code atau Codex, jadi saya penasaran prompt apa yang dipakai dalam riset ini
Sepertinya ada di sini dan perubahan terakhirnya 8 bulan lalu
https://github.com/nreHieW/fyp/blob/5a4023e4d1f287ac73a616b5b944a14f28422c7e/partial_edits/utils/prompts_utils.py
GPT-5.4 menulis ulang 50 baris dengan alasan lebih rapi, padahal yang saya minta hanya tambahan 10 baris
Padahal itu cuma penambahan mekanis sederhana: lihat kode yang ada, lalu masukkan hal serupa dengan mengganti nama variabel
Lebih parah lagi, pada awalnya dia bahkan tidak memasukkan fitur yang saya minta
Over-editing jelas bukan masalah masa lalu, dan ini terjadi karena saya lupa menurunkan thinking sehingga jalan dengan xhigh thinking
Buat saya ini terbaca seperti masalah era awal agent
Tulisan ini cukup solid
LLM terlalu bertele-tele, baik dalam prosa maupun kode, dan menurut saya penyebab utamanya adalah cara pelatihannya
Cross entropy loss membuat model cenderung memilih kalimat seperti garden path
Sesuatu yang manusia akan selesaikan dalam satu kalimat, bahkan beberapa kata saja, malah direntangkannya menjadi satu paragraf
Karena kalimat panjang adalah jalur dengan kejutan statistik lebih kecil, yaitu jalur perplexity rendah
Saya juga punya perasaan campur aduk soal masalah ini
Kebanyakan dia melakukan terlalu banyak dan saya harus menghabiskan 30 menit untuk membenahinya, jadi saya setuju dengan penilaian itu
Tapi kadang dia juga justru melewatkan perubahan yang lebih menyeluruh
Mungkin karena keterbatasan konteks, dan karena itu saya mulai memperlakukan alat ini dengan lebih ketat
Meski begitu saya masih belum mendapatkan tingkat rasa kendali yang saya inginkan
Ini terasa seperti jejak data pelatihan
Data SFT dan preference penuh dengan contoh “versi file yang diperbaiki jadi lebih rapi”, sedangkan contoh seperti “diff tepat 3 baris” jauh lebih sedikit
Jadi model belajar bahwa output yang lebih besar dan lebih dipoles itu yang menang
Sampai batas tertentu ini bisa dikendalikan dengan prompt, tetapi pada akhirnya tetap seperti melawan kecenderungan bawaan yang kuat