Vibe coding: kegunaan dan batasannya

Berikan ruang untuk membangun

CTO enterprise dapat membantu lebih banyak orang mengubah pengetahuannya menjadi ide perangkat lunak. Libatkan orang dari keuangan, operasi, penjualan, dan engineering. Berikan waktu, data sintetis, API sandbox, dan dukungan.

Izinkan orang menggunakan berbagai alat untuk eksplorasi dengan batas jelas untuk instalasi, akun, dan input yang diizinkan. Builder berbasis browser, asisten pemrograman, atau agen lokal dapat membantu menguji ide. Pilihan alat tidak memberikan izin untuk mengunggah informasi perusahaan atau menghubungkan sistem aktif.

Publikasikan jalur sederhana untuk membawa prototipe yang berguna ke tim engineering atau platform. Pembuat menyumbangkan masalah, contoh alur kerja, dan nilai yang diamati. Pembuat tidak harus menjadi tim keamanan dan operasi layanan tersebut.

Identifikasi hal yang perlu dipelajari

Vibe coding biasanya dimulai dengan deskripsi perangkat lunak yang diinginkan. Anda menerima kode yang dihasilkan dan menggunakan hasil yang terlihat untuk mengarahkan perubahan berikutnya. Istilah ini memiliki beberapa makna. Dalam panduan ini, orang yang mengarahkan pekerjaan belum tentu memahami setiap keputusan implementasi.

Metode ini dapat membantu pembelajaran. Antarmuka sederhana dapat menunjukkan bahwa proses persetujuan memiliki terlalu banyak langkah. Script sementara dapat membantu menilai format file. Prototipe memberi desain spesifik untuk didiskusikan. Pengetahuan ini dapat dipertahankan meskipun kodenya dibuang.

Pertama, tentukan pertanyaan dengan jawaban yang dapat diamati. Misalnya: “Dapatkah manajer tim memahami proses persetujuan ini?” Pertanyaan ini memiliki cakupan jelas. Permintaan membangun sistem pengeluaran juga mencakup perlindungan data, kontrol akses, operasi, dan tanggung jawab.

Prototipe perbankan pada hari Selasa

Pertimbangkan contoh fiktif. Pada hari Selasa, rekan dari bagian keuangan menggunakan Lovable untuk membangun dashboard dari transaksi bank rekaan. Dashboard mengelompokkan pengeluaran dan menampilkan invoice yang belum dibayar. Kini tim dapat mendiskusikan alur kerja yang berguna.

Seseorang menyarankan menghubungkan rekening bank perusahaan. Hal itu mengubah dampaknya, meskipun aplikasi masih berlabel “prototipe”.

Akses baca dapat mengungkap saldo, riwayat transaksi, nama pelanggan, atau referensi pembayaran, bergantung pada API. Jika koneksi juga mengizinkan pembayaran, kesalahan dapat memindahkan uang nyata. Konfirmasikan cakupan izin yang sebenarnya; koneksi bank tidak selalu mencakup akses pembayaran.

Demo tidak membuktikan bahwa pengguna hanya dapat melihat rekening yang boleh diaksesnya. Tombol tersembunyi tidak menegakkan izin. OWASP menjelaskan cara pemeriksaan rekening atau data yang hilang dapat membuka data pengguna lain.

Untuk API pembayaran, idempotensi berarti permintaan yang diulang tidak mengulang efek yang dimaksud. Stripe mendokumentasikan salah satu implementasi. Periksa perilaku, batas, dan aturan percobaan ulang penyedia yang sebenarnya. Rollback aplikasi tidak membatalkan pembayaran yang telah diproses bank.

Contoh ini bukan bukti cacat Lovable. Panduan keamanan Lovable sendiri mengharuskan perlindungan secret, pemeriksaan di server, kebijakan data yang diuji, dan peninjauan berkelanjutan. Terapkan standar bukti yang sama pada setiap builder, agen, atau aplikasi yang ditulis manual.

Periksa akses sebelum menghubungkan sistem nyata

Terus uji alur kerja dengan data sintetis dan akun sandbox. Sebelum akses ke sistem aktif, minta penanggung jawab layanan, keamanan, dan platform memverifikasi aplikasi serta lingkungan operasinya.

Gunakan alur koneksi yang disetujui bank atau penyedia. Berikan akses hanya ke rekening dan izin yang diperlukan. Simpan kredensial privat dalam penyimpanan secret yang disetujui, di luar prompt dan kode browser. Tetapkan persetujuan dan batas pembayaran jika pembayaran diperlukan. Verifikasi cara mencabut akses, menyelidiki kegagalan, dan merespons aktivitas mencurigakan.

Keputusan ini harus dibuat sebelum input rahasia atau kredensial aktif masuk ke sistem. Menunggu rilis produksi formal dapat menjadi terlalu terlambat. Lanjutkan ke batas data dan infrastruktur enterprise.

Tentukan tanggung jawab sebelum memperluas penggunaan

Eksperimen dengan data rekaan dapat berumur singkat dan memiliki sedikit pengguna. Ketika orang lain bergantung pada aplikasi, tentukan tanggung jawab penggunaannya.

1. Tetapkan penanggung jawab.
2. Identifikasi pengguna dan data yang diizinkan.
3. Tentukan respons terhadap kegagalan.
4. Simpan kode sumber dan konfigurasi dalam repositori.
5. Verifikasi bahwa orang lain dapat memeriksa dan mereproduksi sistem.

Tidak setiap script memerlukan platform enterprise. Formatter pribadi tanpa data sensitif memerlukan lebih sedikit kontrol daripada aplikasi persetujuan pembayaran. Nilai dampak kesalahan. Periksa apakah kesalahan dapat dideteksi dan dampaknya dibatalkan.

Sebelum memperluas prototipe, pisahkan hal yang dipelajari tentang masalah dari bukti tentang implementasi. Anda dapat mempertahankan antarmuka dan mengganti kode internal. Anda dapat membatasi penggunaan yang dimaksud. Anda juga dapat mempertahankan prototipe sebagai eksperimen sementara.

Rencanakan penanganan kerentanan setelah demo

Demo yang berhasil dapat menyembunyikan kekurangan pemeliharaan yang serius. Dependensi dapat menerima advisori kerentanan baru tanpa perubahan apa pun pada kode Anda. Pemindaian saat rilis hanya menggambarkan kondisi pada saat itu.

Jika aplikasi tetap digunakan, seseorang harus terus menemukan, menilai, dan memperbaiki kerentanan. Perbaikan harus mencapai produksi dan lulus verifikasi. Pemindai tanpa proses respons ini membiarkan paparan tetap belum terselesaikan.

Periksa hal yang benar-benar disediakan alat dan konfigurasi Anda. Nanti, pengelolaan kerentanan berkelanjutan menjelaskan proses lengkap, termasuk kegagalan pemindaian dan versi yang di-deploy.

Buat perubahan berikutnya mudah ditinjau

Berikan satu perubahan kecil kepada agen dengan kriteria penerimaan eksplisit. Nyatakan tindakan yang boleh dilakukan agen. Periksa diff yang dihasilkan. Jalankan pemeriksaan yang dapat menolak implementasi keliru. Pertahankan deployment sebagai keputusan terpisah sampai tanggung jawab rilis jelas.

NIST Secure Software Development Framework menjelaskan praktik pengembangan aman yang lebih luas. Gunakan sebagai referensi ketika menilai kontrol yang belum tersedia. Anda tidak perlu menghafal kerangka tersebut. Anda perlu mengidentifikasi bukti yang belum tersedia sebelum perangkat lunak memengaruhi orang lain.