Havedev
Vibe Coding Bukan Alasan untuk Mengaburkan Etika Produk
Corgi, startup insurtech yang didukung Y Combinator, sedang menjadi perhatian setelah Papermark menuduh produk Dataroom milik Corgi meniru software data room open source mereka.
Corgi membantah memakai kode Papermark. Menurut mereka, tidak ada kode yang digunakan dari produk tersebut. CEO Corgi juga menunjukkan bahwa basis kode keduanya berbeda.
Namun tuduhan itu cepat menyebar karena ada hal lain yang terlihat jelas: beberapa bagian produk Corgi memakai bahasa, struktur fitur, dan elemen visual yang sangat mirip dengan Papermark.
Corgi kemudian mengakui bahwa bagian tersebut dibuat dengan pendekatan vibe coding dan sudah diperbarui. Mereka menegaskan bahwa isu ini terbatas pada elemen visual di beberapa halaman pengaturan.
Di titik ini, perdebatan menjadi lebih menarik. Masalahnya bukan hanya apakah kode disalin. Masalahnya adalah apakah produk boleh terlihat, berbunyi, dan terasa hampir sama hanya karena AI membantu membuat ulang dari referensi yang ada.
The Core Update
Kasus ini memperlihatkan gesekan baru dalam dunia produk digital.
Dulu, tuduhan meniru software biasanya berpusat pada source code. Apakah repository disalin? Apakah lisensi dilanggar? Apakah ada file, fungsi, atau struktur kode yang sama?
Sekarang, AI membuat batas itu lebih kabur.
Seseorang bisa meminta AI membuat fitur yang mirip dengan produk lain. Kode yang dihasilkan bisa berbeda secara teknis, tetapi hasil akhirnya tetap sangat dekat: layout serupa, copywriting serupa, alur serupa, bahkan istilah yang dipakai bisa sama.
Secara hukum, perbedaan kode mungkin menjadi hal penting. Tetapi secara reputasi, pasar tidak selalu membaca sedetail itu.
Jika pengguna, founder lain, atau komunitas melihat produk baru yang terlalu mirip dengan produk yang sudah ada, pertanyaan yang muncul bukan hanya “apakah ini ilegal?” tetapi juga “apakah ini malas?”
Itu pertanyaan yang lebih sulit dijawab dengan screenshot perbandingan kode.
The Reality Check
Banyak tim memakai AI coding karena ingin bergerak lebih cepat. Itu wajar.
AI bisa membantu membuat prototype, menyusun UI, menulis boilerplate, mempercepat integrasi, dan mengurangi pekerjaan repetitif. Untuk startup, ini terasa seperti leverage yang besar.
Tetapi kecepatan tanpa arah bisa membuat produk kehilangan karakter.
Ketika prompt terlalu bergantung pada produk lain sebagai referensi, hasilnya sering bukan inspirasi. Hasilnya adalah bayangan produk lain dengan warna, nama, dan repository yang berbeda.
Di sinilah banyak tim perlu lebih jujur.
Masalahnya bukan memakai AI. Masalahnya adalah memakai AI untuk melewati proses berpikir produk.
Produk yang sehat biasanya punya jawaban atas beberapa hal:
- siapa pengguna utamanya
- masalah spesifik apa yang ingin diselesaikan
- mengapa alur ini dibuat seperti ini
- bahasa apa yang paling mudah dipahami pengguna
- bagian mana yang memang harus familiar
- bagian mana yang harus berbeda karena konteks bisnis berbeda
Kalau jawaban itu belum ada, AI akan mengambil jalan paling mudah: meniru pola yang sudah terlihat di internet.
Itulah risiko vibe coding yang sering tidak dibicarakan. Ia bisa membuat tim merasa produktif, padahal mereka hanya mempercepat kemiripan.
Dalam kasus seperti Corgi dan Papermark, pembelaan “kode kami berbeda” mungkin cukup untuk sebagian aspek legal. Tetapi itu belum tentu cukup untuk membangun kepercayaan.
Kepercayaan pasar tidak hanya dibentuk oleh legal compliance. Kepercayaan juga dibentuk oleh kesan bahwa tim punya integritas, punya sudut pandang sendiri, dan tidak sekadar mengambil shortcut dari kerja orang lain.
Apalagi untuk produk yang menjual keamanan, dokumen sensitif, insurance, atau proses bisnis penting. Di kategori seperti ini, reputasi bukan aksesoris. Reputasi adalah bagian dari produk.
Jika calon pelanggan merasa sebuah tim ceroboh dalam membedakan inspirasi dan peniruan, mereka bisa bertanya lebih jauh: apakah tim ini juga ceroboh dalam mengelola data, proses, dan tanggung jawab lain?
The Havedev Way
Dari sudut pandang Havedev, AI coding sebaiknya dipakai sebagai akselerator, bukan pengganti product judgment.
Tim boleh memakai referensi. Hampir semua produk digital lahir dari pola yang sudah ada: dashboard, data room, CRM, checkout, onboarding, kanban, dan form. Tidak semua hal harus dibuat dari nol.
Tetapi referensi harus diolah, bukan disalin mentah.
Sebelum memakai AI untuk membangun fitur, tim perlu punya batas kerja yang jelas:
- apa yang boleh dijadikan inspirasi
- apa yang tidak boleh ditiru secara langsung
- copywriting mana yang harus ditulis ulang sesuai konteks sendiri
- komponen mana yang memakai pola umum industri
- pengalaman mana yang menjadi pembeda produk
- siapa yang melakukan review sebelum fitur dirilis
Ini bukan birokrasi. Ini cara sederhana untuk menjaga agar AI tidak membawa risiko reputasi ke dalam produk.
Untuk tim yang sedang membangun dengan AI, proses review juga perlu berubah. Code review saja tidak cukup.
Tim perlu melakukan product originality review.
Artinya, sebelum fitur dirilis, jangan hanya bertanya apakah kodenya jalan. Tanyakan juga:
- apakah halaman ini terlalu mirip dengan produk tertentu?
- apakah kalimatnya terasa seperti copy dari kompetitor?
- apakah alurnya memang cocok untuk pengguna kita?
- apakah desain ini punya alasan, atau hanya hasil prompt?
- apakah kita nyaman jika publik membandingkannya secara berdampingan?
Pertanyaan terakhir penting. Jika tim tidak nyaman melihat produknya dibandingkan side-by-side dengan referensi yang dipakai, itu tanda ada sesuatu yang perlu diperbaiki sebelum rilis.
AI membuat pembuatan software menjadi lebih cepat. Tetapi semakin cepat sebuah tim bisa meniru, semakin penting juga kemampuan tim untuk memilih, menyaring, dan bertanggung jawab.
Bagi bisnis, pelajarannya sederhana: jangan melihat AI hanya sebagai cara memangkas waktu development. Lihat juga sebagai sistem yang perlu guardrail.
Tanpa guardrail, AI bisa menghasilkan fitur yang terlihat selesai tetapi membawa utang etika, utang diferensiasi, dan utang reputasi.
Pada akhirnya, produk yang baik bukan hanya produk yang kodenya original. Produk yang baik juga punya sudut pandang yang jelas.
Jika sebuah tim memakai AI untuk membangun lebih cepat, mereka tetap perlu menjawab pertanyaan dasar: bagian mana dari produk ini yang benar-benar milik kita?
Kalau jawabannya belum jelas, mungkin masalahnya bukan di AI.
Masalahnya ada pada proses produk yang terlalu terburu-buru untuk terlihat selesai.
Dapatkan Audit Teknis Gratis untuk meninjau alur produk, website, dan automation Anda sebelum AI mempercepat hal yang belum siap secara strategi.
Sumber referensi berita: TechCrunch