Dari Prompt ke Production: Anatomy of an AI-Augmented Development Sprint

Konteks

Artikel ini adalah walk-through nyata (dengan detail disamarkan) dari bagaimana kami mengerjakan sebuah feature dalam sprint. Tujuannya bukan untuk menunjukkan bahwa AI "ajaib" — tapi untuk memberikan gambaran jujur tentang seperti apa pekerjaan ini sebenarnya.

Feature: Dashboard analytics untuk platform SaaS — menampilkan revenue metrics, user growth, dan churn rate dengan filter date range dan export CSV.

Timeline yang diberikan: 2 hari.

Tim yang terlibat: 1 developer + AI agent.

Hari Pertama: Foundation

Pagi (2 jam) — Planning & Context Setup

Sebelum menulis kode, developer luangkan waktu untuk:

1. Breakdown requirements menjadi task-task spesifik:

- API endpoint untuk metrics dengan date range filtering

- Chart components (line chart untuk growth, bar untuk revenue)

- Filter UI dengan date picker

- Export CSV functionality

- Loading states dan error handling

2. Update context file dengan informasi relevan:

- Struktur database yang ada (tabel users, subscriptions, transactions)

- Existing API patterns yang digunakan di project ini

- Chart library yang sudah terpasang (Recharts)

3. Buat test scenarios untuk acceptance criteria:

- API mengembalikan data yang correct untuk date range yang diberikan

- Chart renders dengan data yang benar

- Export CSV mengandung semua kolom yang diharapkan

- Filter perubahan trigger re-fetch data

Siang (3 jam) — Backend

Dengan context yang sudah disiapkan, developer minta AI generate:

• Database queries yang dioptimasi (developer review untuk N+1 issue dan missing index)
• API endpoint dengan proper validation dan error handling
• TypeScript types untuk response data

Hasilnya: ~80% langsung bisa digunakan. ~20% butuh adjustment — terutama query optimization yang spesifik untuk dataset kami.

Developer focus di sini pada: review query plan, pastikan tidak ada data yang bisa bocor antar tenant, dan validasi bahwa edge cases (user baru tanpa data, date range yang terlalu lebar) di-handle dengan benar.

Sore (2 jam) — Frontend skeleton

AI generate komponen dasar: chart wrappers, filter UI, loading states. Developer review untuk: accessibility basics, konsistensi dengan design system, dan pastikan component structure yang benar untuk reusability.

Hari Kedua: Polish & Testing

Pagi (2 jam) — Test implementation

Dengan test scenarios yang sudah ditulis hari pertama, AI generate test code. Developer review untuk memastikan:

• Test benar-benar menguji hal yang penting
• Mocks tidak terlalu naive (contoh: mock database yang berperilaku berbeda dari real database)
• Edge cases yang paling penting ter-cover

Siang (2 jam) — CSV export & polish

CSV export diimplementasikan dengan AI. Satu bug ditemukan oleh test: karakter koma dalam nama field menyebabkan CSV malformed. AI memperbaiki dengan proper quoting. Ini contoh di mana TDD benar-benar bekerja — bug yang mungkin terlewat di manual testing tertangkap otomatis.

Polish UI: animasi loading, empty states, responsive layout. AI yang paling banyak pegang ini, developer review dari sisi UX feel.

Sore (1.5 jam) — Final review & deployment

• Code review manual untuk security (terutama: apakah ada cara user bisa akses data tenant lain?)
• Run full test suite: semua pass
• Deploy ke staging, manual testing oleh developer
• Deploy ke production

Sisa waktu: Dokumentasi, update project notes, dan — karena selesai lebih cepat dari 2 hari — mulai task berikutnya.

Refleksi Jujur

Yang bekerja dengan baik:

• AI sangat membantu untuk boilerplate dan common patterns
• Context file yang baik menghasilkan kode yang konsisten dengan codebase
• Test yang ditulis di awal benar-benar menangkap bug yang penting

Yang masih butuh manusia:

• Query optimization yang spesifik untuk data model kami
• Security review — AI flagged beberapa, tapi final human review masih penting
• "Does this feel right?" untuk UX decisions

Estimasi time savings: Task yang mungkin butuh 4-5 hari selesai dalam 2 hari. Tapi ini bukan berarti developer "menganggur" — waktu yang dihemat digunakan untuk review yang lebih dalam, planning sprint berikutnya, dan komunikasi dengan klien.

Ini adalah bentuk leverage, bukan replacement.