Manfaat Ekonomis dari Refactoring

• Setelah melakukan refactoring bertahap pada lapisan akses data Rust sepanjang 17.155 baris yang ditulis agen, token input yang dibutuhkan untuk perubahan fungsi yang sama turun dari 159.564 menjadi 27.360, atau turun 83%
• Total jumlah kode hampir tidak berubah, tetapi dengan memisahkan kode terkait ke file-file yang lebih kohesif, agen dapat membaca hanya sekumpulan file minimum yang diperlukan untuk perubahan
• Token input tidak banyak berkurang sampai file terbesar cukup diperkecil; pada akhirnya lapisan data dipecah menjadi 19 file Rust dan ukuran file terbesar turun dari 17.155 baris menjadi 3.695 baris
• Token output dan jumlah implementasi fitur hampir tidak berubah, dan Claude juga tidak mampu memilih atau menjalankan refactoring yang tepat secara konsisten sendiri, sehingga dibutuhkan arahan manusia yang aktif untuk perencanaan dan eksekusi
• Dengan harga input Sonnet 5 sebesar $3/MTok, penghematan per perubahan hanya sekitar $0,397, tetapi ini menunjukkan kemungkinan penurunan biaya yang berulang setiap kali lapisan akses data dimodifikasi setelahnya

---

File 17.155 baris yang dibuat agen

• Aplikasi pendukung kerja ini memiliki web UI dengan pembaruan dan pencarian dinamis, modal dan autosave, integrasi dengan sistem eksternal, machine learning dan analisis teks, pekerjaan latar belakang, serta lingkungan deployment otomatis
• Dari total sekitar 150 ribu baris, sekitar 120 ribu baris adalah Rust dan sisanya TypeScript serta Terraform; sebagian besar ditulis agen menggunakan Claude Code dan sebagian Cursor
• Pengembang hampir tidak pernah membaca atau meninjau kode, kecuali sesekali melihatnya karena penasaran
• Lapisan akses data tumbuh melewati 6.000 baris karena semua kueri baca/tulis mengulang konfigurasi permintaan HTTP yang sama serta encoding/decoding JSON, dan akhirnya satu file Rust mencapai 17.155 baris
• Modul ini tidak memiliki penghapusan duplikasi maupun bahasa internal, ekstraksi fungsi terbatas, dan hampir tidak ada ekstraksi kelas, tetapi memiliki antarmuka yang harus dipertahankan dan batas yang jelas sehingga cocok untuk eksperimen refactoring

Metode pengukuran dengan mengulang perubahan yang sama

• Tujuannya adalah memeriksa apakah investasi token pada refactoring saat ini bisa menurunkan konsumsi token untuk perubahan fitur di masa depan
• Karena agen tidak belajar dari pekerjaan sebelumnya, pada setiap tahap sub-agen baru diminta melakukan perubahan yang sama persis agar efek pembelajaran tidak tercampur
• Eksperimen dijalankan dalam urutan berikut
  • Menulis rencana keseluruhan sesuai prinsip refactoring yang ketat
  • Mendefinisikan perubahan representatif dalam satu prompt
  • Meminta sub-agen melakukan perubahan dan melaporkan konsumsi token untuk mengukur nilai dasar
  • Membuang hasil perubahan lalu menerapkan satu tahap refactoring
  • Mengulangi proses melakukan perubahan yang sama lagi dan membuang hasilnya
  • Mencatat biaya token, waktu eksekusi, dan jumlah baris kode di tiap tahap
• Karena Claude tidak dapat memberikan jumlah token real-time secara andal, agen diminta melaporkan jumlah karakter kirim/terima, lalu jumlah karakter dibagi 4 dengan tiktoken untuk mendekati jumlah token

Hasil pengukuran per tahap

