Seri Wawancara AI 16: Kepiye Spec Coding sing Apik?

Spec Coding (koding spesifikasi) sing apik, intine iku ngowahi "pikiran sing burem" dadi "kontrak sing tepat, bisa diverifikasi, lan bisa dieksekusi". Iku ora mung nulis dokumen, nanging mbangun basa komunikasi sing ora ambigu antarane manungsa lan AI (utawa antarane manungsa). Ing ngisor iki aku bakal menehi gambaran spec sing apik saka papat dimensi: struktur isi spesifikasi, prinsip panulisan, alur kolaborasi karo AI, lan verifikasi kualitas.

1. Struktur Standar Dokumen Spesifikasi (Contone Modul Fungsi)

Bab	Isi Wajib	Conto
1. Tujuan lan Lingkup	Siji ukara nerangake apa sing ditindakake, lan jelasake apa sing ora ditindakake	"Ngleksanakake API registrasi pangguna, ora kalebu verifikasi email"
2. Kontrak Input/Output	Struktur data, jinis, kolom wajib/pilihan, nilai conto	`POST /register` body panjalukan `{email: string, password: string}`, tanggepan `201` utawa `400` ngemot kode kesalahan
3. Prilaku lan Logika	Aturan bisnis, kahanan wates, owah-owahan status	"Panjang sandi 8-20 karakter, paling ora ngemot siji angka; yen email wis ana, bali `409`"
4. Penanganan Kesalahan	Kabeh skenario luar biasa lan kode kesalahan/pesen sing cocog	"Gagal sambungan database → bali `503`, aja mbukak tumpukan"
5. Syarat Non-Fungsional	Kinerja (wektu tanggepan < 200ms), keamanan (query parameter), log, observabilitas	"Kabeh SQL kudu nggunakake precompiled; nyathet `email` nanging ora nyathet `password`"
6. Kasus Uji (Penting)	Paling ora 3 input khas + 2 input wates/aneh, menehi output sing dikarepake	Pirsani tabel ing ngisor
7. Ketergantungan lan Watesan	Pustaka apa sing digunakake, versi, variabel lingkungan	"Python 3.10+, FastAPI, variabel lingkungan `DB_URL`"

Conto Kasus Uji (kalebu ing spec)

Skenario	Input	Output sing Dikarepake
Registrasi normal	email: `a@b.com`, sandi: `Pass1234`	`201`, bali `user_id`
Sandi cendhak	sandi: `Ab1`	`400`, kode kesalahan `WEAK_PASSWORD`
Email wis ana	email sing padha	`409`, kode kesalahan `EMAIL_EXISTS`

Spec sing apik kudu nulis kasus uji luwih dhisik, amarga AI bisa langsung ngasilake tes unit adhedhasar kasus kasebut, lan sawise rampung bisa diverifikasi kanthi otomatis.

2. Prinsip Inti Nulis Spec (Varian SMART)

Prinsip	Panjelasan	Conto Salah
Tepat (Precise)	Gunakake angka spesifik, jinis, kondisi boolean, aja nggunakake "saben bisa", "biasane"	❌ "Sandi kudu cukup aman" → ✅ "Sandi paling ora 8 karakter, ngemot huruf kapital, huruf cilik, lan angka"
Bisa Diverifikasi (Verifiable)	Saben syarat bisa dipriksa liwat tes otomatis utawa pamriksan manual	❌ "Kode kudu elegan" → ✅ "Kompleksitas siklus fungsi ≤ 10, ora ana blok kode sing duplikat"
Ora Ambigu (Unambiguous)	Istilah sing padha digunakake kanthi konsisten ing saindhenging teks, yen perlu wenehi glosarium	❌ "Yen pangguna ora ana, bali kesalahan" → ✅ "Pangguna ora ana → bali `404` lan `{code: 'USER_NOT_FOUND'}`"
Lengkap (Complete)	Nutupi jalur bahagia, kabeh jalur luar biasa, lan syarat non-fungsional	❌ Mung nulis skenario sukses → ✅ Kalebu wektu entek database, kurang wewenang, lsp.
Atomik (Atomic)	Siji spec mung nggambarake siji titik fungsi sing bisa dikirim kanthi mandiri (supaya AI bisa ngrampungake siji-siji)	❌ Nggunakake siji spec kanggo nulis "kabeh sistem pembayaran" → ✅ Dipérang dadi "ngasilake slip pembayaran", "verifikasi callback", "mbalekake dhuwit"

