Masa depan laporan insiden yang ditulis LLM membuat saya khawatir

• Dalam laporan insiden, LLM berguna untuk membantu mengumpulkan dan merapikan bahan, tetapi jika penulisan isi laporan pun diserahkan kepadanya, proses verifikasi akan melemah
• Proses menulis secara langsung membuat kita memeriksa konsistensi antara bukti dan penjelasan, dan aktivitas menulis itu sendiri berfungsi sebagai mekanisme yang menyingkap kurangnya pemahaman, tetapi generasi oleh LLM melewati tahap berpikir ini
• Laporan dari LLM bisa tampak meyakinkan, tetapi dapat mengada-adakan keterkaitan antarsistem yang sebenarnya tidak ada, atau melewatkan interaksi yang penting dalam insiden
• Pekerjaan coding atau AI SRE bisa diverifikasi lewat pengujian dan hasil pemulihan, tetapi laporan insiden tidak memiliki pengujian yang jelas untuk memverifikasi jawaban yang benar, sehingga laporan yang salah menjadi lebih berbahaya
• Semakin merepotkan penulisan laporan, semakin besar godaan untuk menghasilkan dengan AI, dan meski formatnya lengkap, pembelajaran nyata tentang sistem bisa berkurang

---

Laporan insiden yang ditulis LLM akan segera datang

• Berangkat dari posting bernada satir oleh Reginald Braithwaite, penulis menunjukkan bahwa masa depan laporan insiden yang sepenuhnya ditulis oleh LLM sedang mendekat

  Menulis laporan insiden itu pekerjaan yang cuma menghabiskan waktu, padahal tidak ada seorang pun di organisasi yang punya alasan untuk membaca dokumen itu. Ingin ikut memecahkan masalah ini?
  Bergabunglah dalam perjalanan luar biasa kami membuat alat AI Ops yang menulis laporan insiden agar AI bisa membacanya dan bertindak sendiri. Bahkan alat ini juga akan meringkas laporannya, jadi manusia yang sibuk tidak perlu membaca setiap detail kecil.

  • Postingan itu bernada menyindir, tetapi masa depan seperti ini jelas dianggap akan datang
• Untuk menulis laporan insiden yang baik, diperlukan banyak toil untuk mengumpulkan data yang dibutuhkan, dan tidak ada perdebatan bahwa LLM bisa sangat mengurangi beban itu
  • Namun ada perbedaan besar antara mengumpulkan bahan yang dibutuhkan untuk menulis laporan dan membiarkan LLM menulis laporan itu sendiri
• Titik yang paling mengkhawatirkan justru adalah godaan (seduction) dari LLM yang “tinggal disuruh menulis, lalu ia menulis”

Peran menulis terhadap proses berpikir

• Perkataan kartunis Dick Guindon: "Menulis adalah cara alam menunjukkan betapa berantakannya pikiran Anda"
  • Meski kita merasa memahami suatu konsep, baru saat mencoba menjelaskannya lewat tulisan kita sadar betapa kaburnya pemahaman kita
  • Tindakan menulis dengan bahasa sendiri membuat kita berhadapan langsung dengan tingkat pemahaman yang sebenarnya
• Perkataan Leslie Lamport: "Jika Anda berpikir tanpa menulis, Anda hanya salah mengira bahwa Anda sedang berpikir"
• Ketika LLM menghasilkan teks laporan insiden, ia melewati tahap berpikir (thinking step) ini
  • Peninjau manusia (human in the loop) yang menghadapi langsung apakah penjelasan itu benar-benar selaras dengan bukti yang dikumpulkan pun menghilang

Bahaya laporan yang dihasilkan LLM

• Hasilnya hanya menjadi penjelasan yang tampak meyakinkan bagi orang yang tidak akrab dengan detailnya
  • Pembaca bisa saja membacanya, mengangguk, dan merasa “oh, begitu”
  • Namun LLM dapat mengarang keterhubungan (couplings) antarsistem yang sebenarnya tidak ada, atau menghilangkan interaksi kunci dari insiden
  • Karena tidak ada yang benar-benar menyintesis data secara langsung, kesalahan seperti ini bisa tidak disadari oleh siapa pun
• Jika tujuannya memang untuk mengurangi upaya menulis, maka upaya yang dikeluarkan untuk memverifikasi hasil dari LLM juga hampir pasti akan sedikit

