Agentic Development Part 1: Overview

Series Spec-Driven Development sudah membahas bagaimana menulis spec yang baik, mengubahnya jadi kontrak API, menerjemahkannya jadi plan dan task, hingga memverifikasinya lewat test. Spec itu sendiri tidak berguna kalau tidak ada yang mengeksekusinya — dan di sinilah agent masuk. Tapi “agent” sering dipakai longgar untuk menyebut apa saja yang melibatkan AI dalam coding, padahal ada perbedaan fungsional yang nyata antara asisten yang menjawab pertanyaan dan agent yang benar-benar bertindak otonom di codebase. Artikel ini membuka series baru, Agentic Development, dengan mendefinisikan apa yang sebenarnya membuat sebuah sistem disebut “agentic”, bagaimana spec dari series sebelumnya menjadi prasyarat yang membuat otonomi ini aman dipakai, dan spektrum kontrol yang perlu dipahami sebelum mendelegasikan pekerjaan ke agent.

Dari Chat Assistant ke Agent

Sebelum membahas agent, ada baiknya melihat spektrum di mana agent berada. AI coding tool tidak muncul sebagai satu kategori tunggal — ia berevolusi melalui beberapa tahap kemampuan yang berbeda secara fungsional, bukan hanya berbeda secara pemasaran.

Autocomplete — bentuk paling awal, menyarankan baris atau blok kode berikutnya berdasarkan konteks yang sedang diketik. Tidak ada pemahaman tujuan, tidak ada eksekusi mandiri. Developer tetap menulis dan menjalankan setiap baris secara manual.

Chat assistant — developer bertanya, AI menjawab atau menghasilkan potongan kode sebagai respons satu putaran. Developer tetap yang mengambil kode tersebut, menempatkannya di file yang tepat, menjalankan, dan mengevaluasi hasilnya. AI tidak punya akses langsung untuk bertindak di luar percakapan.

Agent — diberi tujuan (bukan instruksi satu langkah), agent merencanakan langkah-langkah yang diperlukan, menggunakan tool (membaca/menulis file, menjalankan perintah, memanggil API) untuk mengeksekusi langkah tersebut, mengevaluasi hasilnya, dan mengulang siklus ini sampai tujuan tercapai atau perlu campur tangan manusia.

%%{init: {"flowchart": {"htmlLabels": false}} }%%
flowchart LR
    A[Autocomplete] -->|tambah konteks percakapan| B[Chat Assistant]
    B -->|tambah tool use + loop eksekusi| C[Agent]
    
    A -.-> A_loop("tanpa\neksekusi\nmandiri") -.-> A
    B -.-> B_loop("satu putaran,\ndeveloper yang eksekusi") -.-> B
    C -.-> C_loop("merencanakan, bertindak,\nmengevaluasi, mengulang") -.-> C

Perbedaan paling mendasar antara chat assistant dan agent bukan soal seberapa pintar modelnya, tapi soal siapa yang memegang loop eksekusi. Pada chat assistant, loop itu ada di tangan developer — developer yang memutuskan kapan menjalankan kode, kapan mengevaluasi hasil, dan kapan bertanya lagi. Pada agent, loop itu dipegang sistem itu sendiri — agent yang memutuskan langkah berikutnya berdasarkan hasil langkah sebelumnya, tanpa menunggu instruksi baru dari manusia di setiap langkah.

Ketiga kategori ini bukan hierarki “lebih baik” secara mutlak. Autocomplete tetap cocok untuk pekerjaan baris-demi-baris yang butuh kontrol penuh; chat assistant cocok untuk eksplorasi dan brainstorming; agent cocok untuk task yang scope-nya sudah jelas dan bisa diverifikasi otomatis. Memilih kategori yang tepat untuk konteks tertentu lebih penting daripada selalu memakai yang paling otonom.

Definisi Agent dalam Konteks Coding

Dengan posisi agent di spektrum di atas sudah jelas, definisi yang lebih presisi: agent coding adalah sistem yang diberi tujuan dalam bahasa natural atau spec terstruktur, lalu secara mandiri merencanakan, mengeksekusi menggunakan tool, dan mengevaluasi hasil pekerjaannya dalam sebuah loop, dengan keterlibatan manusia yang lebih jarang dibanding satu konfirmasi per langkah.

Tiga karakteristik ini selalu hadir bersama pada sistem yang layak disebut agentic:

