Hentikan Prompt Manual Agen Kode. Ciptakan Perulangan Otomatis yang Memicunya.

Anda seharusnya tidak lagi memberi perintah kepada agen pengodean. Anda seharusnya mendesain loop yang memberi perintah kepada agen Anda. Ini terdengar seperti kalimat biasa, tetapi ini menunjuk pada perubahan terbesar dalam cara insinyur yang baik bekerja dengan AI saat ini. Orang-orang yang benar-benar mendapatkan keuntungan dari agen pengodean AI berhenti memperlakukan agen sebagai mitra obrolan. Mereka memperlakukannya sebagai pekerja dalam sebuah loop yang mereka bangun.

TL;DR

Loop agen pengodean adalah struktur kontrol yang menjalankan agen berulang kali: membuat perubahan, menjalankannya, memeriksa hasilnya terhadap sinyal keras, memberi umpan balik kegagalan, mengulang hingga pemeriksaan berhasil atau batas tercapai. Agen bukanlah bagian yang sulit. Gerbang verifikasi lah yang sulit. Loop dengan gerbang yang kabur ("terlihat baik-baik saja, coba lagi") akan melenceng dan berhalusinasi "selesai". Loop dengan gerbang deterministik (tes yang gagal, ketidaksesuaian skema, kontrak yang rusak) akan konvergen. Untuk pekerjaan API dan backend, rangkaian pengujian otomatis dan pemeriksaan kontrak Anda adalah gerbang tersebut, itulah sebabnya pengujian API berada di pusat alur kerja berbasis agen, bukan dipasang di akhir.

Dari memberi perintah ke mendesain loop

Kebanyakan orang bertemu pengodean AI melalui kotak obrolan. Anda mengetik permintaan, membaca jawaban, menyalin yang berhasil, dan mengetik lagi. Itu adalah pemberian perintah. Ini bagus untuk fungsi sekali pakai atau penjelasan singkat. Ini akan runtuh saat tugas membutuhkan lebih dari satu putaran umpan balik untuk diselesaikan dengan benar, yang merupakan sebagian besar pekerjaan nyata.

Berikut adalah masalah dengan pemberian perintah secara manual. Anda adalah loopnya. Anda membaca output, Anda menemukan bug, Anda memutuskan apa yang akan dikatakan selanjutnya, Anda menempelkan kesalahan kembali. Setiap iterasi menunggu manusia. Agen dapat menghasilkan kode dalam hitungan detik, lalu menganggur selama beberapa menit sementara Anda beralih konteks, menggulir, dan mengetik. Anda menjadi bagian lambat dari sistem yang cepat.

Mendesain loop membalikkan itu. Alih-alih menjadi hal yang membaca output dan memutuskan perintah berikutnya, Anda membangun kerangka kerja yang melakukannya secara otomatis. Agen menulis kode. Sebuah skrip menjalankannya. Hasilnya ditangkap. Jika gagal, kegagalan itu langsung kembali ke agen sebagai perintah berikutnya. Tidak ada manusia dalam loop internal. Anda hanya campur tangan di tepi: untuk menetapkan tugas, untuk menyetujui hasilnya, untuk menghentikan jalannya jika terjadi kesalahan. Tulisan Anthropic sendiri tentang membangun agen yang efektif membuat poin yang sama dengan kata-kata yang berbeda. Kemenangan datang dari lingkungan yang Anda sambungkan di sekitar model, bukan dari satu perintah yang lebih cerdas.

Pergeseran model mental kecil tapi total. Berhenti bertanya "apa yang harus saya katakan pada agen?" Mulailah bertanya "loop seperti apa yang akan membuat agen mengatakan pada dirinya sendiri?"

Apa sebenarnya loop agen pengodean itu

Singkirkan gembar-gembornya dan loop agen pengodean memiliki lima bagian. Hilang satu dan loop tidak akan pernah berakhir atau berakhir salah.

