Pekerjaan yang Selesai dalam 30 Menit, Tapi Kenapa Proyek Masih Macet?

Pukul sebelas malam, kamu menatap layar terminal. Agent baru saja selesai menulis kode untuk sebuah fitur, sekaligus menjalankan semua pengujiannya. Saat notifikasi muncul, kamu melirik stempel waktunya — tiga puluh menit. Pekerjaan yang sama, minggu lalu timmu butuh waktu tiga hari penuh untuk menyelesaikannya.

Saat kamu baru mau mematikan komputer dan pulang, ponsel tiba-tiba berbunyi: di daftar kebutuhan yang belum diproses masih ada delapan tiket yang belum tersentuh, dan Pull Request kemarin pun belum ada yang meninjaunya. Kamu tiba-tiba sadar satu hal — yang jadi lebih cepat hanya bagian "menulis kode", setiap tahap lainnya masih sama seperti dulu.

Inilah persis masalah yang ingin disorot langsung oleh Boris Cherny, pencipta Claude Code, dan tim Anthropic, ketika mereka baru-baru ini merilis sebuah "playbook Software Development Lifecycle (SDLC) yang AI-native". YouTuber Rob Shocks membedah dokumen ini di kanalnya, dan intinya bisa diringkas dalam satu kalimat: Kode bukan lagi hambatannya — alur kerjamu-lah yang jadi hambatan.

"Dua Kali Lebih Cepat" Itu Nyata, Tapi Cuma Terjadi di Satu Tempat

Siklus hidup pengembangan perangkat lunak (SDLC) tradisional biasanya terlihat seperti ini: perencanaan, desain, pembuatan (build), pengujian, deployment, lalu pemeliharaan — setelah satu putaran selesai, kembali lagi ke titik awal untuk menyambut fitur berikutnya, bug berikutnya, atau rilis berikutnya.

Sebelum ada Agent, tahap "build" hampir selalu menjadi bagian yang paling memakan waktu sekaligus paling mahal. Setelah Agent hadir, tahap ini terpangkas drastis — menurut Rob Shocks, kecepatannya jadi dua kali lipat. Masalahnya, tidak satu pun dari tahap perencanaan, desain, pengujian, peninjauan, dan pemeliharaan ikut jadi lebih cepat. Justru pertanyaan inilah yang ingin dijawab dokumen Anthropic ini: kalau Agent sudah memampatkan tahap "build", bagaimana caranya mendesain ulang setiap tahap lainnya dengan Agent juga?

Dari "Rapat Mengumpulkan Kebutuhan" Menjadi "Berdebat dengan Agent Sampai Sepakat"

Mari lihat dulu tahap perencanaan. Cara tradisionalnya adalah duduk rapat, mengumpulkan kebutuhan, menulis PRD, mengadakan workshop, lalu menyelaraskan pandangan dengan para stakeholder putaran demi putaran.

Dalam alur kerja baru yang dijabarkan Anthropic, langkah pertamanya justru dibalik: biarkan Agent yang berulang kali mewawancaraimu terlebih dahulu, menanyakan dengan jelas fitur apa yang ingin kamu buat, bug apa yang ingin diperbaiki, atau seperti apa wujud produk secara keseluruhan, untuk membangun konteks yang lengkap. Rob Shocks menyebut dirinya menggunakan sebuah skill eksploratif bernama "Switch Dimension Discovery", dan juga menyinggung adanya "Realm" buatan Matt Pocock, atau "Requirements Discovery" bawaan Cursor — alatnya bisa berbeda-beda, tapi tujuannya sama: membiarkan Agent terus bertanya sampai benar-benar memahami apa yang kamu inginkan. Tugasmu adalah mencurahkan sebanyak mungkin pengalaman, pemahaman terhadap domain, dan berbagai konteks latar belakang ke dalam percakapan ini.

Agent kemudian merangkum dan menyaring titik-titik masalah (pain points) yang tergali dari percakapan tersebut, lalu menuliskannya menjadi sebuah file — intent.md. Keistimewaan file ini adalah: bisa dipahami manusia, sekaligus langsung bisa dieksekusi mesin (human-readable and machine-actionable).