3. Alur Spec Coding nalika Kolaborasi karo AI

Manungsa nulis spec (struktur ing ndhuwur, utamane nulis kasus uji lan tandha fungsi).
Wenehana spec kasebut marang AI bebarengan (aja nambahake syarat kanthi obrolan, supaya ora ana kontaminasi vibe).
AI ngasilake kode + tes unit (AI kudu ngetutake kasus uji ing spec kanggo ngasilake tes sing bisa dieksekusi).
Jalanake tes: Yen kabeh lulus, menyang langkah sabanjure; yen ora, ubah spec utawa langsung benerake kode (ing kene bisa mlebu siklus cilik, nanging kudu nyathet owah-owahan).
Pamriksan manungsa: Priksa manawa ana fungsi ing njaba spec (scope creep), priksa keamanan/kinerja.
Kukuhake: Kirim dokumen spec lan kode pungkasan menyang repositori bebarengan, minangka dokumen permanen.

Praktek Penting: Spec dadi kode — gunakake spec.md + test_spec.py, ing endi file tes langsung saka conto ing spec, supaya nalika ngowahi kode mung kudu mbukak tes kanggo verifikasi yen spec ora rusak.

4. Efek Spec sing Apik (Bisa Dadi Standar Penerimaan)

Determinasi: Spec sing padha kanggo AI sing beda (utawa wong sing beda) ngasilake implementasi sing padha.
Tesabilitas: Sawise nulis kode, 90% kebeneran bisa diverifikasi kanthi otomatis.
Maintainabilitas: Sawise setaun, sapa wae sing ndeleng spec bisa ngerti maksud desain asli.
Biaya Komunikasi Sing Cecak: Diskusi tim mung ngrembug spec, ora ngrembug baris kode tartamtu.
Keamanan/Kualitas Dibangun: Syarat keamanan (kayata query parameter) lan kahanan wates ditulis ing spec, AI kudu manut.

5. Conto Spec sing Apik (Versi Minimal)

# Spec: API Registrasi Pangguna

## Lingkup
- Nampa email, sandi
- Ora ngirim email verifikasi, ora mriksa keaslian email

## Kontrak
POST /register
Content-Type: application/json
Panjalukan: { "email": string, "password": string }
Tanggepan 201: { "user_id": string }
Tanggepan 400: { "code": "INVALID_PASSWORD" | "INVALID_EMAIL" }
Tanggepan 409: { "code": "EMAIL_ALREADY_EXISTS" }

## Prilaku
- email kudu cocog karo format dhasar RFC 5322 (a@b.c)
- sandi: dawane 8-20, paling ora ngemot siji angka lan siji huruf kapital
- Gunakake bcrypt kanggo enkripsi panyimpenan, biaya uyah 10
- Yen sadurunge nyimpen ing database nemokake email wis ana → 409

## Kasus Uji (input -> kode status + kolom tanggepan sing dikarepake)
| Input email | sandi | Dikarepake |
|------------|----------|------|
| test@x.com | Pass1234  | 201, user_id ana |
| test@x.com | pass      | 400, INVALID_PASSWORD |
| bad        | Pass1234  | 400, INVALID_EMAIL |
| (email sing wis ana) | Pass1234 | 409, EMAIL_ALREADY_EXISTS |

## Non-Fungsional
- SQL kudu nggunakake query parameter (nyegah injeksi)
- Log nyathet IP sumber registrasi, ora nyathet sandi
- Wektu tanggepan 95% panjalukan < 100ms (ora kalebu bcrypt)

## Ketergantungan
- Python 3.10+, FastAPI, bcrypt, asyncpg

Spec Coding sing apik = Nulis "keputusan desain" manungsa dadi "kasus uji + tandha jinis + watesan prilaku" kanggo mesin, supaya AI mung ngisi implementasi, dene manungsa tansah ngontrol kualitas lan arah.