• Pada kondisi dasar, lapisan akses data dan file terbesar sama-sama 17.155 baris, total kode Rust adalah 50.359 baris, dan perubahan representatif memerlukan 159.564 token input, 1.705 token output, serta 342 detik
• Setelah 15 tahap, lapisan akses data menjadi 16.608 baris, file terbesar 3.695 baris, total kode Rust 49.812 baris, dengan 27.360 token input, 2.113 token output, dan waktu eksekusi 454 detik
• Pada tahap-tahap menengah, token input ikut turun seiring mengecilnya file terbesar
  • Setelah tahap 7, ekstraksi queries.rs membuat file terbesar menjadi 15.670 baris dan input turun menjadi 151.850 token
  • Setelah tahap 8, ekstraksi traits.rs membuatnya menjadi 13.845 baris dan input menjadi 132.558 token
  • Setelah tahap 12, pemisahan store/ menurunkannya menjadi 9.269 baris dan input hingga 104.080 token
  • Setelah pemisahan store/ terakhir, file terbesar menjadi 3.695 baris dan input anjlok menjadi 27.360 token
• Lapisan akses data akhir terdiri dari 19 file Rust, dan file terbesar menjadi library pengujian
• Pada refactoring lanjutan, pendekatan yang sama dapat diterapkan ke file pengujian tersebut

Mengapa token input turun 83%

• Token input untuk pekerjaan yang sama turun dari 159.564 menjadi 27.360, sehingga menghemat 132.204 token
• Karena total jumlah kode di lapisan akses data hampir tidak berubah, ini bukan hasil dari berkurangnya kode yang perlu dibaca
• Agen berhasil mengidentifikasi kumpulan file minimum yang dibutuhkan untuk pekerjaan, lalu membaca area kode yang makin kecil; ini juga terlihat pada output penalaran dan ringkasan pembacaan file Claude Code
• Jika file hanya dipecah kecil-kecil secara acak, agen justru harus membaca banyak file untuk mencari kode terkait sehingga efek yang sama sulit didapat
• Penurunan terbesar terjadi pada pemisahan terakhir, tetapi itu dimungkinkan karena tahap-tahap sebelumnya telah mengekstrak duplikasi dan membentuk struktur inti yang berulang
• Urutan ini bukan dirancang sebelumnya demi penghematan biaya, melainkan muncul dari proses refactoring umum: menghapus duplikasi lokal terlebih dahulu, menampakkan inti bersama, lalu memecahnya menjadi file-file kecil

Token output dan dampak finansial

• Token output yang dihasilkan saat menulis perubahan representatif hampir tidak berubah, sehingga refactoring tidak berhasil mengurangi ukuran perubahan aktual
• Harga token output memang 5 kali token input, tetapi jumlah absolutnya jauh lebih kecil
• Dengan harga input Sonnet 5 sebesar $3/MTok, penghematan per perubahan adalah sekitar 39,7 sen
• Belum diketahui apakah penghematan akan terus terakumulasi pada debugging, fitur yang lebih kompleks, atau refactoring skala seluruh codebase, dan juga belum diketahui biaya refactoring itu sendiri
• Juga belum jelas apakah refactoring yang menurunkan token output memungkinkan, karena pada perubahan representatif yang sederhana, noise dari generasi kode nondeterministik menutupi perbedaan akibat perubahan struktur

Refactoring bersama Claude

• Claude tidak bisa melihat kode lalu memilih sendiri refactoring yang akan diterapkan; hasil nyata sesuai dengan pekerjaan yang secara langsung diperintahkan dalam prompt
• Walau ada tahap refactoring eksplisit dalam harness pengembangan, Claude tidak memperbaiki file 17.155 baris itu melalui mekanisme tersebut
• Dalam proses perencanaan, Claude Code menemukan ekstraksi fungsi sebagai langkah pertama, sedangkan Claude.ai bahkan mengidentifikasi ekstraksi seluruh kelas klien
• Untuk perubahan mekanis digunakan skrip Python dengan grep dan sed, tetapi skrip itu sering bingung karena indentasi
• Pemisahan file store yang paling bernilai terlewat pada percobaan pertama dan diterapkan lagi pada tahap lanjutan; karena itu jumlah tahap pada hasil pengukuran tidak cocok dengan tahap rencana di lampiran
• Seluruh eksperimen memakan waktu sekitar 8 jam dan sebagian besar berjalan tanpa pengawasan
  • Setelah 6 jam 40 menit, ditemukan tahap yang terlewat dan dilakukan satu kali intervensi
  • Penyebab utama lambatnya eksekusi tes bukan Wi‑Fi hotel yang lambat, melainkan cache build sementara Cargo yang tumbuh terlalu besar

