Sapan Pandya, Insinyur Perangkat Lunak Senior dan Anggota Senior IEEE – Seri Wawancara

Sapan Pandya adalah Insinyur Perangkat Lunak Senior dan Anggota Senior IEEE yang berbasis di New Jersey, dengan pengalaman lebih dari sepuluh tahun dalam sistem transaksi terdistribusi yang tangguh. Kiprahnya mencakup integritas transaksi, integrasi perangkat lunak dengan perangkat fisik, pemecahan masalah di lingkungan produksi, dan validasi penerapan di lingkungan yang diatur. Ia meraih gelar magister Ilmu Komputer dari Stevens Institute of Technology serta berkontribusi dalam penelaahan akademik dan penelitian teknis.

Penelitian Pandya mengkaji keamanan siber kios, AI tepi, dan rekayasa keandalan berbantuan AI. Pengalamannya di lingkungan produksi membentuk fokusnya pada bukti, hasil transaksi, dan akuntabilitas operasional. Dalam wawancara ini, ia membahas idempotensi, catatan transaksi yang saling bertentangan, ketidakpastian dalam sistem pemulihan, serta kontrol yang diperlukan sebelum agen AI dapat bertindak pada infrastruktur yang sangat penting. Ia membedakan pengalaman praktis di bidang rekayasa dari penelitian yang dilakukan melalui analisis literatur serta pengujian terkontrol atau sintetis.

Karier Anda berfokus pada keandalan perangkat lunak dan sistem transaksi terdistribusi. Bagaimana pengalaman tersebut membentuk pemahaman Anda tentang keandalan, dan tantangan apa yang memengaruhi pandangan Anda tentang penggunaan AI untuk mengelola sistem yang kompleks?

Pandangan saya bergeser dari mempertanyakan apakah suatu komponen berfungsi menjadi mempertanyakan apakah transaksi pelanggan telah selesai dan dapat dipertanggungjawabkan.

Pada awal karier, sebagian besar perhatian saya tertuju pada perilaku aplikasi: memvalidasi masukan, menangani respons, dan memastikan antarmuka mengikuti alur kerja yang direncanakan. Seiring tanggung jawab saya meluas hingga mencakup integrasi sistem, pemecahan masalah di lingkungan produksi, dan validasi penerapan, saya harus melihat lebih jauh daripada komponen individual.

Sebuah layanan dapat menyelesaikan tugasnya sementara layanan lain masih menunggu konfirmasi. Perangkat lunak dapat mencatat operasi yang berhasil, sementara perangkat fisik gagal memberikan hasil yang diharapkan. Lulusnya pengujian setiap komponen saja tidak membuktikan bahwa interaksi secara keseluruhan akan berjalan dengan benar.

Pengalaman itu membuat saya sangat tertarik pada batas antarsistem. Apa yang diketahui setiap komponen? Apa yang diasumsikannya? Apa yang terjadi ketika asumsi-asumsi itu tidak lagi berlaku?

Pengalaman itu juga membentuk cara saya memandang AI. AI sangat bermanfaat untuk membantu para insinyur mengumpulkan bukti, mengenali pola, dan menyelidiki kegagalan dengan lebih cepat. Namun, penjelasan tentang apa yang mungkin terjadi berbeda dengan catatan terverifikasi tentang apa yang sebenarnya terjadi.

Saya ingin AI mengurangi upaya yang diperlukan untuk menyelidiki masalah tanpa menurunkan standar bukti yang dibutuhkan untuk menyelesaikannya.

Anda menekankan bahwa kode yang benar secara teknis tidak selalu menjamin hasil transaksi yang benar. Bisakah Anda menjelaskan contoh konkret ketika sebuah transaksi tampak gagal akibat waktu tunggu habis, padahal sebenarnya sudah selesai? Apa yang bisa salah ketika sistem secara otomatis mencoba kembali operasi tersebut, dan bagaimana seharusnya para insinyur mencegah transaksi ganda?

Bayangkan pembayaran hipotetis sebesar $50. Aplikasi mengirimkan permintaan, layanan pembayaran berhasil mencatatnya, tetapi responsnya hilang sebelum sampai ke aplikasi.

Pelanggan melihat pesan bahwa waktu tunggu habis, padahal pembayaran sudah diproses. Jika aplikasi mengirimkan permintaan pembayaran baru, pelanggan bisa dikenai biaya sekali lagi.

