Ali-Reza Adl-Tabatabai, Pendiri dan CEO di Gitar – Seri Wawancara

Ali-Reza Adl-Tabatabai, Pendiri dan CEO di Gitar, adalah seorang veteran pemimpin teknik yang karirnya meliputi beberapa perusahaan teknologi paling berpengaruh di Lembah Silikon, termasuk Uber, Google, Facebook, Intel, AMD, dan IBM. Sebelum meluncurkan Gitar pada tahun 2023, ia menjabat sebagai Direktur Senior Teknik di Uber, di mana ia membantu memimpin inisiatif platform pengembang perusahaan, setelah sebelumnya menjabat sebagai pemimpin di Google yang mengawasi Site Reliability Engineering untuk produk seperti Komunikasi, Foto, Sosial, Cloud, dan infrastruktur teknis.

Pada awal karirnya, ia bekerja pada teknologi compiler, mesin virtual, sistem komputasi paralel, dan optimasi perangkat keras di Intel Labs dan tim HipHop VM Facebook, sambil juga mengajar desain compiler lanjutan di Universitas Stanford. Latar belakangnya yang panjang dalam bahasa pemrograman, keandalan infrastruktur, pengembangan alat, dan arsitektur sistem skala besar telah memposisikannya sebagai tokoh terkemuka dalam lanskap rekayasa perangkat lunak yang ditenagai AI yang terus berkembang.

Gitar berfokus pada masalah yang tumbuh yang muncul dari munculnya pengembangan perangkat lunak yang dibantu AI: memvalidasi dan mengamankan volume besar kode yang dihasilkan mesin yang sekarang mengalir ke sistem perusahaan. Platform ini menggunakan agen AI untuk mengotomatisasi tinjauan kode, menyelidiki kegagalan pipa CI/CD, mengidentifikasi bug dan kerentanan, merekomendasikan perbaikan, dan terintegrasi langsung ke dalam alur kerja teknik yang ada melalui alat seperti GitHub, GitLab, Jenkins, Jira, dan Slack. Daripada bersaing hanya dalam generasi kode AI, perusahaan ini memposisikan diri di sekitar apa yang mereka sebut “gerbang kualitas agen,” membantu tim teknik mempertahankan keandalan, keamanan, dan pengawasan operasional saat pengembangan perangkat lunak semakin bergeser ke arah alur kerja pengkodean otonom dan yang dibantu AI.

Anda telah memimpin teknik di Uber, Google, dan Intel Labs, bekerja pada platform pengembang skala besar dan infrastruktur. Pengalaman spesifik apa dari perjalanan itu yang membuat Anda mendirikan Gitar, dan mengapa fokus pada validasi kode bukan generasi kode?

Di seluruh Uber, Google, Facebook, dan Intel Labs, saya bekerja pada platform pengembang dengan skala yang sangat berbeda, dan pelajaran yang sama terus muncul: pengalaman pengembang adalah keunggulan kompetitif. Alat yang hebat menarik dan mempertahankan insinyur terbaik dan memungkinkan perusahaan bergerak cepat. Pengembang ingin alat yang cepat, bebas kebisingan yang menjaga mereka dalam aliran dan mengotomatisasi pekerjaan yang berat. Namun, pengembangan alat sangat terfragmentasi, dan sebagian besar perusahaan membakar sumber daya teknik yang sangat besar hanya untuk menyatukan pengalaman yang kohesif. Saya melihat langsung seberapa besar pengaruhnya dalam memperbaiki hal itu.

AI mengubah persamaan dengan membuatnya mungkin untuk mengotomatisasi lebih banyak alur kerja pengembang daripada sebelumnya. Generasi kode sudah tercakup dengan baik, tetapi itu hanya memindahkan bottleneck ke hilir, ke validasi, refactoring, dan pemeliharaan kode yang sekarang kita produksi dengan volume yang belum pernah terjadi sebelumnya. Itulah di mana Gitar berfokus. Ketika AI menulis lebih banyak kode, sumber daya yang langka bukanlah generasi; itu adalah kepercayaan, kesalahan, dan kemaintanabilitasan dari apa yang dikirim. Validasi kode adalah bagian dari alur kerja yang menentukan apakah kode yang dihasilkan AI benar-benar masuk ke produksi dengan aman, dan itu adalah masalah yang lebih sulit dan lebih berharga untuk dipecahkan.