Prompt perubahan representatif

• Setiap sub-agen hanya diberi codebase dan dokumen arsitektur, lalu diminta mengimplementasikan trait publik asinkron ItemWatchStore yang sama
• Trait itu mencakup tiga metode berikut
  • watch_item(&self, item_id: &str, user_id: &str) -> Result<()>
  • unwatch_item(&self, item_id: &str, user_id: &str) -> Result<()>
  • watched_items_for_user(&self, user_id: &str) -> Result<Vec<String>>
• Informasi watch disimpan di koleksi Firestore item_watches dengan field itemId, userId, createdAt
• Mengembalikan Vec<String> berisi item ID tanpa struct record Rust terpisah
• Pada FakeStore ditambahkan field Vec<(String, String)> di memori, dan pada FirestoreStore implementasi dibuat dengan pola HTTP yang sudah ada
• Di akhir respons, agen diminta mencetak JSON berisi file yang dibaca dan jumlah karakternya, serta jumlah karakter respons, dan diinstruksikan untuk tidak meng-commit kode

Rencana refactoring yang diterapkan

• Tahap 1 — ekstraksi kelas FirestoreClient

  • Memisahkan tanggung jawab koordinasi kueri domain dan pengiriman HTTP Firestore
  • Memindahkan reqwest::Client, project_id, MetadataAuth, serta penanganan URL dan header autentikasi ke struct baru
  • Dalam rencana, ini mengurangi sekitar 1.200 baris dari implementasi FirestoreStore dan menambah sekitar 120 baris ke klien

• Tahap 2 — ekstraksi fungsi extract_doc_id, new_link

  • Menyatukan ekstraksi ID pada 20 parser dokumen dan pembuatan Link yang berulang 62 kali
  • Diperkirakan mengurangi sekitar 500 baris

• Tahap 3 — ekstraksi fungsi pipeline kueri link

  • Menyatukan pola pengumpulan hasil kueri di sekitar 15 tempat dan pencarian satu target ID di sekitar 8 tempat
  • Diperkirakan mengurangi sekitar 200 baris

• Tahap 4 — ekstraksi fungsi kondisi link FakeStoreInner

  • Memisahkan transformasi inner.links.iter() yang berulang di sekitar 15 metode menjadi dua metode
  • Diperkirakan mengurangi sekitar 120 baris

• Tahap 5 — pengenalan fungsi pembuat nilai Firestore

  • Mengganti ekspresi json! untuk string, timestamp, dan lainnya yang berulang lebih dari 128 kali dengan empat pemanggilan fungsi
  • Mengubah macro multi-baris menjadi pemanggilan satu baris, diperkirakan mengurangi sekitar 80 baris

• Tahap 6 — ekstraksi FieldsBuilder

  • Menyatukan pola pembuatan field map pada sekitar 20 encoder ke dalam builder
  • Mengurangi encoder sekitar 40 baris menjadi sekitar 12 baris, dengan total pengurangan yang diperkirakan 500–600 baris

• Tahap 7 — pemisahan queries.rs

  • Memindahkan 32 konstanta LinkQuery dan tipe terkait ke modul terpisah
  • Mengurangi sekitar 800 baris dari mod.rs tanpa mengubah pemanggil yang ada

