Task Graph PRD untuk AI Coding: Cara Mengurutkan Pekerjaan agar Agent Tidak Membangun dari Tengah

AI coding agent sangat cepat ketika diberi tugas yang jelas. Masalahnya, banyak proyek dimulai dengan daftar seperti “buat login, dashboard, laporan, pembayaran.” Semua terdengar masuk akal, tetapi tidak memberi urutan. Agent lalu bebas memilih pekerjaan yang paling mudah dilihat, biasanya halaman antarmuka. Ketika aturan data, akses, atau integrasi belum selesai, layar yang sudah dibuat harus dirombak berkali-kali.

Task graph di Skematik mengubah daftar kerja menjadi hubungan yang terlihat. Setiap task dapat memiliki ketergantungan pada task lain, sehingga tim dan agent tahu fondasi apa yang harus selesai lebih dulu. Graph bukan diagram dekoratif. Ia adalah cara memeriksa apakah rencana punya jalur implementasi yang masuk akal dari setup sampai aplikasi dapat diuji utuh.

Mengapa urutan tugas menentukan kualitas hasil

Contoh sederhana: sebelum membuat halaman daftar pesanan, Anda perlu memutuskan bentuk pesanan, siapa yang boleh melihatnya, validasi saat membuatnya, dan bagaimana data disimpan. Jika halaman dibuat dulu, agent mungkin menciptakan struktur sementara yang nanti tidak cocok dengan database atau role pengguna. Setiap perubahan berikutnya menjadi lebih mahal karena UI, API, dan test harus diubah bersama.

Urutan yang sehat biasanya bergerak dari keputusan dan fondasi ke perilaku yang terlihat: setup dan test dasar, model data serta akses, aturan bisnis, endpoint atau service, antarmuka, lalu pengujian alur utuh. Tidak semua aplikasi memerlukan semua lapisan, tetapi prinsipnya tetap sama: jangan meminta hasil yang bergantung pada sesuatu yang belum didefinisikan.

Pecah task sampai satu hasil dapat diperiksa

• Satu task memiliki satu tujuan utama, bukan tiga fitur yang disambung dengan kata “dan”.
• Task menyebut area kode atau komponen yang relevan tanpa mengarang nama file yang belum diputuskan.
• Ada definition of done: perilaku atau test yang membuktikan hasilnya.
• Ketergantungan menunjuk task fondasi yang benar-benar dibutuhkan.
• Kasus tepi berisiko menjadi task nyata, bukan hanya catatan kecil di akhir PRD.

Sebagai contoh, “bangun sistem booking” terlalu besar. Pecah menjadi: desain data slot dan status booking, validasi ketersediaan saat membuat booking, API atau service untuk membuat booking, layar pemilihan slot, lalu smoke test dari memilih slot sampai konfirmasi muncul. Dengan pecahan ini, agent dapat mengerjakan dan Anda dapat mereview satu perilaku pada satu waktu.

Task yang kecil bukan berarti remeh. Task yang kecil berarti hasilnya dapat dipahami, diperiksa, dan dikembalikan tanpa membuat seluruh proyek ikut kabur.

Gunakan dependency untuk mencegah pekerjaan palsu

Dependency bukan daftar formalitas. Ia menjelaskan mengapa suatu task belum boleh dimulai. Task UI bergantung pada kontrak data bila tampilan perlu menampilkan data nyata. Task notifikasi bergantung pada event bisnis yang stabil. Task laporan bergantung pada data yang sudah dicatat dengan benar. Ketika dependency terlihat di graph, Anda dapat menghindari meminta agent “lanjutkan dashboard” sebelum sumber angkanya ada.

Hindari graph yang semuanya bergantung pada semuanya. Jika banyak task tidak bisa dimulai bersamaan, mungkin task fondasi terlalu besar atau batasnya belum jelas. Sebaliknya, bila graph tampak penuh task terpisah tanpa hubungan, cek apakah ada keputusan data atau keamanan yang sebenarnya dipakai bersama tetapi belum dijadikan fondasi.

Sertakan prompt agent dan test pada setiap langkah

Setiap task di PRD Skematik dirancang dengan prompt siap-tempel untuk agent. Prompt yang baik menyebut tujuan, konteks yang sudah ada, batas perubahan, dan hasil yang harus dibuktikan. Beri juga task awal untuk memasang test runner serta test rumus atau aturan inti. Pengujian bukan pekerjaan yang ditambahkan setelah aplikasi tampak selesai; ia bagian dari jalan menuju hasil yang dapat dipercaya.

Untuk task berisiko, tulis edge case sebagai pekerjaan eksplisit. Misalnya, dua pengguna mengirim booking pada slot sama, pembayaran gagal di tengah proses, atau koneksi putus saat menyimpan. Agent akan lebih mungkin membangun penanganannya bila kasus tersebut tampil sebagai task yang punya status dan hasil, bukan hanya paragraf panjang dalam overview.

Review graph sebelum mulai implementasi

1. Cari task pertama yang menghasilkan fondasi aplikasi, bukan sekadar setup kosong.
2. Periksa apakah setiap task punya satu hasil dan satu cara memeriksa selesai.
3. Pastikan tidak ada dependency yang melingkar atau merujuk task yang tidak ada.
4. Cek apakah alur inti dari pengguna pertama sampai hasil akhir dapat ditelusuri dalam graph.
5. Mulai dari task yang sudah tidak bergantung pada pekerjaan lain, lalu review perubahan kecil sebelum lanjut.