Tool use — kemampuan bertindak di dunia nyata (atau setidaknya di luar percakapan), bukan hanya menghasilkan teks. Membaca dan menulis file, menjalankan perintah terminal, memanggil API eksternal, mencari di codebase. Tanpa tool use, sistem hanya bisa “berbicara tentang” solusi, tidak bisa benar-benar menerapkannya.

Planning dan reasoning — kemampuan memecah tujuan besar menjadi langkah-langkah konkret, dan menyesuaikan rencana ketika hasil langkah sebelumnya tidak sesuai ekspektasi. Ini yang membedakan agent dari script otomatis biasa: script mengikuti urutan langkah yang sudah ditentukan di awal, agent menyesuaikan urutan berdasarkan apa yang ditemukan di tengah jalan.

Loop eksekusi-evaluasi — siklus berulang bertindak, memeriksa hasil, dan memutuskan langkah berikutnya, tanpa menunggu instruksi baru di setiap iterasi. Loop inilah yang memungkinkan agent menangani task multi-langkah secara mandiri, alih-alih berhenti dan bertanya setelah setiap langkah kecil.

flowchart TD
    A[Terima Tujuan/Task] --> B[Plan: Rencanakan Langkah]
    B --> C[Act: Eksekusi via Tool]
    C --> D[Observe: Evaluasi Hasil]
    D --> E{Tujuan Tercapai?}
    E -- Belum --> F{Perlu Sesuaikan Plan?}
    F -- Ya --> B
    F -- Tidak --> C
    E -- Ya --> G[Selesai]
    E -- Gagal/Stuck --> H[Eskalasi ke Manusia]

Loop ini akan menjadi rujukan berulang di artikel-artikel berikutnya series ini — Part 2 membahas komponen yang membangun loop ini secara lebih rinci (planner, tool execution, memory), dan Part 7-10 membahas bagaimana mengontrolnya supaya tidak melenceng.

Kenapa Spec Jadi Prasyarat Penting di Sini

Ada hubungan langsung antara seberapa otonom sebuah agent dan seberapa mahal harga ambiguitas. Pada chat assistant, developer mengevaluasi setiap respons sebelum dipakai — ambiguitas di prompt paling buruk menghasilkan satu jawaban yang kurang tepat, yang langsung kelihatan dan bisa diperbaiki di putaran berikutnya. Pada agent yang bekerja dalam loop panjang tanpa supervisi ketat, ambiguitas yang sama bisa menjalar — keputusan yang salah di langkah ketiga jadi fondasi bagi keputusan keempat, kelima, dan seterusnya, sebelum manusia sempat melihat hasilnya.

Inilah kenapa seluruh series Spec-Driven Development sebelumnya bukan kebetulan ditulis lebih dulu. Spec yang jelas — intent, constraint, acceptance criteria, dan non-goals seperti dibahas di Part 2 series sebelumnya — berfungsi sebagai pagar yang membuat otonomi agent aman dipakai. Tanpa pagar ini, memberi agent otonomi lebih besar sama dengan memberi ruang lebih besar bagi kesalahan untuk berkembang biak tanpa terkontrol.

flowchart LR
    A[Otonomi Agent Rendah] -->|ambiguitas spec relatif aman| B[Dampak Kesalahan Kecil]
    C[Otonomi Agent Tinggi] -->|tanpa spec jelas| D[Ambiguitas Menjalar di Setiap Langkah Loop]
    C -->|dengan spec jelas sebagai pagar| E[Otonomi Tinggi Tetap Terkendali]

Hubungan ini juga menjelaskan kenapa urutan series ini disusun seperti sekarang: spec-driven development sebagai fondasi, baru kemudian agentic development. Mencoba memberi agent otonomi besar tanpa spec yang solid sebagai pagar adalah resep untuk masalah yang akan dibahas di bagian berikutnya.

Spektrum Otonomi Agent

Otonomi agent bukan kondisi biner — agent dengan otonomi penuh atau tidak otonom sama sekali. Dalam praktiknya, otonomi berada di spektrum, dan posisi yang tepat di spektrum ini bergantung pada konteks task, tingkat kepercayaan terhadap agent, dan seberapa kuat mekanisme verifikasi otomatis yang tersedia.

Level yang lebih tinggi tidak otomatis “lebih baik” — ini trade-off eksplisit antara kecepatan dan kontrol. Level 1-2 memberi kontrol maksimal tapi mengorbankan kecepatan karena setiap langkah menunggu approval manusia. Level 4-5 memberi kecepatan tinggi tapi menuntut infrastruktur verifikasi yang jauh lebih matang — test coverage kuat, definisi task yang jelas, dan guardrail otomatis — sebelum aman dipakai secara rutin.