• Tahap 8 — pemisahan traits.rs

  • Memindahkan 17 trait publik dan tipe error terkait lalu mengekspornya kembali
  • Mengurangi sekitar 1.900 baris dari mod.rs, tetapi file baru juga menjadi sekitar 1.900 baris

• Tahap 9 — pemisahan traits/ per domain

  • Membagi trait ke planning.rs, content.rs, people.rs, system.rs
  • Tanpa mengubah definisi maupun pemanggil, ukuran file dibatasi ke sekitar 300–650 baris per file

• Tahap 10 — pemisahan codec.rs

  • Memindahkan encoder/decoder dokumen, parser, FieldsBuilder, dan fungsi pembuat nilai
  • Setelah tahap 6, ini menjadi modul sekitar 400–500 baris dan mengurangi sekitar 500 baris dari mod.rs

• Tahap 11 — pemisahan fake_store.rs

  • Memindahkan FakeStore, FakeStoreInner, dan 18 implementasi trait
  • Mengurangi sekitar 4.700 baris dari mod.rs

• Tahap 12 — pemisahan implementasi FirestoreStore

  • Menempatkan struct, constructor, FirestoreClient, dan MetadataAuth di store/mod.rs, lalu membagi implementasi trait ke file-file per domain
  • Mengubah file sekitar 10.000 baris menjadi 10 file dengan ukuran masing-masing 120–650 baris, dan menjadikan mod.rs file re-export sekitar 100 baris

• Tahap 13 — menempatkan tes bersama modul target

  • Tanpa mengubah kode tes, memindahkannya ke bawah masing-masing file implementasi
  • Mengurangi sekitar 2.000 baris dari mod.rs, dan menambah 200–700 baris tes terkait ke tiap file

Keterbatasan dan eksperimen lanjutan

• Token yang dipakai untuk menulis dan menjalankan rencana refactoring tidak dihitung terpisah, sehingga biaya investasi refactoring tidak bisa dihitung dengan tepat
• Batas atas berdasarkan total penggunaan pada rentang waktu tersebut adalah 5 juta token, tetapi ini mencakup dua kali penulisan rencana, eksperimen dan desain perubahan representatif, serta pekerjaan lain
• Objek eksperimen masih berada pada tahap greenfield dan merupakan satu aplikasi besar yang dibangun serta dikelola satu pengembang, sehingga hasilnya tidak bisa digeneralisasi
• Pekerjaan lanjutan perlu mencakup pengukuran token refactoring yang akurat, perubahan yang lebih kompleks, refactoring dengan cakupan lebih luas, refactoring berkelanjutan, dan perbandingan nilai relatif antarpendekatan
• Eksperimen ini menjadi titik awal untuk mengukur sekaligus nilai waktu/uang dari refactoring dan biaya refactoring itu sendiri

[GN⁺]

Komentar Hacker News