Waktu tunggu yang habis memberi tahu Anda bahwa respons tidak tiba tepat waktu. Hal itu tidak memberi tahu apakah transaksi yang mendasarinya berhasil.

Salah satu perlindungan yang umum digunakan adalah idempotensi: mengizinkan permintaan logis yang sama untuk dikirim ulang tanpa menimbulkan dampak finansial tambahan. Aplikasi mempertahankan pengenal operasi yang sama pada setiap percobaan ulang, dan layanan penerima mengenalinya sebagai permintaan awal, bukan pembelian baru.

Hal terpenting bukan sekadar menyertakan pengenal. Layanan harus menerapkan identitas tersebut dan menyimpan informasi yang cukup untuk membedakan operasi yang telah selesai dari yang masih berlangsung. Pengenal tidak dapat melindungi tindakan lanjutan yang mengabaikannya.

Jika hasilnya masih belum pasti, proses pemulihan seharusnya memeriksa transaksi yang sudah ada dan mencocokkan catatan terkait, alih-alih langsung membuat transaksi pengganti.

Saya juga akan membatasi percobaan ulang dan menetapkan langkah yang harus diambil jika pemulihan otomatis tidak dapat memastikan hasilnya. Pelanggan memerlukan status tertunda yang jelas dan jalur penyelesaian, bukan tagihan berulang atau layar pemrosesan yang tak kunjung selesai.

Dalam sistem terdistribusi, basis data, layanan backend, dan kios fisik dapat melaporkan informasi yang saling bertentangan tentang transaksi yang sama. Pernahkah Anda menghadapi inkonsistensi semacam ini di lingkungan produksi, dan bagaimana masalah tersebut diselidiki serta diselesaikan? Jika ada, apa peran AI dalam mencocokkan catatan-catatan yang saling bertentangan ini?

Ya, penyelidikan inkonsistensi status transaksi telah menjadi bagian dari pekerjaan saya di lingkungan produksi. Agar dapat menjelaskan alur penalarannya tanpa membahas insiden di tempat kerja, saya akan menggunakan contoh hipotetis.

Bayangkan mesin kasir swalayan biasa. Layanan pembayarannya mencatat transaksi pembelian berhasil, printernya melaporkan bahwa tugas mencetak struk telah diterima, lalu layar menampilkan pesan kesalahan. Pengamatan tersebut mungkin menggambarkan tahapan interaksi yang berbeda, bukan membuktikan bahwa seluruh transaksi pembelian gagal.

Pertama-tama, saya akan menyusun ulang urutan kejadian dengan menggunakan ID transaksi serta catatan layanan dan perangkat yang relevan. Setelah itu, saya akan memastikan apa yang dibuktikan oleh setiap pengamatan. Printer yang menerima tugas cetak belum tentu membuktikan bahwa struk sampai ke pelanggan. Permintaan yang diterima juga belum tentu membuktikan bahwa dampak finansialnya telah tercatat.

Penyelesaian masalah bergantung pada tahapan yang mengalami kegagalan. Mengulangi seluruh transaksi mungkin tidak tepat jika yang perlu ditangani hanya tahap keluaran. Jika bukti yang tersedia tidak cukup untuk memastikan apa yang terjadi, operasi yang terdampak harus tetap dikendalikan selama penyelidikan berlangsung.

Perbaikan jangka panjang juga harus mengatasi penyebab terjadinya inkonsistensi tersebut, bukan sekadar memperbaiki satu catatan.

AI dapat membantu menghubungkan berbagai peristiwa dan mengidentifikasi informasi yang belum tersedia. Saya akan memintanya menyajikan beberapa kemungkinan penjelasan beserta bukti yang mendukung masing-masing. AI seharusnya membantu mempersempit penyelidikan, bukan menyelesaikan pertentangan antarcatatan dengan memilih penjelasan yang terdengar paling meyakinkan.

Seiring perkembangan agen AI dari mendiagnosis insiden produksi menjadi merekomendasikan atau menjalankan tindakan pemulihan, perlindungan apa yang harus diterapkan sebelum sistem AI dapat mencoba kembali, membatalkan, atau mengubah transaksi? Bagaimana kontrol deterministik seperti kunci idempotensi, log transaksi, dan mekanisme rekonsiliasi dapat mencegah AI menimbulkan kegagalan tambahan?

Saya akan memisahkan pengusulan tindakan dari pemberian otorisasi dan pelaksanaannya.

