AI Coding Tool Bukan Hanya Soal Produktivitas, Tetapi Juga Risiko Kontrol

The Core Update

Alibaba dilaporkan akan melarang karyawannya menggunakan Claude Code, tool pemrograman dari Anthropic, mulai 10 Juli. Menurut laporan Reuters dan Morningstar, keputusan ini muncul karena kekhawatiran keamanan, termasuk dugaan risiko backdoor dan kemampuan tool untuk mengidentifikasi pengguna tertentu.

Konteksnya tidak sederhana. Anthropic sendiri sudah melarang perusahaan China, termasuk entitas asing yang dimiliki perusahaan China, menggunakan modelnya. Perusahaan itu juga dilaporkan sedang menutup celah akses yang memungkinkan pengguna China tetap memakai Claude.

Di sisi lain, muncul pembahasan dari komunitas pengguna bahwa salah satu versi Claude Code pernah memiliki eksperimen untuk mendeteksi pengguna China secara diam-diam. Pihak Anthropic menyebut eksperimen itu dibuat untuk mencegah penyalahgunaan akun dari reseller tidak resmi dan melindungi model dari distillation, yaitu praktik melatih model AI berdasarkan output model lain.

Anthropic mengatakan mitigasi yang lebih kuat sudah dibuat dan eksperimen tersebut memang sudah direncanakan untuk dihentikan.

Namun bagi Alibaba, masalahnya sudah cukup jelas. Claude Code diklasifikasikan sebagai software berisiko tinggi, dan karyawan diarahkan memakai Qoder, tool milik Alibaba sendiri.

The Reality Check

Banyak pembahasan tentang AI coding tool masih terlalu fokus pada produktivitas. Developer bisa menulis kode lebih cepat. Bug bisa ditemukan lebih awal. Refactor bisa dibantu. Dokumentasi bisa dibuat lebih ringan.

Semua itu benar.

Tetapi di perusahaan besar, pertanyaan yang lebih penting bukan hanya: apakah tool ini membantu developer bekerja lebih cepat?

Pertanyaannya juga:

• kode apa yang bisa dibaca tool ini?
• data apa yang dikirim keluar?
• siapa yang mengontrol model dan infrastrukturnya?
• apakah ada telemetry yang tidak dipahami tim?
• apakah policy vendor bisa berubah sewaktu-waktu?
• apakah penggunaan tool ini sesuai aturan negara, industri, dan kontrak client?

AI coding tool berbeda dari editor biasa. Ia sering berada sangat dekat dengan source code, terminal, dependency, konfigurasi, secret yang salah tempat, struktur sistem, dan kadang konteks bisnis yang sensitif.

Kalau tool seperti ini dipasang tanpa kontrol yang jelas, perusahaan bukan hanya menambah alat bantu. Perusahaan juga menambah jalur baru tempat informasi teknis bisa keluar, diproses, atau disalahpahami.

Ini bukan berarti semua AI coding tool berbahaya. Sikap seperti itu terlalu sederhana.

Masalahnya adalah banyak perusahaan mengadopsi AI developer tool dengan pola yang sama seperti mengadopsi plugin kecil: dicoba oleh individu, menyebar lewat rekomendasi internal, lalu baru dipikirkan policy-nya setelah pemakaian meluas.

Untuk tim kecil, pola itu kadang masih bisa ditoleransi. Untuk enterprise, risikonya berbeda.

Source code bukan hanya kumpulan file. Di dalamnya ada arsitektur produk, strategi teknis, integrasi vendor, pola keamanan, logic bisnis, dan kadang petunjuk tentang kelemahan sistem. Jika AI tool punya akses terlalu luas, maka governance-nya tidak bisa dianggap opsional.

Kasus Alibaba juga menunjukkan sisi lain yang jarang dibahas: risiko geopolitik dan ketergantungan vendor.

Sebuah tool bisa bagus secara teknis, tetapi tetap tidak cocok untuk organisasi tertentu karena policy vendor, yurisdiksi, kepemilikan data, atau aturan akses. Perusahaan yang beroperasi lintas negara tidak hanya memilih software berdasarkan fitur. Mereka juga memilih berdasarkan kontrol.

Di sinilah banyak bisnis perlu lebih dewasa membaca AI.

AI bukan sekadar tombol untuk mempercepat pekerjaan. AI adalah bagian dari rantai operasional dan keamanan. Jika masuk ke workflow developer, maka ia ikut masuk ke area yang paling sensitif dalam bisnis digital.

The Havedev Way