• Menarik melihat praktik terbaik pengembang yang dulu diabaikan oleh sebagian besar perusahaan IT diciptakan ulang sebagai praktik terbaik AI
  Dulu, menaruh dokumentasi di dalam kode, tidak sekadar melempar tugas Jira, melainkan memberi konteks seluruh proyek, dan melakukan refactoring demi produktivitas jangka panjang dianggap membosankan
  Sekarang, ketika hal yang sama dikemas sebagai menaruh dokumentasi AI di kode dan CLAUDE.md, tidak mengendalikan detail lewat prompt, dan melakukan refactoring demi produktivitas AI, orang justru menganggapnya menarik

  • Jauh lebih mudah membuat agen AI melakukan pekerjaan yang sama secara konsisten dibanding rekan kerja manusia
    Manusia, meski tahu cara yang benar, bisa sibuk atau kehilangan fokus, sedangkan agen tidak bosan dengan tugas yang membosankan, sehingga prosedur yang terbukti efektif untuk manusia tetapi sulit diterapkan secara konsisten kini menjadi realistis
    Berdasarkan spesifikasi bersama, agen terpisah digunakan untuk menulis implementasi dan pengujian, lalu agen audit memverifikasinya agar hasil mereka tidak saling terkontaminasi; ini adalah penerapan luas dan konsisten dari cleanroom engineering yang dikembangkan IBM untuk manusia pada tahun 1980-an, kini diterapkan pada AI
  • Tokoh yang terkait dengan tulisan ini adalah Martin Fowler, yang lebih dari 20 tahun lalu menulis buku Refactoring dan mempopulerkan istilah tersebut
    Ini bukan membungkus praktik lama agar tampak baru demi tren AI, melainkan menunjukkan dengan bukti bahwa praktik terbaik yang berusia lebih dari 20 tahun masih tetap relevan
  • Perbedaan besar antara sebelum dan sesudah AI adalah bahwa manusia memiliki kemampuan mengelola konteks jangka panjang yang cukup baik
    Agen harus mempelajari ulang konteks di setiap sesi, sehingga nilai praktik terbaik menjadi jauh lebih besar dan efeknya juga langsung terasa
  • Berkat demam AI, kini jadi mungkin mendapatkan anggaran untuk perbaikan developer experience yang sudah lama diinginkan, tetapi alasan di baliknya terasa pahit karena keliru
    Meski begitu, menyenangkan bisa menjalankan CLI 100 kali selama satu jam untuk menguji kegunaan flag baru
  • Manusia tetap bisa menghasilkan sesuatu bagaimanapun juga, meski harus bekerja dengan dokumen usang di SharePoint, konteks keseluruhan yang hanya terdengar sekilas saat rapat, dan prioritas refactoring yang rendah; akibatnya kualitas dan jadwal memang memburuk
    Sebaliknya, AI akan bekerja sangat buruk atau bahkan tidak bisa berfungsi sama sekali tanpa fondasi seperti ini, sehingga praktik rekayasa yang sehat bukan lagi perbaikan jangka panjang, melainkan prasyarat mutlak
    Bahkan jika efek bersihnya sama sekali nol, memasukkan AI ke dalam alur kerja tetap berguna karena memberi alasan untuk memperkenalkan praktik pengembangan yang semestinya

• Tulisan ini bagus karena mengkritik AI secara konkret dan kuantitatif berdasarkan bagaimana alat AI benar-benar digunakan
  Dibanding tulisan yang hanya membahas risiko sosial secara samar tanpa contoh penggunaan nyata, tulisan yang menunjukkan dengan ukuran apa yang tidak bisa dilakukan AI jauh lebih bermanfaat
  Dengan alasan yang sama, laporan yang mewawancarai anggota Boko Haram untuk menyelidiki bagaimana AI digunakan dalam terorisme juga terasa mengesankan

• Saya sangat menyukai refactoring yang dilakukan langsung tanpa AI
  Tidak ada perubahan yang terlihat, tetapi ada kepuasan karena membuat situs web yang hasilnya mungkin tidak langsung tampak sekarang menjadi jauh lebih mudah dikelola di masa depan
  Menemukan masalah yang sebenarnya sudah diselesaikan oleh pola mapan tetapi kembali dipecahkan oleh kode jalan pintas aneh dari masa lalu, lalu memindahkannya ke arah praktik terbaik tanpa menambah utang teknis baru, terasa menyenangkan seperti memecahkan teka-teki
  Saya bahkan pernah mengimplementasikan semuanya sendiri secara seadanya, termasuk autentikasi, dan mempelajari cara kerja internalnya dengan cara yang sulit; hasilnya, saya juga mendapatkan bahan refactoring yang bisa dinikmati selama 10 tahun ke depan

  • Saat membaca Refactoring karya Fowler, saya ragu apakah itu akan efektif untuk kode sains dan riset, tetapi setelah mencobanya secara eksperimental pada struktur kode yang tidak memuaskan, sudut pandang saya berubah total
    Saya jadi memahami secara konkret maksud dari pernyataan bahwa codebase adalah satu sistem, dan mulai melihatnya pada level yang lebih tinggi sebagai organisasi kontinu atau jaring yang bisa ditarik dan ditekan
    Bahwa AI bisa menghilangkan proses belajar seperti ini menyoroti masalah bagi pengembang junior. Untuk mendapatkan intuisi, tidak ada jalan lain selain menggali sendiri secara mendalam, dan meski Naur sudah memperingatkannya 40 tahun lalu, pelajaran ini terus dilupakan
  • Mungkin karena rasanya memberi hadiah dopamin seperti saat melihat layar defragmentasi disk Windows 98
  • Perasaan itu adalah kebanggaan sebagai perajin. Bagi yang paham, tidak perlu penjelasan; bagi yang tidak paham, penjelasan apa pun tidak akan cukup
  • Saya penasaran sejauh mana test suite dibangun sebagai semacam pengaman untuk mencegah regresi selama refactoring
  • Menyenangkan mempelajari berbagai pola refactoring dan contoh penerapannya di dunia nyata

