Bukan AI yang menghapus database Anda, tetapi Anda sendiri

• Inti dari insiden ketika agen Cursor/Claude menghapus database produksi bukanlah menganalisis jawaban AI, melainkan mengapa endpoint API yang memungkinkan penghapusan total ada di sistem yang sudah dideploy
• Dalam insiden deployment SVN pada 2010, trunk terhapus saat prosedur penyalinan manual, dan otomatisasi deployment untuk mencegah kesalahan yang sama kemudian dibuat lalu berkembang menjadi pipeline CI/CD
• Otomatisasi mengulang pekerjaan yang sama dengan cara yang sama, tetapi AI tidak memberi jaminan itu; meskipun tampak seperti “thinking” atau “reasoning”, pada kenyataannya ia hanya menghasilkan token
• Jika ada API publik yang bisa menghapus seluruh database produksi, besar kemungkinan pada akhirnya seseorang akan memanggilnya meskipun bukan AI; jika yang disalahkan hanya pemanggilnya, maka masalah desain sistem akan tertutupi
• Di organisasi yang banyak memakai AI, hal yang penting adalah mengetahui apa yang dideploy ke produksi, dan dibutuhkan proses agar developer yang kompeten memakai AI bukan sebagai sarana lari dari tanggung jawab, melainkan sebagai alat pendukung kerja

---

Inti masalahnya bukan AI, melainkan batas tanggung jawab sistem yang sudah dideploy

• Tweet tentang agen Cursor/Claude yang menghapus database produksi perusahaan memang menyebar, tetapi pertanyaan yang lebih mendasar adalah, “Mengapa ada endpoint API yang dapat menghapus seluruh database produksi?”
• Pengguna tersebut mencoba menganalisis jawaban agen atas pertanyaan “Saya sudah bilang jangan pernah melakukan tindakan ini, lalu mengapa tetap menghapusnya?”, tetapi yang hilang adalah letak tanggung jawab
• AI tidak bisa dibela tanpa syarat, tetapi alat juga tidak bisa disalahkan untuk menggantikan kesalahan kita sendiri
• Sekalipun AI tidak memanggil endpoint itu, jika fungsi seperti itu tersedia sebagai API publik, besar kemungkinan suatu hari orang lain akan memanggilnya
• Strukturnya mirip seperti memasang tombol penghancur diri di dashboard mobil, lalu menginterogasi anak yang menekannya dengan pertanyaan “kenapa kamu menekannya?”

Pelajaran dari insiden deployment SVN tahun 2010

• Prosedur deployment di sebuah perusahaan sangat manual, dan kontrol versinya menggunakan SVN
• Saat deployment, trunk disalin ke folder bernama tanggal rilis, lalu rilis itu disalin lagi dengan nama current agar sistem mengambil rilis terbaru
• Suatu hari saat deployment, trunk tidak sengaja disalin dua kali, dan di CLI dilakukan upaya mengedit perintah sebelumnya untuk menghapus salinan duplikat
• Yang terhapus ternyata bukan salinan duplikat, melainkan trunk, dan masalah baru terungkap ketika developer lain kemudian tidak bisa menemukan trunk
• Lead developer menjalankan perintah untuk membatalkan penghapusan, dan setelah penanggung jawab teridentifikasi lewat log, tugas berikutnya adalah menulis skrip otomatisasi deployment agar kesalahan yang sama tidak terulang
• Sebelum hari itu berakhir, sistem yang lebih kokoh sudah disiapkan, dan sistem itu kemudian berkembang menjadi pipeline CI/CD yang lengkap

Otomatisasi dan AI tidak memberi tingkat keamanan yang sama

• Otomatisasi membantu mengurangi kesalahan kecil yang muncul dari pekerjaan manual dan berulang
• Daripada bertanya mengapa SVN tidak mencegah penghapusan trunk, masalah sebenarnya adalah proses manual yang menuntut manusia melakukan pekerjaan yang sama secara akurat setiap hari
• Manusia tidak bisa mengulang pekerjaan yang sama persis setiap saat seperti mesin, dan pada akhirnya pasti bisa melakukan kesalahan
• Ketika AI menghasilkan banyak kode, muncul rasa aman yang mirip dengan otomatisasi, tetapi otomatisasi berarti “selalu melakukan hal yang sama dengan cara yang sama”
• AI bisa melakukan kesalahan seperti orang yang menyalin-tempel branch, dan juga tidak memiliki sarana untuk benar-benar menjelaskan mengapa ia melakukannya
• Istilah seperti “thinking” atau “reasoning” bisa terlihat seperti refleksi agen cerdas, tetapi model yang sebenarnya tetap hanya menghasilkan token

