Generasi Kode AI Memicu Kendala Tinjauan Kode karena Para Insinyur Kesulitan

Penulis: The Pragmatic Engineer

Diterjemahkan oleh Deep潮 TechFlow

Panduan DeepChain: AI semakin cepat dalam menulis kode, tetapi yang memeriksa kode tetap manusia. Kontradiksi ini sedang berkembang menjadi sebuah krisis: insinyur tenggelam dalam PR yang dihasilkan AI, entah karena lelah mengurus pemeriksaan yang tidak teliti, atau langsung menyetujui tanpa memeriksa karena AI tidak melaporkan kesalahan. Perusahaan besar saling membangun alat sendiri untuk mengatasinya, tetapi hingga kini belum ada jawaban standar.

Hai, saya Gergely, ini adalah edisi gratis tambahan dari Pragmatic Engineer Newsletter. Setiap edisi, saya melaporkan tentang perusahaan teknologi besar dan startup dari perspektif insinyur berpengalaman dan pemimpin teknik. Hari ini kita membahas salah satu dari empat topik dari jurnal The Pulse. Artikel ini sudah dikirimkan kepada pelanggan lengkap seminggu yang lalu. Jika email ini diteruskan kepada Anda, Anda dapat berlangganan di sini.

Saya mendengar bahwa salah satu hal paling diperhatikan oleh para pemimpin teknik adalah bagaimana mengatasi beban tinjauan kode yang terus meningkat. Topik ini telah ada sejak lama, dan sekarang percakapan semacam ini tampaknya semakin sering terjadi.

Bagi saya, ini dimulai pada Januari tahun ini, ketika Opus 4.5 dan GPT 5.4 mulai menulis lebih banyak dan lebih banyak kode yang lebih baik di sebagian besar perusahaan. Sekitar saat itu, orang-orang tingkat direktur mulai membahas bahwa bottleneck dalam pengembangan perangkat lunak berpindah dari tahap pemrograman ke tahap tinjauan.

Sejak Februari, alat tinjauan kode AI mengalami pertumbuhan pesat untuk mengatasi peningkatan beban, dengan eksperimen dan adopsi alat tinjauan kode AI khusus seperti CodeRabbit, Greptile, Qodo, dan SonarQube (sekarang juga Gitar) yang meledak-ledak. Selain itu, alat-alat yang disediakan langsung oleh alat pengkodean, seperti Claude Code review, Cursor review, dan GitHub Copilot review. Kemudian, alat-alat sebelumnya yang tidak terlibat dalam tinjauan kode tetapi memiliki konteks terhadap kode base juga bergabung di bidang ini, seperti Seer AI reviews dari Sentry dan Linear code reviews.

Perusahaan besar sedang membangun alat internal untuk meningkatkan pengalaman tinjauan kode. Code Inbox dari Uber adalah salah satu contohnya:

Smart Allocation adalah fitur dalam Code Inbox yang digunakan untuk mempercepat proses tinjauan:

Gambar: Pengaturan penugasan cerdas (Smart assignment) Code Inbox untuk mempercepat proses tinjauan. Sumber: The Pragmatic Engineer

Selain itu, ada fitur profil risiko untuk mengevaluasi dampak perubahan dan mendorong pengembang untuk memberikan perhatian khusus pada perubahan berisiko tinggi:

Gambar: Fitur Risk Profiles dari Code Inbox, yang memperkirakan risiko perubahan kode dan menyarankan fokus utama. Sumber: The Pragmatic Engineer

Kami telah melaporkan bagaimana Uber menggunakan AI dalam pengembangan perangkat lunak, dan bukan hanya Uber: Cloudflare (AI Code Reviewer), Faire (Fairey), HubSpot (Sidekick), dan banyak perusahaan lain juga membangun alat untuk membuat proses tinjauan kode mereka lebih lancar, karena mereka menemukan bahwa implementasi internal lebih efektif daripada mengintegrasikan solusi pihak ketiga.

Cara lain adalah memikirkan bagaimana memverifikasi kode, bukan hanya meninjau kode. Mudah diucapkan, sulit dilakukan; secara teori, pengujian yang komprehensif seharusnya dapat memverifikasi bahwa kode berfungsi sesuai harapan. Tetapi berapa banyak pengujian yang dianggap 'komprehensif'? Jenis pengujian apa yang kita maksud? Apakah pengujian integrasi dan pengujian end-to-end juga termasuk? Bagaimana dengan fuzz testing? Bagaimana dengan metode formal? Bagaimana cara memverifikasi bahwa pengujian baru mencakup fungsionalitas sesuai harapan? Bagaimana kita menghubungkan semua ini dengan observabilitas?

Ulasan kode yang terlalu mendalam sedang membuat insinyur kelelahan dan menyebabkan penurunan kualitas ulasan. Saya sering mendengar kabar bahwa pengembang melihat orang lain tidak lagi mampu melakukan ulasan kode dengan sungguh-sungguh, dan jika ulasan AI tidak memberikan masukan substansial, mereka langsung melewatkannya. Sementara itu, para pengembang yang tetap berkomitmen untuk memberikan usaha dan waktu yang sama seperti sebelumnya dalam ulasan kode merasa tenggelam oleh PR sampah AI yang dikirimkan kepada mereka.

Masalah ada, tetapi solusinya terasa lebih seperti eksperimen.