• Menurut saya, saat agen melakukan refactoring, keterlibatan manusia itu wajib
  Model generatif bisa saja menemukan bagian yang terlewat saat fokus pada pekerjaan awal melalui model peninjau, tetapi masih diragukan apakah ia benar-benar memahami tujuan keseluruhan proyek dan cara kode terikat satu sama lain sehingga bisa menilai duplikasi atau struktur yang lebih elegan
  Menyerahkan refactoring kepada coding agent itu mirip seperti meminta ahli bedah trauma meningkatkan kemampuan atletik; untuk melakukannya dengan benar dibutuhkan sudut pandang holistik
  Hanya memecah file besar menjadi beberapa file tetaplah refactoring yang dangkal. Tanpa teori tentang kode mana yang harus tetap bersama dan apa yang perlu diekstrak menjadi fungsi utilitas, itu lebih mirip memecah bilangan besar menjadi bilangan kecil lalu menjumlahkannya kembali daripada faktorisasi
  Agen kadang membuat sistem yang menyimpan dan menghitung ulang nilai yang sebenarnya sudah diambil dari API, tetapi manusia bisa melihat seluruh proyek dan dengan cermat menemukan bahwa data yang dibutuhkan sudah ada pada key tertentu di JSON

  • LLM saat ini juga cukup baik jika diberi instruksi refactoring yang spesifik untuk bagian kode tertentu. Misalnya, ia bisa menangani permintaan rumit seperti mengimplementasikan pola Command dengan functools.partial alih-alih data class
    Batas file merepresentasikan batas subsistem logis sehingga memudahkan penalaran, dan konsep bahwa isi file lain pada dasarnya diperlakukan sebagai sesuatu yang opak juga sangat banyak dalam data pelatihan
    Saya rasa kelebihan struktur ini bukan cuma sifat kebetulan dari kognisi manusia, tetapi juga punya sisi objektif
  • Dengan manusia di sampingnya menjelaskan arah, refactoring yang biasanya memakan waktu beberapa bulan sebagian besar selesai dalam sekitar satu minggu
    Pengalaman refactoring, cara menangani codebase orang lain, dan kemampuan menjelaskan niat masa lalu dan saat ini sebagai perancang asli sangat membantu
    Bahasanya non-mainstream, dengan sedikit kerentanan dependensi dan mudah ditangani LLM, dan setelah bias ke JavaScript serta Python disingkirkan, kecepatan kerja meningkat besar
    Ini adalah proyek JSR-223 yang menulis skrip dalam beberapa bahasa populer, tetapi semuanya dijalankan di JVM sesuai kebutuhan lingkungan: https://en.wikipedia.org/wiki/Scripting_for_the_Java_Platform
  • Penilaian bahwa agen tidak bisa melakukan refactoring sudah usang; sekarang kemampuannya sangat bagus
    Di pasar kerja ini, kita harus menggunakan coding agent berbasis model frontier terbaru dan memahami dengan tepat kemampuan serta batasannya; jika memberi penilaian sebaliknya saat wawancara, itu bisa menjadi alasan gagal