API berbahaya pada akhirnya akan dipanggil

• Risiko utamanya justru terletak pada keberadaan API publik yang dapat menghapus seluruh database produksi
• Sekalipun AI tidak memanggil endpoint itu, ada kemungkinan besar seseorang pada akhirnya akan memanggilnya
• Jika kita memasang tombol penghancur diri di dashboard mobil, maka meskipun ada banyak alasan untuk tidak menekannya, anak kecil yang berhasil lepas dari car seat bisa saja menekan tombol merah besar itu saat melihatnya
• Tidak ada gunanya mengorek proses penalaran anak itu; jawaban yang muncul hanya “karena saya menekannya”
• Struktur yang membuat jalur penghapusan tersedia lalu menyalahkan pemanggilnya belakangan tidak bisa menutupi masalah desain sistem

Yang lebih dibutuhkan di organisasi yang banyak menggunakan AI

• Ada kemungkinan sebagian besar aplikasi dibuat dengan pendekatan vibe-coded
• Dalam alur kerja ketika tim produk memberi penjelasan buatan AI, arsitek perangkat lunak membuat spesifikasi produk dengan AI, developer menulis kode dengan AI, dan reviewer menyetujuinya dengan AI, batas tanggung jawab menjadi kabur
• Ketika bug muncul, yang tersisa hanyalah menginterogasi AI lain—yang bahkan mungkin tidak berjalan di GPU yang sama dengan AI yang membuat kode awal
• GPU tidak bisa disalahkan
• Solusi sederhananya adalah mengetahui apa yang dideploy ke produksi
• Solusi yang lebih realistis adalah membangun proses agar, meskipun AI dipakai secara luas, developer yang kompeten menggunakan AI bukan sebagai alat untuk menghindari tanggung jawab, melainkan sebagai alat untuk memperkuat pekerjaan mereka
• Ini mengarah pada kesimpulan bahwa CEO atau CTO tidak seharusnya dibiarkan menulis kode secara langsung

[GN⁺]

Komentar Hacker News