Dalam SDLC tradisional, sebuah ide akan terlebih dahulu menjadi satu user story di daftar backlog, dihitung story point-nya, lalu melewati beberapa kali serah terima sebelum akhirnya ada orang yang benar-benar mengerjakannya. Sementara dalam dunia yang digambarkan Anthropic, siapa pun yang mengajukan sebuah isu — entah itu pelanggan yang melaporkan bug, product manager dengan ide fitur baru, atau engineer yang ingin mencatat ide perbaikan proses — bisa langsung brainstorming dengan Claude dan menuliskan hasilnya menjadi sebuah intent.md. Cara praktiknya sederhana: buat satu folder bernama `intent` di dalam proyek, dan setiap intent.md disimpan di dalamnya.

Setelah file ini selesai ditulis, pekerjaannya belum berakhir. Orang yang mengajukan niat ini (disebut Anthropic sebagai originator) perlu memeriksa kembali isi yang ditulis Agent, untuk memastikan pemahaman keduanya sudah selaras — originator tidak harus seorang ahli di dalam tim, siapa pun bisa berperan sebagai originator. Setelah itu, intent.md yang berserakan ini akan dikumpulkan menjadi semacam daftar backlog, bisa berupa file-file markdown, atau dirapikan ke dalam Notion atau Linear, lalu diurutkan prioritasnya oleh pemilik produk (product owner) — bahkan bisa juga diserahkan ke Agent untuk melakukan kategorisasi awal, misalnya memberi label front-end/back-end, ukuran tugas, jenis fitur, hingga tingkat prioritas.

intent.md Hanyalah Langkah Pertama: Sebuah Lini Produksi Bernama "Artifact Chain"

Begitu intent.md disetujui, alur kerja bergerak ke tahap berikutnya — spec (spesifikasi). Anthropic menyarankan, begitu intent dikonfirmasi, gunakan sebuah hook atau alur tetap untuk secara otomatis memicu pembuatan spec, dan memberikan contoh prompt: baca intent.md yang dilampirkan, hasilkan sebuah spesifikasi kebutuhan dan desain, terapkan skill yang tersedia untuk merencanakan sekaligus mematuhi pedoman merek, lalu tuliskan lengkap ke dalam spec.md. Tidak ada jawaban baku di sini — kamu bisa langsung memakai plan mode bawaan Cursor, Claude Code, atau Codex, atau membuat sendiri sebuah skill pembuat spec yang khas gaya timmu.

Langkah berikutnya adalah plan: engineer memasukkan intent dan spec bersama-sama ke Agent dalam plan mode, lalu menghasilkan sebuah plan.md. Anthropic menyarankan agar di tahap ini kamu justru menantang balik rencana tersebut — tanyakan padanya "perubahan mana yang berpotensi salah". Tujuannya adalah membuat plan.md selengkap mungkin, sampai-sampai jika diserahkan sendirian ke engineer lain, orang itu tidak perlu membuka lagi intent atau spec, dan tetap bisa langsung mengeksekusinya. Poin ini penting sekali, karena Rob Shocks khusus mengingatkan: seluruh alur ini tidak pernah dikerjakan oleh satu Agent yang sama dari awal sampai akhir — setiap tahap bisa ditangani Agent yang berbeda, bahkan thread percakapan (context window) yang berbeda pula. Karena itu, kamu harus memperlakukan intent, spec, dan plan ini sebagai "artifact" — dokumen serah terima resmi, sehingga Agent berikutnya bisa langsung memulai dari dokumen itu sendiri, tanpa membawa memori percakapan sebelumnya.

plan.md sendiri juga punya format baku: daftar file yang perlu diubah, urutan kerja atau daftar tugas, risiko dan batasan, serta "proof" — semacam standar keberhasilan yang bisa diverifikasi, bisa berupa pemeriksaan lint, bisa juga status lulus atau tidaknya pengujian. Anthropic juga menyarankan agar setiap versi intent, spec, dan plan, beserta siapa yang mengubahnya setiap kali, disimpan dengan baik — ini adalah bagian yang menurut banyak perusahaan paling sulit diterapkan, tapi justru paling krusial untuk melacak hasil (misalnya metrik DORA).

