Gautam Korlam, Insinyur Utama di Sonar – Seri Wawancara

Gautam Korlam, Insinyur Utama di Sonar, adalah seorang insinyur perangkat lunak veteran dan pemimpin teknologi yang kariernya berfokus pada infrastruktur pengembang, kualitas kode, otomasi, dan pengembangan perangkat lunak berbantuan AI. Sebelum bergabung dengan Sonar, ia ikut mendirikan Gitar dan menjabat sebagai CTO, membangun platform berbasiskan AI yang dirancang untuk mengotomatisasi tinjauan kode, mendiagnosa kegagalan integrasi berkelanjutan (CI), mengidentifikasi penyebab akar, dan menghasilkan perbaikan. Sonar mengakuisisi Gitar pada Mei 2026, dengan Korlam dan tim Gitar bergabung ke perusahaan untuk melanjutkan pengembangan teknologi tersebut sebagai bagian dari platform verifikasi kode Sonar yang lebih luas. Sebelum Gitar, Korlam menghabiskan hampir satu dekade di Uber, naik dari insinyur pendiri pada tim platform seluler menjadi Insinyur Utama. Selama masa baktinya, ia membantu membangun dan menskalakan infrastruktur pengembang terpusat Uber, memimpin inisiatif monorepo dan sistem build utama, mengembangkan lingkungan pengembang remote serta alat CI/CD, dan bereksperimen dengan model bahasa besar sumber terbuka seperti StarCoder, OctoCoder, dan Code Llama untuk meningkatkan pemrograman berbantuan AI dalam basis kode Uber. Pengalaman sebelumnya mencakup peran rekayasa di Lookout dan pekerjaan riset di UC Santa Barbara, serta magang di Microsoft dan Oracle.

Sonar adalah perusahaan perangkat lunak yang berfokus pada verifikasi kode, tinjauan kode otomatis, kualitas kode, dan keamanan aplikasi. Platform andalannya, SonarQube, menganalisis kode yang ditulis pengembang maupun yang dihasilkan AI untuk mengidentifikasi bug, kerentanan, masalah maintainability, dan isu kualitas lainnya sebelum mencapai produksi, dengan penawaran yang mencakup alur kerja cloud, self-managed, dan lingkungan pengembangan terintegrasi. Sonar menyatakan teknologinya digunakan oleh lebih dari 7 juta pengembang dan 22.000 pelanggan serta menganalisis lebih dari 750 miliar baris kode setiap hari. Akuisisi Gitar memperluas pendekatan ini ke tinjauan kode berbasiskan AI dan remediasi, menggabungkan mesin verifikasi SonarQube dengan alat agen yang mampu meninjau kode, menyelidiki kegagalan CI, serta mengusulkan atau menerapkan perbaikan seiring pengembangan perangkat lunak semakin didorong oleh AI.

Karier Anda telah membawa Anda dari membangun infrastruktur seluler dan pengembang Uber hingga melatih model bahasa besar sumber terbuka pada basis kode mereka, sebelum mendirikan Gitar dan bergabung dengan Sonar setelah akuisisinya. Bagaimana pengalaman-pengalaman tersebut membentuk keyakinan Anda bahwa menghasilkan kode hanyalah sebagian dari tantangan, dan bahwa memvalidasi kode secara andal mungkin merupakan masalah yang lebih sulit?

Di Uber saya bekerja pada bagian sistem yang memutuskan apakah sesuatu dapat dirilis: monorepo, proses build, antrean CI, dan rangkaian tes. Mempermudah produksi perubahan menumpahkan semua tekanan ke mesin tersebut. Anda mendapatkan lebih banyak layanan yang berinteraksi dengan cara yang tidak diprediksi siapa pun, dan lebih banyak insinyur menunggu untuk mengetahui apakah perubahan mereka aman untuk digabung.

Kemudian saya bekerja pada pelatihan model pada basis kode kami sendiri, di mana ketidakseimbangan menjadi jelas. Sebuah model dapat menghasilkan implementasi yang masuk akal dengan cepat. Membuktikan bahwa implementasi tersebut cocok dengan sistem produksi yang berjalan, mengikuti konvensi yang sebenarnya digunakan tim, dan tidak merusak sesuatu dua layanan jauh, memakan waktu jauh lebih lama, dan sebagian besar pekerjaan itu jatuh pada orang. Gitar lahir dari hal itu, dan selaras dengan apa yang telah dilakukan Sonar dari sisi analisis selama lebih dari tujuh belas tahun.

