Penulis: The Pragmatic Engineer
Diterjemahkan oleh Deep潮 TechFlow
Pengantar Deep潮: AI semakin pantas menulis kod, tetapi pemeriksaan kod masih dilakukan oleh manusia. Kontradiksi ini sedang berkembang menjadi sebuah krisis: jurutera ditenggelamkan oleh PR yang dihasilkan AI, sama ada terlalu letih untuk memeriksa dengan teliti, atau terus membenarkan tanpa pemeriksaan kerana AI tidak melaporkan ralat. Syarikat besar sedang membangun alat sendiri untuk mengatasi ini, tetapi sehingga kini tiada jawapan standard.
Hai, saya Gergely, ini adalah edisi tambahan percuma dari Pragmatic Engineer Newsletter. Setiap edisi, saya melaporkan mengenai syarikat teknologi besar dan permulaan dari perspektif jurutera berpengalaman dan pemimpin kejuruteraan. Hari ini, kita membincangkan salah satu daripada empat topik dalam edisi The Pulse sebelumnya. Pelanggan penuh telah menerima artikel ini seminggu yang lalu. Jika e-mel ini dihantar semula kepada anda, anda boleh berlanggan di sini.
Saya mendengar bahawa satu perkara yang paling diperhatikan oleh pemimpin kejuruteraan ialah bagaimana menghadapi beban semakan kod yang terus meningkat. Topik ini telah wujud selama beberapa masa, dan kini perbincangan sebegini kelihatan semakin ramai.
Bagi saya, ini bermula pada Januari tahun ini, apabila Opus 4.5 dan GPT 5.4 mulai menulis lebih banyak dan lebih banyak kod yang lebih baik di kebanyakan syarikat. Lebih kurang sejak itu, orang yang berada di peringkat pengarah mula membincangkan bahawa bottleneck dalam pembangunan perisian sedang berpindah dari peringkat pengkodean ke peringkat pemeriksaan.
Ledakan alat semakan kod AI
Sejak Februari, alat semak kod AI mengalami pertumbuhan pesat untuk mengatasi peningkatan beban, dengan eksperimen dan pengambilan alat semak kod AI khusus seperti CodeRabbit, Greptile, Qodo, dan SonarQube (kini termasuk Gitar) yang meledak. Terdapat juga alat yang disediakan oleh alat pengkodean itu sendiri, seperti Claude Code review, Cursor review, dan GitHub Copilot review. Selain itu, alat yang sebelumnya tidak terlibat dalam semak kod tetapi memiliki konteks terhadap repositori kod kini turut masuk ke bidang ini, seperti Seer AI reviews dari Sentry dan Linear code reviews.
Alat dalaman yang dibina sendiri oleh syarikat besar: Code Inbox dari Uber
Syarikat besar sedang membina alat dalaman untuk memperbaiki pengalaman semakan kod. Code Inbox milik Uber adalah satu contoh:
Pengagihan pintar ialah fungsi dalam Code Inbox yang digunakan untuk mempercepat proses pemeriksaan:
Rajah: Tetapan penghantaran pintar (Smart assignment) Code Inbox untuk mempercepat proses pemeriksaan. Sumber: The Pragmatic Engineer
Serta fungsi profil risiko untuk menilai kesan perubahan dan mendorong pembangun untuk memberi perhatian khusus terhadap perubahan berisiko tinggi:
Rajah: Fungsi Profil Risiko Code Inbox, yang menganggarkan risiko perubahan kod dan menandakan perkara yang perlu diberi perhatian. Sumber: The Pragmatic Engineer
Kami sebelum ini melaporkan bagaimana Uber menggunakan AI dalam pembangunan perisian, dan bukan hanya Uber: Cloudflare (AI Code Reviewer), Faire (Fairey), HubSpot (Sidekick), dan banyak lagi syarikat lain telah membina alat untuk mempercepatkan proses semakan kod mereka, kerana mereka mendapati pelaksanaan dalaman lebih berkesan berbanding integrasi penyelesaian pihak ketiga.
Dari "pemeriksaan" ke "pengesahan"
Cara lain adalah memikirkan bagaimana mengesahkan kod, bukan mengulas kod. Mudah dikatakan tetapi sukar dilakukan; secara teori, pengujian yang menyeluruh seharusnya dapat mengesahkan bahawa kod berfungsi seperti yang diharapkan. Tetapi berapa banyak pengujian yang dianggap 'menyeluruh'? Apa jenis pengujian yang dimaksudkan? Adakah pengujian integrasi dan pengujian end-to-end juga termasuk? Bagaimana dengan pengujian fuzz? Bagaimana dengan kaedah formal? Bagaimana cara mengesahkan bahawa pengujian baru mencakupi fungsi seperti yang diharapkan? Bagaimana kita menghubungkan semua ini dengan observabiliti?
Pengawasan berlebihan sedang melemahkan jurutera
Pemeriksaan kod yang terlalu mendalam sedang meletihkan jurutera dan menyebabkan kualiti pemeriksaan menurun. Saya mendengar banyak cerita bahawa pembangun melihat orang lain tidak lagi mampu memeriksa kod dengan teliti, dan jika pemeriksaan kod AI tidak memberikan cadangan yang bermakna, mereka langsung membenarkannya. Sementara itu, pembangun yang masih memberikan usaha dan masa yang sama seperti sebelum ini untuk memeriksa kod merasa tenggelam di bawah PR AI yang tidak bermutu yang dikirimkan kepada mereka.
Masalah masih ada, penyelesaian masih eksperimen
Masalah ada, tetapi penyelesaian kelihatan lebih seperti eksperimen.