CEO Proton Sebut Minta Waktu Pentest Itu Loser Thinking: Analisis Risiko

Investigasi 404 Media yang terbit akhir Oktober 2026 mencatat CEO Proton, Andy Yen, menyebut permintaan seorang engineer untuk beberapa hari pengujian keamanan sebelum rilis sebagai "bullshit and loser thinking". Percakapan itu terjadi di kanal Slack tim keamanan, dan menurut blog raed.dev yang merangkum laporan tersebut pada 1 November 2026, karyawan juga diberi tahu bahwa tingkat pemakaian AI bisa menentukan apakah mereka tetap bekerja. Insiden ini bukan soal AI menulis kode, tapi soal siapa yang menanggung risiko kalau kode itu gagal.

TL;DR

• Seorang engineer meminta waktu beberapa hari untuk pentest sebelum rilis, dan permintaan itu disebut "loser thinking" oleh CEO.
• Karyawan disebut menerima pesan bahwa pemakaian AI bisa memengaruhi status pekerjaan mereka.
• Rencana itu dilaporkan ditarik setelah bocor, dan CEO menyatakan rencananya sudah mencapai tujuannya.
• Untuk perusahaan yang menjual privasi, kehati-hatian adalah produknya, bukan hambatan yang bisa ditukar dengan kecepatan.

Apa sebenarnya yang terjadi?

Menurut laporan 404 Media yang dikutip blog tersebut, CEO Proton menanggapi permintaan pentest dengan menyebutnya "bullshit and loser thinking", lalu meminta tim berhenti "lovingly handcrafting code" dan lebih banyak memakai AI. Kanal tempat percakapan itu terjadi adalah kanal Slack tim keamanan, jadi audiensinya bukan orang luar yang salah paham konteks.

Detail kedua lebih berat. Karyawan disebut diberi tahu bahwa tingkat pemakaian AI bisa memengaruhi apakah mereka mempertahankan pekerjaan. Ketika rencana itu bocor dan akhirnya dibatalkan, Yen dilaporkan menyatakan bahwa rencana tersebut "sudah mencapai tujuannya". Kalimat itu, kalau akurat, mengubah insiden ini dari kebijakan internal menjadi pernyataan tentang cara perusahaan memperlakukan tekanan publik.

Konteks pembandingnya penting: Proton menjual privasi. Produk intinya adalah email terenkripsi, VPN, dan penyimpanan awan, semuanya bersaing dengan layanan gratis yang jauh lebih besar. Argumen jualannya bukan fitur terbanyak, tapi klaim bahwa perusahaan ini lebih hati-hati dengan data penggunanya.

Kenapa "hanya soal AI" adalah kesimpulan yang salah?

Karena masalahnya bukan model yang menulis kode, melainkan respons terhadap seseorang yang mengangkat risiko. Banyak perusahaan merilis kode hasil agen tanpa mempermalukan engineer di kanal internal, dan itu terjadi setiap hari di seluruh industri.

Yang membedakan adalah apa yang terjadi ketika ada yang bertanya. Dalam organisasi yang sehat, pertanyaan "boleh saya uji dulu beberapa hari" adalah sinyal bahwa prosesnya bekerja. Dalam organisasi yang menganggapnya loser thinking, pertanyaan itu berubah menjadi risiko karier, dan setelah itu tidak ada lagi yang bertanya.

Efek jangka panjangnya lebih mahal daripada beberapa hari penundaan. Kalau satu-satunya orang yang berani menyuarakan risiko sudah diberi contoh, sisa tim belajar untuk diam. Biaya itu tidak muncul di laporan sprint, tapi muncul sebagai bug yang lolos ke produksi enam bulan kemudian.

Aspek	Perusahaan biasa	Perusahaan yang menjual privasi
Trade-off kecepatan versus pengujian	Wajar ditukar, dampaknya terbatas	Sulit ditukar, karena itulah produknya
Dampak satu bug pada data pengguna	Gangguan layanan, kompensasi, reputasi	Kebocoran isi email, dampaknya permanen
Alasan pelanggan membayar	Fitur dan kenyamanan	Keyakinan bahwa timnya berhati-hati
Biaya menunda rilis	Kehilangan momentum	Jauh lebih murah daripada satu insiden

Bagaimana pembelaan dari dalam perusahaan?