• Konteks yang ringkas bukan hanya mengurangi konsumsi token, tetapi juga meningkatkan penalaran dan memungkinkan lebih banyak lapisan dimasukkan ke dalam satu konteks untuk ditangani secara cerdas
  Refactoring menuju abstraksi yang baik menghasilkan perangkat lunak yang melakukan generalisasi lebih baik, sehingga lebih mungkin benar bukan hanya pada kasus yang diuji tetapi juga pada kasus hasil interpolasi dan ekstrapolasi
  Ada matematika teori informasi dan Bayes yang mendukung hal ini, dan perangkat lunak yang lebih efisien secara ekonomi dan energi menjadi lebih akurat terasa seperti kebetulan yang indah
  Intinya adalah mengurangi entropi kode

  • Di mana pun di dunia dan alam semesta, pengurangan entropi bisa dipandang sebagai tindakan membangun sesuatu
  • Jika keterbacaan manusia dibuang dari tujuan dan fungsi objektif hanya pengurangan konsumsi token, sulit tahu ke mana kita akan sampai
    LLM sudah cukup baik menalar makna bahkan dengan konteks yang sedikit

• Menarik bahwa ada data yang ditunjukkan, dan itu sesuai dengan kesan saya bahwa LLM sangat diuntungkan oleh kode yang terpisah dengan baik, tetapi kemampuan mereka untuk membuat kode seperti itu sendiri tidak terlalu hebat
  Kebanyakan pengembang manusia pun mungkin sama

  • Saya juga memasukkan waktu untuk membersihkan kode berantakan sebagai pos anggaran, dan saat ini pun sedang melakukan pekerjaan itu di jendela sebelah
    Secara keseluruhan keuntungan AI besar, tetapi tetap perlu waktu untuk merapikan, dan saya masih merasa setiap baris tetap harus dibaca
    Saya menunda sebagian review agar tidak menghambat progres tim lain, lalu belakangan membayar utang teknis yang lebih besar dari biasanya, tetapi melonggarkan bottleneck lebih dulu memang layak
    AI telah membuat utang teknis lebih mudah ditarik dalam segala arti, dan jika diarahkan dengan baik juga cukup mampu melunasinya. Namun hasilnya berbeda-beda pada tiap orang: https://news.ycombinator.com/item?id=49035455
  • Dalam kondisi default saya melihat hasil yang sama, tetapi jika arah refactoring diberikan secara spesifik, ia bisa menghasilkan kode yang lebih terpisah dengan baik
    Sangat membantu jika ditunjukkan contoh kode yang tersusun baik atau repositori open source untuk memperlihatkan apa yang harus dan tidak boleh dilakukan

• Sebagian besar manfaat ekonomi dari refactoring datang bukan dari penghematan token, melainkan dari peningkatan pemahaman manusia
  Kita bisa lebih cepat menyelesaikan panggilan insiden jam 3 pagi, mengurangi bug yang masuk ke lingkungan produksi, dan merilis lebih cepat daripada pesaing
  Yang terpenting, ketika orang memahami sistem, mereka jadi lebih bersedia memikul tanggung jawab dan kepemilikan, sehingga saat masalah muncul mereka lebih cepat memperbaikinya dan lebih proaktif terjun ke bagian yang perlu ditingkatkan