Dengan munculnya kode yang dihasilkan AI, banyak tim sekarang menghadapi apa yang disebut beberapa orang sebagai “kelebihan kode”. Seberapa signifikan masalah ini di dalam perusahaan hari ini, dan di mana tim-tim paling banyak berjuang?

Perubahan itu tidak terletak pada menulis kode. Bagian itu sudah bergerak lebih cepat daripada sebagian besar tim dapat menyerapnya. Apa yang telah berubah adalah segala sesuatu yang datang setelah itu.

Alat AI menghasilkan aliran konstan permintaan pull, sering kali lebih cepat daripada tim dapat meninjau mereka, yang menciptakan tekanan pada bagian sistem yang tidak pernah dirancang untuk tingkat output ini.

Setiap perubahan masih harus melewati validasi. Tinjauan kode. CI. Periksa keamanan. Persetujuan. Tidak ada yang menghilang hanya karena kode dihasilkan lebih cepat. Apa yang dulunya aliran yang dapat dikelola telah berubah menjadi backlog. Tim tidak lagi terhalang oleh ide atau implementasi. Mereka terhalang oleh kepercayaan. Apakah ini dapat dikirim? Apakah itu aman? Apakah itu memecahkan sesuatu yang halus?

Itulah di mana gesekan sekarang berada. Bukan pada penciptaan, tetapi pada mendapatkan kode melewati garis finish tanpa memperkenalkan risiko.

Industri secara luas telah fokus pada menghasilkan kode lebih cepat. Mengapa Anda percaya validasi telah diabaikan, dan mengapa itu menjadi lebih kritis sekarang?

Karena sistem di hilir generasi kode belum berkembang dengan kecepatan yang sama. Ketika output meningkat, segala sesuatu di hilir menjadi tertekan. Permintaan pull menjadi lebih besar dan lebih sering. Kegagalan CI mulai menumpuk. Siklus tinjauan dikompresi karena tidak ada yang memiliki waktu untuk memeriksa setiap perubahan secara mendalam.

Kualitas mulai tergelincir, bukan karena insinyur tidak peduli, tetapi karena volume memaksa kompromi. Tim platform mengambil lebih banyak beban, menangani masalah pipa, triase kegagalan, dan mencoba menjaga semuanya bergerak. Insinyur senior berakhir sebagai koordinator, menyatukan log, mendiagnosis masalah, dan memutuskan apa yang aman untuk digabungkan.

Tim menghadapi pilihan yang tidak benar-benar berhasil dengan cara apa pun. Dorong kode dengan cepat dan tangani regresi nanti, atau perlahan dan lindungi kualitas, tetapi terima bahwa kecepatan turun. Tegangan itu sekarang muncul di seluruh organisasi teknik.

Gitar menggunakan agen AI untuk menangani tinjauan kode, pengujian, dan alur kerja CI. Bagaimana agen-agen ini secara fundamental berbeda dari alat analisis statis tradisional dan pipa berbasis aturan?

Perbedaan itu tidak kosmetik. Agen yang sebenarnya perlu melakukan lebih dari sekadar merespons prompt. Mereka perlu menangani pekerjaan multi-langkah, merencanakan, menggunakan alat, memantau konteks, dan memajukan tugas tanpa input konstan.

Sebagian besar sistem tidak memenuhi standar itu. Mereka menghasilkan output, tetapi mereka tidak mengelola eksekusi. Ketika alat-alat ini ditempatkan di dalam alur kerja nyata, celahnya segera terlihat. Mereka tidak mengurangi kompleksitas. Dalam banyak kasus, mereka menambahkan lapisan lain yang harus dikelola oleh seseorang.

Itulah mengapa percakapan bergeser dari “apakah kita memiliki agen” ke “apa pekerjaan yang sebenarnya dapat ditangani dengan andal.”

Kepercayaan adalah hambatan utama untuk otomatisasi dalam pengembangan perangkat lunak. Bagaimana Gitar memastikan bahwa proses validasi mereka cukup andal untuk tim untuk mengandalkannya?

Polanya yang berhasil sederhana. Bagi pekerjaan menjadi langkah-langkah yang lebih kecil. Tetapkan batas yang jelas. Validasi output secara terus-menerus. Pertahankan keterlibatan manusia di mana keputusan membawa risiko.

Agen dapat meninjau kode dan menonjolkan masalah yang mudah terlewatkan pada skala besar. Mereka dapat menganalisis kegagalan CI, mengelompokkan kesalahan terkait, dan menunjuk ke penyebab akar yang mungkin. Mereka dapat merekomendasikan perbaikan dan, dalam beberapa kasus, menerapkan perbaikan tersebut dengan cara yang terkendali.

