Pengeditan Berlebihan: Saat model mengubah kode melampaui cakupan yang diperlukan

 (nrehiew.github.io)
10 poin oleh GN⁺ 2026-04-23 | 1 komentar | Bagikan ke WhatsApp
  • Bahkan pada bug yang bisa diselesaikan hanya dengan perubahan minimal, model mudah menghasilkan diff besar dengan menulis ulang seluruh fungsi, menambahkan logika bantu, hingga mengubah signature
  • Dalam pekerjaan brown-field yang mempertahankan struktur yang ada, lolos pengujian saja tidak cukup; seberapa sedikit yang diubah juga harus dinilai agar kemudahan review dan keamanan perubahan tetap terjaga
  • Berdasarkan 400 soal BigCodeBench yang dirusak secara terprogram, over-editing diukur secara kuantitatif dengan Levenshtein tingkat token, skor patch relatif, dan Added Cognitive Complexity
  • Kecenderungan menulis ulang secara berlebihan ditemukan di berbagai model coding terbaru; Claude Opus 4.6 kuat dalam kombinasi akurasi dan minimnya perubahan, 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 metode pelatihan, RL menghasilkan keseimbangan terbaik dengan mempelajari perilaku edit minimal tanpa menurunkan performa coding umum

Masalah Over-Editing

  • Over-Editing mengacu pada fenomena ketika model mengubah 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 mengganti range(len(x) - 1) menjadi range(len(x)), model dapat membuat 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 mengganti logika plotting; pengujian tetap lolos, tetapi menghasilkan diff besar
  • Dalam pekerjaan brown-field yang menangani codebase yang sudah ada, lebih penting mempertahankan kode yang sudah dipahami dan sengaja ditulis tim sambil hanya memperbaiki masalahnya
    • Berbeda dari green-field yang dibangun dari nol, perubahan yang tidak menghormati struktur yang ada membuat reviewer sulit memahami apa yang berubah dan mengapa
    • Jika seluruh fungsi ditulis ulang, kode menjadi lebih sulit dikenali dan juga lebih sulit menilai keamanan perubahannya
  • Standar bahwa yang penting pengujian lolos saja sulit menangkap masalah ini
    • Over-Editing bukan kegagalan akurasi, melainkan kegagalan kesetiaan pengeditan, sehingga sering tidak terlihat dalam test suite
    • Semakin banyak kode yang dihasilkan, semakin besar pula volume yang harus direview, dan ketika kompleksitas yang tidak perlu menumpuk, kualitas codebase bisa diam-diam menurun

Cara Mengukur Over-Editing

  • Untuk membuat dataset dengan jawaban perubahan minimal yang jelas, 400 soal BigCodeBench dirusak secara terprogram untuk membentuk set evaluasi
    • Alih-alih menyuntikkan bug dengan LLM lain seperti pada benchmark yang ada, perubahan dikendalikan secara rinci, misalnya mengganti < menjadi <=, + menjadi -, atau True menjadi False
    • Setiap sampel yang dirusak divalidasi agar tetap valid secara sintaks dan mematahkan test case terkait, dan perbaikan yang benar dirancang hanya berupa membalikkan kerusakan itu sehingga menjadi perubahan minimal
  • Susunan ini memungkinkan evaluasi 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 telah dirusak
    • Semakin banyak perubahan tambahan di luar pemulihan jawaban yang benar, semakin buruk skornya
  • Kode terkait disediakan di repositori GitHub

Metrik Pengukuran

  • Levenshtein Distance tingkat token

    • Alih-alih Levenshtein tingkat karakter yang umum, digunakan varian tingkat token Python
    • Kode dipecah dengan tokenizer Python menjadi 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 tingkat karakter adalah 19, tetapi jarak tingkat token menjadi 1 karena hanya satu identifier yang dianggap berubah
    • Nilai dinormalisasi dengan jumlah total token agar fungsi dengan panjang berbeda tetap bisa dibandingkan
    Iklan

  • Skor patch relatif

    • 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 diukur seberapa dekat edit buatan model dengan itu
    • Semakin dekat nilainya ke 0, semakin mirip patch model dengan perubahan minimal yang sebenarnya

  • Added Cognitive Complexity

    • Cognitive Complexity yang lebih baik mencerminkan tingkat kesulitan membaca dibanding Cyclomatic Complexity juga digunakan bersama
    • Metrik ini memberi penalti pada nested, 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 state
    • Dalam 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 pada keluaran model meningkat, berarti ada kode tambahan yang tidak diminta, dan nilai di bawah 0 juga dianggap tidak diinginkan karena berarti terjadi penyederhanaan yang tidak perlu

