Moshe Sambol, Wakil Presiden Solusi Pelanggan di Lightrun – Seri Wawancara

Moshe Sambol, Wakil Presiden Solusi Pelanggan di Lightrun – membawa lebih dari dua dekade pengalaman yang meliputi rekayasa perangkat lunak, arsitektur, infrastruktur cloud, dan kepemimpinan teknis yang berfokus pada pelanggan. Sebelum bergabung dengan Lightrun pada 2022, ia menghabiskan hampir satu dekade di Google, di mana ia memegang beberapa posisi kepemimpinan, termasuk Manajer Rekayasa Pelanggan Cloud, membantu organisasi mengadopsi dan menskalakan teknologi Google Cloud. Sebelumnya dalam karirnya, Sambol memegang peran kepemimpinan rekayasa dan pengembangan di Oracle, Sun Microsystems, BMC Software, dan JPMorgan Chase. Di Lightrun, ia awalnya memimpin Rekayasa Solusi global sebelum menjadi Wakil Presiden Solusi Pelanggan, di mana ia fokus membantu pelanggan mengadopsi teknologi Runtime Insights perusahaan dan menerjemahkan kemampuannya menjadi keuntungan bisnis dan produktivitas pengembang yang dapat diukur.

Lightrun adalah platform keandalan rekayasa yang asli AI yang dirancang untuk memberikan pengembang dan agen AI visibilitas langsung ke dalam cara perangkat lunak berperilaku saat dijalankan. Teknologinya dapat menangkap log, snapshot, metrik, jejak, nilai variabel, dan konteks eksekusi dari aplikasi live tanpa memerlukan perubahan kode atau redeploy. Perusahaan ini semakin memperluas intelijen runtime ini ke pengembangan perangkat lunak yang dibantu AI melalui Lightrun MCP, yang menggunakan Protokol Konteks Model untuk memberikan asisten pengkodean dan alat agen dengan konteks aplikasi live bukan hanya mengandalkan kode sumber statis. Ini memungkinkan sistem AI untuk menyelidiki masalah produksi, memvalidasi hipotesis melawan perilaku eksekusi aktual, dan mendukung analisis penyebab akar sementara mengintegrasikan kontrol perusahaan seperti akses berbasis peran dan redaksi data sensitif.

Karir Anda telah meliputi pengembangan perangkat lunak tangan dan arsitektur, rekayasa pelanggan cloud di Google, rekayasa solusi global, dan sekarang solusi pelanggan di Lightrun. Bagaimana kombinasi membangun perangkat lunak dan bekerja langsung dengan pelanggan perusahaan telah membentuk pemahaman Anda tentang apa yang memisahkan demonstrasi agen AI yang mengesankan dari sistem yang dapat dipercaya dalam produksi?

Terdapat perbedaan besar antara menunjukkan apa yang dapat dilakukan agen AI dan membuktikan bahwa itu dapat dipercaya dalam lingkungan perusahaan. Ini karena agen hanya satu bagian dari sistem yang siap produksi. Kerangka di sekitarnya sama pentingnya. Ini harus menegakkan akses dengan hak istimewa terendah, memantau aktivitas, melestarikan jejak audit, mencegah tindakan yang berisiko tidak dapat diterima, dan memasukkan manusia ketika diperlukan.

Sistem agen secara inheren berbeda dari perangkat lunak tradisional, karena pengembang tidak menentukan secara pasti bagaimana sistem akan bekerja. Kami menetapkan tujuan, menyediakan alat dan panduan, dan model menentukan bagaimana melanjutkan. Fleksibilitas itu kuat, tetapi juga membuat perilaku sistem lebih sulit diprediksi.