Sebagian besar tim produksi saat ini beroperasi paling efektif di level 3-4, dengan level 5 diterapkan secara selektif untuk task yang sempit scope-nya dan sudah terverifikasi dengan baik. Naik level otonomi membutuhkan investasi nyata di test coverage dan kejelasan definisi task — bukan sekadar prompt yang lebih baik.

Risiko yang Muncul dengan Otonomi Lebih Besar

Semakin tinggi level otonomi, semakin besar pula beberapa kategori risiko yang perlu dipahami sebelum mendelegasikan pekerjaan ke agent.

Compounding error — kesalahan kecil di langkah awal loop menjadi fondasi bagi langkah-langkah berikutnya. Pada level otonomi rendah, kesalahan ini tertangkap cepat karena manusia mengevaluasi tiap langkah. Pada level otonomi tinggi, kesalahan bisa terakumulasi melalui banyak langkah sebelum akhirnya terlihat di hasil akhir — dan pada titik itu, melacak balik akar masalahnya jauh lebih sulit dibanding kalau tertangkap di langkah pertama.

Keputusan tak terduga di luar scope yang dimaksud — agent yang diberi tujuan luas dan otonomi besar bisa mengambil pendekatan yang secara teknis mencapai tujuan, tapi dengan cara yang tidak diantisipasi atau diinginkan. Ini berhubungan langsung dengan pentingnya non-goals yang dibahas di Part 2 series sebelumnya — tanpa batas eksplisit, agent dengan otonomi besar punya ruang gerak yang sangat luas untuk berimprovisasi.

Kesulitan rollback — semakin banyak langkah yang dieksekusi agent tanpa checkpoint, semakin sulit memisahkan mana perubahan yang valid dan mana yang perlu dibatalkan ketika ditemukan masalah. Perubahan yang saling bergantung satu sama lain membuat rollback parsial menjadi rumit, kadang lebih rumit daripada menulis ulang dari awal.

Verifikasi yang tertinggal di belakang kecepatan eksekusi — agent bisa menghasilkan perubahan jauh lebih cepat daripada kecepatan manusia mereview perubahan tersebut secara mendalam. Kalau kecepatan eksekusi tidak diimbangi dengan verifikasi otomatis yang memadai, otonomi yang tinggi justru menciptakan backlog review yang menumpuk, bukan benar-benar mempercepat pengiriman fitur yang sudah terverifikasi.

flowchart TD
    A[Otonomi Agent Meningkat] --> B[Kecepatan Eksekusi Meningkat]
    B --> C{Verifikasi Otomatis Memadai?}
    C -- Ya --> D[Kecepatan Pengiriman Riil Meningkat]
    C -- Tidak --> E[Backlog Review Menumpuk]
    E --> F[Compounding Error Tidak Tertangkap Dini]

Risiko-risiko ini bukan alasan untuk menghindari otonomi tinggi sama sekali, tapi alasan untuk membangun mekanisme verifikasi yang sepadan sebelum menaikkan level otonomi. Part 7 sampai 10 series ini akan membahas secara spesifik bagaimana mendesain task, context, dan guardrail yang membuat otonomi lebih besar tetap aman dipakai — bukan sekadar lebih cepat tapi berisiko.

Kapan Agentic Development Tepat Dipakai

Sama seperti spec-driven development tidak selalu sepadan untuk setiap pekerjaan, otonomi agent yang tinggi juga tidak selalu pilihan yang tepat. Beberapa sinyal yang menunjukkan konteks cocok untuk otonomi lebih besar:

• Task dengan scope yang jelas dan well-defined — kalau acceptance criteria dari spec (lihat Part 2 series sebelumnya) sudah cukup spesifik untuk diverifikasi otomatis, agent punya target yang jelas untuk dituju tanpa perlu menebak-nebak
• Codebase dengan test coverage yang kuat — test suite yang komprehensif berfungsi sebagai guardrail otomatis (dibahas lebih dalam di Part 5 series sebelumnya), membuat regresi langsung terdeteksi tanpa menunggu review manual
• Pola kerja yang repetitif dan sudah terbukti — migrasi rutin, refactoring dengan pola yang konsisten, atau implementasi fitur yang mirip dengan fitur sebelumnya yang sudah pernah dikerjakan dengan sukses
• Lingkungan eksekusi yang terisolasi — perubahan bisa diuji di sandbox atau branch terpisah sebelum menyentuh production, mengurangi konsekuensi dari kesalahan yang tidak tertangkap sebelum review

