Merawat aplikasi yang dibangun dengan AI: yang tak seorang pun ceritakan soal minggu kedua

Di akhir pekan pertamamu dengan Proyecta, kamu merilis sesuatu yang nyata. Ia berfungsi. Penggunamu (atau timmu, atau dirimu di masa depan) mulai memakainya. Lalu tibalah hari Senin dan seorang pelanggan mengirim email: “Bisa tambahkan dropdown untuk memfilter berdasarkan wilayah?”

Selamat datang di perawatan. Inilah bagian dari membangun aplikasi AI yang tak seorang pun bahas, dan bagian di mana sebagian besar proyek bisa menjadi aset jangka panjang atau diam-diam jatuh dari tebing. Kabar baiknya, merawat aplikasi buatan AI adalah pengalaman yang berbeda dari merawat kode tradisional. Kabar jujurnya, “berbeda” bukan berarti “gratis”.

Apa makna perawatan sebenarnya

Saat developer profesional bilang “perawatan”, kurang lebih mereka memaksudkan empat hal:

1. Menambahkan fitur kecil yang diminta orang setelah peluncuran.
2. Memperbaiki hal-hal yang rusak atau salah sejak awal.
3. Mengikuti perkembangan perubahan di luar aplikasimu — penyedia pembayaran memperbarui API mereka, browser baru dirilis, bentuk datamu berubah.
4. Beres-beres supaya codebase-nya tidak perlahan berubah jadi rawa.

Untuk aplikasi buatan AI, keempatnya tetap terjadi. Yang berubah adalah siapa yang mengerjakannya dan bagaimana rasanya pekerjaan itu.

Kabar baiknya: kamu bisa mengobrol dengannya

Inilah bagian yang tak seorang pun beritahu saat kamu sedang copy-paste kode dari tutorial lama. Dengan AI app builder, kamu merawat aplikasinya dengan cara yang sama seperti saat kamu membangunnya: dengan menjelaskan apa yang kamu inginkan.

Sebuah contoh nyata. Seorang founder yang kami kenal membangun CRM kecil untuk praktik coaching-nya — klien, sesi, pelacakan pembayaran, lengkap. Tiga minggu setelah peluncuran, seorang klien menyebut bahwa ia ingin melihat berapa banyak sesi yang telah ia jalani tahun itu. Ia membuka aplikasinya, bilang, “Tambahkan penghitung ‘sesi tahun ini’ ke setiap kartu klien, menarik dari tabel sesi di mana tanggalnya ada di 2026.” Dua belas menit kemudian, ia sudah live. Ia kembali ke coaching.

Cerita itu terdengar biasa sampai kamu ingat alternatifnya: menghubungi seorang freelancer, menunggu dua hari, membayar $300, meninjau sebuah PR yang tidak ia pahami sepenuhnya, dan berdoa tidak ada hal lain yang rusak. Loop perawatannya tidak lebih cepat karena AI lebih pintar dari freelancer. Ia lebih cepat karena loop-nya melibatkan lebih sedikit manusia.

Kabar yang lebih sulit: hal-hal kecil menumpuk

Inilah bagian yang menjebak orang. Aplikasi buatan AI tampak mudah diubah karena menambahkan sesuatu itu mudah. Yang tidak mudah adalah menjaga keseluruhan aplikasinya tetap koheren saat ia tumbuh.

Beberapa pola yang kami lihat berjalan keliru:

• Kekusutan tak sengaja. Kamu meminta “tambahkan kolom diskon di checkout”. Enam revisi kemudian, logika diskonnya tinggal di tiga tempat, dan cuma satu yang benar. Belum ada yang rusak, tapi perubahan berikutnya akan jadi membingungkan.
• Persyaratan yang terlupa. Kamu menambahkan “gratis ongkir di atas $50” di bulan Maret. Di bulan Mei, kamu minta AI untuk “rombak ulang checkout supaya mendukung gift card”. Ia mengerjakannya. Aturan gratis ongkir hilang. Tak ada yang menyadarinya selama dua minggu.
• Pergeseran. Aplikasimu mulai sebagai “tools untukku”. Sekarang dipakai oleh timmu. Model mental yang dipakai AI masih “untukku”, karena begitulah yang awalnya kamu katakan. Fitur baru terasa janggal, dan kamu tidak bisa menunjuk persis apa penyebabnya.