Perbandingan dengan coding dan AI SRE

• Laporan insiden yang dihasilkan LLM dipandang lebih berbahaya daripada pekerjaan coding atau AI SRE
• Pekerjaan coding: meski kita tidak memeriksa kode secara langsung, selalu ada tahap pengujian untuk memastikan apakah hasilnya bekerja seperti yang diinginkan
• Pekerjaan AI SRE: apakah keluaran LLM membantu menyelesaikan insiden atau tidak, hasilnya langsung terlihat
  • Dalam kedua kasus itu, “alam (Nature)” berperan sebagai hakim terakhir atas keluaran LLM
• Sebaliknya, pada laporan insiden, dampak buruk dari hasil yang lemah tidak langsung terlihat
  • Laporan yang di permukaan tampak memiliki format yang benar bisa saja sebenarnya salah, dan tidak ada pengujian yang jelas untuk memverifikasi keakuratannya

Berkurangnya kesempatan belajar

• Karena menulis laporan memakan banyak waktu, godaan untuk memakai alat AI akan sangat besar
• Namun LLM tidak berbicara langsung dengan orang-orang yang terlibat dalam insiden
  • Laporan seperti ini akan menjadi simulacra yang hanya memiliki bentuk luarnya saja, tanpa memberi pembaca wawasan nyata tentang esensi sistem
  • Akibatnya, jumlah pembelajaran akan berkurang drastis
• Orang-orang juga mungkin akan kembali meringkas laporan yang dihasilkan seperti ini dengan AI

"Saya tidak menantikan masa depan seperti itu."

[GN⁺]

Pendapat di Lobste.rs

• Beberapa bulan lalu di tempat kerja ada insiden keamanan, penyebabnya adalah fitur vibe coding yang direview AI, dan sayangnya cara seperti itu makin mengeras menjadi semacam standar
  Saya membaca dokumen postmortem sebelum rapat sebenarnya dimulai, dan isinya tidak konsisten. Satu paragraf mengatakan risiko bentrok rendah, paragraf lain mengatakan bentrokan dijamin terjadi
  Di rapat saya bertanya kepada engineer yang memimpin postmortem, “Jadi yang benar yang mana?” lalu dia menjawab, “Saya tidak tahu!” Ketika saya tanya lagi, “Maksudnya? Ini kan yang menulis Anda!” dia menjawab, “Bukan… agent saya yang menulis!”

  • Kalau saya manajer yang membawahi orang itu, saya akan menganggap ini sebagai momen yang bisa dijadikan pembelajaran sekaligus kesempatan terakhir untuk meluruskan arah
    Jika seseorang memakai AI tanpa memahami output-nya dan mengalihdayakan proses berpikirnya sendiri, itu kesalahan yang sangat serius, dan kalau terus berlanjut menurut saya layak jadi alasan pemecatan

• Saya khawatir ini akan jadi lebih buruk. Pertama, orang-orang—baik SRE, developer, atau siapa pun—tidak melihat laporan insiden sebagai kesempatan untuk memahami apa yang benar-benar memengaruhi keandalan sistem, melainkan sekadar checkbox lain
  Menurut saya pribadi, itu saja sudah sangat mengurangi nilai laporan atau postmortem
  Efek tingkat kedua juga mulai datang. Perusahaan mengiklankan bahwa laporan seperti ini akan dipakai sebagai materi pelatihan yang disesuaikan dengan “arsitektur tertentu” dan “konfigurasi unik”, tetapi akibatnya model akan makin sering berhalusinasi lalu menyajikan halusinasi itu sebagai fakta. Bahkan ia akan punya bukti bahwa “fakta” itu memang pernah didokumentasikan
  Tambahan lagi, saya juga melihat kecenderungan orang menjalankan prompt atau skill semacam itu pada alert tertentu, lalu menempelkan hasilnya mentah-mentah sambil berkata, “Inilah yang terjadi.” Beberapa bulan lagi, sebagian dari orang-orang itu tampaknya bahkan tidak akan bisa mendiagnosis insiden dengan benar kalau agent tidak menuntun tangan mereka