Untuk perusahaan, terutama yang beroperasi di industri yang diatur, alur kerja produksi yang biasanya berfungsi atau membutuhkan waktu yang tidak pasti untuk diselesaikan adalah tidak dapat diterima. Lingkungan produksi berisi data sensitif, kode sumber, dan kekayaan intelektual, sehingga organisasi perlu dapat mencegah agen dari mengungkapkan informasi tersebut, atau mengambil rute kreatif tetapi tidak dapat diterima untuk mencapai tujuan mereka. Ini menjadi semakin penting, karena setiap minggu membawa contoh baru dari sistem AI yang, dalam upaya mencapai tujuan, berakhir rentan terhadap atau menyebabkan eksploitasi keamanan.

Kebanyakan pemimpin yang saya ajak bicara masih mengevaluasi agen dengan cara yang sama seperti mereka mengevaluasi karyawan baru: berdasarkan kemampuan, penilaian, dan output. Pertanyaan sebenarnya bukanlah apakah agen itu cukup pintar. Ini adalah apakah sistem di sekitarnya dapat menangkap dan mengandung momen-momen ketika agen tidak berfungsi.

Banyak perusahaan awalnya percaya bahwa membangun agen AI sebagian besar merupakan masalah menulis prompt yang efektif. Apa yang salah dipahami oleh organisasi tentang persyaratan rekayasa, arsitektur, dan operasional di balik agen yang siap produksi?

Saya pikir kesalahpahaman terbesar adalah keyakinan yang hampir naif dalam kekuatan AI untuk memecahkan setiap tantangan, begitu diberi prompt yang efektif, konteks yang relevan, dan alat yang sesuai. Tim menghubungkan LLM mereka ke kode, dokumentasi, tiket, dan telemetri historis, dan kemudian mengharapkan itu untuk menemukan jalan yang akurat ke keputusan yang tepat.

Apa yang mereka tidak bangun adalah model verifikasi untuk setiap langkah penalaran AI. Salah satu kekuatan besar AI adalah bahwa itu menggunakan penalaran probabilistik, menemukan dan mengambil salah satu dari banyak jalur yang mungkin untuk mencapai tujuan. Dalam lingkungan produksi yang kompleks dan terhubung, kekuatan itu memperkenalkan risiko serius: satu keputusan dapat memicu kemunduran hilir, kegagalan sunyi, atau perilaku yang tidak terduga lainnya yang mengancam ketahanan operasional sistem yang berjalan.

Ini adalah tempat di mana pengarahan deterministik menjadi penting. Penalaran agen dapat tetap probabilistik, tetapi pemeriksaan sekitar tindakannya tidak dapat. Untuk agen yang berpartisipasi dalam alur kerja rekayasa, ini memerlukan langkah verifikasi yang memeriksa hipotesis tindakan berikutnya melawan kenyataan produksi, gerbang deterministik bukan tebak probabilistik lain. Ini perlu melihat apa konsekuensi dari keputusan itu akan, dan hanya menyetujui setelah itu menentukan bahwa tindakan itu aman.

Melihat gelombang pertama agen perusahaan yang dikembangkan secara internal, apa kesalahan arsitektur yang paling umum yang Anda lihat, dan masalah mana yang dapat diperbaiki secara bertahap daripada memerlukan pembangunan ulang total?

Keprihatinan inti yang saya terus kembali adalah validasi. Agen dapat menjadi kotak hitam: mereka mengumpulkan informasi dari berbagai sumber dan kemudian membuat keputusan yang terlihat masuk akal secara prinsip tetapi mungkin tidak sesuai untuk kenyataan lingkungan produksi yang kompleks.

Ini menunjukkan pergeseran yang lebih mendasar, dan ini adalah sesuatu yang kami bahas terus-menerus di Lightrun ketika kami membantu pelanggan membangun otomatisasi agen untuk organisasi rekayasa mereka. Tim perlu membangun kembali alur agen itu sendiri dan meletakkan gerbang pada tindakan agen, untuk memastikan bahwa penggunaan alatnya tunduk pada pengawasan, audit, dan tinjauan. Memberikan agen itu sendiri dengan umpan balik yang kuat – termasuk pengamatan runtime live – fokus konteksnya pada apa yang terjadi sekarang. Akses itu adalah yang memungkinkan agen untuk memvalidasi keputusan desainnya sendiri, analisis penyebab akar, dan rekomendasi mitigasi kesalahan melawan kenyataan produksi bukan melawan asumsi yang didasarkan pada analisis statis kode atau telemetri lama.

