Aplikasi Dibuat dengan AI, Lalu Mau Dikembangkan: Apa yang Kami Periksa Lebih Dulu

"Tinggal Tambah Fitur Saja, Bisa?"

Permintaannya biasanya sederhana dan masuk akal. Seorang pemilik usaha membuat versi pertama aplikasinya sendiri dengan bantuan AI. Aplikasinya jalan, dipakai pelanggan atau karyawan setiap hari. Usahanya berkembang, dan kini ada daftar keinginan: laporan baru, peran pengguna tambahan, pembayaran online, formulir yang nyaman dibuka dari ponsel. Bisa ditambahkan?

Jawaban jujurnya: bisa, tetapi tidak di hari pertama.

Belum lama ini kami mengambil alih aplikasi seperti itu. Pemiliknya sangat paham proses bisnisnya, tidak punya latar belakang pengembangan software, dan membangun seluruh aplikasinya lewat percakapan dengan asisten AI. Yang diserahkan kepada kami hanya source code, tanpa dokumen lain. Untuk menjaga privasi klien, nama proyek dan bidang usahanya tidak kami sebutkan.

Di artikel sebelumnya kami sudah membahas cara menyusun kembali pengetahuan tentang sistem dari source code: membaca route, database, peran pengguna, dan alur kerja menjadi dokumen yang bisa dipelihara. Artikel ini melanjutkan dari titik itu. Setelah kita tahu apa yang dikerjakan aplikasi, apa saja yang perlu diperiksa sebelum mengubahnya, dan mengapa daftar fitur pemilik harus menunggu sampai pemeriksaan itu selesai?

Bisa Jalan Belum Berarti Bisa Dikembangkan

Aplikasi yang berjalan hari ini sudah lulus satu ujian: ia mengerjakan apa yang diminta, untuk kasus-kasus yang pernah dicoba. Itu pencapaian yang nyata, dan tidak semua versi pertama sampai ke sana.

Namun lulus ujian itu belum sama dengan siap berkembang. Setiap fitur baru pasti bersinggungan dengan bagian yang sudah ada, entah tabel, hak akses, halaman, atau proses otomatis. Kalau tidak ada yang memahami bagian-bagian itu, setiap perubahan hanyalah tebakan, dan akibat tebakan yang salah ditanggung oleh orang yang memakai aplikasinya.

Pada kode buatan AI, persoalan ini lebih terasa. Asisten AI menjawab setiap prompt secara terpisah. Ia tidak menyimpan gambaran utuh sistemnya, dan tidak menanyakan hal yang biasa ditanyakan seorang engineer sebelum menulis kode: siapa yang boleh melakukan ini, bagaimana kalau datanya salah, apa yang terjadi kalau dua orang melakukannya bersamaan. Sisi teknis dari persoalan ini dibahas di qadrlabs dalam artikel AI Can Write Code. But Can You Read It?. Kalau diterjemahkan ke bahasa pemilik aplikasi, intinya begini: Anda baru benar-benar memiliki sebuah software ketika ada orang yang bisa memperkirakan bagian mana yang harus diubah, sebelum mengubahnya.

Karena itu, tahap pertama pengambilalihan bukan membangun. Tahap pertamanya adalah membuat aplikasi itu dipahami, disepakati, dan cukup aman untuk dikembangkan.

Sepakati Dulu Aplikasi Ini Sebenarnya untuk Apa

Pada proyek yang dibangun dengan AI, prompt itulah spesifikasinya, dan prompt-nya biasanya sudah tidak ada. Sebagian perilaku aplikasi memang keputusan pemilik. Sebagian lagi hanya hasil yang kebetulan diberikan AI, lalu dibiarkan karena sudah terlanjur dipakai. Sebelum menilai kesehatan kodenya, kita perlu tahu mana yang mana.

Di proyek ini, tahap tersebut kami kerjakan dalam lima kegiatan:

• Meninjau ulang dokumentasi hasil pemulihan. Daftar fitur, diagram data, matriks peran, dan alur kerja yang sudah disusun dibaca kembali, kali ini sebagai gambaran bisnis, bukan gambaran kode.
• Menganalisis sistem yang sedang berjalan. Bagaimana aplikasi benar-benar dipakai: fitur mana yang diandalkan, mana yang dihindari, dan cara kerja manual apa yang muncul di sekitarnya.
• Brainstorming langsung dengan klien. Duduk bersama pemilik dan menelusuri aplikasi layar demi layar. Pertanyaan seperti "Di halaman ini semua staf bisa menghapus data. Memang begitu yang diinginkan?" hanya bisa dijawab oleh pemiliknya.
• Requirement gathering. Mengubah daftar keinginan pemilik menjadi kebutuhan tertulis: siapa penggunanya, apa yang harus bisa dilakukan, dan apa yang tidak boleh terjadi.
• Analisis kebutuhan. Mencocokkan kebutuhan baru dengan sistem yang ada. Ada yang langsung cocok, ada yang bertentangan dengan aturan yang sudah tertanam di kode, dan ada yang bergantung pada bagian aplikasi yang perlu dibenahi dulu.

