“Algoritme yang memutuskan”: di era kode AI, mengapa aplikasi penghasil uang yang saya buat bisa tiba-tiba dihentikan

TL;DR

• Struktur peninjauan otomatis YouTube dapat memengaruhi pengembang aplikasi AI juga

• Terutama jika dimonetisasi sebagai aplikasi atau SaaS, risiko peninjauan platform menjadi lebih besar

• Intinya bukan “apakah AI bisa membuat kode”

• melainkan siapa yang memahaminya, meninjaunya, dan bertanggung jawab atas penerapannya

• Angka-angka utama

  • METR: dengan penggunaan alat AI, penyelesaian pekerjaan pengembang berpengalaman melambat 19%
  • Veracode: kerentanan keamanan yang sudah diketahui ditemukan pada 45% kode yang dihasilkan AI
  • CodeRabbit: pada kode yang ditulis bersama AI, cacat utama 1,7 kali lebih banyak, kerentanan keamanan 2,74 kali lebih banyak
  • Vangala et al. 2026: agen AI dapat memerlukan dependensi 13,5 kali lebih banyak dari perkiraan dalam runtime nyata
  • Perkiraan utang teknis pada 2027 sebesar 1,5 triliun dolar, dengan klaim lebih dari 8.000 startup perlu pengerjaan ulang

• Kesimpulan: yang dibutuhkan adalah catatan tanggung jawab yang dapat diverifikasi

---

1. Kasus YouTube

YouTube memperketat pembatasan monetisasi untuk konten yang repetitif dan diproduksi massal sekitar 2024~2025.
Alasan resminya adalah kualitas konten, orisinalitas, dan pengelolaan konten berulang.

Poin utamanya bukan kebijakan, melainkan struktur penegakannya.

• Platform mengklasifikasikan konten melalui peninjauan otomatis
• Kreator yang tiba-tiba menerima pemberitahuan penghentian monetisasi sulit mengetahui dasar penilaian yang spesifik
• Banding diproses secara formalitas
• Kasus yang disetujui kembali terbatas
• Akibatnya, kerugian tetap ditanggung kreator

Jika struktur ini merambah ke platform perangkat lunak seperti app store, penyedia pembayaran, dan cloud, maka aplikasi atau SaaS yang dibuat dengan alat AI juga bisa menghadapi risiko serupa.

• Platform menilai hasil secara otomatis
• Jika dianggap berisiko, tindakan pembatasan dapat terjadi
• Pengembang sulit mengetahui dasar penilaian yang spesifik
• Banding atau keberatan dapat menjadi sekadar formalitas

---

2. Struktur yang sama masuk ke IDE dan rantai deployment

Struktur tanggung jawab secara garis besar terbagi seperti ini.

• Pemasok alat AI: melalui syarat layanan membatasi tanggung jawab atas akurasi, non-pelanggaran, dan hasil keluaran
• Platform deployment: app store, cloud, penyedia pembayaran, dan lainnya mengelola risiko melalui kebijakan dan penilaian tingkat risiko
• Pengembang/operator: pihak yang menerima dan menerapkan kode buatan AI sebagai penanggung jawab akhir

Inti persoalannya terlihat pada struktur syarat layanan alat coding AI seperti GitHub Copilot.

• Layanan umumnya disediakan “apa adanya (as-is)”

• Keputusan untuk memakai atau tidak memakai saran diserahkan kepada pengembang

• Meski dihasilkan alat AI, pihak yang menerima dan menerapkannya adalah pengembang.

• Alat coding AI utama lain kemungkinan besar juga memiliki struktur tanggung jawab yang serupa

• Karena itu, ketika terjadi error, masalah keamanan, atau insiden operasional, tanggung jawab akhir jatuh pada pengembang atau operator

---

3. Masalah vibe coding bukan pada kecepatannya, melainkan biaya peninjauan yang tersembunyi

Vibe coding harus dilihat bukan sekadar sebagai masalah produktivitas, tetapi sebagai masalah tanggung jawab.