Pembangunan ulang dramatis bukan satu-satunya pilihan. Apa yang dapat dilakukan secara bertahap, dan ini tidak revolusioner tetapi penting, adalah berinvestasi dalam keterampilan yang memandu perilaku agen. Keterampilan yang dirancang dengan hati-hati dan dievaluasi dengan cermat mendorong agen ke arah alur kerja deterministik. Tim tidak perlu merancang ulang seluruh sistem untuk mendapatkan manfaat itu. Mereka perlu memperlakukan desain keterampilan dengan ketat yang sama seperti mereka memberikan logika produksi lainnya.

Mengapa beberapa agen berfungsi dengan baik selama pengujian yang dikendalikan tetapi mulai menghasilkan hasil yang tidak konsisten, tidak lengkap, atau menyesatkan ketika terkena pengguna nyata, data yang berubah, alat eksternal, dan lingkungan produksi yang kompleks?

Pengujian yang dikendalikan menghilangkan sebagian besar variabilitas yang akan menentukan kenyataan produksi yang harus dihadapi AI. Data dikurasi, perilaku alat dapat diprediksi, izin diketahui, dan kita menutupi jalur yang kita antisipasi. Ketika Anda melepaskan agen untuk berinteraksi dengan pengguna nyata dan efek mereka dalam sistem live, Anda tidak membandingkan seperti dengan seperti.

Pengguna memperkenalkan permintaan yang ambigu dan menjalankan tindakan paralel, keadaan sistem berubah terus, agen sering harus bekerja dari data parsial, dan alat eksternal membawa latency dan mode kegagalan mereka sendiri di atas itu. Karena modelnya probabilistik, setiap variabel baru menciptakan tempat lain di mana alur kerja dapat divergen atau memperburuk kesalahan sebelumnya.

Bagian berbahaya adalah bahwa agen dapat terus tampak bekerja dengan benar sementara menghasilkan respons yang tidak benar tetapi masuk akal, dibangun dari data parsial atau asumsi yang berakar pada informasi kuno. Itulah mengapa agen produksi memerlukan evaluasi terus-menerus yang terus berjalan setelah peluncuran, penanganan eksplisit data yang hilang dan kegagalan alat, dan verifikasi live dari keputusan sebelum menyelesaikan tindakan berdampak tinggi.

Lightrun menekankan pemberian akses konteks runtime kepada sistem AI. Informasi apa yang disediakan konteks runtime yang mungkin tidak tercakup dalam log, metrik, dan jejak konvensional, dan mengapa informasi ini khususnya penting untuk mendiagnosis kegagalan agen?

Kemampuan pengamatan konvensional menunjukkan gejala eksternal perilaku sistem, sering agregat, sampel, atau disaring melalui dasbor dan peringatan yang memicu ambang batas. Mereka biasanya bergantung pada keputusan yang dibuat oleh pengembang pada saat kode ditulis: apa informasi yang akan menarik di masa depan? Apa yang layak dicatat atau diukur? Konteks runtime melepaskan visibilitas dari kebutuhan untuk mengetahui sebelumnya apa yang mungkin menarik, dan menyediakan data granular yang menunjukkan apa yang terjadi di bawah tenda, dan bagaimana kita sampai di sana.

Celah nyata adalah data statis versus dinamis. Log, metrik, dan jejak konvensional adalah statis, dan menghasilkan catatan sejarah tentang apa yang terjadi. Konteks runtime Lightrun adalah dinamis. Ini memberikan agen kemampuan untuk menempatkan instrumentasi baru ke dalam kode yang berjalan, pada permintaan, dan mengamati nilai variabel yang tepat, argumen fungsi, keadaan objek, tumpukan panggilan, atau kondisi cabang sebagaimana terjadi.