Anda berpendapat bahwa tinjauan kode AI harus melengkapi analisis deterministik, bukan menggantikannya. Jenis masalah apa yang paling baik diidentifikasi melalui analisis berbasis aturan yang dapat diulang, dan di mana AI dapat menyediakan kemampuan yang tidak dapat dicapai teknik tradisional?

Analisis berbasis aturan adalah alat yang tepat ketika sifatnya dapat diputuskan dari kode itu sendiri. Input yang terkontaminasi mencapai sink, dereferensi null pada jalur yang terlewat, kredensial yang dikodekan keras, dependensi dengan CVE yang diketahui, impor yang melintasi lapisan yang seharusnya tidak. Anda mendapatkan jawaban yang sama pada setiap run dan dapat menunjuk alasan mengapa aturan tersebut terpicu, itulah mengapa penegakan berada pada lapisan itu.

Apa yang tidak dicakup oleh aturan adalah niat. Tidak ada parser yang akan memberi tahu Anda bahwa string yang ditujukan bagi pengguna akan ambigu bagi siapa pun yang menerjemahkannya, atau bahwa sebuah perubahan mengklaim menutup tiket sementara hanya mengimplementasikan setengah dari apa yang diminta tiket, atau bahwa loop retry baru melawan cara layanan lain menangani backpressure. Model yang membaca diff bersama isu yang ditautkan dan konteks seluruh basis kode akan mengangkat hal‑hal tersebut, dan mereka seharusnya muncul sebagai temuan yang diperiksa orang, bukan sebagai keputusan akhir.

Sistem AI dapat menilai logika bisnis, niat pengembang, dan pertukaran arsitektural, namun kesimpulannya bersifat probabilistik. Bagaimana tim pengembangan dapat memanfaatkan penalaran kontekstual ini tanpa memperlakukan output peninjau AI sebagai benar secara inheren?

Tinjauan AI memperoleh tempatnya pada masalah yang dilewatkan pemeriksaan konvensional: kesalahan logika, perilaku yang tidak sesuai dengan niat yang dinyatakan, perubahan yang tampak baik secara terpisah namun salah untuk sistem tertentu. Kesimpulan tersebut bersifat probabilistik, sehingga mereka menjadi masukan untuk keputusan, bukan keputusan itu sendiri. Tim menjaga batas itu dengan mempertahankan kontrol deterministik di depan proses merge, yang berarti tes otomatis, validasi CI, pemindaian keamanan, pemeriksaan kebijakan, dan seorang manusia yang bertanggung jawab atas perubahan. AI dapat mengusulkan perbaikan, atau menerapkannya dalam batasan yang ditetapkan tim, selama perubahan tersebut melewati verifikasi yang sama seperti apa pun yang ditulis manusia dan tidak mendapat jalan pintas karena dihasilkan mesin.

Kami menerapkan batas yang sama dalam implementasi kami sendiri. Model mengusulkan temuan, dan keputusan tinjauan dihitung dalam kode berdasarkan status temuan tersebut. Penyelesaian berfungsi dengan cara yang sama. Ketika kode di balik sebuah temuan tidak lagi ada dalam diff, itu menjadi pemeriksaan deterministik terhadap diff yang diparse, dan model tidak diizinkan untuk membatalkan penyelesaian yang sudah diperbaiki diff.

Versi umum dari ini adalah menyerahkan lapisan probabilistik pada pekerjaan di mana kesalahan dapat dipulihkan, menjaga mesin status tetap deterministik, dan menyerahkan akuntabilitas kepada tim. Kepercayaan diperoleh dari bukti yang dapat diperiksa dan dikendalikan sehingga berperilaku sama pada setiap run.

Sonar menggabungkan tinjauan pull request yang sadar konteks dengan analisis deterministik dan quality gate. Seperti apa proses verifikasi berlapis yang efektif, dan bagaimana lapisan‑lapisan tersebut harus berinteraksi tanpa menduplikasi pekerjaan atau membebani pengembang dengan terlalu banyak temuan?

Analisis deterministik dan quality gate memuat hal‑hal yang tidak dapat dinegosiasikan, dan itulah yang menjadi penghalang merge. Tinjauan kontekstual mengambil keputusan penilaian apakah perubahan melakukan apa yang diklaim, apakah cocok dengan basis kode, dan apakah risiko tertentu layak mendapat perhatian manusia.