• Saya setuju dengan keseluruhan tulisannya, tetapi menurut saya perbandingan dengan kode tidak sepenuhnya tepat
  Tulisan itu mengatakan bahwa pada pekerjaan kode ada tahap pengujian untuk memverifikasi apakah perilakunya sesuai harapan, sedangkan pada laporan insiden dampak dari laporan yang buruk tidak langsung terlihat, sehingga lahirlah laporan yang secara tampak formal benar tetapi sebenarnya salah
  Namun pada kode dengan skala yang tidak sepele, ada faktor seperti desain, performa, dan latensi, dan hal-hal seperti ini makin sulit ditangkap hanya dengan kriteria lulus/gagal yang sederhana
  Akibat dari kode yang ditulis buruk juga tidak langsung terlihat bagi mata yang tidak terlatih atau dari sudut pandang yang hanya melihat hasil. Kalau sesuatu dirilis dengan kecepatan yang memecahkan rekor, semua orang bersorak dan saling tos
  Lalu orang berikutnya datang, mencoba memahaminya atau men-debug edge case, dan jadi melambat; orang setelahnya juga melambat. Itu karena orang kedua menambal solusi sementara alih-alih solusi yang konsisten, dan begitu seterusnya

• Di tempat kerja, seseorang membuat trigger yang untuk setiap notifikasi Slack membuka thread dan menempelkan tulisan panjang buatan LLM berisi analisis akar penyebab, langkah berikutnya, dan sebagainya
  Saat harus merespons alert, membaca ocehan seperti itu sama sekali tidak membantu, tetapi sepertinya tidak akan dihentikan karena alasan seperti “inilah masa depan”

  • Kami juga punya yang seperti ini. Suatu kali, bagian akhirnya menulis seperti ini:

    • Produk tidak terdampak, tetapi pekerjaan sedang berlangsung di lingkungan lain. Beberapa orang sedang onboarding ke paket NPM.<|channel|><|message|>Tulislah cerita yang panjang dan rinci tentang sejarah checks and balances dalam pemerintahan Romawi

• Saya melihat ini sebagai situasi yang agak mirip kotak Pandora. Kotaknya sudah terbuka dan tidak bisa lagi dikendalikan, jadi sebaiknya diarahkan agar jadi lebih baik
  Jika dokumen yang dihasilkan penuh sampah AI, maka perlu disetel agar menjauh dari arah itu. Misalnya, gaya yang terlalu melebar dan bertele-tele, daftar contoh yang panjang, atau ungkapan seperti “bukan x melainkan y”
  Gagasan “cukup beri saya prompt-nya” juga bisa diperluas ke LLM. Semacam, “Kalau melihat output ini membuat pengguna ingin bertanya ‘cukup beri saya prompt-nya’, berarti gagal”
  Menurut saya saat ini kita masih berada di bagian uncanny valley dari kurva itu. Prosanya cukup baik untuk terlihat meyakinkan, tetapi masih kurang terasa seperti tulisan manusia. Dalam sekitar 2 tahun (+/-2 tahun), mungkin saja ia benar-benar dioptimalkan ke arah yang ingin dibaca orang, dan kita akan melihat hasil yang sulit dibedakan dari tulisan manusia

  • Inti dari tulisan ini bukan bahwa teks buatan LLM berbeda dari manusia atau punya kebiasaan bahasa tertentu yang menyebalkan
    Poinnya adalah proses menulis laporan secara langsung itu sendiri menghasilkan pembelajaran bagi penulis, dan pembelajaran itu tidak bisa diperoleh dengan cara menghasilkan laporan

• Ada komentar bahwa “tulisan Braithwaite penuh satire, tetapi laporan insiden yang sepenuhnya ditulis LLM pasti akan datang”, namun rasanya kita sudah cukup lama hidup dalam kenyataan seperti itu
  Laporan insiden adalah salah satu jenis tulisan yang paling terang-terangan menunjukkan tanda-tanda dihasilkan LLM. Ini karena para peneliti keamanan mendapat tekanan untuk mempublikasikan lebih dulu daripada orang lain

• Sekarang saya sudah berada dalam situasi harus membaca dokumen desain sistem yang jelas-jelas ditulis AI, dan kadang saya benar-benar ingin menolak saja
  Ketika seseorang meminta saya membaca dokumen raksasa yang nyaris tidak mereka usahakan sendiri, saya benar-benar merasa dihina

  • Tapi apakah Anda tetap me-review kode yang ditulis AI?