1. Spesifikasi tugas. Deskripsi tertulis yang jelas tentang seperti apa hasil yang "selesai". Bukan "buat agar berfungsi," tapi "endpoint POST /orders mengembalikan 201 dengan pesanan yang dibuat, memvalidasi body terhadap skema, dan menolak bidang yang hilang dengan 422."
2. Agen. Model ditambah alatnya: membaca file, menulis file, menjalankan perintah shell. Ini adalah bagian yang paling difokuskan semua orang dan bagian yang paling sedikit Anda kendalikan.
3. Langkah tindakan. Agen membuat perubahan, lalu sesuatu benar-benar menjalankannya. Tes, build, pemeriksaan tipe, permintaan terhadap endpoint langsung.
4. Gerbang verifikasi. Pemeriksaan deterministik yang mengembalikan lulus atau gagal dengan alasan yang konkret. Ini adalah kemudi. Kita akan menghabiskan sebagian besar postingan ini di sini.
5. Kondisi penghentian. Kapan loop berhenti? Gerbang lolos, atau Anda mencapai jumlah iterasi maksimum, atau Anda melebihi anggaran biaya. Loop tanpa jalan keluar adalah pelarian, bukan alur kerja.

Dalam pseudocode, seluruh pola cocok dalam beberapa baris:

task = load_spec("orders-endpoint.md")
for attempt in range(MAX_ITERATIONS):
    agent.run(task, feedback=last_result)   # hasilkan
    result = run_verification()             # jalankan + periksa gerbang
    if result.passed:
        break                               # hentikan: berhasil
    last_result = result.failures           # berikan umpan balik kegagalan
else:
    escalate_to_human(last_result)          # hentikan: menyerah

Loop itu adalah keseluruhan idenya. Agen menghasilkan, gerbang menilai, kegagalan menjadi prompt berikutnya, dan semuanya berjalan hingga hijau atau habis upaya. Varian yang dibagikan orang secara online sebagai teknik "Ralph" adalah ini dengan `MAX_ITERATIONS` yang disetel tinggi dan spesifikasi yang ditulis ketat. Jika Anda telah membaca uraian kami tentang arsitektur kerangka kerja agen, ini adalah kerangka kerja dalam bentuk jujurnya yang terkecil.

Mengapa prompting sekali jalan menemui jalan buntu

Satu prompt mengasumsikan model mengerjakannya dengan benar pertama kali, atau bahwa Anda akan mengetahui apa yang salah. Kedua asumsi tersebut gagal pada skala.

Model kuat dalam menghasilkan kode yang masuk akal dan lemah dalam mengetahui apakah kode itu benar. Mereka akan menulis endpoint yang terlihat benar, mengkompilasi, dan diam-diam mengembalikan kode status yang salah pada kasus ekstrem. Dalam obrolan, Anda mungkin tidak menyadarinya sampai produksi. Model tidak memiliki umpan balik yang memberitahunya bahwa kasus ekstrem rusak, jadi ia dengan yakin melaporkan keberhasilan. Kesenjangan antara "terlihat selesai" dan "sudah selesai" inilah persis di mana loop sangat berguna.

Sebuah loop menutup celah dengan menolak menerima pendapat model sendiri tentang pekerjaannya. Agen tidak bisa mengatakan itu sudah selesai. Gerbang yang mengatakannya. Jalankan tes; jika merah, tugas belum selesai, titik, dan output merah adalah hal berikutnya yang dibaca agen. Kepercayaan diri model berhenti penting. Hanya sinyal yang penting.

Ada juga sudut pandang produktivitas. Hand-prompting membatasi throughput Anda pada satu agen yang sedang Anda awasi. Loop memungkinkan Anda menjalankan beberapa sekaligus, masing-masing mengerjakan tugasnya sendiri terhadap gerbangnya sendiri, karena tidak ada yang membutuhkan Anda dalam loop internal. Itu adalah lompatan yang dibahas dalam tulisan kami tentang alur kerja agen dinamis dan paralel: setelah loop diotomatisasi, Anda melakukan skala dengan menambahkan loop, bukan dengan mengetik lebih cepat.

Bagian yang kurang dibangun semua orang: gerbang verifikasi

Inilah kebenaran yang tidak nyaman. Sebagian besar alur kerja agen yang gagal tidak gagal karena model terlalu lemah. Mereka gagal karena sinyal umpan balik terlalu lunak.

Pikirkan apa yang dilakukan gerbang. Setiap iterasi, ia memberi tahu agen salah satu dari dua hal: Anda lulus, berhenti; atau Anda gagal, inilah alasan pastinya. Kualitas "inilah alasan pastinya" menentukan apakah iterasi berikutnya meningkat atau menyimpang. Beri agen jejak tumpukan yang tepat yang menunjuk pada baris 42 dan pernyataan yang meledak, dan ia akan menambal hal yang benar. Beri ia "ada yang tidak beres, mohon tinjau," dan ia menebak, seringkali membuat kode menjadi lebih buruk sambil terdengar lebih percaya diri.