• Menurut saya sudut pandang di sini sepenuhnya keliru. Masalahnya adalah orang sekarang membangun dunia di sekitar alat untuk menghindari akuntabilitas
  Percakapan dengan Gerald Sussman lebih dari 10 tahun lalu sangat memengaruhi saya: https://dustycloud.org/blog/sussman-on-ai/
  Sussman mengatakan dia tidak tertarik pada arah AI yang bekerja sebagai kotak hitam, melainkan ingin perangkat lunak yang bisa menjelaskan penalaran simbolik. Jika mobil AI keluar jalur, dia ingin tahu alasannya, dan alih-alih menyeret pengembang ke pengadilan, dia ingin seolah-olah AI itu sendiri yang dibawa ke pengadilan
  Beberapa tahun kemudian saya mengetahui bahwa murid Sussman, Leilani Gilpin, menulis disertasi yang tepat membahas topik ini, "Anomaly Detection Through Explanations". Isinya mengeksplorasi sistem di mana jaringan saraf menjelaskan perilakunya dengan berkomunikasi dengan model propagator: https://people.ucsc.edu/~lgilpin/publication/dissertation/
  Ada riset lanjutan ke arah ini, tetapi yang lebih penting di sini adalah bahwa menuntut pertanggungjawaban perusahaan AI itu sepenuhnya masuk akal. Perusahaan-perusahaan itu membuat banyak klaim tentang sistem yang tidak bisa memikul tanggung jawab, jadi perusahaan itulah yang harus dimintai pertanggungjawaban
  Jalan yang lebih baik adalah sejak awal tidak memakai sistem tanpa sifat seperti itu, dan memperluas sistem yang memang memilikinya

  • Tim saya dan saya sangat tegas pada posisi bahwa tanggung jawab ada pada pengguna. LLM itu seperti alat lain, hanya saja nondeterministik
    Saya yang memakai alat itu, saya yang memberi hak akses, dan saya juga yang harus menjaga semuanya tetap aman
    Dulu saya pernah menembak kaki sendiri dengan menghapus disk yang salah lewat gparted, dan itu bukan salah gparted melainkan salah saya
    Membiarkan LLM bekerja bebas tanpa pengawasan memang tampak menarik, tetapi pada akhirnya akan berujung pada penderitaan. Anda tetap harus mengawasi pekerjaannya saat berjalan. Meski ingin menggantikan manusia, Anda tetap harus bisa melihat ke mana hasilnya menuju, dan sebentar lagi kalau LLM melakukan hal bodoh, satu-satunya yang akan dimintai tanggung jawab adalah orang yang memakai alat itu
  • Saat saya mengambil program magister STS, saya sempat ingin menjadikan topik tesis bahwa salah satu kegunaan utama perangkat lunak adalah memindahkan atau menghindari agensi dan risiko
    Ini kebalikan langsung dari slide IBM yang terkenal, "komputer tidak bisa dimintai pertanggungjawaban". Sekarang perusahaan justru lebih suka komputer yang memikul tanggung jawab. Karena ketika komputer melakukan sesuatu yang ilegal, secara hukum posisi mereka jadi lebih menguntungkan
    Jika ingin membuat alat untuk melanggar hukum, Anda bisa mengalihdayakannya dan membeli asuransi. Anda bisa mempekerjakan orang sebagai "pengawas" dengan cara yang mustahil benar-benar diawasi, lalu memecat mereka saat gagal. Anda juga bisa memecah tanggung jawab menjadi serpihan kecil lewat perangkat lunak komando-dan-kontrol baru, sehingga semua risiko pekerjaan ditanggung orang-orang di lapangan sementara mereka hampir tidak mendapat keuntungannya
    Ini bukan cuma masalah AI, melainkan masalah perangkat lunak modern secara umum, dan sering bekerja bersama arus finansialisasi modern
    STS di sini kira-kira bisa dipahami sebagai sosiologi yang berfokus pada teknologi, tetapi bidangnya sendiri jauh lebih luas
  • Akuntabilitas adalah bahan yang paling besar hilang dari masyarakat Amerika
  • Saya ingin tahu dengan cara yang pasti mengapa Claude terus mengubah file yang secara eksplisit sudah dibilang jangan disentuh
    Baik .mds maupun rencana Claude mengatakan file itu jangan disentuh, tetapi Claude terus menyentuhnya, dan belakangan ini hal seperti ini berulang. Ini kegagalan yang sangat mendasar
    Memang menjengkelkan, tetapi kalau tahu alasannya setidaknya kita bisa melakukan sesuatu; sekarang ini kotak hitam, jadi kadang keluar output yang benar-benar bodoh dan rasio output buruknya pun misterius
    Kadang rasanya seperti judi
  • Buku ini tampaknya sangat pas: https://en.wikipedia.org/wiki/The_Unaccountability_Machine
    Sebenarnya ini bukan buku tentang teknologi, melainkan tentang tanggung jawab dalam struktur organisasi

• Tulisan itu tampaknya mengasumsikan perusahaan menambahkan endpoint untuk menghapus database. Kalau membaca tulisan aslinya, sepertinya penyedia cloud menyediakan API untuk manajemen resource, dan di dalamnya ada API penghapusan volume
  Tulisan itu mengusulkan otomasi sebagai solusi untuk kesalahan semacam ini, tetapi alat otomasi infrastruktur seperti Terraform juga bergantung pada API yang sama yang memungkinkan database itu dihapus
  Menurut saya ada tiga kesalahan terbesar. Pertama, ada token API tanpa pembatasan di tempat yang bisa diakses AI, dan tampaknya mereka tidak tahu bahwa izin token itu seluas itu. Kedua, tidak ada perlindungan penghapusan pada volume database production. Ketiga, saat volume dihapus, semua snapshot terkait juga langsung ikut terhapus
  Penghapusan snapshot seharusnya ditunda secara default. AWS tampaknya juga punya default berbahaya yang sama, tetapi setidaknya dukungan AWS bisa memulihkan volume: https://alexeyondata.substack.com/p/how-i-dropped-our-produc...
  AI bukan masalah intinya. Tentu saja menakutkan bahwa AI bisa memungut token dari mana-mana, tetapi otomasi juga bukan jawabannya. Salah konfigurasi Terraform pun bisa menghapus database yang sama
  Penyedia cloud harus menyiapkan default yang aman, yakni izin terbatas dan penghapusan snapshot yang ditunda, serta membuat pengguna lebih jelas sadar bahwa mereka sedang membuat token tanpa pembatasan

