Havedev
Larangan Claude Code di Alibaba Bukan Sekadar Cerita Tool AI
Banyak tim teknologi sedang berada di fase yang sama: AI coding tool terasa terlalu berguna untuk diabaikan.
Developer bisa menulis kode lebih cepat. Bug bisa dicari lebih awal. Dokumentasi bisa diringkas. Refactor yang biasanya terasa berat menjadi lebih mudah dimulai.
Karena itu, kabar bahwa Alibaba dilaporkan melarang karyawan memakai Claude Code mulai 10 Juli terlihat seperti cerita besar tentang kompetisi AI antara perusahaan teknologi.
Memang ada unsur itu.
Tetapi untuk bisnis, pelajaran yang lebih penting bukan hanya soal Alibaba, Anthropic, atau tool mana yang menang. Pelajarannya adalah ini: semakin dekat AI tool dengan kode, data, dan proses internal, semakin besar kebutuhan bisnis untuk punya aturan yang jelas.
The Core Update
Menurut beberapa laporan, Alibaba akan melarang karyawan memakai Claude Code, tool pemrograman dari Anthropic. Claude Code diklasifikasikan sebagai software berisiko tinggi, dan karyawan diarahkan memakai Qoder, tool milik Alibaba sendiri.
Konteksnya cukup sensitif.
Anthropic sudah melarang perusahaan China, termasuk entitas asing yang dimiliki perusahaan China, untuk memakai modelnya. Di sisi lain, Anthropic juga dilaporkan berusaha menutup celah akses yang masih memungkinkan pengguna dari China memakai Claude.
Ada pula diskusi publik tentang eksperimen di Claude Code yang disebut dapat membantu mengidentifikasi pengguna China secara diam-diam. Perwakilan Anthropic menyebut eksperimen itu dibuat untuk mencegah penyalahgunaan akun oleh reseller tidak sah dan melindungi model dari distillation, yaitu praktik melatih model AI menggunakan output dari model lain.
Anthropic mengatakan mitigasi yang lebih kuat sudah dibuat dan eksperimen itu sebenarnya sudah direncanakan untuk dihentikan.
Namun dari sudut pandang perusahaan besar seperti Alibaba, detail teknis seperti ini cukup untuk memicu keputusan konservatif. Jika sebuah tool developer dianggap dapat membawa risiko backdoor, identifikasi tersembunyi, kebocoran kode, atau ketidakpastian akses, maka larangan internal menjadi keputusan yang masuk akal.
Bukan karena AI coding tidak berguna.
Justru karena terlalu berguna dan terlalu dekat dengan aset penting perusahaan.
The Reality Check
Banyak bisnis melihat AI coding tool dari sisi produktivitas terlebih dahulu. Berapa cepat developer bisa membuat fitur. Berapa banyak waktu yang bisa dihemat. Berapa banyak pekerjaan repetitif yang bisa dibantu.
Pertanyaan itu valid.
Tetapi belum cukup.
AI coding tool bukan sekadar editor yang lebih pintar. Ia bisa membaca struktur project, memahami potongan kode, memberi saran implementasi, menjelaskan bug, dan dalam beberapa mode bahkan menjalankan perintah di lingkungan kerja developer.
Artinya, tool seperti ini berada di area yang sangat sensitif.
Ia dekat dengan source code. Dekat dengan konfigurasi. Dekat dengan dependency. Dekat dengan token jika lingkungan kerja tidak rapi. Dekat dengan logika bisnis yang belum tentu boleh keluar dari perusahaan.
Masalahnya, banyak tim mengadopsi AI coding tool dengan cara yang terlalu santai. Satu developer mencoba. Lalu terasa membantu. Lalu dipakai lebih sering. Lalu tim lain ikut. Baru setelah itu perusahaan bertanya: data apa yang pernah dikirim? kode apa yang pernah dibaca? apakah tool ini boleh dipakai untuk repository client? apakah ada aturan untuk secret, database schema, atau kode proprietary?
Urutannya terbalik.
Di level individu, eksperimen seperti itu terasa wajar. Di level bisnis, pola seperti itu bisa menjadi risiko.
Bukan berarti semua perusahaan harus melarang AI coding tool. Itu juga terlalu reaktif. Tetapi perusahaan perlu membedakan antara memakai AI untuk pekerjaan umum dan memberi AI akses ke lingkungan engineering.
Ada perbedaan besar antara meminta AI menjelaskan konsep REST API dengan meminta AI membaca repository production.
Ada perbedaan besar antara membuat contoh fungsi generik dengan mengirim potongan kode sistem pembayaran internal.
Ada perbedaan besar antara memakai AI di browser untuk ide awal dengan menjalankan agent coding yang punya akses ke file, terminal, dan dependency project.
Kasus Alibaba menunjukkan satu hal yang sering dilupakan: risiko AI tool tidak hanya datang dari output yang salah. Risiko juga bisa datang dari akses, telemetry, policy vendor, lokasi data, kontrol akun, supply chain, dan perubahan perilaku tool yang tidak selalu terlihat oleh user akhir.
Untuk perusahaan besar, ini bukan paranoia. Ini governance.
The Havedev Way
Dari sudut pandang Havedev, pertanyaan yang lebih sehat bukan “boleh atau tidak memakai AI coding tool?”
Pertanyaan yang lebih penting adalah: AI boleh dipakai di bagian mana, dengan akses seperti apa, dan untuk jenis pekerjaan apa?
Bisnis tidak perlu langsung membuat kebijakan AI yang rumit. Tetapi bisnis perlu punya batas awal yang jelas.
Misalnya:
- AI boleh dipakai untuk menjelaskan konsep, menulis draft dokumentasi, atau membuat contoh kode non-produksi
- AI boleh membantu refactor hanya pada repository yang sudah disetujui
- AI tidak boleh menerima secret, token, credential, private key, atau data pelanggan mentah
- AI tidak boleh dipakai di project client tanpa persetujuan atau aturan tertulis
- AI coding agent yang dapat menjalankan command harus dibatasi di environment yang aman
- hasil AI tetap harus melalui review manusia, test, dan standar security yang sama
Aturan seperti ini tidak membuat tim menjadi lambat. Justru membuat adopsi AI lebih aman dan lebih dipercaya.
Tanpa aturan, setiap developer membuat standar sendiri. Ada yang sangat hati-hati. Ada yang terlalu bebas. Ada yang menganggap semua kode aman dikirim karena tidak ada nama pelanggan. Ada yang lupa bahwa struktur database, endpoint internal, atau business logic juga termasuk informasi sensitif.
Di banyak bisnis, masalahnya bukan karena tim memakai AI. Masalahnya karena perusahaan belum menentukan batas pemakaian AI.
Untuk tim engineering, langkah paling praktis adalah mulai dari inventarisasi sederhana.
Tool AI apa yang dipakai? Dipakai oleh siapa? Untuk project apa? Apakah tool itu membaca file lokal? Apakah mengirim konteks ke server vendor? Apakah menyimpan prompt? Apakah bisa menjalankan command? Apakah dipakai untuk kode internal, kode client, atau hanya eksperimen?
Jawaban dari pertanyaan ini sering lebih berguna daripada debat abstrak tentang AI.
Setelah itu, perusahaan bisa menentukan tingkat risiko.
AI untuk brainstorming konten mungkin risikonya rendah. AI untuk membantu query database production risikonya tinggi. AI untuk membuat unit test di repository internal mungkin bisa diterima dengan batasan. AI agent yang punya akses terminal di project sensitif perlu kontrol yang lebih ketat.
Tidak semua harus dilarang. Tidak semua boleh dibebaskan.
Yang dibutuhkan adalah klasifikasi yang masuk akal.
Kasus Alibaba dan Claude Code memberi pengingat bahwa AI coding tool bukan hanya urusan developer experience. Ia sudah masuk ke wilayah security, compliance, vendor risk, dan kontrol operasional.
Bagi bisnis yang lebih kecil, pelajarannya tetap relevan. Mungkin skalanya berbeda, tetapi prinsipnya sama. Jangan tunggu sampai ada insiden baru membuat aturan.
Mulai dari batas sederhana:
- data apa yang tidak boleh dikirim ke AI
- project mana yang boleh dibantu AI
- siapa yang boleh memakai AI coding agent
- review apa yang wajib dilakukan sebelum kode masuk production
- bagaimana cara mencatat tool AI yang dipakai tim
AI coding tool akan terus berkembang. Sebagian akan semakin pintar. Sebagian akan semakin terintegrasi dengan IDE, terminal, repository, CI/CD, dan deployment.
Semakin besar manfaatnya, semakin penting kontrolnya.
Penutupnya sederhana: bisnis tidak perlu anti-AI untuk menjadi aman. Tetapi bisnis juga tidak boleh memakai AI hanya karena tool itu sedang populer.
Produktivitas tanpa batas yang jelas bisa berubah menjadi risiko yang sulit dilacak.
Sebelum memberi AI akses lebih dalam ke pekerjaan engineering, pastikan tim sudah punya aturan dasar: apa yang boleh dibaca, apa yang tidak boleh dikirim, siapa yang bertanggung jawab, dan kapan hasil AI harus ditolak.
Karena dalam software, kecepatan selalu penting. Tetapi kecepatan yang tidak bisa diaudit biasanya hanya menunda masalah.
Dapatkan Audit Teknis Gratis untuk meninjau penggunaan AI, workflow development, dan risiko teknis sebelum tool baru masuk terlalu dalam ke sistem bisnis Anda.
Sumber referensi berita: TechCrunch