Dinding temuan yang besar akan diabaikan dengan tingkat yang kira‑kira sama seperti tidak ada temuan sama sekali. Kami menghilangkan duplikasi antar peninjau sebelum apa pun sampai ke penulis, menyingkirkan kandidat yang tidak dapat diverifikasi, dan memfokuskan pada temuan dengan sinyal tinggi. Di sisi aturan, sebuah predikat memutuskan apakah aturan berlaku pada diff saat ini sebelum model dijalankan, sehingga sebagian besar aturan tidak menambah beban pada kebanyakan perubahan. Semua itu muncul pada pull request yang sudah dibuka pengembang.

Seiring agen‑agen pemrograman menghasilkan lebih banyak kode dan pull request, apakah tinjauan dan verifikasi perangkat lunak dapat menjadi bottleneck baru? Bagian mana dari proses tinjauan yang harus diotomatisasi, dan keputusan mana yang harus tetap berada di tangan insinyur berpengalaman?

Tinjauan dan verifikasi sudah menjadi bottleneck. Faktanya, survei 2026 State of Code Developer Survey kami menemukan bahwa tim melaporkan menghabiskan sekitar seperempat minggu kerja untuk memeriksa dan memperbaiki output AI. Dengan hal ini, tidak mengherankan bahwa hanya 48% pengembang yang selalu memeriksa kode yang dihasilkan AI sebelum melakukan commit, meskipun mayoritas (96%) tidak sepenuhnya mempercayai bahwa kode tersebut berfungsi secara fungsional.

Pekerjaan yang layak diotomatisasi bersifat mekanis dan tidak menyenangkan: mengelompokkan kegagalan CI hingga menemukan akar penyebab sehingga tidak ada yang harus membaca empat ribu baris log, memutuskan apakah sebuah temuan masih berlaku setelah rebase, mereproduksi kegagalan, menulis perbaikan yang jelas. Insinyur harus mempertahankan niat, desain, dan keputusan tentang seberapa banyak bukti yang cukup untuk perubahan tertentu. Ketika seorang insinyur senior menghabiskan malam membaca log untuk menentukan mana dari sembilan kegagalan yang penting, itu adalah triase bukan penilaian, dan itulah jenis pekerjaan yang seharusnya kami ambil dari mereka.

Sistem tinjauan kode AI dapat mengidentifikasi masalah, mengusulkan perbaikan, dan memvalidasi perubahan tersebut terhadap pipeline integrasi berkelanjutan. Bagaimana Anda mencegah sistem remediasi otonom memperkenalkan regresi atau mengoptimalkan sempit hanya untuk build yang berhasil daripada kualitas perangkat lunak secara keseluruhan?

Hal utama adalah menolak memperlakukan warna hijau sebagai kriteria penerimaan, karena build yang lolos hanya memberi tahu Anda bahwa tes yang ada tidak gagal.

Sebagian besar batasan yang kami terapkan pada remediasi kami sendiri berkaitan dengan ruang lingkup. Gitar memperbaiki CI yang rusak, dan memeriksa bahwa commit sebelum pushnya sendiri berwarna hijau sebelum mengklaim tanggung jawab atas apa pun. Ia berhenti setelah dua commit lanjutan alih‑alih terus‑menerus memperbaiki build merah. Ketika kegagalan tidak ada hubungannya dengan perubahan, tes flaky atau gangguan infrastruktur, itu masuk ke jalur retry bukan jalur perbaikan, karena “membuat tes berhenti gagal” adalah tujuan yang paling tidak ingin dikejar oleh agen yang kompeten.

Setelah itu, perubahan harus melewati lapisan yang tidak dikendalikan Gitar. SonarQube mengevaluasi hasil dengan istilahnya sendiri, quality gate menjadi hal yang menentukan merge, dan tim memiliki kebijakan tersebut. Kami juga memeriksa perubahan terhadap isu yang diklaim diimplementasikan, dengan ekstraksi kebutuhan dipisahkan dari penilaian penyelesaian, sehingga kebutuhan yang diam-diam keluar dari tiket tidak dapat kembali dianggap sudah diimplementasikan.

Tinjauan kode AI yang efektif bergantung pada pemahaman konvensi repositori, dependensi, arsitektur, dan tujuan perubahan yang diusulkan. Konteks apa yang dibutuhkan peninjau AI untuk membuat keputusan yang berguna, dan bagaimana organisasi dapat menjaga konteks tersebut tetap akurat seiring sistem mereka berkembang?

Itu memerlukan cukup konteks untuk beralasan seperti peninjau berpengalaman, bukan sekadar cukup untuk membaca diff. Itu mencakup tujuan perubahan, jalur kode relevan dan informasi tipe, dependensi, perilaku tes, konvensi repositori, serta batasan arsitektural yang diharapkan tim untuk dipatuhi oleh perubahan.