Masuk ke tahap build (pembuatan), Anthropic menyarankan penggunaan "auto mode" untuk mempercepat — tapi Rob Shocks mengingatkan hal ini sangat bergantung pada organisasimu: jalankan dulu selama beberapa waktu di lingkungan dengan izin yang ketat, baru longgarkan secara bertahap. Setelah kamu memahami alat, paket eksternal, dan sumber jaringan mana saja yang termasuk "cakupan penggunaan wajar" yang boleh diizinkan, baru kunci set izin tersebut ke dalam pengaturan Cursor atau Claude. Dengan begitu, Agent bisa bergerak lebih cepat tanpa harus selalu diawasi, sambil tetap menjaga "radius ledakan" (blast radius) tetap terkendali. Tim juga disarankan memakai worktree, agar beberapa Agent bisa mengerjakan tugas berbeda secara paralel; dan yang merangkai semua ini agar tetap berada di jalurnya adalah hook — misalnya secara otomatis memperbarui plan setelah build selesai, mencegah Agent menyentuh folder tertentu, atau melarangnya menginstal paket npm yang belum disetujui. Lingkungan eksekusi Agent yang lebih canggih bahkan bisa memecah plan menjadi beberapa tugas independen, lalu menyerahkannya ke beberapa sub-agent untuk dikerjakan secara paralel.

Sampai di tahap test (pengujian), prinsip Anthropic adalah: biarkan Agent menyelesaikan pengujian sebanyak mungkin sebelum engineer manusia atau QA turun tangan — menulis test, menjalankan lint, menjalankan build untuk memastikan tidak ada error; jika tim menggunakan alat seperti Playwright, Agent bahkan bisa benar-benar menjalankan layanannya, mengambil screenshot, merekam proses operasinya, baru kemudian menyerahkannya kembali. Anthropic juga menyarankan agar setiap kali ada perubahan skill atau pergantian model, jalankan satu putaran evals: kumpulkan dulu sekitar dua puluhan kasus nyata yang pernah ditangani beserta hasil yang diharapkan, lalu setiap kali ada model baru, skala baru, atau perubahan fundamental pada cara kerja, uji ulang dengan kumpulan kasus ini untuk memastikan seluruh SDLC tidak mengalami kemunduran.

Masuk ke tahap deploy (penerapan), Agent membuka sebuah Pull Request berdasarkan hasil peninjauan yang telah dilakukan manusia; Anthropic menyarankan agar sebuah instance Claude lain meninjau PR ini secara asinkron, sesuai kebijakan dan standar keamanan tim — jika instance itu tidak setuju, akan ada instance Claude lain lagi yang khusus menangani bolak-balik komentar peninjauan tersebut. Dari sisi tata kelola (governance), kamu bisa merancang hook agar deployment baru bisa dilepas setelah disetujui orang tertentu, atau memenuhi gerbang rilis (release gate) tertentu. Setelah PR disetujui, masih ada Agent lain yang menjalankan satu putaran pemeriksaan keamanan dan CI — bisa berupa pemeriksaan lint dan ambang batas yang menentukan, atau bisa juga Agent semacam Cursor Bugbot atau pemeriksaan keamanan Claude yang membantu menangkap kesalahan sekali lagi.

Terakhir adalah maintenance (pemeliharaan) — Rob Shocks terang-terangan menyebut ini sebagai bagian "paling ambisius" dari seluruh dokumen. Pemeliharaan tradisional bersifat reaktif: kamu sedang makan siang, sedang stand-by, atau mungkin menerima alarm server down pukul tiga pagi, sementara satu tiket terkubur begitu saja di tumpukan backlog dan terabaikan sepenuhnya. Sementara dalam SDLC AI-native, sebuah insiden keamanan, tiket baru, pesan di Slack, atau bahkan jadwal (schedule) itu sendiri, bisa membangunkan Claude sepenuhnya tanpa keterlibatan manusia, membuatnya mendiagnosis dan menangani masalah secara asinkron — dan Claude akan membuat sendiri sebuah intent.md berdasarkan log yang ditemukan atau pesan yang diterima. Dalam praktiknya, kamu mungkin akan menetapkan dulu beberapa metrik yang harus dijaga; begitu sebuah halaman down atau traffic API tiba-tiba melonjak, ini akan memicu Agent untuk mendiagnosis, menulis intent, dan mengajukan usulan solusi — semuanya terjadi sebelum kamu sempat menyentuh komputer.

