Rangkuman dan Latihan

Poin-poin penting

• Spesifikasi datang lebih dulu dan itu singkat — satu paragraf yang menyebutkan batasan-batasan yang penting, termasuk batasan alur kerja yang tidak pernah tampak di aplikasi yang sedang berjalan.
• Rahasia (secret) tidak pernah menyentuh repositori; setiap proyek membaca kunci dari variabel lingkungan atau konfigurasi terenkripsi yang diatur di sebuah dashboard.
• Stack-nya dipilih agar lebih sedikit yang bisa salah — autentikasi terkelola, basis data terkelola, hosting statis, fungsi serverless.
• Hambatan diselesaikan dengan memberi AI bukti yang persis — pesan error yang literal, kode sesungguhnya, konfigurasi deployment — dan membatasi cakupan perbaikan secara sempit.
• Peluncuran berarti sebuah uji nyata terhadap kenyataan, bukan "sudah bisa dikompilasi": sebuah pembelian yang live, sebuah akun kedua, sebuah tautan mendalam di situs yang sudah di-deploy.

Coba sendiri

Pilih salah satu idemu sendiri dan tulis spesifikasi satu paragrafnya seperti yang dilakukan keempat studi kasus ini: sebutkan aksi inti, data apa yang boleh dilihat setiap pengguna, dan setidaknya satu batasan alur kerja (bagaimana konten dipublikasikan, siapa yang boleh melakukan apa). Lalu daftar komponen-komponen terkelola (managed) yang ingin kamu andalkan agar lebih sedikit kode kustom yang bisa rusak. Batasi menjadi satu paragraf ditambah daftar poin singkat — kalau melebihi itu, berarti kamu terlalu detail dalam menspesifikasikan (over-specifying).

Prompt bab ini

I want to build: [one-paragraph description of the app].
Before any code, help me tighten this into a buildable spec.
1. Restate the single core action a user performs.
2. List the data each user can see — and what they must NOT see.
3. Name the workflow constraints that won't show up in the UI
   (e.g. "pushing a file should publish it", "only their own data").
4. Recommend a stack that MINIMIZES custom code: managed auth,
   managed database, static or serverless hosting where possible.
5. Flag the one part most likely to go wrong, and how we'll test it
   against reality (a real purchase, a second account, a deep link).
Keep the spec to a paragraph plus bullets. Push back if it's too big.