Konteks juga harus hidup bersama kode. Simpan aturan dan panduan tinjauan versi dalam repositori, perbarui ketika layanan atau konvensi berubah, dan buat kepemilikan jelas untuk keputusan arsitektural dan kebijakan. Jika tidak, peninjau AI dapat menghasilkan saran yang tampak masuk akal secara individual namun bertentangan dengan cara sistem yang lebih luas sebenarnya beroperasi.

Analisis deterministik menghasilkan hasil yang konsisten dan dapat diaudit, sementara tinjauan berbasis model bahasa besar dapat bervariasi antar run. Bagaimana perusahaan harus mendokumentasikan, mereproduksi, dan mengatur temuan AI‑generated dalam lingkungan yang diatur atau sensitif keamanan?

Jejak audit harus menunjukkan perubahan yang ditinjau, temuan AI, keputusan yang diambil, dan bukti independen yang digunakan untuk memvalidasi hasil. Tim dapat menggunakan AI untuk mempercepat tinjauan dan remediasi, sambil menjaga keputusan penegakan dan persetujuan berlandaskan kebijakan yang ditetapkan serta akuntabilitas manusia.

Metode apa yang harus digunakan pemimpin teknik untuk menentukan apakah tinjauan kode AI benar‑benar meningkatkan pengembangan perangkat lunak? Haruskah mereka memprioritaskan waktu tinjauan, bug yang lolos, tingkat false‑positive, kegagalan CI, technical debt, kepercayaan pengembang, atau ukuran lain?

Mulailah dengan hasil, bukan jumlah komentar yang dihasilkan sistem AI. Saya akan mengukur waktu dari pull request hingga merge, waktu yang dihabiskan untuk mendiagnosa kegagalan CI, tingkat perbaikan yang lolos pada upaya validasi pertama, serta seberapa sering isu meloloskan ke tahap selanjutnya atau produksi.

Kemudian perhatikan sinyal kualitas seperti tingkat false‑positive dan penolakan, isu yang dibuka kembali, regresi yang terkait dengan perubahan yang baru saja digabung, dan umpan balik pengembang tentang apakah temuan dapat ditindaklanjuti. Campuran metrik yang tepat bervariasi per tim, tetapi pertanyaannya tetap konsisten: apakah kami mengurangi pekerjaan ulang dan waktu tunggu tinjauan tanpa menurunkan standar untuk perangkat lunak yang aman dan dapat diandalkan?

Ke depan, apakah Anda memperkirakan pengembangan perangkat lunak akan menjadi loop berkelanjutan di mana agen menghasilkan, meninjau, menguji, dan memperbaiki kode di bawah batasan deterministik? Dalam lingkungan itu, bagaimana tanggung jawab dan keterampilan yang dibutuhkan insinyur perangkat lunak manusia akan berubah?

Loop itu sudah ada, dan tim cenderung mengadopsinya dalam urutan tetap: deteksi dulu, kemudian remediasi, kemudian persetujuan berdasarkan kondisi yang mereka catat, lalu merge. Tidak ada yang langsung melompat ke langkah terakhir, dan bukti yang mendorong mereka maju adalah basis kode mereka sendiri, bukan benchmark. Merge adalah langkah yang paling menarik bagi saya, karena frekuensi konflik meningkat seiring throughput commit, dan throughput adalah apa yang semuanya tingkatkan.

Keterampilan yang memperoleh nilai berada di sekitar loop, bukan di dalamnya. Menjadi tepat tentang masalah dan kendalanya menjadi lebih penting ketika agen mengambil deskripsi Anda secara harfiah. Begitu pula menentukan bukti yang cukup untuk mengizinkan perubahan lewat, yang dulu hidup dalam kepala orang sebagai kebiasaan dan kini harus dituliskan sebagai kebijakan yang dapat diterapkan otomatis. Sisanya adalah desain sistem: membatasi apa yang dapat disentuh pekerjaan otomatis, memiliki sesuatu yang tidak dikendalikan agen untuk memeriksa hasil, dan memastikan dapat ditelusuri ketika terjadi kesalahan. Insinyur akan menghabiskan lebih sedikit waktu menghasilkan implementasi dan lebih banyak waktu memutuskan apa yang harus ada serta apa yang akan dihitung sebagai bukti bahwa itu berfungsi.

Terima kasih atas wawancara yang luar biasa, pembaca yang ingin belajar lebih lanjut sebaiknya mengunjungi Sonar.