Gerbang deterministik konvergen. Gerbang fuzzy menyimpang. Itu intinya.

Apa yang membuat gerbang yang baik?

• Itu biner dan dapat direproduksi. Input yang sama, keputusan yang sama, setiap saat. Tidak ada "tergantung bagaimana perasaan model hari ini."
• Ini gagal dengan keras dengan alasan. Nama pengujian, perbedaan yang diharapkan vs. aktual, nomor baris, kode kesalahan. Alasannya adalah prompt berikutnya, jadi harus spesifik.
• Agen tidak dapat mengeditnya secara diam-diam. Jika agen dapat mengubah pengujian agar berhasil, gerbang itu hanyalah sandiwara. Lindungi gerbangnya. Perlakukan itu sebagai spesifikasi, bukan sebagai kode yang dimiliki agen.
• Ini berjalan cukup cepat untuk diulang. Gerbang yang memakan waktu 20 menit membatasi kecepatan iterasi Anda. Loop yang ketat membutuhkan pemeriksaan cepat.

Gerbang yang baik sudah ada di setiap basis kode yang matang. Uji unit. Pemeriksa tipe. Linter. Compiler. Validator skema. Pengujian kontrak. Ini adalah oracle deterministik. Mereka dibangun untuk memberi tahu manusia "ini salah dan inilah alasannya," yang persis merupakan sinyal yang dibutuhkan loop agen. Anda tidak perlu membuat gerbang. Anda hanya perlu mengarahkan loop ke gerbang yang sudah Anda percaya, dan menulis yang baru di mana cakupannya tipis. Jika Anda belum pernah memformalkan lapisan itu, panduan kami tentang apa itu pengujian otomatis adalah dasar yang baik sebelum Anda menghubungkannya ke loop.

Untuk pekerjaan API dan backend, rangkaian pengujian Anda adalah loopnya

Di sinilah ide abstrak menjadi konkret bagi siapa pun yang membangun layanan. Ketika seorang agen menulis titik akhir API, apa kebenaran mutlak yang mengatakan itu berfungsi? Bukan ringkasan model. Perilaku aktual titik akhir yang diuji: kode status yang benar, badan respons yang cocok dengan skema, otentikasi yang diberlakukan, input yang buruk ditolak, kontrak yang dihormati.

Setiap dari hal tersebut dapat diperiksa, secara otomatis, dengan hasil yang deterministik. Yang berarti rangkaian pengujian API Anda sudah berbentuk persis seperti gerbang verifikasi yang dibutuhkan loop agen. Anda membangun gerbang itu selama ini; Anda hanya menyebutnya pengujian.

Loop konkret untuk pekerjaan endpoint terlihat seperti ini:

1. Agen membaca spesifikasi tugas dan definisi OpenAPI, lalu menulis atau mengedit endpoint.
2. Kerangka kerja menjalankan rangkaian pengujian API terhadap layanan yang berjalan: pernyataan status, validasi skema JSON pada setiap respons, pemeriksaan kontrak terhadap spesifikasi.
3. Kegagalan kembali terstruktur. "Diharapkan 422 pada `customer_id` yang hilang, mendapatkan 500." "Bidang respons `total` adalah string, skema mengatakan angka." "Endpoint `/orders/{id}` dalam spesifikasi tidak memiliki implementasi."
4. Kegagalan terstruktur itu menjadi perintah agen berikutnya. Ini menambal celah tertentu.
5. Ulangi hingga rangkaian berwarna hijau, lalu serahkan kepada manusia untuk ditinjau.

Kuncinya adalah umpan balik pada langkah 3 tepat dan dihasilkan oleh mesin, bukan sekadar perasaan. Itulah yang membuat loop konvergen alih-alih menyimpang. Pengujian yang berpusat pada skema dan kontrak lebih penting dari sebelumnya di sini, karena spesifikasi OpenAPI menjadi sumber kebenaran bersama yang dibaca oleh agen dan gerbang. Pergeseran antara kode dan spesifikasi berhenti menjadi masalah dokumentasi yang lambat dan menjadi gerbang merah instan.