Agen AI mungkin merekomendasikan percobaan ulang, tetapi kontrol terpisah harus menentukan apakah tindakan tersebut diizinkan. Kontrol itu harus memeriksa status transaksi saat ini, identitas operasi, izin agen, serta kondisi yang menjadikan tindakan tersebut aman.

Pemeriksaan itu harus dilakukan saat tindakan dijalankan, bukan hanya ketika model pertama kali memeriksa insiden. Sementara itu, proses lain mungkin telah menyelesaikan transaksi tersebut.

Ruang lingkup alat yang tersedia bagi agen juga harus dibatasi. Izin untuk mengambil status transaksi berbeda dengan izin untuk membatalkan pembayaran atau mengubah catatan keuangan. Agen tidak boleh dapat memperluas kewenangannya sendiri hanya karena solusi yang diutamakannya memerlukan akses lebih luas.

Idempotensi membatasi dampak duplikat. Log menyimpan riwayat yang diperlukan untuk penyelidikan. Rekonsiliasi memeriksa kesesuaian antarcatatan yang relevan. Namun, tak satu pun dari ketiganya, jika berdiri sendiri, dapat memastikan bahwa tindakan yang diusulkan memang tepat.

Saya juga akan mencatat bukti yang digunakan, rekomendasi, keputusan pemberian otorisasi, dan hasil sebenarnya. Dengan begitu, intervensi tersebut dapat ditinjau kembali setelahnya.

Kontrol ini harus diterapkan melalui perangkat lunak yang dapat diuji dan berada di luar model. Instruksi agar agen bertindak hati-hati merupakan panduan yang berguna, tetapi bukan mekanisme pemberian otorisasi.

Bayangkan sebuah sistem pemantauan AI mendeteksi dugaan kegagalan transaksi dan merekomendasikan pembatalan operasi secara otomatis. Jika transaksi sebenarnya berhasil, tetapi konfirmasinya tertunda, intervensi tersebut dapat menimbulkan masalah baru. Bagaimana tim rekayasa sebaiknya merancang sistem pemulihan berbasis AI agar dapat mengenali ketidakpastian dan menghindari tindakan korektif yang didasarkan pada informasi yang belum lengkap?

Sistem perlu memiliki status “hasil belum diketahui” yang benar-benar terpisah. Jika tidak, sistem kemungkinan akan mengartikan ketiadaan informasi sebagai keputusan keliru bahwa transaksi gagal.

Konfirmasi yang tertunda merupakan alasan untuk menyelidiki, bukan alasan otomatis untuk membatalkan transaksi. Pembatalan adalah operasi keuangan lain yang memiliki konsekuensinya sendiri. Tindakan itu memerlukan alasan yang ditetapkan secara independen serta otorisasi yang sesuai.

Saya akan memisahkan respons menjadi dua jalur. Jalur penyelidikan dapat mengambil status, mengumpulkan peristiwa yang belum tercatat, membandingkan catatan, dan memberi tahu tim yang bertanggung jawab. Jalur tindakan keuangan tetap diblokir sampai persyaratannya terpenuhi.

Dengan demikian, skor keyakinan AI tidak menggantikan bukti transaksi. Model bisa sangat yakin pada penjelasan yang disusun berdasarkan informasi yang belum lengkap.

Titik eskalasi yang jelas juga harus ditetapkan. Membiarkan transaksi tertunda tanpa batas waktu bukan hasil yang memuaskan bagi pelanggan. Seseorang harus bertanggung jawab menangani kasus yang belum terselesaikan, dengan konteks yang cukup untuk menentukan langkah aman berikutnya.

Karena itu, proses pemulihan harus mampu menyatakan, “Saya belum dapat memberikan alasan yang cukup untuk mengubah transaksi ini,” sekaligus, “Berikut hal yang perlu dilakukan untuk menyelesaikannya.”

Mengenali ketidakpastian hanya berguna jika sistem memiliki cara praktis untuk menanganinya.

Salah satu pertanyaan terbesar seputar AI otonom adalah menentukan kapan persetujuan manusia tetap diperlukan. Tindakan pemulihan dalam sistem produksi apa yang menurut Anda boleh dilakukan AI secara mandiri, dan tindakan apa yang harus selalu memerlukan otorisasi manusia? Bagaimana organisasi sebaiknya menetapkan batasan ini ketika transaksi keuangan, kepatuhan terhadap peraturan, atau kepercayaan pelanggan menjadi taruhannya?

