Selama bertahun-tahun, kecerdasan buatan duduk di sisi anda di dalam penyunting dan meneka apa yang akan berlaku seterusnya. Anda menulis satu baris; ia mencadangkan

Selama bertahun-tahun, kecerdasan buatan duduk di sisi anda dalam editor dan meneka apa yang akan menyusul. Anda menulis satu baris; ia mencadangkan baris seterusnya. Anda masih mengawal seni bina, penyahpepijatan, dan sintaks. Aturan tersebut kini telah berakhir.

Kita sedang beralih ke arah Pembangunan Beracuankan Niat (Intent-Driven Development). Anda berhenti menaip gelung (loops) dan syarat (conditionals). Sebaliknya, anda menerangkan hasil yang anda perlukan. Seorang ejen menyerap matlamat tersebut, merancang langkah-langkahnya, menulis kod, menjalankan ujian, dan membaiki ralatnya sendiri sebelum anda melihat hasilnya. Papan kekunci bukan lagi alat utama. Pemikiran yang jelas adalah alat utamanya.

Berakhirnya Pengkodan Baris-demi-Baris

Aliran kerja lama memaksa anda menterjemah setiap niat ke dalam bahasa khusus yang difahami oleh pengkompil (compiler). Anda menyimpan keperluan perniagaan dalam minda, kemudian memecahkannya secara manual kepada fungsi, import, pengendalian ralat, dan kes ujian. Pembangunan Beracuankan Niat meruntuhkan lapisan terjemahan tersebut.

Katakan anda perlu menyepadukan webhook pembayaran. Sebelum ini, anda akan menulis pengendali laluan (route handler), menghurai (parse) muatan (payload), mengesahkan tandatangan, mengemas kini pangkalan data di dalam transaksi, dan menjadualkan e-mel resit. Sekarang anda menerangkan keperluan tersebut: “Sahkan webhook Stripe yang masuk, rekodkan acara secara idempotently, dan mulakan aliran resit. Batalkan (roll back) jika penulisan pangkalan data gagal.” Ejen tersebut menulis pengendali, memilih strategi penghuraian, menyusun logik cubaan semula (retry logic), dan menjana ujian. Peranan anda beralih daripada penulis kepada pengarah.

Ini hanya berjaya kerana ejen tersebut tidak berhenti pada peringkat penjanaan sahaja. Ia memasuki satu gelung.

Di Dalam Gelung Ejen

Kerja teras bukan lagi pengetikan manusia atau penyahpepijatan manual. Ia adalah kitaran yang rapat antara penjanaan dan pengesahan. Ejen menghasilkan kod, melaksanakannya terhadap set ujian anda, membaca output, dan membaiki kegagalan secara sendiri. Import yang hilang, ketidakpadanan jenis (type mismatch), pengesahan (assertion) yang gagal — ejen melihat jejak timbunan (stack trace), menyunting fail, dan menjalankan semula set ujian tersebut. Anda tidak berada dalam gelung itu. Kitaran tersebut mengikut rentak mesin.

Anda masuk campur apabila gelung itu sendiri terganggu. Mungkin ejen tidak dapat menyelesaikan konflik antara dua kebergantungan (dependencies), atau ia terus menjana kod yang melepasi ujian unit tetapi melanggar peraturan perniagaan tahap tinggi. Sempadan itulah di mana pertimbangan manusia masih penting.

Tugas Sebenar Anda: Pereka Kekangan dan Pemburu Kes Pinggiran (Edge-Case)

Jika mesin menulis fungsi, apa yang tinggal untuk anda? Dua perkara, dan ia lebih sukar daripada menaip sintaks.

Pertama, anda menulis kekangan yang memastikan ejen kekal di landasan yang betul. Ejen mempunyai pengetahuan yang luas tetapi tidak memahami persekitaran khusus anda. Anda mesti memberitahunya: “Gunakan hanya API pengebilan dalaman, jangan sekali-kali log token kad mentah, dan pastikan kependaman (latency) respons di bawah dua ratus milisaat.” Sempadan tersebut bukan sekadar arahan (prompt) yang boleh dibuang begitu sahaja. Ia adalah spesifikasi yang menentukan kejayaan atau kegagalan.

Kedua, anda menangkap sepuluh peratus kes di mana ejen gagal. Ejen mengendalikan laluan biasa dengan baik. Mereka tersandung pada keadaan perlumbaan (race conditions) yang halus, kes pinggiran (edge cases) logik perniagaan yang kabur, dan andaian keselamatan yang terbina dalam data latihan mereka. Kelebihan anda datang daripada mengesan persaingan antara pengendali webhook dan tugasan cron bayaran balik, atau menyedari bahawa logik cubaan semula yang dijana boleh menyebabkan caj berganda. Mesin menyelesaikan masalah standard. Anda menangkap pengecualian (exception) yang berbahaya.

Gantikan Semakan Kod dengan Perumah Pengesahan (Verification Harness)

Apabila ejen boleh menghasilkan lima puluh fail dalam satu malam, anda tidak boleh menyemaknya dengan hanya melihat perbezaan (diffs) secara sepintas lalu untuk melihat jika ia "kelihatan betul." Jumlah yang besar menjadikan pemeriksaan mata manusia mustahil. Anda memerlukan perumah (harness) yang menangkap ralat sebelum kod tersebut sampai kepada anda.

Perumah ini bersandar pada tiga tonggak.

Pelaksanaan tahan lama (Durable execution). Tugasan ejen sering berjalan lebih lama daripada masa tamat (timeout) permintaan tunggal. Jika satu langkah gagal disebabkan gangguan rangkaian sementara, perumah akan berhenti seketika, mencuba semula, dan menyambung semula tanpa merosakkan keadaan (state). Kerja tersebut dapat bertahan walaupun terdapat gangguan.

Output berstruktur (Structured outputs). Daripada berharap ejen mengembalikan fail konfigurasi yang tersusun rapi, anda menguatkuasakan kontrak tersebut dari awal. Alatan seperti JSON Schema mengesahkan output dengan serta-merta. Jika ejen meninggalkan medan yang diperlukan atau menggunakan jenis data yang salah, perumah akan menolaknya sebelum kod tersebut menyentuh repositori anda.

Pagar keselamatan dinamik (Dynamic guardrails). Ejen tidak sepatutnya mempunyai kebebasan mutlak untuk membaca rahsia atau menulis ke pangkalan data pengeluaran (production). Perumah mengawal kebenaran secara dinamik, mengasingkan (sandboxing) ejen supaya ia hanya boleh menyentuh pangkalan data ujian yang ditetapkan dan titik akhir (endpoints) dalaman. Anda tidak menyemak setiap baris. Anda sedang mengaudit pagar di sekeliling ejen 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.