Ini mengurangi jumlah triase manual yang harus dilakukan insinyur. Ini tidak menghilangkan insinyur dari loop, tetapi mengubah di mana mereka menghabiskan waktu. Sebagian besar sistem beroperasi dengan titik-titik periksa, bukan kemandirian lengkap.

Platform Anda memungkinkan tim untuk membuat agen mereka sendiri. Seberapa penting kustomisasi untuk adopsi perusahaan, dan apa beberapa kasus penggunaan yang paling menarik yang Anda lihat?

Kustomisasi sangat penting untuk adopsi perusahaan. Setiap tim platform menghabiskan sumber daya yang signifikan untuk menyesuaikan CI dengan kebutuhan spesifik perusahaan mereka, dan ini secara tradisional memerlukan skrip khusus, konfigurasi, integrasi alat, pemroses log, dan semua duct tape yang menyatukan infrastruktur pengembang modern.

Gitar menggabungkan pekerjaan itu. Tim platform dapat menulis periksa kustom menggunakan prompt bahasa alami, yang memungkinkan mereka untuk memvalidasi hal-hal yang sulit atau tidak mungkin dengan analisis program tradisional, misalnya, menandai string penghadap pengguna yang ambigu untuk terjemahan, atau memvalidasi pembaruan ke file AGENTS.md. Mereka juga dapat mengotomatisasi alur kerja kustom di atas permintaan pull: menghubungkan PR ke masalah Jira, membuka tiket follow-up untuk komentar tinjauan yang belum terselesaikan, secara otomatis mengulangi tes yang tidak stabil, atau menambahkan daftar tugas kustom ke ringkasan PR.

Kasus penggunaan yang paling menarik cenderung menjadi kasus yang tidak kita antisipasi. Tim-tim tahu kode basis dan poin sakit mereka lebih baik daripada vendor mana pun, jadi ketika Anda memberi mereka primitif yang mengubah “kita berharap CI bisa hanya memeriksa X” menjadi prompt 10 baris, mereka segera mulai mengotomatisasi hal-hal yang tidak akan kita bangun secara default. Itulah tepat apa yang kita inginkan.

Tim teknik modern bergantung pada tumpukan alat yang kompleks seperti GitHub, GitLab, dan Jira. Seberapa penting bagi Gitar untuk terintegrasi ke dalam alur kerja yang ada daripada mencoba menggantikannya?

Adopsi tergantung pada bertemu dengan pengembang di mana mereka sudah ada. Insinyur tidak ingin permukaan lain untuk dipelajari, dashboard lain untuk diperiksa, atau lebih banyak konteks-berselingkuhan antara alat. Mereka ingin alur kerja yang ada menjadi lebih cepat dan lebih tenang. Jadi, integrasi yang dalam dengan GitHub, GitLab, Jira, dan tumpukan lainnya bukanlah hal yang menyenangkan bagi kami; itu adalah strategi utama.

Namun, ambisi kami melangkah lebih jauh dari integrasi. Kami tidak mencoba menggantikan alat-alat ini, dan kami tidak hanya mencoba memasuki mereka. Kami mengotomatisasi alur kerja yang berjalan di atasnya. Tinjauan PR, penghubung tiket, tugas follow-up, pengulangan tes yang tidak stabil, semuanya harus terjadi secara otomatis, di latar belakang. Dan kami mendorong lebih jauh: agen mengedit PR secara langsung untuk menangani umpan balik tinjauan kode dan memperbaiki kegagalan CI, dan pada akhirnya menangani persetujuan dan penggabungan untuk perubahan yang memenuhi kebijakan tim. Peran pengembang bergeser dari mengemudi setiap langkah ke menetapkan niat, meninjau hasil, dan menangani pengecualian.

Keadaan akhir bukanlah alat baru yang pengembang masuki. Itu adalah alat yang ada melakukan lebih banyak hal sendiri, sehingga pengembang dapat tetap fokus pada pekerjaan yang sebenarnya memerlukan penilaian mereka.

Anda telah menyarankan bahwa tinjauan kode manusia akhirnya dapat menjadi pengecualian daripada aturan. Apa yang perlu terjadi agar organisasi merasa nyaman dengan perubahan itu?