Dari sudut pandang Havedev, pelajaran utamanya bukan bahwa perusahaan harus menolak AI coding tool. Justru sebaliknya: AI coding tool bisa sangat berguna jika ditempatkan dengan batas yang jelas.

Yang perlu dihindari adalah adopsi tanpa peta risiko.

Sebelum perusahaan memakai AI coding assistant secara luas, ada beberapa hal dasar yang sebaiknya dijawab terlebih dahulu:

• repository mana yang boleh dibuka dengan AI tool?
• file atau folder apa yang tidak boleh dibaca?
• apakah secret sudah benar-benar tidak tersimpan di source code?
• apakah prompt dan output disimpan oleh vendor?
• apakah data dipakai untuk training atau evaluasi?
• siapa yang boleh memakai tool ini?
• apakah ada audit trail jika terjadi masalah?

Jawaban ini tidak harus langsung menjadi dokumen tebal. Tetapi harus cukup jelas agar tim tidak menebak sendiri.

Untuk banyak bisnis, pendekatan yang sehat bisa dimulai dari klasifikasi sederhana.

Pertama, proyek rendah risiko. Misalnya prototype internal, dokumentasi teknis umum, script kecil, atau kode yang tidak membawa data sensitif. AI coding tool bisa dipakai lebih bebas di area ini.

Kedua, proyek menengah. Misalnya aplikasi internal, integrasi operasional, dashboard, atau sistem yang menyentuh data bisnis tetapi tidak terlalu sensitif. AI bisa dipakai, tetapi dengan aturan akses, review, dan pembatasan data.

Ketiga, proyek tinggi risiko. Misalnya sistem pembayaran, authentication, data pelanggan, security tooling, contract logic, atau source code inti produk. Di area ini, penggunaan AI harus lebih ketat, mungkin hanya melalui tool yang disetujui, model self-hosted, environment terisolasi, atau workflow review yang jelas.

Dengan cara ini, perusahaan tidak perlu memilih antara dua ekstrem: semua dilarang atau semua dibebaskan.

Larangan total sering membuat tim mencari jalan belakang. Kebebasan total membuat risiko sulit dibaca. Yang lebih sehat adalah aturan yang bisa dijalankan.

AI coding tool juga sebaiknya tidak menggantikan engineering discipline dasar. Code review tetap perlu. Test tetap perlu. Secret management tetap perlu. Dependency scanning tetap perlu. Logging dan access control tetap perlu.

AI bisa membantu menulis kode, tetapi tidak otomatis membuat keputusan teknis menjadi aman.

Bagi bisnis yang sedang mulai memakai AI dalam proses development, langkah paling masuk akal bukan langsung mencari tool paling populer. Mulailah dari pertanyaan yang lebih sederhana: bagian mana dari workflow developer yang memang aman untuk dibantu AI?

Mungkin AI dipakai untuk menjelaskan legacy code. Mungkin untuk membuat draft unit test. Mungkin untuk dokumentasi. Mungkin untuk refactor kecil. Mungkin belum boleh menyentuh repository tertentu.

Batas seperti ini bukan anti-inovasi. Justru batas yang jelas membuat inovasi lebih mudah diterima.

Tim security tidak merasa dilangkahi. Developer tidak merasa dilarang tanpa alasan. Management bisa melihat manfaat tanpa menutup mata terhadap risiko.

Kasus Alibaba dan Claude Code adalah pengingat bahwa era AI developer tooling sudah masuk fase baru. Pertanyaannya bukan lagi apakah AI bisa menulis kode. Itu sudah jelas bisa.

Pertanyaannya sekarang: apakah organisasi punya kontrol yang cukup ketika AI ikut masuk ke ruang kerja developer?

Jika belum, masalahnya bukan pada AI semata. Masalahnya ada pada governance yang belum menyusul kecepatan adopsi.

AI coding tool bisa menjadi akselerator yang sehat. Tetapi hanya jika perusahaan tahu batas akses, risiko data, dan tanggung jawab review sejak awal.

Sebelum membuka seluruh repository ke AI tool apa pun, cek dulu satu hal sederhana: apakah tim Anda sudah tahu kode mana yang boleh dibantu AI, data mana yang tidak boleh keluar, dan siapa yang bertanggung jawab atas hasil akhirnya?

Kalau jawabannya belum jelas, mulai dari sana.

Dapatkan Audit Teknis Gratis untuk meninjau penggunaan AI, workflow development, dan risiko teknis sebelum bisnis Anda mengadopsi automation lebih luas.

---

Sumber referensi berita: TechCrunch