Selama bertahun-tahun, kecerdasan buatan mendampingi Anda di editor dan menebak apa yang akan muncul berikutnya. Anda menulis satu baris; ia menyarankan

Selama bertahun-tahun, kecerdasan buatan duduk di samping Anda di editor dan menebak apa yang akan muncul berikutnya. Anda menulis satu baris; ia menyarankan baris berikutnya. Anda masih memegang kendali atas arsitektur, debugging, dan sintaksis. Pengaturan tersebut telah berakhir.

Kita sedang bergerak menuju Intent-Driven Development. Anda berhenti mengetik loop dan kondisional. Sebaliknya, Anda mendeskripsikan hasil yang Anda butuhkan. Sebuah agen menyerap tujuan tersebut, merencanakan langkah-langkahnya, menulis kode, menjalankan pengujian, dan memperbaiki kesalahannya sendiri sebelum Anda melihat hasilnya. Keyboard bukan lagi alat utama. Berpikir jernihlah yang menjadi utamanya.

Akhir dari Coding Baris-demi-Baris

Alur kerja lama memaksa Anda untuk menerjemahkan setiap niat ke dalam bahasa spesifik yang dipahami oleh kompiler. Anda menyimpan persyaratan bisnis di kepala Anda, lalu memecahnya secara manual menjadi fungsi, import, penanganan kesalahan (error handling), dan kasus pengujian. Intent-Driven Development meruntuhkan lapisan penerjemahan tersebut.

Katakanlah Anda perlu mengintegrasikan webhook pembayaran. Sebelumnya, Anda akan menulis route handler, memproses payload, memvalidasi tanda tangan (signature), memperbarui database di dalam sebuah transaksi, dan mengantrekan email tanda terima. Sekarang Anda mendeskripsikan persyaratannya: “Validasi webhook Stripe yang masuk, catat event secara idempoten, dan picu alur tanda terima. Batalkan (roll back) jika penulisan database gagal.” Agen tersebut menulis handler, memilih strategi parsing, menyusun logika retry, dan menghasilkan pengujian. Peran Anda bergeser dari penulis menjadi sutradara.

Ini hanya berhasil karena agen tidak berhenti pada tahap pembuatan (generation). Ia memasuki sebuah loop.

Di Dalam Agent Loop

Pekerjaan inti bukan lagi mengetik secara manual atau debugging manual. Ini adalah siklus ketat antara pembuatan dan validasi. Agen menghasilkan kode, mengeksekusinya terhadap suite pengujian Anda, membaca output, dan memperbaiki kegagalan secara mandiri. Import yang hilang, ketidakcocokan tipe (type mismatch), assertion yang gagal — agen melihat stack trace, mengedit file, dan menjalankan ulang suite tersebut. Anda tidak berada dalam loop tersebut. Siklusnya berjalan secepat mesin.

Anda turun tangan ketika loop itu sendiri rusak. Mungkin agen tidak dapat menyelesaikan konflik antara dua dependensi, atau ia terus menghasilkan kode yang lolos unit test tetapi melanggar aturan bisnis tingkat tinggi. Batasan-batasan itulah di mana penilaian manusia masih sangat penting.

Pekerjaan Nyata Anda: Perancang Batasan dan Pemburu Edge-Case

Jika mesin yang menulis fungsi, apa yang tersisa untuk Anda? Dua hal, dan keduanya lebih sulit daripada mengetik sintaksis.

Pertama, Anda menulis batasan (constraints) yang menjaga agen tetap pada jalurnya. Agen memiliki pengetahuan yang luas tetapi tidak memahami lingkungan spesifik Anda. Anda harus memberitahunya: “Gunakan hanya API penagihan internal, jangan pernah mencatat (log) token kartu mentah, dan jaga latensi respons di bawah dua ratus milidetik.” Batasan-batasan tersebut bukanlah prompt sembarangan. Itu adalah spesifikasi yang menentukan keberhasilan atau kegagalan.