Apakah model benar-benar melakukan Over-Edit?

  • Over-Editing juga terkonfirmasi pada model frontier terbaru
    • Baik model penalaran maupun non-penalaran menunjukkan adanya perbedaan antara Pass@1 dan tingkat perubahan minimal
    • Kemampuan memperbaiki dengan benar saja tidak cukup untuk menilai apakah pengeditannya setia terhadap kode asal
  • Dalam perbandingan model penalaran, Claude Opus 4.6 menunjukkan kombinasi terkuat
    • Pass@1 tertinggi di 0.912, dan diff juga yang paling kecil dengan Levenshtein ternormalisasi 0.060 serta Added Cognitive Complexity 0.200
    • Gemini 3.1 Pro Preview berada di area serupa, dan di antara model open-weight, GLM 5 mengedit dengan relatif konservatif
  • GPT-5.4 termasuk yang paling parah dalam Over-Editing di antara model yang dievaluasi
    • Dalam mode penalaran, Levenshtein mencapai 0.395 dan Added Cognitive Complexity 2.313, sementara dalam mode non-penalaran masing-masing tetap tinggi di 0.327 dan 1.563
    • Pass@1 juga relatif rendah, masing-masing 0.723 dan 0.770, sehingga menunjukkan hasil yang lemah baik dari sisi akurasi maupun minimnya perubahan
  • Di antara 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 skala perubahan yang sangat kecil dengan Levenshtein 0.079 dan Added Cognitive Complexity 0.313
Iklan

Apakah bisa diperbaiki dengan prompt?

  • Saat prompt ditambahkan kalimat “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 meningkat
    • Ini bisa ditafsirkan bahwa batasan perubahan minimal mempersempit ruang modifikasi yang mungkin, sehingga mendorong perubahan yang lebih akurat dan lebih terarah
  • Efek ini terutama lebih besar pada model penalaran
    • Karena cenderung lebih baik mengikuti instruksi eksplisit, tuntutan untuk meminimalkan edit lebih kuat berujung pada penyusutan diff
    • Ini menunjukkan bahwa meski dalam kondisi default model bisa terlalu banyak mengutak-atik, ketika diberi instruksi, model dapat beralih 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 keduanya sama-sama menjawab benar
    • Jika sampel gagal banyak, akan muncul bias karena kesempatan terjadinya Over-Editing sendiri berkurang; karena itu akurasi dikendalikan lebih dulu lalu hanya gaya pengeditannya yang dipisahkan untuk dilihat
  • 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 ke arah “implementasi yang lebih baik” alih-alih perbaikan minimal, sehingga memunculkan refaktorisasi yang tidak perlu
    • Pengecualiannya adalah Claude Opus 4.6, yang versi penalarannya justru mengubah jauh lebih sedikit daripada versi non-penalaran
  • Jika model secara eksplisit diarahkan untuk mempertahankan kode asli, gambarnya berubah besar
    • Model penalaran menunjukkan Levenshtein Distance yang sama atau lebih rendah daripada model non-penalaran pada hampir semua pasangan
    • Claude Opus 4.6 versi penalaran mencatat Levenshtein terendah di antara seluruh model dalam pengaturan ini
    • GPT-5 dan GPT-5.4 juga mengalami penurunan skor versi penalaran yang besar, tetapi pada GPT-5.4 versi non-penalaran masih sedikit lebih unggul
  • Dalam perilaku default, model penalaran memang mudah mengalami Over-Editing, tetapi kemampuan penalaran yang sama juga membuatnya lebih baik dalam mengikuti batasan
    • Perbedaan antara pengaturan umum dan pengaturan eksplisit secara konsisten tampak lebih besar pada model penalaran
    • Karena itu, Over-Editing lebih mirip perilaku default daripada keterbatasan mendasar, dan dapat dibalik melalui batasan

