Tim engineering Uber menerbitkan sebuah blog yang memperkenalkan sistem internal bernama AutoClean. Sistem ini terhubung ke platform pengelolaan feature flag milik perusahaan, mencari flag yang sudah aman dimatikan, lalu membuat diff yang menghapus kode terkait. Setelah pengujian lolos, diff diserahkan kepada insinyur untuk disetujui. Dalam beberapa tahun terakhir, sistem ini telah membersihkan lebih dari 16.000 feature flag dan lebih dari 1 juta baris kode, dan hingga kini masih berjalan di beberapa monorepo Uber.
Artikel tersebut ditulis oleh Daniel Ramos dan Diego Marcilio (senior software engineer di Uber) serta Nikhil Parasaram (software engineer).
Mengapa menghapus kode itu sulit
Uber meluncurkan fitur baru secara bertahap lewat feature flag, dan ribuan flag bisa aktif sekaligus di platformnya. Setelah peluncuran selesai, cabang kondisi, fungsi bantu, titik pemanggilan, konfigurasi, dan pengujian sering kali dibiarkan di tempatnya. Menghapus satu flag berarti mengubah semua bagian itu sekaligus, sambil memastikan perilaku di lingkungan produksi sama sekali tidak berubah.
Blog tersebut juga menyebut satu biaya baru: kode mati bukan hanya membuat manusia lelah membacanya. Asisten pemrograman AI pun harus menghabiskan lebih banyak waktu dan token untuk cabang-cabang itu saat mengurai basis kode.
Pipeline tiga tahap
Tahap pertama: penulisan ulang. Agen diberi akses ke basis kode, lalu memanggil PolyglotPiranha lewat MCP. Ini adalah mesin transformasi kode yang dikembangkan dan dibuka sumbernya oleh Uber, yang menangani penyederhanaan boolean dan penghapusan kondisi. Alasan para penulis lugas: bila penyederhanaan boolean salah, hasilnya "can silently change program behavior", yakni mengubah perilaku program tanpa disadari, sehingga sebisa mungkin diserahkan kepada alat yang deterministik.
Tahap kedua: memperbaiki CI. Kegagalan sederhana ditangani oleh perbaik deterministik, misalnya menghapus nilai default yang tak terpakai atau membersihkan galat lint. Kasus yang rumit diserahkan kepada agen, contohnya menentukan apakah sebuah pengujian sebaiknya dihapus atau diubah. Wewenang tiap perbaik dibatasi ketat; perbaik pengujian hanya boleh menyentuh berkas pengujian. Siklus ini berulang sampai CI lolos atau jatah percobaan habis.
Tahap ketiga: verifikasi. Setelah CI lolos, pemeriksaan statis dijalankan terlebih dahulu, lalu diff diserahkan ke lapisan verifikasi bernama CodeCourt, tempat beberapa agen peninjau khusus memeriksanya secara paralel. Aturan yang dicantumkan blog tersebut antara lain:
- Hanya menghapus, tidak menambahkan kode baru;
- Perilaku yang dapat diamati tetap sama;
- Hanya menangani flag yang ditunjuk, tanpa ikut menghapus flag lain yang berkaitan;
- Tidak meninggalkan komentar atau jejak proses penalaran agen.
Jika satu saja aturan tidak terpenuhi, diff langsung dibatalkan dan tidak akan sampai ke tangan manusia. Para penulis menyebut bahwa beberapa sub-agen yang fokus bekerja lebih baik daripada satu agen yang memeriksa seluruh diff dari awal sampai akhir.
Dari Piranha ke agen
Fondasi AutoClean adalah Piranha, yang dibuka sumbernya oleh Uber beberapa tahun lalu. Alat itu sejak awal dibuat untuk menghapus flag kedaluwarsa dan bekerja lewat penulisan ulang statis berbasis pencocokan aturan. PolyglotPiranha kemudian memperluas mesin aturannya ke banyak bahasa pemrograman. Perubahan kali ini ada di lapisan luarnya: mesin aturan tetap memegang logika boolean yang paling rawan salah, sementara agen mengambil alih bagian yang tak sepenuhnya tercakup aturan, seperti memperbaiki pengujian dan melengkapi titik pemanggilan. Kelompok agen lain kemudian saling memeriksa hasilnya.
Blog tersebut juga blak-blakan soal beberapa pola kegagalan. Agen bisa mengubah kode produksi hanya agar pengujian lolos, menghapus pengujian yang seharusnya mempertahankan perilaku, atau berhenti terlalu dini sehingga pembersihan terhenti di tengah jalan. Bila instruksinya banyak, agen juga bisa melewatkan salah satu batasan. Masalah semantik seperti ini tidak terdeteksi oleh CI, dan pembatasan wewenang perbaik serta penambahan CodeCourt memang ditujukan untuk menjawabnya.
Artikel itu tidak menyebut tingkat keberhasilan, rata-rata waktu proses, maupun persentase diff yang dibatalkan. Kode contohnya menggunakan Go, dan cakupan untuk bahasa lain juga tidak diuraikan. Menurut penjelasan para penulis, peninjau manusia kini hanya perlu menjawab satu pertanyaan: apakah flag ini layak dihapus? Kebenaran di tingkat mekanis sudah disaring lebih dulu oleh ketiga tahap sebelumnya.
Sumber: blog resmi Uber Engineering, CocoLoop, halaman proyek PolyglotPiranha di GitHub. Angka pembersihan mengikuti total kumulatif yang diungkap blog Uber.