Hasil tahap ini adalah kesepakatan. Pemilik dan tim pengembang memegang satu gambaran yang sama tentang apa yang seharusnya dikerjakan aplikasi. Justru gambaran inilah yang paling sering tidak dimiliki proyek buatan AI.

Delapan Hal yang Kami Periksa di Kode

Setelah perilaku yang diinginkan disepakati, kami menilai apakah kodenya sanggup menopangnya. Ada delapan area yang kami periksa di proyek ini. Untuk tiap area kami jelaskan apa yang dilihat, mengapa harus beres sebelum fitur baru, dan pertanyaan yang bisa Anda ajukan kepada tim mana pun yang akan mengambil alih aplikasi Anda.

Akses dan Data Rahasia

Kami memastikan kode, server, database, domain, dan akun layanan pihak ketiga dipegang oleh organisasi pemilik, bukan perorangan. Kami juga mencari data rahasia yang tersimpan di tempat yang salah, seperti password, API key, atau token yang ditulis langsung di kode atau ikut tersimpan di repository.

Asisten AI sering menaruh kunci di mana saja asalkan contohnya jalan. Kunci yang pernah masuk repository atau pernah ditempel di percakapan sebaiknya dianggap sudah diketahui orang lain, lalu diganti.

Mengapa didahulukan: integrasi baru hampir selalu menambah kunci baru. Menambahkannya ke sistem yang kuncinya sudah bocor hanya memperbesar masalah.

Tanyakan: "Kredensial apa saja yang ditemukan di kode, dan apakah sudah diganti?"

Pembatasan Akses di Sisi Server

Aplikasi bisnis biasanya dipakai beberapa jenis pengguna. Kami memeriksa di mana aturan "siapa boleh melakukan apa" ditegakkan. Tempat yang aman adalah di server, sebelum aksinya dijalankan. Yang sering terjadi, pembatasannya hanya di tampilan: tombolnya disembunyikan dari sebagian pengguna, tetapi aksinya tetap menerima siapa pun yang bisa mengaksesnya.

Mengapa didahulukan: peran dan fitur baru termasuk permintaan yang paling sering muncul. Kalau model hak aksesnya kabur atau hanya diatur di layar, setiap peran baru ikut mewarisi kelemahan itu.

Tanyakan: "Kalau pengguna mengetik langsung alamat halaman yang bukan haknya, apa yang menghalanginya?"

Library dan Versi Framework

Kami mendata framework beserta versinya dan semua library yang dipakai, lalu mencocokkannya dengan versi yang masih didukung dan advisory keamanan yang sudah terbit. Kami juga mencari paket yang dipasang untuk satu percobaan lalu tidak pernah dihapus.

Mengapa didahulukan: fitur yang dibangun di atas framework usang harus ditulis ulang ketika framework-nya di-upgrade. Membereskan fondasi lebih murah daripada menambah bangunan di atasnya lebih dulu.

Tanyakan: "Apakah versi framework ini masih menerima perbaikan keamanan?"

Keutuhan Data

Kami membaca struktur database dan membandingkannya dengan cara data itu dipakai. Apakah hubungan antartabel dijaga oleh database, atau hanya diandaikan oleh kode? Apakah input divalidasi sebelum disimpan? Adakah data ganda atau saling bertentangan, tanda bahwa sebuah aturan diterapkan di satu tempat tetapi terlupa di tempat lain?

Mengapa didahulukan: data bertahan lebih lama daripada kode. Bug bisa diperbaiki dalam sehari, tetapi data yang tersimpan keliru berbulan-bulan butuh perbaikan yang hati-hati, dan fitur baru yang dibangun di atasnya akan mengulang kesalahan yang sama.

Tanyakan: "Bagaimana nasib data yang sudah ada kalau fitur ini ditambahkan besok?"

Aturan yang Ditulis Berulang dan Tidak Seragam

Pemeriksaan ini khas aplikasi buatan AI. Kalau sistem dibangun lewat banyak prompt terpisah, satu aturan bisnis sering ditulis berkali-kali dengan cara yang sedikit berbeda. Potongan harga, batas waktu, atau syarat persetujuan bisa dihitung dengan satu cara di formulir dan dengan cara lain di laporan.

Kami mencari aturan yang muncul di lebih dari satu tempat, lalu memastikan bersama pemilik versi mana yang benar.

Mengapa didahulukan: mengubah aturan yang tersebar di tiga tempat berarti harus menemukan ketiganya. Satu saja terlewat, muncul bug yang biasanya disadari pengguna lebih dulu daripada developer.

Tanyakan: "Kalau aturan ini diubah, ada berapa tempat di kode yang ikut berubah?"

Test Otomatis

Kami memeriksa apakah aplikasi punya test otomatis dan bagian apa saja yang diuji. Pada proyek buatan AI, jawabannya biasanya tidak ada, karena memang tidak pernah diminta.