Titik Balik: Yang Sebenarnya Diuji Bukan Sepintar Apa Agent-nya, Tapi Sebaik Apa Tata Kelolamu

Sampai di sini, sangat mudah membaca playbook ini sebagai "asal setiap tahap disisipi Agent, alur kerja otomatis jadi lebih cepat". Tapi kalau dirangkum, yang sebenarnya menopang artifact chain ini justru serangkaian hal yang tidak begitu menarik: menyimpan setiap versi intent, spec, dan plan serta mencatat jelas siapa yang mengubahnya; menjalankan dulu di lingkungan berizin ketat baru dilonggarkan bertahap; memakai hook untuk mencegah Agent menyentuh folder dan paket yang tidak seharusnya; menjalankan evaluasi regresi setiap kali ganti model; PR yang harus melalui peninjauan independen dan gerbang keamanan. Hilangkan salah satu saja dari bagian-bagian ini, "membiarkan Agent mengambil alih seluruh SDLC" akan dengan mudah berubah menjadi "membiarkan Agent menyebarkan kekacauan ke lebih banyak tahap dengan kecepatan yang lebih tinggi".

Rob Shocks sendiri juga mengakui, alur kerja yang ia ajarkan di kanalnya tidak sepenuhnya sama dengan dokumen Anthropic ini; di luar sana juga ada pendekatan-pendekatan dari aliran lain seperti Superpowers dan BMAD — tidak ada satu jawaban baku yang cocok untuk semua orang, yang penting tim memilih satu pendekatan dan berusaha tidak gonta-ganti setiap beberapa hari sekali.

Mulai Hari Ini, yang Harus Kamu Tulis Duluan Bukan Kode, Tapi Sebuah intent.md

Kalau hanya boleh membawa pulang satu perubahan kebiasaan dari seluruh alur kerja ini, kira-kira inilah jawabannya: sebelum mengerjakan sebuah fitur atau memperbaiki sebuah bug berikutnya, biarkan Agent berulang kali bertanya padamu terlebih dahulu, curahkan konteks di kepalamu, tuliskan menjadi sebuah intent.md, baru lanjutkan ke tahap berikutnya.

Inilah juga alasan mengapa alur kerja ini sangat menarik terkait satu hal lain yang kami pedulikan: begitu sebuah fitur harus melewati tujuh gerbang — intent, spec, plan, build, test, deploy, maintain — di setiap gerbangnya kemungkinan besar dijalankan oleh Agent yang berbeda, model yang berbeda pula, dan jumlah pemanggilannya jauh lebih banyak dibanding "satu Agent yang menulis dari awal sampai akhir". Setelah alur kerja distandarkan, penggunaannya jadi lebih bisa diprediksi, tapi juga jadi lebih tersebar — dan inilah persis yang ingin dibantu selesaikan oleh AI Token King untuk tim: tidak peduli berapa banyak Agent yang tersambung di baliknya atau berapa model yang bergantian dipakai, setiap kali panggilan menggunakan model apa, menghabiskan berapa Token, dan sungguh-sungguh memotong biaya berapa — semuanya bisa dicek sekaligus.

Pertanyaan yang Sering Diajukan (FAQ)

T1: Sebenarnya apa itu intent.md? Menurut penuturan Rob Shocks tentang praktik tim Anthropic, intent.md adalah dokumen niat yang dirangkum dari sesi brainstorming antara "originator (orang yang mengajukan isu)" dengan Claude, dengan ciri khas "bisa dipahami manusia, sekaligus langsung bisa dieksekusi mesin". Dokumen ini menggantikan user story yang berserakan di backlog tradisional, dan menjadi titik awal bagi artifact-artifact berikutnya seperti spec dan plan.

T2: Siapa yang boleh menulis intent.md? Siapa saja. Bisa pelanggan yang melaporkan bug, product manager yang ingin menambah fitur, atau engineer yang ingin mencatat ide perbaikan proses — tidak perlu menjadi ahli di dalam tim. Setelah selesai ditulis, Anthropic menyarankan agar orang yang mengajukan isu tersebut memeriksa kembali isi yang dirangkum Agent, untuk memastikan pemahaman kedua belah pihak sudah selaras.