Kepercayaan dibangun dalam tahap, bukan sekaligus. Organisasi perlu melihat, dengan kode mereka sendiri, bahwa AI dapat menemukan bug dan kerentanan yang sebenarnya penting dan menegakkan aturan kustom dengan presisi dan cakupan tinggi. Dari sana, jalur menuju penggabungan otonom adalah kemajuan alami melalui empat tingkat kepercayaan yang meningkat.

Tingkat pertama adalah deteksi. Tim-tim membangun kepercayaan bahwa agen menemukan masalah nyata dengan tingkat positif palsu yang rendah. Setelah kepercayaan itu terjalin, mereka membiarkan AI secara otomatis memblokir PR ketika menemukan masalah kritis.

Tingkat kedua adalah perbaikan. AI tidak hanya menandai masalah, tetapi juga memperbaikinya, membatalkan PR dan mengubah CI menjadi hijau tanpa intervensi manusia. Kepercayaan di sini berarti agen dapat menyelesaikan masalah dan kegagalan CI dengan presisi, tanpa merusak apa pun.

Tingkat ketiga adalah persetujuan. Setelah tim-tim melihat agen secara andal mengubah PR menjadi hijau, mereka membiarkan AI menyetujui PR di bawah aturan yang mereka tetapkan. Memberikan organisasi kontrol eksplisit atas kondisi untuk persetujuan otomatis adalah apa yang membuat langkah ini terasa aman daripada ceroboh.

Tingkat keempat adalah penggabungan. AI mendaratkan perubahan, lagi di bawah kondisi yang tim nyaman dengan. Langkah ini memiliki batangnya sendiri: agen harus menyelesaikan konflik penggabungan dengan presisi, tanpa memperkenalkan regresi atau memecahkan main. Itu penting lebih dari yang orang sadari, karena frekuensi konflik meningkat dengan throughput komit, dan throughput meledak karena AI menghasilkan lebih banyak kode. Monorepo besar sudah merasakannya; yang lain akan segera merasakannya.

Perubahan ke AI sebagai peninjau default bukanlah satu lompatan iman. Itu adalah tangga, dan organisasi memanjatnya satu rung demi satu rung seiring bukti yang terkumpul.

Bagaimana Anda melihat peran insinyur senior berkembang selama beberapa tahun mendatang saat AI mengambil lebih banyak proses pengkodean?

Insinyur senior sudah bergeser ke peran koordinasi, menyatukan log, mendiagnosis masalah, dan memutuskan apa yang aman untuk digabungkan. Itu bukan peran yang direncanakan. Itu adalah reaksi terhadap sistem yang rusak di bawah beban.

Ketika agen mengambil lebih banyak pekerjaan validasi berulang, insinyur tetap dalam loop tetapi pindah lebih tinggi di tumpukan. Mereka menghabiskan waktu lebih sedikit pada triase manual dan lebih banyak waktu membuat keputusan tentang apa yang harus dikirim dan mengapa.

Gitar baru-baru ini mengumpulkan $9 juta untuk menskala platform. Apa prioritas utama Anda untuk modal itu, dan apa yang terlihat seperti kesuksesan selama 12 hingga 18 bulan ke depan?

Modal itu digunakan untuk dua prioritas. Yang pertama adalah go-to-market: kami menskala gerakan perusahaan dan berinvestasi dalam kesadaran pengembang sehingga tim yang akan diuntungkan dari Gitar sebenarnya tahu kami ada. Yang kedua adalah produk: kami terus membangun menuju visi kami tentang validasi kualitas kode yang sepenuhnya otonom, yang berarti kemampuan agen yang lebih dalam, cakupan alur kerja yang lebih luas, dan integrasi yang lebih ketat dengan alat yang pengembang sudah gunakan.

Kesuksesan selama 12 hingga 18 bulan ke depan terlihat seperti basis pelanggan perusahaan yang signifikan yang menjalankan Gitar di seluruh kode basis mereka, komunitas pengembang yang mengenali kami sebagai default untuk validasi kode yang didorong AI, dan bukti yang jelas bahwa agen kami melakukan lebih banyak pekerjaan tinjauan, perbaikan, dan penggabungan secara otonom dari waktu ke waktu. Jika kami berada di jalur yang tepat, percakapan satu tahun dari sekarang bukanlah apakah AI dapat memvalidasi kode, tetapi seberapa banyak pipa validasi yang telah diserahkan tim kepada agen.

Terima kasih atas wawancara yang luar biasa, pembaca yang ingin mempelajari lebih lanjut harus mengunjungi Gitar.