Inilah peran Apidog dalam alur kerja agen. Ini adalah platform API all-in-one tempat desain, skema, server mock, dan pengujian otomatis berada di satu tempat, yang berarti gerbang dan spesifikasi tetap sinkron secara default. Anda mengarahkan loop ke skenario pengujian Apidog, agen mendapatkan lulus/gagal yang divalidasi skema pada setiap iterasi, dan server mock berdiri untuk dependensi yang belum dibangun sehingga agen dapat bekerja terhadap target yang stabil. Tim yang sudah menjalankan pola ini menghubungkan akses alat agen melalui sesuatu seperti debugger agen AI Apidog sehingga agen dapat mencapai dan memeriksa endpoint dengan cara yang sama seperti penguji manusia. Unduh Apidog jika Anda ingin membangun gerbang secara visual alih-alih membuat runner pengujian secara manual.

Bangun loop API koreksi diri minimal hari ini

Anda tidak membutuhkan kerangka kerja untuk memulai. Anda membutuhkan spesifikasi, perintah pengujian, dan beberapa baris penghubung. Berikut adalah versi terkecil yang melakukan pekerjaan nyata.

Langkah 1: tulis spesifikasi sebagai niat gerbang. Letakkan kontrak dalam file OpenAPI dan perilaku dalam kasus pengujian. Agen membaca keduanya. Ini berfungsi ganda sebagai dokumentasi, jadi ini bukan pekerjaan yang sia-sia.

Langkah 2: pilih perintah pengujian yang keluar tidak nol jika gagal. Apa pun berfungsi selama kode keluar jujur. Sebuah suite pytest, sebuah Newman run, sebuah skenario pengujian Apidog CLI. Loop hanya peduli tentang lulus/gagal ditambah output yang ditangkap.

# gerbang, sebagai satu perintah
apidog run ./tests/orders-suite --reporter json > result.json

Langkah 3: sambungkan loop. Jalankan agen, jalankan gerbang, cabang berdasarkan hasil.

MAX_ITERATIONS = 8
feedback = None
for attempt in range(MAX_ITERATIONS):
    run_agent(task="implement orders API per spec", feedback=feedback)
    gate = subprocess.run(["apidog", "run", "./tests/orders-suite",
                           "--reporter", "json"], capture_output=True)
    if gate.returncode == 0:
        print(f"green on attempt {attempt + 1}")
        break
    feedback = parse_failures(gate.stdout)   # prompt berikutnya menulis sendiri
else:
    print("8 percobaan, masih merah; eskalasi ke manusia")

Langkah 4: lindungi gerbang. Jauhkan file pengujian dan spesifikasi dari kumpulan file yang diizinkan untuk diedit oleh agen. Jika ia dapat menulis ulang pengujian agar lulus, Anda telah membangun mesin untuk memalsukan kemajuan.

Langkah 5: batasi biaya. Batasi iterasi. Batasi pengeluaran. Catat setiap percobaan sehingga Anda dapat melihat apakah loop konvergen atau bergejolak. Jika Anda mengamati pengeluaran token, catatan kami tentang mengurangi biaya token agen berlaku langsung, karena loop yang tidak konvergen menghabiskan anggaran dengan cepat.

Itu adalah loop koreksi diri yang berfungsi. Agen menulis, suite menilai, kegagalan mengarahkan, dan Anda mendapatkan endpoint hijau atau eskalasi yang bersih alih-alih kebohongan yang percaya diri.

Mendesain loop yang baik: kesalahan yang menggigit

Beberapa pola memisahkan loop yang berhasil dari loop yang diam-diam membuang-buang uang.

• Membiarkan agen menilai pekerjaan rumahnya sendiri. Jika satu-satunya pemeriksaan adalah "agen, apakah Anda selesai?" Anda tidak memiliki loop, Anda memiliki chatbot dengan langkah-langkah tambahan. Gerbang harus eksternal dari agen.
• Gerbang yang terlalu kasar. "Tes lulus" dengan tiga tes dangkal berarti agen memenuhi tiga tes dan mengirimkan bug di semua yang tidak teruji. Kualitas loop dibatasi oleh cakupan gerbang. Tes tipis, hasil tipis.
• Tidak ada penjaga penghentian. Loop tanpa jumlah iterasi maksimum dan batas biaya dapat berputar selamanya pada tugas yang tidak dapat diselesaikan oleh model. Selalu atur jalan keluar, dan selalu eskalasi ke manusia ketika itu terjadi.
• Gerbang lambat. Rangkaian integrasi 15 menit adalah pemeriksaan malam yang baik dan loop internal yang buruk. Jaga gerbang cepat untuk loop dan gerbang menyeluruh untuk penggabungan. Mock dependensi eksternal sehingga loop tidak menunggu pihak ketiga yang tidak stabil.
• Spesifikasi yang dapat diubah. Jika agen mengedit file OpenAPI agar sesuai dengan kode yang salah, pengujian kontrak akan menjadi hijau karena alasan yang salah. Spesifikasi adalah konstitusi. Agen bekerja di bawahnya, bukan di atasnya.
• Satu tugas raksasa. Loop yang mengunyah "membangun seluruh layanan" jarang konvergen. Dekomposisi menjadi tugas-tugas berukuran endpoint, masing-masing dengan gerbangnya sendiri. Loop kecil selesai; yang besar bergejolak.