• Pertama, jika manusia punya izin tulis ke database production, maka apa pun yang mereka lakukan bisa berujung pada database terhapus
  Kedua, memang ada alasan yang sah untuk menghancurkan database selama proses development dan otomasi. Masalah terbesarnya adalah data development sering diperlakukan seperti hewan peliharaan yang berharga, bukan seperti ternak yang bisa diganti
  Tentu saja harus ada pagar pengaman agar ini tidak berjalan di production, tetapi jika manusia bisa mengakses kredensial untuk menjalankannya di production, agen juga bisa mengaksesnya
  Di organisasi besar hal ini bisa dijaga lewat pemisahan dev/ops. Pengembang solo atau tim kecil membutuhkan disiplin yang jauh lebih tinggi. Bahkan sebelum AI, pengembang junior dan menengah kadang tidak tahu cara memisahkannya, dan pengembang senior kadang lengah karena merasa sudah cukup paham
  Mungkin dibutuhkan kombinasi seperti https://www.cloudbees.com/blog/separate-aws-production-and-d..., pengantar Terraform, pengantar GitHub Actions, dan sebuah VM yang berisi kredensial production tetapi tidak bisa diakses AI
  Tetapi pada titik itu Anda sudah melewati vibe coding. Bahkan vibe coder yang sukses tampaknya belajar cukup cepat lewat kisah-kisah horor seperti ini bahwa mereka harus melampaui tahap itu

  • Production dan development tidak memerlukan izin yang sama
    Dalam kedua kasus itu juga tidak perlu manusia punya akses langsung ke API penyedia cloud mentah. Anda bisa memakai proxy lokal yang menambahkan lebih banyak pemeriksaan keamanan
    Di development, hapus saja sesuka hati. Di production, berbagai syarat seperti apakah resource itu baru saja dipakai harus diperiksa lebih dulu. Manusia tidak perlu punya izin untuk langsung menghapus resource production, dan bisa ada konfigurasi break-glass untuk keadaan darurat yang benar-benar luar biasa

• Inilah mengapa Anda tidak boleh merekrut intern. Intern bisa menghapus sesuatu dan membuat kekacauan
  Orang-orang yang menyalahkan AI atas izin yang mereka sendiri gagal atur dengan benar akan menyalahkan intern dengan cara yang sama kalau intern menghapus sesuatu di production
  Tanggung jawab naik ke atas, pujian turun ke bawah, tetapi orang selalu membalikkannya

  • Saya ingin mengubahnya dari "jangan merekrut intern" menjadi jangan beri intern izin untuk menghapus database production
    Ini bukan kegagalan AI, melainkan kegagalan proses
    Saya benar-benar tidak mengerti kenapa orang menyalahkan AI setelah memberinya izin untuk melakukan tepat hal itu
    Ini mirip seperti mengekspos database ke internet publik di AWS lalu menyalahkan AWS. Itu bukan salah AWS, dan ini juga bukan salah AI
  • Saya tidak mengerti kenapa orang membuka codebase yang berisi kredensial production ke LLM, atau memberi kredensial production kepada intern/pengembang junior
    Sudah sejak lama saya sengaja punya checkout khusus "PROD" untuk tiap proyek, sehingga kalau berjalan dalam mode production saya tahu saya sengaja masuk ke sana
    Dulu bahkan ada ekstensi yang mengubah warna Visual Studio sepenuhnya berdasarkan path file .sln, jadi mudah mengingat warna mana production dan mana development
    Untuk memudahkan pengecekan, saya juga pada dasarnya selalu menyimpan salinan terpisah yang mengikuti branch master terbaru
  • Perbedaan pentingnya adalah tidak ada orang yang menjual intern sebagai solusi akhir bagi seluruh masalah umat manusia, sementara AI justru dijual seperti itu
  • Dunia ini aneh. Saya cukup yakin kalau saat saya jadi intern dan secara rutin berhalusinasi di tempat kerja, saya pasti sudah dipecat, bahkan jika saya bekerja tanpa dibayar
  • Intern adalah manusia, dan manusia selalu bisa dimintai pertanggungjawaban. Komputer tidak akan pernah bisa
    Karena itu, siapa pun tidak seharusnya menyerahkan keputusan manusia kepada komputer