Sebaliknya, beberapa konteks lebih cocok dengan otonomi rendah atau bahkan tanpa agent sama sekali:

• Eksplorasi arsitektur di tahap awal — ketika requirement sendiri belum sepenuhnya jelas, otonomi besar pada agent justru mempercepat pembentukan keputusan arsitektur yang prematur sebelum cukup eksplorasi dilakukan
• Keputusan berisiko tinggi tanpa supervisi memadai — perubahan pada sistem pembayaran, keamanan inti, atau data sensitif yang konsekuensi kesalahannya berat, sebaiknya tetap melibatkan review manusia yang ketat terlepas dari seberapa matang infrastruktur verifikasi yang ada
• Codebase dengan test coverage minim — tanpa guardrail otomatis yang memadai, menaikkan otonomi agent di sini sama dengan menghilangkan jaring pengaman sebelum benar-benar diperlukan

Godaan paling umum adalah menaikkan level otonomi karena tergiur kecepatan, tanpa lebih dulu memastikan infrastruktur verifikasi sudah sepadan. Urutan yang benar adalah sebaliknya: bangun guardrail dan kejelasan task terlebih dahulu, baru naikkan otonomi secara bertahap sambil mengamati hasilnya.

Preview Series

Part 1 ini memberi gambaran besar tentang apa itu agent, bagaimana hubungannya dengan spec yang sudah dibahas di series sebelumnya, dan spektrum otonomi yang perlu dipahami sebelum mendelegasikan pekerjaan. Enam artikel berikutnya dalam series Agentic Development akan membedah tiap aspek ini lebih dalam:

• Part 2 — Anatomi coding agent: komponen planner, tool use, memory, dan loop verifikasi secara lebih rinci
• Part 3 — Mendesain task untuk agent: granularitas, definisi “selesai”, dan scope yang mencegah agent melenceng
• Part 4 — Context engineering: menyediakan konteks codebase yang tepat supaya hasil agent konsisten dengan project
• Part 5 — Verifikasi dan guardrail: mekanisme otomatis untuk mencegah agent “berhalusinasi” perubahan yang merusak
• Part 6 — Multi-agent workflow: pola orkestrasi banyak agent untuk task kompleks, dan kapan ini bermanfaat vs overkill
• Part 7 — Best practice gabungan spec-driven dan agentic development: sintesis seluruh dua series, checklist, dan anti-pattern umum

Setiap artikel akan terus merujuk balik ke konsep dari series Spec-Driven Development — keduanya dirancang sebagai satu kesatuan, bukan dua topik yang berdiri sendiri-sendiri.

Ringkasan

• Agent berbeda dari chat assistant dalam hal siapa yang memegang loop eksekusi — pada agent, sistem itu sendiri yang memutuskan langkah berikutnya berdasarkan hasil sebelumnya, bukan menunggu instruksi baru di setiap langkah
• Tiga karakteristik inti agent coding: tool use (bertindak di luar percakapan), planning/reasoning (memecah tujuan jadi langkah dan menyesuaikan rencana), dan loop eksekusi-evaluasi (siklus bertindak-memeriksa-memutuskan yang berulang)
• Semakin besar otonomi agent, semakin mahal harga ambiguitas — inilah kenapa spec yang jelas dari series sebelumnya menjadi pagar yang membuat otonomi besar aman dipakai
• Otonomi agent berada di spektrum lima level, dari saran per baris hingga eksekusi penuh tanpa supervisi langsung — level lebih tinggi bukan otomatis lebih baik, melainkan trade-off eksplisit antara kecepatan dan kontrol
• Risiko yang membesar seiring otonomi naik: compounding error, keputusan di luar scope yang dimaksud, kesulitan rollback, dan verifikasi yang tertinggal di belakang kecepatan eksekusi
• Agentic development paling tepat untuk task dengan scope jelas, codebase dengan test coverage kuat, dan pola kerja repetitif — kurang cocok untuk eksplorasi arsitektur awal atau keputusan berisiko tinggi tanpa supervisi memadai
• Urutan yang benar: bangun guardrail dan kejelasan task lebih dulu, baru naikkan level otonomi secara bertahap — bukan sebaliknya