Workflow: Sprint Driven Development

Kenapa delegasi asal prompt gampang berantakan

Belakangan ini saya sering mendelegasikan task besar ke AI — termasuk membangun satu project full-stack dari hulu ke hilir, murni buat melihat seberapa jauh kemampuannya.

Awalnya saya lakukan freestyle tanpa pola yang jelas. Hasilnya bisa ditebak:

Banyak issue baru bermunculan, waktu habis buat debugging
Harus mengulang prompt yang sama berkali-kali sebelum agent paham maksudnya
Context window cepat penuh — dan begitu penuh, output mulai ngawur dan berhalusinasi

Saya sempat coba berbagai plugin open-source, skills, dan tool orkestrasi yang ada di pasaran. Bisa jalan sih, tapi terasa overkill: boros token dan makan banyak context overhead untuk masalah yang sebenarnya nggak serumit itu.

Akhirnya saya merumuskan workflow pribadi yang lebih terstruktur untuk membangun project baru dari nol. Nggak tahu apakah ada istilah resminya, jadi sebut saja Sprint Driven Development.

Satu aturan baku: setiap project wajib punya folder docs/sprint

Implementasinya sangat simpel. Di setiap project, siapkan struktur direktori docs/sprint-<x>/:

docs/
└─ sprint-<x>/
   ├─ plan.md
   ├─ tasks.md
   ├─ final-report.md
   ├─ reports/
   ├─ rca/          (optional)
   └─ resources/    (optional)
AGENTS.md              (optional, repo root)

Ada dua aturan utama yang menggerakkan seluruh prosesnya:

Tiap sprint fokus ke satu milestone spesifik. Sprint 1: slicing UI. Sprint 2: arsitektur backend. Sprint 3: integrasi dan wiring data. Begitu seterusnya.
Di tiap sprint, agent wajib tunduk pada satu kontrak kerja: minimal menghasilkan plan, tasks, report per fase, dan final report.

Fungsi tiap file dalam sprint

plan.md — mulai dari plan mode; agent wajib merencanakan strategi sebelum menyentuh kode apa pun. Di sinilah human-in-the-loop paling krusial: kita challenge dan diskusikan rencananya sampai arah teknisnya benar-benar matang.
tasks.md — setelah plan disetujui, pecah pengerjaan jadi task-task kecil dan terisolasi per fase.
reports/ — agent membuat laporan ringkas per fase: apa yang sudah dibangun, temuan penting, dan cara menjalankannya. Dari sini kita bisa tentukan apakah mau verifikasi manual dulu atau langsung lanjut.
rca/ — kalau ada bug atau arsitektur yang jebol, minta agent memperbaikinya sekaligus mendokumentasikan root cause analysis-nya. Kalau masalah serupa muncul lagi di masa depan, tinggal rujuk file ini.
resources/ — dokumen referensi untuk sprint berikutnya. Contoh: sprint 2 mendokumentasikan api-contract.md, lalu agent di sprint 3 tinggal membacanya.
AGENTS.md — handoff note antar sprint. Backend selesai di sprint 2? Agent sprint 2 merangkum alur integrasi, urutan endpoint, dan edge cases sebagai panduan untuk agent di sprint 3.
final-report.md — rangkuman menyeluruh dari sprint yang baru lewat. File ini berfungsi ganda sebagai konteks ringkas untuk sprint berikutnya atau saat debugging di session yang sama.

Value nyata yang didapat

Semuanya tercatat rapi: roadmap, checkpoint task, laporan per fase, RCA, resources, hingga handoff note buat agent selanjutnya.

Dampaknya bukan cuma soal kerapian file. Pindah session jadi effortless. Begitu juga kalau mau lempar task — atau bahkan satu sprint utuh — ke agent atau model lain. Saya sudah menguji workflow ini lintas platform (CommandCode, Claude Code, OpenCode) serta gonta-ganti model di tengah pengerjaan. Semuanya langsung jalan melanjutkan titik terakhir tanpa perlu briefing ulang dari nol.

Satu tips praktis: susun plan dan tasks menggunakan reasoning model kelas atas (seperti Opus, GLM 5.2, atau DeepSeek V4 Pro). Begitu kedua file panduan itu solid, tahap implementasi kodenya sangat aman didelegasikan ke model yang lebih murah dan cepat.

Template-nya bisa kamu ambil di sini: docs/sprint template.