Kedua, Anda menangkap sepuluh persen kasus di mana agen gagal. Agen menangani jalur umum dengan baik. Mereka tersandung pada race condition yang halus, edge case logika bisnis yang ambigu, dan asumsi keamanan yang tertanam dalam data pelatihan mereka. Keunggulan Anda datang dari mendeteksi race condition antara webhook handler dan cron job refund, atau mengenali bahwa logika retry yang dihasilkan dapat menduplikasi tagihan. Mesin menyelesaikan masalah standar. Anda menangkap pengecualian (exception) yang berbahaya.

Ganti Code Review dengan Verification Harness

Ketika seorang agen dapat menghasilkan lima puluh file dalam semalam, Anda tidak dapat meninjaunya hanya dengan melihat sekilas diff untuk melihat apakah mereka "terlihat benar." Volumenya membuat pemeriksaan manual oleh manusia menjadi mustahil. Anda memerlukan harness yang menangkap kesalahan sebelum kode tersebut sampai kepada Anda.

Harness ini bertumpu pada tiga pilar.

Eksekusi yang tahan lama (Durable execution). Tugas agen sering kali berjalan lebih lama daripada timeout permintaan tunggal. Jika sebuah langkah gagal karena gangguan jaringan sementara, harness akan menjeda, mencoba lagi, dan melanjutkan tanpa merusak state. Pekerjaan tersebut tetap bertahan meskipun ada gangguan.

Output terstruktur (Structured outputs). Alih-alih berharap agen mengembalikan file konfigurasi yang terbentuk dengan baik, Anda menegakkan kontrak di awal. Alat seperti JSON Schema memvalidasi output secara instan. Jika agen melewatkan bidang yang diperlukan atau menggunakan tipe data yang salah, harness akan menolaknya sebelum kode tersebut menyentuh repositori Anda.

Pagar pengaman dinamis (Dynamic guardrails). Agen tidak boleh memiliki kebebasan penuh untuk membaca rahasia (secrets) atau menulis ke database produksi. Harness mengontrol izin secara dinamis, melakukan sandboxing pada agen sehingga ia hanya dapat menyentuh database pengujian yang ditentukan dan endpoint internal. Anda tidak meninjau setiap baris. Anda mengaudit pagar di sekeliling agen tersebut.

When the Code Works but the Product Fails

Here is the paradox. The harness catches bad code. It cannot catch bad intent.

If your specification says, “Send a welcome email to every new user,” the agent will write clean, tested code that sends that email. It will not know you meant, “Send the welcome email only if the user verified their address, opted into marketing, and signed up during business hours in their local timezone.” The code is technically flawless and commercially dangerous.

The real risk in Intent-Driven Development is ambiguous specification. Unclear intent produces software that solves the wrong problem with textbook elegance. This is why you must treat your specifications as real assets. Version them. Review them with stakeholders. Validate them against actual workflows before the agent starts building. A prompt scribbled into a chat box is not a specification. It is a liability.

Engineering Judgment Moves Upstream

Engineering judgment is not disappearing. It is migrating to a higher altitude.

You no longer spend mental energy on how to iterate a map or structure a class hierarchy. You spend it on what the system must do under failure, what data it must never expose, and which invariants must hold across distributed services. The craft of coding is becoming the craft of requirements.

This means your specifications need the same rigor you once applied to your code. Name your constraints precisely. Define the failure modes explicitly. State the business rules as clearly as you once declared your types. The agent will handle the implementation. You must guarantee that the implementation is worth building.

Move your quality bar from the pull request to the prompt. Build the harness first. Write the specification second. Then let the machine handle the syntax while you focus on whether the problem is defined correctly and the boundaries are drawn safely.

If you want to explore the ideas behind this shift in more depth, the original discussion on Intent-Driven Development is available here. For ongoing conversations around AI-native engineering, you can also join the GyaanSetu community.