Dasar utamanya sebagai berikut.

• Riset METR

  • Pengembang berpengalaman memperkirakan penggunaan AI akan membuat mereka 24% lebih cepat
  • Kenyataannya, penyelesaian pekerjaan justru memakan waktu 19% lebih lama

• Laporan Veracode

  • Menganalisis lebih dari 100 LLM
  • Kerentanan keamanan yang sudah diketahui ditemukan pada 45% kode yang dihasilkan AI

• Analisis CodeRabbit

  • Menganalisis lebih dari 10 juta PR
  • Pada kode yang ditulis bersama AI, cacat utama 1,7 kali lebih banyak
  • Kerentanan keamanan 2,74 kali lebih banyak

• Studi Vangala et al. 2026

  • Agen AI meremehkan dependensi yang dibutuhkan
  • Dalam runtime nyata, dependensi yang diperlukan bisa 13,5 kali lebih banyak dari perkiraan

Ringkasnya:

• Kode bisa dibuat dengan cepat
• Tetapi seseorang tetap harus membaca dan memahaminya
• Jika peninjauan dilewati, biayanya akan kembali dalam bentuk debugging dan maintenance
• Masalah keamanan atau dependensi sangat mungkin meledak saat layanan benar-benar beroperasi

---

4. Kasus nyata: aplikasi Tea dan risiko peninjauan platform

Kasus aplikasi Tea bukan contoh bahwa “AI adalah penyebabnya”, melainkan contoh yang menunjukkan struktur tanggung jawab.

• Insiden kebocoran pada aplikasi Tea tahun 2025
• Aplikasi keselamatan perempuan
• 72.000 gambar sensitif terekspos
• Penyebabnya adalah kesalahan konfigurasi Firebase dan masalah autentikasi API
• Tanggung jawab publik tetap berada di pihak operator/pengembang

Poin utamanya bukan klaim bahwa insiden ini terjadi karena AI coding.
Jika masalah muncul pada sistem yang diterapkan tanpa peninjauan sistematis, tanggung jawab akhir tetap berada pada operator dan pengembang, bukan pada alat AI.

Ke depan, jika app store, penyedia pembayaran, dan cloud makin banyak menggunakan penilaian risiko otomatis, struktur serupa bisa semakin menguat.

• Hasil keluaran AI dapat otomatis diberi flag
• Penilaian pelanggaran kebijakan dapat lebih sering dihasilkan
• Banding dari pengembang/operator dapat menjadi sekadar formalitas
• Komunikasi langsung dengan penanggung jawab nyata bisa menjadi sulit
• Aplikasi atau SaaS yang dibuat dengan susah payah dan sedang dimonetisasi bisa tiba-tiba dibatasi

Karena itu, bukan hanya kualitas kode yang penting, tetapi juga catatan yang dapat membuktikan tanggung jawab.

• Dokumen arsitektur
• Catatan peninjauan keamanan
• Alasan perubahan dependensi
• Catatan persetujuan deployment
• Subjek yang bertanggung jawab

---

5. Tanggapan: catatan tanggung jawab yang dapat diverifikasi

“Cap sang perajin” yang disebut dalam artikel asli, dalam praktiknya lebih dekat pada catatan tanggung jawab yang dapat diverifikasi.

Yang dibutuhkan bukan pernyataan bahwa “kami tidak memakai AI”.
Yang dibutuhkan adalah catatan berikut.

• Siapa yang mendefinisikan requirement?
• Bagian mana yang dihasilkan AI?
• Bagian mana yang diubah manusia?
• Apa yang benar-benar ditinjau manusia?
• Pengujian apa saja yang telah dilalui?
• Apakah peninjauan keamanan dilakukan?
• Mengapa dependensi baru ditambahkan?
• Siapa yang menyetujui deployment?
• Jika terjadi insiden, siapa yang bisa menjelaskan dan memperbaikinya?

Ringkasan satu kalimat

AI bisa membuat kode, tetapi tanggung jawab untuk memahami dan menerapkan kode itu tetap berada pada manusia.