Saya akan menetapkan batas berdasarkan konsekuensi jika tindakan itu salah, bukan berdasarkan apakah suatu tindakan diberi label “AI”.

Investigasi hanya-baca merupakan langkah awal yang wajar, asalkan agen hanya dapat mengakses informasi yang diizinkan. Agen dapat mengumpulkan catatan diagnostik, mengelompokkan peringatan yang berkaitan, dan menyiapkan ringkasan insiden tanpa diberi wewenang untuk mengubah transaksi yang mendasarinya.

Sejumlah prosedur pemulihan yang telah ditetapkan sebelumnya juga mungkin cocok untuk diotomatisasi jika kondisinya diverifikasi secara independen dan dampaknya terbatas.

Saya akan mewajibkan otorisasi manusia jika intervensi yang diusulkan berada di luar prosedur yang disetujui, jika catatan saling bertentangan dan hasil keuangannya belum dapat dipastikan, atau jika tindakan tersebut akan mengubah kontrol keamanan maupun izin agen itu sendiri. Agen tidak seharusnya mengotorisasi keputusan semacam itu untuk dirinya sendiri.

Bukan berarti setiap operasi keuangan rutin harus mendapat persetujuan seseorang. Pemrosesan berdasarkan aturan yang telah ditetapkan berbeda dari membiarkan model merancang koreksi saat terjadi insiden.

Peninjauan oleh manusia juga harus bermakna. Layar persetujuan seharusnya menampilkan bukti pendukung, ketidakpastian yang masih ada, dampak yang diperkirakan, serta alternatif yang tersedia. Meminta seseorang menyetujui paragraf bernada yakin tanpa konteks tersebut hanya memberi sedikit perlindungan.

Batasan ini sebaiknya disepakati sebelum penerapan. Saat terjadi gangguan, bukan waktu yang tepat untuk menentukan seberapa besar wewenang yang seharusnya dimiliki sistem otomatis.

Anda telah banyak berkecimpung dalam sistem backend yang toleran terhadap kesalahan, perangkat observabilitas, dan integrasi antara layanan perangkat lunak dengan perangkat keras fisik. Telemetri dan bukti produksi seperti apa yang dibutuhkan agen AI agar dapat mendiagnosis insiden secara andal? Bagaimana tim rekayasa dapat membedakan rekomendasi berguna yang dihasilkan AI dari kesimpulan yang tampak masuk akal tetapi keliru dan dapat memperburuk gangguan?

Saya akan mulai dengan bukti yang menghubungkan operasi pelanggan di seluruh sistem yang terlibat: pengenal transaksi, peristiwa layanan, perubahan status yang tersimpan secara persisten, respons perangkat, dan kegagalan komunikasi.

Versi perangkat lunak dan perubahan konfigurasi juga penting. Kegagalan yang mulai terjadi setelah peluncuran versi baru memberi petunjuk berguna kepada penyelidik, tetapi waktu terjadinya saja tidak membuktikan hubungan sebab-akibat.

Agen juga perlu memahami keterbatasan bukti. Log bisa tidak lengkap, catatan bisa terlambat masuk, dan jam sistem bisa menunjukkan waktu yang berbeda. Tidak adanya tanda terima bukan berarti tidak ada operasi yang terjadi.

Diagnosis yang berguna harus memisahkan pengamatan dari penafsiran. “Klien mencatat waktu tunggu yang habis” adalah pengamatan. “Backend tidak tersedia” adalah penjelasan yang memerlukan dukungan lebih lanjut.

Saya berharap rekomendasi mencantumkan catatan yang mendasarinya, menjelaskan hal-hal yang masih belum diketahui, serta menyebutkan pemeriksaan tambahan yang dapat mengonfirmasi atau membantah kesimpulannya.

Selanjutnya, para insinyur sebaiknya memverifikasi rekomendasi yang berdampak besar berdasarkan catatan asli, alih-alih hanya mengandalkan ringkasan agen. Hal ini terutama penting ketika ringkasan memadatkan riwayat peristiwa yang panjang atau saling bertentangan.

Standar yang akan saya gunakan sederhana: dapatkah insinyur lain menelusuri bukti dan mencapai kesimpulan yang dapat dipertanggungjawabkan? Jika penjelasannya tidak lolos pemeriksaan itu, rekomendasi tersebut belum siap menjadi dasar perubahan di sistem produksi.