Perbedaan ini khususnya penting untuk mendiagnosis kegagalan dalam kode yang dihasilkan agen, karena kegagalan tersebut sering sunyi. Agen dapat memilih alat yang salah, melewati argumen yang salah, atau bertindak berdasarkan asumsi kuno, dan masih menyelesaikan tugasnya tanpa memicu kesalahan. Kegagalan seperti itu tidak akan muncul dalam telemetri statis, karena tidak ada yang tahu sebelumnya untuk menginstrumentasikan untuk itu. Perilaku yang tidak terduga memerlukan penyelidikan dinamis langsung pada sistem yang berjalan, menempatkan instrumentasi baru tepat di mana model agen tentang dunia menyimpang dari kenyataan, bukan mengandalkan apa yang sudah direkam.

Itulah yang membuat konteks runtime dinamis menjadi lapisan verifikasi alami untuk keputusan AI yang dihasilkan dalam rekayasa.

Bagaimana Protokol Konteks Model (MCP) dan lapisan integrasi serupa dapat memungkinkan agen pengkodean untuk belajar dari perilaku eksekusi nyata tanpa memberikan akses berlebihan atau tidak aman ke sistem produksi?

MCP dan akses terkontrol ke alat eksternal (misalnya, pembungkus CLI) memungkinkan agen untuk memanggil kemampuan yang spesifik, terbatas, daripada diberi akses luas ke sistem dan dipercaya untuk berperilaku. Agen yang terhubung melalui server MCP untuk konteks runtime dapat meminta bukti baca-saja, nilai variabel, jalur panggilan, apakah ambang batas dilampaui, tanpa menyentuh akses tulis, tanpa kemampuan untuk mengirim ulang apa pun, dan tanpa memerlukan kredensial berdiri ke lingkungan yang mendasarinya.

Ketika merancang ulang agen generasi pertama, bagaimana perusahaan harus mendekati izin alat, memori, pengambilan data, evaluasi, pengawasan manusia, dan prosedur fallback sebagai bagian dari arsitektur kohesif daripada fitur terpisah?

Anda tidak dapat memasang bagian-bagian ini secara independen karena setiap bagian mengubah yang lain. Tempat terbaik untuk memulai adalah kerangka, harness yang mengontrol loop agen, dan orkestrasi alur kerja secara keseluruhan yang mengikat bersama beberapa agen dan aktor lain. Untuk alur kerja analisis penyebab akar, misalnya, tim harus memutuskan apa bukti yang diperlukan, sistem mana yang agen dapat inspeksi, apakah itu dapat menerbitkan kesimpulan atau hanya menggambar satu, kapan manusia harus menyetujui langkah berikutnya, dan apa yang terjadi jika bukti runtime tidak tersedia.

Setelah kontrak itu jelas, harness dan kerangka menyediakan mekanisme untuk menegakkan pedoman tersebut. Gerbang MCP dapat dimanfaatkan untuk membatasi akses agen ke kemampuan tertentu yang relevan dengan tujuannya. Alat dapat diberikan dengan hak istimewa terendah. Memori dapat diawasi, dengan data sensitif yang dihapus secara deterministik. Pengambilan dapat dirancang di sekitar bukti yang alur kerja butuhkan.

Evaluasi, pengawasan, dan fallback kemudian menutup loop. Sistem harus mengukur apakah kesimpulan benar dan didukung, membawa manusia ketika risiko atau ketidakpastian melintasi ambang batas yang ditentukan, dan berhenti atau jatuh kembali ke rekomendasi baca-saja ketika tidak dapat mengumpulkan bukti yang cukup. Catatan audit bersama harus menghubungkan pemicu, izin, bukti, panggilan alat, persetujuan, tindakan, dan hasil. Itulah yang membuat komponen-komponen ini menjadi satu arsitektur produksi daripada enam fitur terpisah.