Mengapa didahulukan: test adalah cara tim mengetahui bahwa sebuah perubahan tidak merusak bagian lain. Tanpa test, setiap fitur baru harus dicek manual, dan cepat atau lambat ada yang terlewat.

Tanyakan: "Bagaimana kita tahu fitur baru tidak merusak fitur lama?"

Penanganan Error dan Log

Kami melihat apa yang terjadi ketika sesuatu gagal. Apakah pengguna mendapat pesan yang jelas, atau halaman error teknis? Apakah mode debug sudah dimatikan di server produksi, supaya detail internal tidak terlihat pengunjung? Apakah error dicatat di log yang bisa dibaca seseorang?

Mengapa didahulukan: fitur baru membawa kemungkinan gagal yang baru. Kalau aplikasi gagal tanpa jejak, masalahnya dilaporkan pelanggan, bukan ditemukan tim.

Tanyakan: "Kalau aplikasi error, di mana kita bisa melihat penyebabnya?"

Proses Deploy dan Backup

Kami menelusuri bagaimana kode sampai ke server produksi, apakah ada lingkungan terpisah untuk mencoba perubahan sebelum dilihat pengguna, dan apakah database di-backup ke tempat selain server itu sendiri.

Mengapa didahulukan: setiap fitur harus dirilis. Kalau rilis berarti menyalin file langsung ke server produksi tanpa jalan kembali yang teruji, setiap rilis menjadi taruhan.

Tanyakan: "Kalau rilis bermasalah, bagaimana cara kembali ke versi sebelumnya?"

Stabilkan Dulu, Baru Tambah Fitur

Setelah pemeriksaan, pekerjaan terbagi menjadi dua daftar: apa yang perlu dibenahi, dan apa yang ingin ditambahkan pemilik. Di proyek ini kami sepakat dengan klien untuk menyelesaikan daftar pertama sebelum memulai daftar kedua.

Urutan ini bisa terasa lambat bagi pemilik yang datang membawa daftar fitur. Dalam praktiknya, urutan inilah yang membuat daftar fitur itu terjangkau. Setiap fitur baru masuk ke sistem yang hak aksesnya jelas, kredensialnya bersih, aturannya seragam, dan punya cara rilis yang aman. Kalau fitur dikerjakan dulu dan pembenahan menyusul, setiap pembenahan harus mengakali fitur-fitur yang ditambahkan di antaranya.

Menstabilkan bukan berarti menulis ulang aplikasi. Versi pertama buatan pemilik berisi keputusan nyata tentang usahanya, dan sebagian besar layak dipertahankan. Menstabilkan berarti membuat perilaku yang sudah ada menjadi jelas, aman, dan bisa diubah, sehingga pengembangan berikutnya bertumpu pada yang sudah ada, bukan menggantinya.

Kalau Aplikasi Anda Juga Dibuat dengan AI

Kalau Anda membangun aplikasi dengan bantuan AI, Anda sudah melakukan sesuatu yang berguna: ide Anda terbukti jalan dan sudah ada orang yang memakainya. Membutuhkan tim engineering untuk melanjutkannya bukan kegagalan Anda ataupun alatnya. Itu hanyalah pekerjaan analisis, desain, dan engineering yang dilewati versi pertama, dikerjakan pada saat pekerjaan itu mulai dibutuhkan.

Beberapa hal bisa membuat proses pengambilalihan lebih cepat dan lebih hemat:

• Kumpulkan akses sebelum pertemuan pertama. Repository kode atau salinannya dari server, login hosting dan server, akun domain, database, dan layanan pihak ketiga yang dipakai.
• Tulis daftar fitur sebagai masalah, bukan solusi. "Staf menghabiskan satu jam setiap minggu untuk merekap laporan ini" lebih informatif daripada "tambahkan tombol ekspor".
• Siapkan contoh nyata. Beberapa kasus yang biasa terjadi, ditambah satu atau dua kasus yang merepotkan, dari cara aplikasi dipakai sekarang.
• Simpan riwayat prompt kalau masih ada. Percakapan lama dengan AI memang bukan dokumentasi, tetapi bisa menunjukkan apa yang dulu Anda minta dan alasannya.

Saat berbicara dengan tim yang akan mengambil alih, tanyakan bagaimana mereka akan memeriksa aplikasi sebelum mengubahnya. Tim yang langsung menambah fitur di hari pertama tanpa menanyakan hal-hal di atas sedang menebak-nebak dengan sistem Anda.

Penutup

Aplikasi buatan AI adalah titik awal yang sah. Mengembangkannya dengan aman membutuhkan langkah yang dilewati versi pertamanya: menyepakati untuk apa aplikasi itu, memeriksa apakah kodenya sanggup menopangnya, dan membenahi yang belum sanggup sebelum membangun di atasnya.

Kalau Anda punya aplikasi buatan AI yang kini perlu dikembangkan, tetapi belum yakin seperti apa kondisinya, hubungi kami. Ceritakan apa yang dikerjakan aplikasinya hari ini dan apa yang Anda inginkan berikutnya. Kami akan mulai dengan memahami apa yang sudah Anda miliki.