Bisakah pembelajaran menghasilkan editor yang setia

  • Menggunakan Qwen3 4B 2507 Instruct sebagai model dasar, lalu menjadikan konfigurasi 0-shot dan 8-shot dengan instruksi pelestarian kode asli sebagai baseline
    • Metode pembelajaran lain diuji dalam pengaturan umum tanpa instruksi pelestarian kode asli yang eksplisit saat evaluasi
    Iklan

  • Konfigurasi eksperimen

    • Soal DeepCoder dirusak dengan cara yang sama untuk membuat dataset sintetis
    • Selain itu, Qwen3 4B 2507 Instruct dasar diminta membuat 8 completion untuk tiap soal, lalu hanya sampel yang benar secara fungsional yang dipertahankan dan diurutkan berdasarkan Levenshtein Distance untuk membentuk dataset self-distillation
    • Pembelajaran disesuaikan agar saat evaluasi model melakukan perilaku edit minimal tanpa instruksi eksplisit, mirip dengan Context Distillation

  • Metode pembelajaran

    • SFT: fine-tuning terawasi langsung pada dataset yang dibuat secara terprogram
    • rSFT: dari dataset self-distillation, hanya 3 completion dengan Levenshtein Distance terendah untuk tiap sampel yang dipilih untuk pelatihan
    • DPO: optimasi preferensi dilakukan antara completion dengan Levenshtein Distance tertinggi dan completion dengan Levenshtein Distance terendah untuk tiap sampel
    • RL: menerapkan reinforcement learning yang menggabungkan akurasi fungsional dan reward edit minimal berbasis Levenshtein
      • Jika semua pengujian lolos, r = r_edit + 0.1
      • Jika tidak lolos, 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 mencatat Pass@1 0.735, Norm. Levenshtein 0.169, Added CC 0.731
    • Baseline 8-shot mencatat 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 terlihat terlalu bagus, muncul pemeriksaan atas kemungkinan model hanya menghafal transformasi balik untuk jenis kerusakan tertentu
    • Ada kemungkinan model tidak mempelajari perilaku edit minimal yang umum, melainkan hanya dilatih untuk membalik pola kerusakan yang sudah ditentukan
    • Untuk memastikannya, jenis kerusakan pada data pelatihan dan data evaluasi kemudian disusun ulang agar benar-benar berbeda

Apakah ini 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 berada dalam kondisi mencoba perubahan minimal tertentu tanpa benar-benar bisa memperbaiki bug
    • Norm. Levenshtein sangat rendah di -0.008 dan Added CC 0.006, tetapi kemampuan menghasilkan perbaikan yang benar 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 pembelajaran dari data jejak yang dibuat sendiri oleh model dasar, generalisasi sampai tingkat tertentu tetap dimungkinkan
    Iklan
  • 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, dan 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 transformasi balik kerusakan, melainkan perilaku edit minimal itu sendiri

Catastrophic Forgetting

  • Dengan fine-tuning untuk edit minimal, diuji juga lewat LiveCodeBench v6 apakah kemampuan coding umum ikut menurun
    • Tujuannya adalah agar setelah pelatihan model tetap mempertahankan level yang mirip dengan model pretrained aslinya
  • SFT menunjukkan penurunan kemampuan umum yang sangat besar
    • Di LiveCodeBench terlihat penurunan performa 43%, dan model bahkan gagal mempertahankan kemampuan dasar mengidentifikasi dan memperbaiki bug
  • rSFT dan DPO juga turun sedikit
    • Meski dilatih menggunakan sampel yang dihasilkan model asli, karena sifat tugasnya tetap ada tingkat Catastrophic Forgetting tertentu
  • RL mempelajari perilaku baru tanpa penurunan performa
  • Dari sudut pandang distribusi, ada juga interpretasi bahwa semakin besar perbedaan antara dataset yang dibuat secara terprogram dan distribusi model asli, semakin besar pula Forgetting
    • SFT sangat disesuaikan dengan data yang sangat berbeda dari distribusi asli sehingga distribusi model berubah besar
    • rSFT dan DPO mengalami perubahan yang tidak terlalu kasar karena data self-distilled lebih dekat dengan distribusi asli
    • Besarnya Catastrophic Forgetting kemungkinan sebanding dengan perbedaan antara distribusi asli dan distribusi data pelatihan tugas