T3: Apa hubungan intent.md dengan spec.md dan plan.md? Ketiganya membentuk apa yang disebut Rob Shocks sebagai "artifact chain (rantai artifact)": intent.md terlebih dahulu menetapkan masalah dan konteks yang ingin diselesaikan; begitu intent disetujui, sebuah hook atau alur tetap akan memicu pembuatan spec.md (spesifikasi kebutuhan dan desain); kemudian engineer memasukkan intent dan spec bersama-sama ke Agent dalam plan mode, menghasilkan plan.md (file yang perlu diubah, urutan kerja, risiko, dan standar verifikasi secara konkret).

T4: Apakah ini berarti seluruh alur kerja bisa berjalan tanpa pengawasan manusia sama sekali? Tidak. Transkrip sumbernya berulang kali menekankan bahwa manusia tetap harus hadir di titik-titik peninjauan penting: originator harus memverifikasi intent, engineer harus mengonfirmasi plan sebelum dieksekusi, dan sebelum deployment tetap butuh persetujuan manusia atau harus memenuhi gerbang rilis tertentu. Yang dibahas Anthropic adalah mengurangi waktu manusia yang terpakai di setiap tahap, bukan menghilangkan sepenuhnya penilaian manusia.

T5: Apakah alur kerja ini harus ditiru persis sama seperti versi Anthropic? Tidak perlu. Rob Shocks sendiri mengatakan di videonya bahwa alur kerja yang benar-benar ia ajarkan tidak sepenuhnya sama dengan dokumen Anthropic ini, dan di luar sana juga ada aliran lain seperti Superpowers dan BMAD. Yang penting tim memilih satu pendekatan dan sebisa mungkin menstandarkannya, bukan mengganti gaya bermain di setiap proyek.

Pernyataan Sumber Data

Artikel ini disusun berdasarkan video berjudul Claude Codes New INTENT.MD, What is It? yang dipublikasikan kanal YouTube Rob Shocks pada September 2026. Isinya merupakan pembahasan dan penuturan lisan dari kanal tersebut terhadap "playbook Software Development Lifecycle AI-native" yang dirilis Anthropic (tim tempat Boris Cherny, pencipta Claude Code, bernaung), bukan kutipan kata demi kata dari dokumen resmi Anthropic yang ditelusuri langsung oleh penulis artikel ini; langkah-langkah alur kerja dan nama-nama alat di dalam artikel ini (seperti Switch Dimension Discovery, Realm, Cursor Requirements Discovery) secara jujur mencerminkan isi video tersebut, bukan terjemahan kata demi kata, melainkan rangkuman yang telah disusun ulang dan dijabarkan kembali. Jika timmu ingin secara resmi mengadopsi alur kerja serupa, disarankan untuk menelusuri sendiri dokumen resmi yang dirilis Anthropic guna memverifikasi detailnya.

Bacaan Lanjutan

• Apa Itu AGENTS.md? Sebuah README untuk AI, Kenapa Codex, Claude Code, dan Copilot Semuanya Memakainya

• Apa Itu Agent Skills? Claude Mengajari AI Bekerja Lewat Folder, Kini Jadi Standar Terbuka yang Diikuti OpenAI dan Google

• Bagaimana Membuat AI Agent Skill yang Andal? 5 Poin Praktik dan Kesalahan Umum

• Claude Code Terlalu Boros Token? 3 Cara Menghemat Biaya Lebih dari 50%

Ambil Tindakan Sekarang

Ketika sebuah fitur harus melewati tujuh gerbang — intent, spec, plan, build, test, deploy, maintain — di baliknya bisa jadi ada beberapa Agent dan beberapa model yang bergantian bekerja, dan tagihan Token pun ikut tersebar di setiap pemanggilan. Coba AI Token King gratis, buka sekaligus setiap Token yang terpakai, model yang dipakai, dan biaya yang sungguh-sungguh terpotong di tiap panggilan — berapa pun banyaknya Agent dan model yang tersambung dalam SDLC AI-native-mu, kamu tetap bisa memahami ke mana uangmu mengalir.