Menurut blog tersebut, seorang karyawan yang membela perusahaan di Reddit menambahkan konteks bahwa Yen tidak menolak pentest, asalkan tidak memperlambat pipeline. Konteks itu dimaksudkan meringankan, tapi justru menegaskan inti masalahnya: pengujian diizinkan selama tidak menunda apa pun.

Penulis blog menilai pembelaan itu sebagai upaya manajemen krisis yang canggung, bukan dissent yang jujur. Penilaian itu opini, bukan fakta yang bisa diverifikasi, dan perlu diperlakukan begitu. Yang bisa diverifikasi hanya kutipan dan urutan peristiwanya, bukan motif orang yang menulis di Reddit.

Apa yang bisa dipelajari tim engineering di Indonesia?

Yang bisa diambil bukan soal Proton secara spesifik, tapi pola respons terhadap risiko. Ada empat tanda yang layak diperiksa di organisasi sendiri, dan semuanya bisa dinilai tanpa perlu menunggu insiden.

• Ketika seseorang meminta waktu pengujian tambahan, apakah jawabannya berupa pertanyaan teknis atau penilaian tentang orangnya?
• Apakah ada jalur bagi engineer untuk menolak rilis tanpa harus berdebat di kanal publik?
• Apakah metrik kecepatan dirilis bersamaan dengan metrik kualitas, atau hanya yang pertama?
• Kalau sebuah kebijakan ditarik setelah bocor, apakah ada penjelasan resmi tentang apa yang berubah?

Untuk tim yang sedang memperkenalkan agen kode, ada satu aturan tambahan yang murah dipasang: pemakaian AI tidak boleh mengubah kewajiban review. Kode yang dihasilkan model tetap harus lewat review manusia, dan yang menandatangani tetap bertanggung jawab. Tanpa itu, kecepatan yang didapat di hulu akan dibayar di hilir dengan bunga.

Apakah ini akan memengaruhi keputusan pembelian?

Untuk segmen bisnis, kemungkinan besar ya, meski efeknya tidak langsung. Pembeli B2B tidak mengevaluasi budaya internal vendor secara langsung, tapi mereka mengevaluasi jawaban vendor saat ditanya soal proses rilis. Kalau jawabannya berubah dari "kami menguji sebelum rilis" menjadi "kami menguji kalau tidak memperlambat", itu masuk ke penilaian risiko pengadaan.

Untuk pengguna individu, keputusannya lebih emosional dan lebih lambat. Blog tersebut mengaku bertahun-tahun membayar dan merekomendasikan Proton, dan sekarang mulai ragu. Itu contoh bagaimana modal kepercayaan bekerja: dibangun bertahun-tahun, dipakai dalam satu kalimat di kanal Slack.

Belum ada data publik tentang dampak insiden ini terhadap jumlah pelanggan Proton, jadi klaim bahwa mereka kehilangan pengguna belum bisa dibuktikan. Yang bisa dicatat adalah tanggal dan isi laporan, lalu dibandingkan dengan pengumuman resmi perusahaan bila ada.

Bagaimana seharusnya perusahaan AI-native mengukur kecepatan?

Dengan memasangkan kecepatan pengiriman ke biaya kegagalan, bukan mengukur keduanya terpisah. Rilis cepat yang lolos pengujian adalah kecepatan, sedangkan rilis cepat yang memaksa perbaikan darurat adalah utang yang dibayar belakangan.

Ada tiga angka yang cukup untuk mulai, dan semuanya bisa diambil dari data yang biasanya sudah ada:

• Waktu dari kode selesai sampai kode direview, bukan waktu dari tiket dibuka sampai kode ditulis.
• Jumlah perubahan yang harus di-revert dalam 30 hari terakhir, dipisah antara kode hasil agen dan kode manual.
• Jumlah temuan keamanan yang muncul setelah rilis, bukan setelah review.

Kalau ketiganya tidak pernah diukur, maka klaim "lebih cepat dengan AI" tidak punya pembanding. Itu bukan penilaian, itu kesan, dan kesan tidak bisa dipakai untuk memutuskan apakah sebuah proses pengujian layak dipertahankan.

Bagaimana pola ini muncul di tim kecil?

Di tim kecil, versinya lebih halus dan jarang berupa kutipan yang bisa dikutip media. Bentuknya biasanya komentar singkat saat review, misalnya "ini kebanyakan tes" atau "kita butuh ini minggu ini". Tidak ada yang melarang pengujian, tapi anggarannya yang tidak pernah disediakan.