Sebagian besar dari hal-hal ini bermuara pada disiplin yang sama: berinvestasi pada sinyal, bukan pada prompt. Pola pengkabelan dan mode kegagalan di sini sejalan dengan apa yang kami bahas dalam pengkabelan alat alur kerja agen, dan berlaku apakah agen Anda adalah Claude Code, Cursor, Codex, atau sesuatu yang Anda bangun sendiri.

Ke mana arah ini

Baris "berhenti memberi perintah, mulai melingkar" adalah gambaran tren yang lebih panjang. Keterampilan yang menjadi berharga bukanlah keahlian membuat prompt. Ini adalah keahlian membuat loop: menulis spesifikasi yang jelas, membangun gerbang deterministik, memilih kondisi penghentian, dan memutuskan apa yang boleh dan tidak boleh disentuh oleh agen. Itu lebih dekat ke desain sistem daripada rekayasa prompt, dan itu menghargai insinyur yang sudah berpikir dalam hal tes, kontrak, dan CI.

Ini juga mengubah nilai infrastruktur pengujian yang baik. Selama bertahun-tahun, pengujian otomatis adalah asuransi yang Anda harap tidak akan pernah dibutuhkan. Dalam alur kerja agen, mereka menjadi mekanisme kemudi, hal yang mengubah generator cepat-tapi-tidak-andal menjadi sistem yang konvergen ke arah yang benar. Tim yang sudah memiliki cakupan pengujian otomatis yang kuat dan kontrak yang bersih adalah orang-orang yang langsung menyambungkan agen dan mendapatkan keuntungan. Tim tanpanya mendapatkan cara cepat untuk menghasilkan kode yang percaya diri, tetapi tidak teruji.

Jadi langkah praktisnya bukanlah mengejar model yang lebih baik atau prompt yang lebih cerdas. Ini adalah membangun gerbang. Perketat spesifikasi Anda. Buat pengujian API Anda deterministik dan cepat. Pertahankan skema Anda sebagai sumber kebenaran. Lalu pasang loop di sekitarnya dan biarkan agen berlari putaran sampai gerbang berubah hijau.

Poin Penting

Pergeseran ini mudah diucapkan tetapi sulit diinternalisasi. Jangan menjadi lebih baik dalam memberi perintah kepada agen pengodean Anda. Jadilah lebih baik dalam mendesain loop yang memberi perintah kepadanya, dan pada sinyal umpan balik yang digunakan loop tersebut. Agen adalah generator cepat yang tidak memiliki pengertian yang dapat diandalkan apakah ia benar. Loop, melalui gerbang deterministik, menyediakan pengertian itu. Bagi siapa pun yang membangun API, Anda sudah memiliki gerbangnya. Rangkaian pengujian Anda, skema Anda, dan kontrak Anda adalah kebenaran dasar yang mengubah generator yang bersemangat menjadi sistem yang konvergen ke arah yang benar.

Mulai dari yang kecil. Tulis satu spesifikasi yang ketat, arahkan loop ke satu rangkaian pengujian API yang cepat, lindungi gerbangnya, batasi iterasi, dan saksikan agen menggerakkan titik akhir merah menjadi hijau tanpa Anda dalam loop internal. Kemudian bangun loop berikutnya. Jika Anda ingin gerbang itu visual, sadar skema, dan dapat dibagikan di seluruh tim Anda, Apidog memberi Anda desain, mocking, dan pengujian otomatis dalam satu ruang kerja; unduh dan jadikan pengujian Anda sebagai pendorong agen Anda.