Rencana yang Anda lewatkan adalah gangguan yang akan Anda perbaiki nanti
Setiap kerangka kerja dalam rekayasa perangkat lunak mengajarkan untuk bergerak cepat, merilis lebih awal, beriterasi langsung di produksi. Untuk situs web hasil AI, itu justru terbalik. Builder di sini menolak untuk langsung men-streaming kode dari prompt Anda — ia berhenti, menulis rencana, dan menunggu Anda meninjaunya — dan penolakan itulah satu keputusan yang menjadi dasar semua hal lain dalam pipeline ini. Lebih lambat di awal, lebih murah di semua tahap sesudahnya. Saya akan selalu memilih pertukaran itu, dan menurut saya kebanyakan orang yang berargumen sebaliknya belum benar-benar melihat berapa besar biaya dari tebakan yang salah di tahap berikutnya.
Inilah mode kegagalan yang dicegah oleh rencana. Anda mengetik "situs pemesanan untuk studio saya" dan menekan mulai. Sistem harus menebak apa arti "pemesanan" — widget kalender, embed pihak ketiga, atau sistem reservasi sungguhan dengan pengecekan bentrokan jadwal — dan ia harus menebak sebelum menulis apa pun, karena tidak ada urutan lain untuk melakukannya. Tebak salah di dalam rencana, perbaikannya cukup satu kalimat, lima detik, selesai. Tebak salah di dalam kode yang sudah dihasilkan, Anda bukan lagi menyunting satu kalimat, tapi membongkar sepuluh file yang sudah bergantung pada asumsi yang salah. Saya sudah melihat kedua versi ini terjadi. Koreksi di tahap perencanaan hanya satu pertukaran percakapan. Perubahan arah pasca-pembuatan untuk ambiguitas yang sama persis adalah buang-dan-bangun-ulang.
Rencana ini juga bukan sekadar daftar tugas, dan inilah bagian yang sering terlewat orang. Ini adalah kontrak, dan sistem memegang janjinya sendiri: verifikator pemeriksa kesesuaian, salah satu agen yang harus memberi persetujuan sebelum build dirilis, membandingkan situs yang selesai dengan rencana yang sudah Anda setujui. Apakah setiap halaman yang direncanakan sudah dibuat? Apakah daftar fitur sesuai dengan yang dirilis? "Selesai" di sini bukan sekadar perasaan — itu relatif terhadap janji tertulis, dapat diperiksa baris demi baris. Itu jaminan yang lebih kuat dibandingkan "kodenya berjalan", dan Anda hanya bisa mendapatkannya karena ada dokumen untuk dibandingkan. Hilangkan rencananya, hilang pula tolok ukurnya.
Di mana ini benar-benar memberi hasil
Pengaruh Anda sebagai orang yang mengarahkan build sudah dimuat di awal, dipakai atau tidak. Jika Anda peduli pada arsitektur informasi, struktur halaman, fitur mana yang masuk v1 versus v2 — kecermatan itu bernilai sepuluh kali lipat saat meninjau rencana dibanding setelah proses pembuatan pertama. Empat menit ekstra membaca ulang rencana lebih baik daripada bolak-balik memperbaiki build yang sudah kadung melenceng.
Contoh paling jelas adalah jenis produk — situs statis biasa, aplikasi yang bisa diinstal, build berbasis framework, aplikasi berbasis server dengan penyimpanan data sungguhan. Tampilannya seperti dropdown biasa. Sebenarnya bukan. Ini adalah pilihan paling struktural dalam seluruh proses, karena diam-diam menentukan selusin hal yang tidak ada hubungannya dengan tampilan situs.
| Jenis produk | Pratinjau | Publikasikan | Akun / basis data |
|---|---|---|---|
| Situs statis biasa | Instan, karena hanya file statis | Output statis disalin dengan bersih | Tidak mungkin — meminta login sama saja meminta sesuatu yang secara struktural tidak bisa dilakukan jenis ini |
| Build berbasis framework | Dikompilasi terlebih dahulu; build yang gagal muncul sebagai "tidak ada pratinjau", bukan "halaman rusak" | Jalur penyalinan statis yang sama bersihnya, setelah dikompilasi | Tidak mungkin |
| Aplikasi berbasis server | — | Membutuhkan tempat untuk benar-benar menjalankan proses, yang gagal dengan cara berbeda — proses yang crash, bukan file yang hilang | Satu-satunya jenis di mana akun dan basis data benar-benar ada |
Dan Anda tidak bisa begitu saja mengupgrade tipe belakangan. Beralih dari situs statis ke aplikasi berbasis server bukan sekadar mengubah pengaturan — hampir setara dengan build kedua, karena separuh asumsi rencana (bagaimana halaman dimuat, di mana data disimpan, apa arti "publikasikan") dibuat berdasarkan tipe lama. Jadi sampaikan ini saat perencanaan, bahkan jika belum yakin sepenuhnya: "ada kemungkinan saya butuh akun pengguna." Merencanakan aplikasi berbasis server namun hanya memakai bagian statisnya tidak merugikan apa pun. Baru menyadari kebutuhan itu belakangan berarti harus membangun ulang.
Di mana para kritikus benar
Tidak ada dari semua ini yang gratis, dan saya tidak akan berpura-pura demikian. Ruang kerja terisolasi per proses berarti file pengetahuan Anda disalin ulang setiap kali, tidak ada yang terhubung balik ke komputer Anda — baik untuk Anda jika laptop Anda mati di tengah proses build, tapi buruk untuk latensi, karena menyiapkan ruang kerja dan, untuk build berbasis framework, menjalankan instalasi dependensi sungguhan di dalam batas kontainer membutuhkan waktu nyata yang cukup lama. Batas kontainer itu ada karena build framework menjalankan `npm install` dan skrip build sembarang — kode yang bukan Anda tulis, dieksekusi dengan hak akses build — dan melakukan itu di host bersama tanpa isolasi hanya berjarak satu serangan dependency-confusion dari menyentuh data tenant lain. Opsi cepat-tapi-tidak-aman tersedia. Hanya saja itu bukan trade-off yang layak diambil.
Sama halnya dengan verifikasi. Build yang selesai tidak keluar dari pipeline saat generasi berhenti; ia keluar saat serangkaian verifikator independen berhenti menemukan hal yang layak diblokir:
- Tinjauan kode
- Keamanan
- Tautan dan SEO
- Aksesibilitas
- Kesesuaian
- Pengujian nyata di dalam browser
Itu bukan satu kali pemeriksaan, melainkan tandai-perbaiki-periksa ulang, berputar sampai tidak ada lagi yang perlu dikatakan siapa pun, karena satu putaran linter saja bisa melewatkan regresi yang justru disebabkan oleh perbaikannya sendiri. Memperbaiki tautan yang rusak namun tanpa sengaja merusak hierarki heading di halaman yang sama adalah contoh persis hal yang terlewat oleh pemeriksaan sekali jalan namun tertangkap oleh pemeriksaan ulang. Biaya nyata dari perulangan ini adalah sesekali build memakan waktu tambahan satu menit tepat di akhir tanpa alasan yang terlihat. Orang-orang menyadari satu menit itu. Mereka tidak menyadari enam agen yang baru saja selesai berdebat soal situs mereka. Itu keluhan yang wajar soal pengalaman pengguna — saya hanya rasa itu bukan alasan bagus untuk merilis tanpa perdebatan itu pernah terjadi sama sekali.