Efeknya tetap sama. Orang yang paling peduli pada kualitas adalah orang yang paling sering harus berdebat, dan pada titik tertentu ia berhenti berdebat. Setelah itu, tim terlihat cepat dan tidak ada yang mengeluh, sampai ada satu rilis yang tidak bisa ditarik kembali.

Untuk tim seperti ini, solusi paling murah bukan kebijakan baru, tapi satu aturan yang bisa diuji: setiap rilis yang menyentuh autentikasi, pembayaran, atau data pribadi wajib punya jeda pengujian minimum. Aturan seperti itu tidak butuh rapat, cukup ditulis di dokumen proses dan dipakai saat memutuskan tanggal rilis.

Apa yang bisa dilakukan pembeli atau pengguna?

Untuk pengguna individu, langkah yang realistis adalah memisahkan klaim pemasaran dari proses internal. Situs resmi merangkum janji privasi, sedangkan liputan media independen biasanya memberi gambaran soal tekanan internal dan keputusan yang diambil saat ada konflik.

Untuk pembeli B2B, satu pertanyaan saat pengadaan sudah cukup menyaring: apa yang terjadi kalau engineer meminta waktu pengujian tambahan? Vendor yang punya proses akan menjawab dengan prosedur. Vendor yang tidak punya akan menjawab dengan jaminan bahwa hal itu tidak akan perlu terjadi.

Dan untuk siapa pun yang sedang membangun produk yang menjual kepercayaan, insiden ini pengingat yang murah: kecepatan adalah fitur, tapi kehati-hatian adalah produknya. Menukar yang kedua untuk yang pertama bekerja sampai ada satu bug yang tidak bisa ditarik kembali.

Yang membuat kasus ini layak dibahas bukan karena Proton, tapi karena polanya bisa dikenali dari luar. Setiap perusahaan yang baru saja memasang agen kode akan melewati momen yang sama: seseorang bertanya apakah ada waktu untuk menguji, dan jawaban pertama atas pertanyaan itu menentukan budaya selama dua tahun ke depan.

Kalau jawabannya berupa tenggat, tim akan belajar bahwa pertanyaan itu tidak diinginkan. Kalau jawabannya berupa prosedur, tim belajar bahwa pengujian adalah bagian dari pekerjaan, bukan permintaan khusus yang harus dinegosiasikan setiap kali.

Ada satu detail yang jarang dikomentari: permintaan itu hanya beberapa hari pengujian. Bukan audit penuh, bukan penundaan satu kuartal. Kalau beberapa hari sudah dianggap loser thinking, maka yang sebenarnya diperdebatkan bukan jadwal rilis, melainkan siapa yang berhak menghentikan sebuah keputusan ketika risiko terlihat.

FAQ

Siapa yang melaporkan insiden ini pertama kali?

404 Media, lewat investigasi yang terbit akhir Oktober 2026. Kutipan dan urutan peristiwanya dirangkum dalam blog raed.dev pada 1 November 2026, dan artikel ini mengacu pada rangkuman tersebut.

Apa kutipan lengkap dari CEO Proton?

Menurut laporan yang dikutip, jawabannya adalah "bullshit and loser thinking" atas permintaan beberapa hari pengujian keamanan, disertai arahan agar tim berhenti "lovingly handcrafting code" dan lebih banyak memakai AI.

Apakah Proton membantah laporan tersebut?

Tidak ada bantahan yang disebut dalam rangkuman yang dipakai artikel ini. Yang tercatat justru pernyataan bahwa rencana yang bocor sudah mencapai tujuannya.

Apakah memakai AI untuk menulis kode memang berbahaya?

Tidak otomatis. Yang berbahaya adalah memakai AI tanpa review, tanpa pengujian, dan tanpa orang yang bertanggung jawab atas hasilnya. Kombinasi tiga hal itu yang membuat kecepatan berubah menjadi risiko.

Apa satu langkah paling murah untuk mencegah pola ini?

Buat permintaan pengujian tambahan menjadi jalur normal, bukan negosiasi. Kalau engineer punya hak menahan rilis tanpa perlu membujuk siapa pun, insiden seperti ini tidak perlu terjadi di kanal Slack.