Tak satu pun dari ini adalah kegagalan AI app builder. Ini kegagalan ingatan dan konteks bersama — masalah yang sama yang dimiliki tim developer manusia, hanya dalam bentuk yang berbeda.

Cara menyiapkan diri

Tim yang berhasil baik dalam perawatan punya beberapa kebiasaan bersama. Sebagian besar bukan kebiasaan teknis. Ini kebiasaan soal cara kamu menjelaskan apa aplikasimu dan apa yang berubah.

Simpan dokumen “apa aplikasi ini”. Satu halaman. Audiensnya, tujuannya, aturannya (“gratis ongkir di atas $50”, “kami tidak pernah mengirim email ke pengguna di hari Minggu”, “telepon adalah kunci utama, bukan email”). Saat kamu minta AI mengubah sesuatu, tempel aturan yang relevan ke dalam prompt-nya. Kamu tidak sedang mem-bypass kecerdasan AI; kamu sedang menyuapinya konteks yang mustahil ia ingat.

Jelaskan perubahan dalam istilah perilaku, bukan kode. “Saya mau pengguna melihat filter wilayahnya diingat antar sesi” adalah permintaan yang jauh lebih baik daripada “tambahkan localStorage ke filter”. Yang pertama menjelaskan apa yang kamu inginkan; yang kedua meresepkan satu dari lima belas cara untuk melakukannya, dan kemungkinan bukan yang terbaik.

Lakukan perubahan satu per satu. Dua perubahan dalam satu prompt berarti salah satunya bisa gagal diam-diam dan kamu tidak akan tahu yang mana. Cara tercepat merawat aplikasi AI adalah menjaga iterasimu cukup kecil supaya kamu bisa tahu, sekilas, apakah hasilnya benar.

Lihat apa yang berubah. Sebagian besar AI app builder menunjukkanmu sebuah pratinjau. Pakai. Tiga puluh detik yang kamu habiskan untuk klik-klik mengonfirmasi fitur barunya berfungsi dan fitur lamanya masih berjalan adalah asuransi termurah yang akan kamu beli tahun ini.

Yang tak bisa kamu lakukan (dan sebaiknya tidak)

Ada godaan, setelah kamu membangun aplikasi dengan AI, untuk berpikir ia juga bisa mengoperasikan aplikasinya untukmu. Ia tidak bisa, dan jaraknya nyata:

• Ia tidak akan memberitahumu saat sesuatu rusak diam-diam. Log, monitoring, rotasi on-call — itu masih urusan terpisah. Sebagian besar AI app builder tidak memantau aplikasi production-mu seperti yang dilakukan seorang backend engineer.
• Ia tidak tahu soal dunia di luar aplikasimu. Kalau penyedia pembayaran men-deprecate sebuah API, AI tidak tahu sampai kamu memberitahunya. Berlanggananlah changelog penyediamu. Baca email-mu.
• Ia tidak bisa membuat keputusan produk untukmu. Apakah menambahkan sebuah fitur, trade-off mana yang diambil, apa yang sebenarnya diinginkan penggunamu — itu masih kamu. AI adalah tangan yang sangat cepat; otaknya milikmu.

Gambaran realistisnya

Setelah enam bulan dengan aplikasi buatan AI, sebagian besar orang yang kami ajak bicara mendarat kira-kira di sini: mereka menghabiskan mungkin dua sampai empat jam sebulan untuk perubahan, hampir semuanya lewat obrolan. Rebuild besar yang dulu mereka takuti — “saya mau menambahkan satu section yang benar-benar baru” — terasa seperti satu sore yang produktif. Hal-hal membosankannya — “format tanggalnya salah di export” — terasa seperti satu prompt yang tepat.

Yang tidak mereka miliki adalah derau latar belakang yang konstan dari codebase tradisional: update dependency, migrasi framework, patch keamanan, konfigurasi build. Derau itu sudah diserap ke dalam platform. Kamu membayar platform untuk menanganinya, yang merupakan kesepakatan yang jauh lebih baik daripada membayar developer untuk menanganinya.

Kalau kamu baru mau membangun aplikasi pertamamu, tulisan tentang aplikasi buatan AI pertama yang sebaiknya kamu buat layak dibaca sebelum kamu mulai. Dan kalau kamu sudah beberapa minggu berjalan dan merasakan beberapa pola di atas, itu normal. Tulis dokumen “apa aplikasi ini”-mu akhir pekan ini. Dirimu di masa depan, tiga bulan dari sekarang, saat meminta dashboard baru, akan sangat senang kamu melakukannya.