Iklan

Eksperimen tambahan

  • RL dengan LoRA: apakah fine-tuning penuh diperlukan

    • Karena tugas ini lebih dekat ke penyesuaian gaya kemampuan mengedit kode yang sudah ada ketimbang memasukkan pengetahuan baru, diuji 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 Full RL terbaik mencatat 0.782 / 0.050 / 0.185 / +0.006
    • LoRA rank 64 hampir menyamai Full RL pada Levenshtein dan menghasilkan Added CC yang lebih baik
    • Seiring rank membesar, Levenshtein dan Added CC turun secara monoton dari 1 ke 64
    • Peningkatan besar terkonsentrasi di tahap awal: dari rank 1→16, Levenshtein turun tajam dari 0.166→0.087, sedangkan dari 16→64 menyempit bertahap dari 0.087→0.051
    • Pada rank 1 dan 8, terlihat trade-off antara akurasi dan pengeditan minimal; ada kemungkinan kapasitasnya tidak cukup untuk mempelajari kedua fungsi reward sekaligus sehingga lebih condong ke minimisasi edit yang reward-nya lebih tinggi
    • Untuk perubahan perilaku pada level gaya dalam tugas yang kemampuannya sudah dimiliki, sejumlah kecil parameter tambahan saja sudah cukup, dan setelah titik tertentu keuntungan dari kapasitas tambahan makin menurun

  • Catatan reward hacking

    • Pada fungsi reward awal, ada bug yang memberi rollout tanpa satu pun eksekusi berhasil nilai 0
    • Karena tanda pada Levenshtein dibalik agar berbentuk “semakin besar semakin baik”, nilai 0 ini justru bisa menjadi reward yang lebih tinggi daripada eksekusi yang berhasil
    • Meski begitu, Full RL tetap mempelajari tugasnya, dan hanya pada LoRA muncul reward hacking berupa sama sekali tidak menghasilkan kode yang benar secara fungsional, yang kemudian memicu pemeriksaan lingkungan
    • Setelah fungsi reward diperbaiki, hasil Full RL hanya sedikit membaik

  • Apakah ini juga meluas ke 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 penerapan RL, muncul peningkatan menyeluruh menjadi Pass@1 0.833, Norm. Levenshtein 0.059, Added CC 0.165, LiveCodeBench Δ +0.011
    • Meski jumlah parameter lebih besar, 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 tampak sebagai hal yang terpisah
    • Khususnya, GPT-5.4 menunjukkan kecenderungan penulisan ulang berlebihan yang relatif kuat dalam pengaturan default, sementara Opus 4.6 menunjukkan baseline yang kuat
  • Dengan prompt eksplisit saja, pengeditan yang setia pada sumber dapat didorong secara signifikan
    • Model penalaran khususnya cenderung terlalu banyak mengubah secara default, tetapi lebih patuh ketika 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 mungkin karena performa dasarnya sudah tinggi
  • Dari sisi pelatihan, RL muncul sebagai solusi yang paling seimbang
    • Sambil mempelajari perilaku pengeditan yang lebih setia, kemampuan coding umum tidak terganggu, dan efek ini tetap bertahan pada Qwen3 4B maupun 14B
    • SFT kuat pada tipe kerusakan tertentu, tetapi sangat gagal dalam generalisasi dan menjaga kemampuan umum
  • Evaluasi perbaikan bug pada level fungsi tunggal memang lebih terbatas cakupannya dibanding evaluasi yang lebih agentic seperti SWE-Bench Pro, tetapi ini menjadi titik awal untuk menangani masalah yang selama ini sulit dikuantifikasi dalam Over-Editing pada pengaturan yang realistis
    • Arah untuk mengevaluasi dan meningkatkan kemampuan edit minimal dapat berujung pada peningkatan kualitas keseluruhan kode yang dihasilkan AI