Dalam penelitian Anda yang telah dipublikasikan tentang ketahanan terhadap ransomware pada kios lotre dan taruhan, Anda mengevaluasi kerangka keamanan berbantuan AI menggunakan lingkungan sintetis yang menyimulasikan 500 kios. Apa temuan terpentingnya, dan keterbatasan apa yang perlu dipahami pembaca saat menafsirkan hasil ini? Validasi tambahan apa yang diperlukan sebelum arsitektur yang diusulkan diterapkan di lingkungan produksi aktif?

Saya ingin mengkaji ketahanan yang melampaui deteksi: bagaimana lingkungan terminal dapat membatasi serangan, mengenalinya, dan memulihkan diri sambil tetap menyimpan bukti tentang apa yang terjadi.

Kerangka Keamanan Tangguh yang dihasilkan menggabungkan kontrol pencegahan, deteksi anomali berbantuan AI, serta mekanisme respons dan pemulihan yang telah ditetapkan. Komponen AI berfokus pada deteksi perilaku mencurigakan. Ini bukan eksperimen yang memungkinkan agen berbasis model bahasa mengubah transaksi keuangan secara mandiri.

Evaluasi tersebut menggunakan lingkungan sintetis yang merepresentasikan 500 kios selama simulasi 72 jam, dengan emulasi perilaku serangan ransomware, bukan penerapan pada 500 terminal fisik.

Dibandingkan dengan tolok ukur dasar studi yang hanya menggunakan antivirus, rata-rata waktu deteksi turun dari 52 menjadi 31 menit, sedangkan rata-rata waktu pemulihan turun dari 120 menjadi 56 menit.

Itulah hasil dari kerangka kerja gabungan dalam kondisi eksperimen. Hasil tersebut tidak boleh dianggap sebagai hasil AI semata atau sebagai jaminan kinerja di lingkungan operasional. Salah satu temuan pentingnya adalah bahwa deteksi yang lebih dini saja tidak menghasilkan peningkatan pemulihan yang sama. Rancangan penahanan dan pemulihan juga berperan.

Keterbatasan penelitian ini penting untuk diperhatikan. Beban kerja simulasi, kondisi jaringan, perilaku serangan, dan pertahanan dasar yang digunakan tidak mencerminkan setiap lingkungan operasional. Perangkat dan aplikasi yang berbeda memerlukan validasi baru.

Sebelum digunakan dalam produksi, saya ingin melihat pengujian dengan perangkat keras yang representatif, penilaian keamanan independen, evaluasi dalam jangka waktu lebih panjang, serta pengukuran yang cermat terhadap alarm palsu dan beban pemrosesan.

Saya juga akan menguji proses pemulihan terhadap aktivitas transaksi yang sah. Memulihkan citra perangkat lunak yang berfungsi saja tidak cukup jika proses tersebut menghilangkan informasi yang diperlukan untuk mencatat transaksi yang telah diselesaikan.

Studi ini menjadi landasan untuk pengujian lebih lanjut. Membuktikan bahwa sistem berperilaku aman di lingkungan operasional nyata merupakan langkah tersendiri.

Sudut pandang Anda memadukan pengalaman bertahun-tahun di bidang rekayasa produksi dengan penelitian akademis tentang keandalan perangkat lunak dan keamanan berbasis AI. Bisakah Anda membedakan mekanisme keandalan yang telah Anda terapkan atau operasikan sendiri dalam sistem produksi aktif dari pendekatan yang Anda kaji melalui penelitian atau pengujian simulasi? Menurut Anda, kemampuan pemulihan berbasis AI apa yang sudah praktis diterapkan saat ini, dan mana yang masih sebagian besar bersifat eksperimental?

Pengalaman kerja saya di lingkungan produksi mencakup pengembangan dan integrasi perangkat lunak, validasi transaksi, pemecahan masalah, pengujian, serta validasi rilis.

Penelitian yang saya publikasikan merupakan bagian tersendiri dari pekerjaan saya, dan setiap studi perlu dipahami sesuai dengan metode dan keterbatasan yang dinyatakan.

