Di era Pengkodean AI, kebiasaan pemrograman yang baik tetap penting


Belakangan ini saya sedang membuat sebuah benchmark Agen, dan menemukan bahwa tidak cukup sederhana menilai tingkat kompleksitas tugas pemrograman terhadap AI dari sudut pandang pengembang.
Misalnya sebuah tugas refaktor: memecah sebuah file besar berisi ribuan baris menjadi lebih dari sepuluh modul kecil berdasarkan fungsi.
Tugas ini sebenarnya tidak terlalu sulit bagi pengembang, pekerjaan utamanya adalah memindahkan kode, mengatur imports, melakukan kompilasi dan verifikasi, bahkan pemula pun bisa menyelesaikannya.
Jadi saya berpikir untuk menggunakan tugas sederhana sebagai benchmark, tetapi hasilnya malah di luar dugaan.
Claude Code menilai tugas ini cukup besar, mencoba membagi sebagian, mengajukan PR dan menulis Future work untuk dilakukan secara bertahap.
Agent saya sendiri “dipaksa keras”, mendorong ke arah pemecahan lengkap yang lebih mendalam, tetapi biayanya juga sangat jelas: konsumsi Token puluhan kali lipat Claude, dan banyak waktu dihabiskan untuk membaca file berulang, memperbaiki error kompilasi, membaca lagi, memperbaiki error lagi.
Ini membuat saya sadar bahwa tugas yang tampaknya sederhana bagi manusia belum tentu sederhana bagi Agent.
Bagi manusia, refaktor semacam ini seringkali hanya “memindahkan bagian ini ke sana”. Tapi bagi Agent, ia harus terlebih dahulu membaca file besar secara bertahap, mengingat fungsi dan pengujian mana yang terkait, lalu menghasilkan sejumlah perubahan lintas file, dan akhirnya menambal celah satu per satu melalui error kompilasi.
Tampaknya seperti pekerjaan mekanis, tetapi sebenarnya menjadi tugas dengan biaya Token tinggi dan manajemen status yang kompleks.
Beberapa waktu lalu saya melihat ada yang bilang, di era Pengkodean AI, prinsip pemecahan modul tidak lagi begitu penting, karena manusia juga tidak membaca kode secara mendalam. Sekarang saya tidak begitu setuju.
Batas modul yang jelas, ukuran file yang sesuai, dan dependensi yang sederhana tidak hanya memudahkan manusia membaca, tetapi juga membantu mengurangi kompleksitas tugas bagi Agent.
Dari sudut pandang lain, alat baca dan ubah file untuk Agent saat ini juga kurang nyaman untuk refaktor semacam ini.
Agent Pengkodean yang mengubah file, utamanya masih berupa penggantian teks. Misalnya Claude Code biasanya menggunakan pola old_string / new_string: pertama memberikan teks lama, lalu menggantinya dengan teks baru.
Codex biasanya memakai apply_patch: menghasilkan patch seperti diff git yang menyatakan mengganti konten lama dengan yang baru.
Keduanya cocok untuk modifikasi kecil, tetapi jika harus menghapus bagian besar kode lama, atau memindahkan sekumpulan fungsi ke file lain, model seringkali harus membaca konten asli ke dalam konteks terlebih dahulu, lalu menghasilkan satu bagian pengganti atau diff yang besar.
Jadi saya kemudian memberi petunjuk ke Agent, agar terlebih dahulu menggunakan skrip, sed, perl, dan alat sejenis untuk memecah file besar secara kasar, langsung menghapus konten lama dan menulis ke file baru, lalu secara perlahan memperbaiki satu per satu.
Hasilnya, tingkat keberhasilannya jauh meningkat.
Secara default, Agent tidak akan melakukan ini, karena dalam sistem prompt-nya akan sangat ditekankan agar Agent menggunakan alat bawaan untuk mengubah file, bukan alat command line.
Lebih jauh lagi, mungkin Agent Pengkodean perlu alat pengeditan yang lebih canggih.
Bukan hanya memberi antarmuka “mengganti teks”, tetapi juga membangun struktur kode melalui parser, LSP, atau compiler, sehingga Agent bisa melakukan refaktor seperti IDE: memindahkan fungsi, menghapus blok impl, mengatur imports.
Saya tidak tahu apakah ada yang sudah mencoba hal ini.
Secara keseluruhan, meskipun di era Pengkodean AI, kebiasaan pemrograman yang baik tetap memiliki nilai.
Sebisa mungkin di awal, melalui rekayasa harness, ubah kebiasaan pemrograman yang baik menjadi cara kerja default Agent, jauh lebih murah daripada melakukan refaktor di kemudian hari.
Lihat Asli
Halaman ini mungkin berisi konten pihak ketiga, yang disediakan untuk tujuan informasi saja (bukan pernyataan/jaminan) dan tidak boleh dianggap sebagai dukungan terhadap pandangannya oleh Gate, atau sebagai nasihat keuangan atau profesional. Lihat Penafian untuk detailnya.
  • Hadiah
  • Komentar
  • Posting ulang
  • Bagikan
Komentar
Tambahkan komentar
Tambahkan komentar
Tidak ada komentar
  • Sematkan