Bacaan terkait

1 komentar

 
GN⁺ 2026-04-23
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

    • Saya juga mirip
      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
    • Saya juga sama. Sebagai alat penghemat tenaga kerja, ini mengejutkan 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
    • Kalau orang bilang akhir-akhir ini Claude Code sudah sampai tidak bisa dipakai, saya percaya saja, tapi saya sendiri tidak terlalu paham
      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
    • Rasanya pengalaman itu akan cukup berbeda tergantung apakah kodenya mendapat review orang lain, apakah dulu code review terasa berat, dan seberapa penting code quality menurut rekan-rekanmu
      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 + foo
      Kita 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
    • Saya juga merasakan hal yang sama
      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

    • Trade-off ini bergantung pada konteks, jadi agent tidak bisa selalu menilai dengan benar hanya dengan menelusuri proyeknya
      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
    • Saya merasa untuk kadang membuat agent benar-benar berpikir sendiri, kita perlu lebih dulu menghapus cukup banyak kode dan markdown
      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
    • Dari gaya bicara ini saja sudah kelihatan kamu pakai Codex

  • 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

    • Perilaku AI cukup bisa diprediksi jika dilihat dari sudut pandang bahwa dia akan bagaimana pun caranya menipu metrik yang dijadikan target optimasi
      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

    • Saya sepenuhnya setuju
      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”
    • Akhir-akhir ini daripada membuat sesuatu langsung dengan AI, saya justru lebih banyak menghabiskan waktu untuk mereview satu konteks AI dengan konteks AI lain
      Semacam membuat mereka saling mereview hasil satu sama lain
      Meski begitu kebanyakan tetap berjalan asinkron, jadi saya bisa mengerjakan hal lain sementara itu berlangsung
    • Kalau saya sendiri tidak tahu apa yang saya tidak tahu, bagaimana saya bisa membuat sesuatu yang lebih baik daripada coding agent
      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
    • Betul. Umumnya dia cukup baik untuk membawa kita sampai titik 80%
      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

    • Saya tidak mengerti kenapa LLM dibiarkan pegang kemudi
      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
    • Untuk urusan kredensial, menurut saya begini
      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
    • Pada praktiknya saya memakai tiga mode
      1. Untuk aplikasi inti, saya yang menspesifikasikan, mengimplementasikan, dan mengetes semuanya, lalu AI hanya saya pakai untuk perapian akhir
      2. Untuk fungsi, saya biarkan AI menulisnya dan membuat kerangka test, lalu saya sering menulis ulang fungsinya sendiri
        Pendekatan ini memang banyak menghasilkan perilaku yang tidak diinginkan atau implementasi yang berlebihan, tetapi berguna untuk menghilangkan boilerplate
      3. Untuk kode eksperimen atau bagian yang kapan pun bisa dibuang, saya biarkan AI mengerjakan semuanya
        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
    • Ini sebenarnya masalah yang lebih mudah dari kelihatannya
      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
    • Biasanya saya meninjau semua kode yang ditulis Claude, dan kode yang saya tulis sendiri pun saya minta Claude review lagi
      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

    • Model yang menulis kode baru untuk melakukan hal yang sama dengan logika yang sudah ada itu bukan refactoring
      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
    • Bahkan ketika kita memutuskan menyentuh sesuatu sambil lewat, sering kali itu bukan perbaikan sama sekali
      Menurut saya ini bukan refactoring, melainkan lebih seperti menarik tuas mesin slot sekali lagi
    • Hari ini pun saya sempat menghabiskan waktu karena ini
      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
    • Ini tidak sesederhana itu
      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
    • Ini bagian yang benar-benar membuat saya penasaran
      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

    • Baru hari ini juga saya mengalaminya
      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
    • Saya juga merasakan hal serupa
      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