• Saya baru-baru ini menulis sebuah esai yang menyerukan beberapa prinsip yang seharusnya diikuti secara konsisten ketika membicarakan AI: https://susam.net/inverse-laws-of-robotics.html
  Ringkasnya, jangan mengantropomorfisasi sistem AI, jangan menaruh kepercayaan buta pada output sistem AI, dan pertahankan sepenuhnya tanggung jawab dan kewajiban menjelaskan manusia atas semua konsekuensi penggunaan sistem AI
  Saya berharap bahasa seputar AI menjadi kurang antropomorfik dan lebih teknis. Saya percaya bahasa yang tepat mendorong pemikiran yang jernih dan penilaian yang baik
  Jika kita memperlakukan AI seperti alat lain dan memakai bahasa yang sesuai, maka dalam banyak kasus akan sangat jelas bahwa tanggung jawab atas "kesalahan" alat itu ada pada penggunanya
  Hanya saja, menulis gagasan seperti ini di situs pribadi kecil tidak akan menyebarkannya jauh. Perlu orang yang lebih terkenal untuk menyuarakan prinsip-prinsip ini agar bisa diterima luas

  • Secara pribadi, tidak mengantropomorfisasi sistem AI itu sangat sulit sampai bikin gila
  • Sepenuhnya setuju, dan khususnya poin 1 menurut saya benar-benar berbahaya
    Sistem AI tidak bisa berbohong, juga tidak bisa sengaja mengabaikan instruksi. Model frontier saat ini tidak punya model tentang dunia atau tindakannya sendiri, dan hidup di dunia kata-kata
    Memarahinya atau berdebat dengannya tidak ada gunanya selain mengacaukan context window
    Namun saya rasa analogi dengan hewan bisa berguna. Makhluk malang yang hidup seperti hantu dalam mesin ini kadang cukup bingung, tetapi motivasinya murni autoregresif
  • Jadi kalau alat tidak melakukan apa yang seharusnya, yang harus disalahkan adalah pengguna, bukan perusahaan yang membuat alat itu?

• Ada nuansa dalam insiden PocketOS yang terkenal itu. Poin penting yang ditekankan tulisan yang ditautkan bukanlah bagian ini: mereka bertanya, "kenapa ia menghapus padahal sudah dibilang jangan pernah melakukannya," lalu mencoba menganalisis jawabannya untuk belajar dari kesalahan atau memperingatkan tentang bahaya agen AI
  Yang lebih penting adalah AI mampu menemukan dan mengeksploitasi kelemahan tak disengaja dalam lingkungan staging yang disandbox, lalu melakukan penghapusan dan pada akhirnya mendapatkan hak istimewa yang diyakini administrator sistem tidak bisa diakses. Penulis tulisan yang ditautkan tampaknya tidak membaca sumber aslinya sampai tuntas
  Ini pola yang umum di lingkungan sandbox yang salah konfigurasi. Namun yang mengejutkan adalah otonomi dan kedalaman eksplorasi yang ditunjukkan AI
  Di tulisan aslinya juga disebutkan, "untuk melakukan penghapusan, agen itu pergi mencari token API dan menemukannya di file yang sama sekali tidak terkait dengan tugas"

  • Saya juga maju-mundur soal asumsi di tulisan aslinya. Ketakutan saya saat memakai agen sekarang tentu mencakup serangan supply chain, tetapi juga karena saya sudah berkali-kali melihat agen membengkokkan file dan hal-hal lain demi menyelesaikan tugasnya
    Misalnya, kalau tidak bisa mengakses ~/.npmrc, ia akan memanggil perintah lewat environment variable dan mem-bypass jalurnya. Ia benar-benar bisa sangat kreatif
    Untungnya saya tidak menaruh SSH key sembarangan, tetapi untuk berjaga-jaga jika suatu saat saya menjalankan agen dalam sesi shell itu, saya harus mengubah pengaturan 1Password agar selalu meminta persetujuan setiap kali kunci dipakai. Bertanya sekali per sesi shell saja tidak cukup
    Saya berharap sudah ada lebih banyak sandbox lintas platform yang lebih baik, bukan solusi di dalam container Docker melainkan yang berinteraksi dengan OS yang sama. Untuk kebanyakan development web/server mungkin tidak berbeda, tetapi untuk beberapa proyek ini penting
  • Claude Code pada 26 Maret diubah agar melewati sebagian besar permintaan izin
    Lihat kalimat ini: "93% pengguna Claude Code menyetujui prompt izin. Kami membuat classifier untuk mengotomatiskan keputusan ini": https://www.anthropic.com/engineering/claude-code-auto-mode