Apa pengaman yang harus mengelilingi agen yang dapat memeriksa aplikasi live atau berpartisipasi dalam alur kerja rekayasa keandalan situs, terutama di lingkungan yang diatur di mana kontrol akses, privasi, auditabilitas, dan stabilitas operasional sangat kritis?

Ini adalah salah satu pertanyaan desain pusat ketika kami membangun Lightrun AI SRE. AI SRE beroperasi dekat dengan beberapa sistem paling sensitif dalam sebuah organisasi, sehingga kami merancangnya sebagai aktor operasional yang diprivilegi, bukan asisten obrolan. Keputusan penting adalah memisahkan bidang inspeksi dari bidang tindakan. AI SRE mengumpulkan bukti melalui integrasi baca-saja dan instrumentasi runtime yang diawasi Lightrun, dengan akses yang dibatasi oleh identitas, penyewa, layanan, dan lingkungan. Ini dapat memeriksa eksekusi live dan menghasilkan bukti yang hilang, tetapi lapisan inspeksi runtime tidak dapat memodifikasi keadaan aplikasi.

Dalam lingkungan yang diatur, batasan itu harus didukung oleh RBAC, SSO, isolasi penyewa, redaksi PII, kontrol retensi, dan jejak audit yang menunjukkan alat dan bukti mana yang mendukung setiap kesimpulan. Kami juga memerlukan batasan operasional sekitar berapa banyak data yang dapat dikumpulkan, seberapa sering runtime dapat diperiksa, dan tindakan mana yang memerlukan persetujuan. Jika bukti hilang atau kesimpulan tidak dapat diverifikasi, AI SRE harus mengatakan demikian dan menyerahkan keputusan kepada manusia daripada bertindak seolah-olah itu tahu lebih dari yang sebenarnya. Tujuannya adalah otonomi yang dikendalikan: cukup berguna untuk mempercepat penyelidikan, tetapi cukup terbatas untuk tetap aman bagi sistem live.

Seiring perusahaan melangkah melampaui agen eksperimental, apa pengukuran yang harus menentukan apakah agen benar-benar siap produksi, dan bagaimana Anda mengharapkan hubungan antara agen AI dan insinyur manusia berkembang selama beberapa tahun mendatang?

Saya akan menilai kesiapan produksi dengan seberapa sering tindakan agen AI menghasilkan hasil yang diinginkan, kesimpulannya bertahan melawan apa yang sebenarnya benar dalam produksi, kesimpulan yang tidak didukung ditangkap sebelum tindakan, dan apakah itu gagal secara terlihat dan aman ketika bukti tidak ada. Untuk agen rekayasa, akurasi hasil yang diverifikasi, cakupan bukti, waktu untuk mengkonfirmasi penyebab akar, tingkat keberhasilan fallback, dan hasil pasca-tindakan adalah metrik inti yang harus kami fokuskan.

Selama beberapa tahun mendatang, saya mengharapkan agen mengambil lebih banyak pengumpulan bukti dan penyelidikan pertama, serta pengawasan alur kerja agen, dan pembelajaran terus-menerus dari pengalaman dan umpan balik, sementara insinyur menetapkan kebijakan, menyelesaikan ketidakjelasan, menyetujui tindakan berisiko tinggi, dan mengarahkan sistem agen yang self-improving. Kepercayaan akan berkembang alur kerja demi alur kerja. Agen yang dapat menelusuri kesimpulan mereka kembali ke bukti live dan secara jelas mengungkapkan apa yang tidak dapat mereka verifikasi akan mendapatkan otonomi yang lebih besar. Yang tidak dapat akan tetap terbatas pada tugas yang sempit, rendah-stakes, terlepas dari seberapa fasih mereka terdengar.

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