• Poin utamanya adalah bahwa refactoring mengurangi konsumsi token, dan bagus bahwa efeknya diukur secara kuantitatif alih-alih dibahas secara abstrak
  Namun Fowler mengatakan dalam 《Refactoring》 bahwa prasyarat penting refactoring adalah pengujian yang kokoh, dan terlepas dari AI saya rasa manfaat yang sesungguhnya ada di sini
  Pengujian yang baik mencegah regresi yang dibuat manusia maupun robot, dan meninggalkan spesifikasi yang bisa dibaca keduanya dalam bentuk kode: https://www.oreilly.com/library/view/refactoring-improving-the/9780134757681/

  • Tulisan itu dimuat di martinfowler.com, tetapi bukan ditulis Martin; penulisnya tercantum sebagai CTO Thoughtworks, Giles Edwards-Alexander
  • Inti sebenarnya adalah bahwa penghematannya hanya di kisaran beberapa puluh sen
    Jika harga Sonnet 5 dihitung 3 dolar per MTok, maka jumlah yang dihemat pada perubahan mendatang yang menyentuh lapisan akses data adalah 39,7 sen
    Jika mempertimbangkan penurunan harga OpenAI, model terbuka, dan tren jangka panjang turunnya harga token, itu mungkin tidak sebanding dengan biaya developer senior dengan tarif sekitar 100 dolar per jam untuk memandu refactoring

• Kode yang dibuat agen telah menjadi gumpalan raksasa yang seolah hanya bisa dibaca dan dipahami oleh agen itu sendiri, dan di sini realitas di lapangan lebih penting daripada apakah itu fitur, bug, atau sifat emergen
  Untuk menangani kode yang dihasilkan alat AI, kita justru kembali menjadi bergantung pada alat AI
  Namun manusia juga sejak dulu membuat file yang sangat besar dan monorepo, dan berkat LLM pekerjaan mengedit serta me-refactor itu akhirnya menjadi cukup tertangani
  Dalam situasi ketika codebase sudah terlalu besar dan berantakan untuk dipahami manusia, LLM mungkin bisa menyelamatkan kita; secara pribadi saya membenci file raksasa, tetapi prinsip perapian ala Fowler mungkin tidak lagi penting, dan itu terasa pahit

  • Pernyataan bahwa kode agen hanya bisa dipahami oleh agen pada dasarnya tidak benar; jika terasa begitu, berarti cara menggunakan LLM-nya yang keliru
  • Kode buruk memang selalu ada, tetapi AI adalah masalah baru yang memperbesar cakupan dampak dari perekrutan yang buruk hingga 1.000 kali lipat
    Bahkan karyawan yang biasa-biasa saja atau sesekali bagus pun kini bisa mengeksekusi dengan sangat cepat hal-hal yang dulu terhalang prosedur perusahaan, dan itu justru bisa mengubah mereka menjadi karyawan yang buruk
  • Bahkan pada codebase yang 100% ditulis LLM, tidak ada masalah untuk membacanya atau menemukan bagian yang diinginkan, dan itu tidak lebih sulit dibanding saat saya menulisnya sendiri
  • Saya belum pernah melihat kode buatan agen lebih buruk daripada kode terburuk buatan manusia
    Jika agen membuat file atau fungsi yang terlalu besar, cukup beri instruksi untuk tidak melakukannya dan mereka akan mengikuti

• Saya menganggap refactoring adalah salah satu tanda terbaik dari tim pengembang yang sehat
  Refactoring sendiri memang punya manfaat, tetapi nilainya sering tidak terlihat dari sudut pandang product owner atau daftar tugas fitur
  Jika tim melakukan refactoring demi kesehatan keseluruhan perangkat lunak, itu berarti pengembang merasa nyaman mengajukan usulan demi perangkat lunak yang baik, dan usulan itu diterima dengan serius
  Pembusukan perangkat lunak paling parah terjadi ketika tim tidak punya motivasi atau kewenangan untuk mewujudkan visi tentang perangkat lunak berkualitas tinggi, dan jika tim bisa mengikuti penilaian mereka tentang keunggulan, itu umumnya pertanda baik
  Tentu ada juga bentuk berlebihan seperti menulis ulang total dari Ruby, Node, Rust, lalu kembali lagi ke teknologi yang ramah agen, tetapi di lingkungan perusahaan jauh lebih umum melihat tim yang merasa tidak mendapat izin untuk melakukan perbaikan