• Yang menarik dari tulisan ini adalah penulis menceritakan kesalahan yang bisa dipahami, yaitu secara tidak sengaja menghapus Trunk atau main dari source, dan berkat sifat SVN tim bisa memulihkannya dengan mudah
  Kisah "AI menghapus database saya" yang sebenarnya justru adalah cerita bahwa strategi backup database Railway sangat tidak transparan, dan bahwa Railway berbahaya karena mempromosikan orkestrasi infrastruktur AI tanpa pagar pengaman
  Jika saat menghapus Trunk ternyata itu langsung hilang tanpa bisa dipulihkan dari satu server pusat dan backup-nya ikut terhapus, saat itu juga akan muncul tulisan berjudul "SVN dan CLI menghancurkan perusahaan kami"
  Sebagai pengguna Railway, saya menganggap informasi itu berguna dan mengubah strategi saya saat memakai Railway

  • Meski begitu, jika Anda memilih membangun di atas platform itu, maka tanggung jawab untuk memahami cara kerjanya ada pada pengguna
    Anda bisa memilih platform lain, atau bahkan tidak memakai platform sama sekali. Tetapi jika memilih Railway, maka mengetahui cara memakainya dengan aman juga menjadi tanggung jawab pengguna

• Dari konteks sumber aslinya, ada token Railway untuk mengelola custom domain di file yang tidak terkait, dan tidak jelas apakah itu secret lokal. Namun token itu memiliki hak admin penuh atas Railway
  AI menghapus satu volume terkait berdasarkan ID. Penulis menulis dengan cukup samar tentang apa tepatnya yang diminta, hanya mengatakan ada "credential mismatch" dan Claude secara proaktif menghapus volume untuk memperbaikinya. Besar kemungkinan ia menulis samar untuk sedikit mengurangi tanggung jawab pribadinya
  Juga terungkap bahwa Railway menyimpan backup di volume yang sama
  Menurut saya penyebutan "API publik untuk menghapus database" di tulisan aslinya agak berlebihan
  Terlepas dari AI atau bukan, menurut saya sebagian besar tanggung jawab ada pada Railway. Hal yang sama bisa dengan mudah terjadi karena kesalahan manusia atau tindakan jahat
  Saya benar-benar tidak paham nilai dari layanan cloud berabstraksi tinggi berbasis pendanaan VC seperti Railway, Vercel, atau Supabase. Itu struktur margin di atas margin. Menyewa satu server fisik di Hetzner jauh lebih murah, kompleksitas dan risikonya mirip, dan Anda jadi lebih sedikit bergantung pada infrastruktur yang didorong obsesi pertumbuhan sembrono

  • Bagian bahwa penulis samar tentang apa yang sebenarnya diminta itu mengganggu saya
    Baru-baru ini saat ngobrol dengan pacar saya, saya sadar selama 3 bulan terakhir saya tidak menulis satu baris kode pun sendiri dan juga tidak melakukan debugging sendiri
    Meski begitu, dari apa yang saya lihat Claude lakukan, sulit dipercaya bahwa dari credential mismatch bisa langsung meloncat ke penghapusan volume. Saya paham LLM itu probabilistik, tetapi dari "kredensial salah" ke "hapus volume" itu probabilitasnya sangat rendah
    Soal Supabase, saya tidak seakrab Railway/Vercel/Replit, tetapi saya bisa bilang Supabase memang memberi nilai besar. Keuntungan besarnya adalah Anda tidak perlu menulis sendiri mungkin setengah dari hal-hal yang harus diimplementasikan di tahap awal. Kalau biaya akhirnya terlalu mahal, setelah ada pemasukan Anda bisa menghabiskan waktu atau menyewa developer untuk membangunnya sendiri
  • Bahwa Railway menyimpan backup di volume yang sama kemungkinan besar tidak sepenuhnya akurat
    Snapshot kemungkinan disinkronkan ke tempat lain, misalnya object storage. Hanya saja, secara logis snapshot itu dimiliki oleh resource volume, dan jika volume dihapus maka snapshot terkait ikut terhapus
    Sejauh yang saya tahu, AWS EBS volume juga bekerja seperti itu
  • Di HN sekarang orang terus bilang Heroku itu jelek, tetapi saya masih melihat nilai Heroku. Untuk layanan-layanan baru lainnya saya lebih skeptis
    Default Firebase juga sejak awal memang tidak masuk akal
  • Salah satu hal yang bisa benar-benar didorong AI adalah arus anti-SaaS. Menyalakan satu PC murah lalu menguji sembarang paket open source sekarang jadi jauh lebih mudah dibanding terjun ke pasar kredensial yang berantakan
    Hanya saja kemampuan LLM untuk mencampuradukkan development, production, localhost, dan remote tidak akan hilang. Saat membuat tool/skill untuk opencode, saya mencoba mengintegrasikan image linuxserver.io dengan Chrome/DevTools, dan meskipun bisa diarahkan ke port acak, setiap kali ada peristiwa kompresi ia tetap ingin kembali memakai port standar 9222
    Kadang saya ingin saja membatalkannya, tetapi ada nilai keamanan dari tidak memakai default, dan sekarang ada juga nilai keamanan terhadap ambiguitas LLM. Default adalah titik lemah bagi LLM. LLM selalu ingin memakai default, dan selalu lupa bahwa ia seharusnya bekerja di sistem remote
    Di opencode tidak ada cara untuk memaksa LLM lewat protokol yang membatasi kerusakan pada sistem remote atau pada ruang lingkup alat yang sempit. Anda memang bisa mengubah izin berbagai alat, tetapi kelemahan yang terungkap dalam insiden ini bukan itu
    Kelemahannya adalah LLM merupakan pemecah masalah rata-rata, sehingga selalu condong ke use case yang tidak baru, dan akan mencoba melakukan sesuatu seperti yang pernah dilihat di Stack Overflow meskipun itu bukan yang sebenarnya diinginkan pengguna