Makalah tentang ransomware mengevaluasi kerangka keamanan yang diusulkan dalam lingkungan pengujian sintetis. Makalah saya tentang AI edge merupakan analisis berbasis tinjauan pustaka mengenai kecerdasan pada perangkat dan kemungkinan penerapannya pada terminal transaksi. Artikel saya di IEEE FeedForward mengkaji arsitektur keandalan berbantuan AI melalui simulasi terkontrol, termasuk pemantauan, eskalasi, dan perilaku pengalihan ke mekanisme cadangan.

Tidak satu pun publikasi tersebut boleh dianggap sebagai bukti bahwa saya pernah menerapkan agen AI otonom yang memiliki wewenang atas transaksi keuangan langsung.

Untuk penerapan praktis, saya akan memprioritaskan bantuan yang dapat diperiksa oleh para insinyur: ringkasan insiden yang ditautkan ke catatan sumber, korelasi di antara berbagai peringatan, dan saran pemeriksaan diagnostik. Kegunaannya tetap perlu diukur di lingkungan tempat bantuan tersebut akan beroperasi.

Masalah yang lebih sulit adalah pemulihan terbuka, ketika model memilih dan menjalankan perubahan dalam kondisi yang tidak diperkirakan sebelumnya. Hal ini memerlukan standar pembuktian yang jauh lebih tinggi daripada sekadar saran diagnostik yang bermanfaat.

Saya memandang pengalaman produksi dan penelitian saya sebagai dua hal yang saling melengkapi: yang satu membentuk pemahaman saya tentang masalah operasional, sementara yang lain mengeksplorasi pendekatan yang masih harus membuktikan kelayakannya melalui validasi.

Ke depan, seiring meningkatnya kemampuan agen AI untuk mendeteksi anomali, mendiagnosis kegagalan, dan mengoordinasikan pemulihan di berbagai sistem terdistribusi, bagaimana Anda membayangkan hubungan antara sistem otonom dan insinyur manusia akan berkembang? Perlindungan teknis, bukti operasional, dan mekanisme akuntabilitas apa yang diperlukan sebelum organisasi dapat dengan yakin memberikan wewenang lebih besar kepada AI atas infrastruktur produksi yang sangat penting bagi misi mereka?

Saya memperkirakan AI akan semakin banyak menangani pekerjaan untuk menyusun gambaran suatu insiden. Insinyur dapat memulai dengan linimasa yang berguna, komponen yang terdampak, berbagai penjelasan yang mungkin, dan bukti yang belum tersedia, alih-alih menghabiskan begitu banyak waktu mengumpulkan semua itu secara manual.

Dengan begitu, orang akan memiliki lebih banyak waktu untuk mengambil keputusan yang membutuhkan pemahaman tentang kewajiban sistem dan konsekuensi dari mengubahnya.

Saya akan memperluas wewenang untuk menjalankan tindakan secara bertahap. Pada awalnya, agen dapat beroperasi dalam mode bayangan, menghasilkan rekomendasi tanpa melaksanakannya. Tim dapat membandingkan rekomendasi tersebut dengan hasil yang telah ditinjau dan menguji perilaku agen saat informasi tidak tersedia, saling bertentangan, atau sudah kedaluwarsa.

Evaluasi harus mencakup intervensi yang keliru, masalah yang tidak terdeteksi, eskalasi yang tidak perlu, serta pemulihan dari kesalahan yang dibuat oleh agen itu sendiri. Rekomendasi yang cepat tidak berguna jika mengarahkan tim penanganan ke jalur yang salah.

Wewenang yang lebih besar juga harus tetap bersyarat. Pembaruan model atau perubahan sistem besar dapat membuat pengujian sebelumnya tidak lagi berlaku. Tim perlu memiliki cara untuk mengurangi atau mencabut izin agen ketika perilakunya tidak lagi memenuhi standar yang disyaratkan.

Tanggung jawab manusia tidak hilang seiring meningkatnya otomatisasi. Seseorang harus bertanggung jawab atas aturan operasional, bukti yang diperlukan untuk melakukan perubahan, dan proses penyelidikan kegagalan.

Saya membayangkan para insinyur akan lebih sedikit menghabiskan waktu untuk mengumpulkan informasi dan lebih banyak mencurahkan waktu untuk menetapkan, menguji, dan memelihara kondisi yang membenarkan tindakan otomatis.

Terima kasih atas wawancara yang luar biasa ini. Pembaca yang ingin mengikuti kiprahnya dalam keandalan transaksi terdistribusi dan pemulihan berbantuan AI yang bertanggung jawab dapat terhubung dengan Sapan Pandya.