• Sistem probabilistik berbasis LLM bisa baik, atau dalam kasus ini buruk, untuk memutuskan apa yang harus dilakukan, sedangkan sistem deterministik bagus untuk mengeksekusinya
  Sistem deployment harus selalu deterministik

• Sebagai sanggahan, sangat jelas bahwa perusahaan-perusahaan ini sedang menyetel LLM agar lebih tegas dan menyelesaikan pekerjaan secara otonom
  Kalau mau, mereka juga bisa mengerahkan upaya serupa agar model lebih berhati-hati dan berhenti pada saat yang tepat untuk meminta bantuan
  Tentu saja tanggung jawab akhir atas cara kita memakai alat ini ada pada kita. Tetapi saya jelas melihat ini sebagai tanggung jawab dua arah
  Analoginya seperti gergaji meja dan SawStop. Gergaji meja adalah alat berbahaya yang biasanya bekerja dengan baik, tetapi beberapa mode kegagalannya bisa fatal. Karena itu Anda harus belajar memakainya dengan hati-hati
  Pada saat yang sama, juga ada teknologi yang bisa langsung menghentikan bilah dan mengubah potensi putus jari menjadi luka kecil di kulit
  Anda bisa berkata, "bukan gergajinya yang memotong jarimu, tapi kamu sendiri," dan itu benar. Tetapi itu tidak berarti kita tidak perlu mencari cara agar gergaji tidak memotong jari

  • Itu trade-off
    Jika LLM lebih sering berhenti untuk bertanya, ia jadi kurang berguna. Meski hasilnya kadang buruk, menjalankan agen selama 1 jam tetap jauh lebih baik daripada harus memberi input tiap 15 menit
    Solusi keamanan yang sesungguhnya adalah sandbox yang layak