Agents membutuhkan alur kontrol, bukan lebih banyak prompt

• Agen yang menangani tugas kompleks secara andal tidak memerlukan rantai prompt yang lebih canggih, melainkan alur kontrol deterministik yang dienkodekan ke dalam perangkat lunak
• Jika Anda bergantung pada ungkapan seperti MANDATORY atau DO NOT SKIP di dalam prompt, itu berarti Anda sudah mencapai batas prompting
• Bayangkan bahasa pemrograman di mana kalimat berperilaku seperti usulan dan fungsi berhalusinasi lalu mengembalikan “Success”; saat kompleksitas meningkat, penalaran menjadi mustahil dan keandalan runtuh
• Perangkat lunak berkembang melalui komposabilitas rekursif yang tersusun dari library, modul, dan fungsi, serta memungkinkan penalaran lokal karena memberikan perilaku yang dapat diprediksi
• Rantai prompt berguna untuk tugas yang sempit, tetapi tidak memiliki sifat yang sama karena bersifat non-deterministik, spesifikasinya lemah, dan sulit diverifikasi

Struktur yang dibutuhkan untuk keandalan agen

• Untuk memastikan keandalan, logika perlu dipindahkan dari penjelasan bahasa alami ke runtime
• Struktur yang dibutuhkan adalah scaffold deterministik yang memperlakukan LLM bukan sebagai keseluruhan sistem, melainkan sebagai satu komponen
• Scaffold ini harus mencakup transisi status yang eksplisit dan checkpoint verifikasi
• Orkestrasi deterministik saja tidak cukup; sistem yang bisa gagal secara diam-diam memerlukan deteksi kesalahan yang agresif
• Tanpa verifikasi terprogram, pilihan yang tersisa hanya tiga

  • Pengawas (Babysitter)

    • Manusia harus tetap berada di dalam loop untuk menangkap kesalahan sebelum menyebar

  • Auditor (Auditor)

    • Setelah eksekusi selesai, seluruh hasil harus diverifikasi secara menyeluruh

  • Doa (Prayer)

    • Anda akhirnya bergantung pada cara menerima hasil berdasarkan kesan semata

[GN⁺]

Komentar Hacker News

• Sangat setuju, 1000%. Semakin sulit percaya pada tabuhan Anthropic yang terus berkata, “bangun berdasarkan kemampuan model masa depan, karena sebentar lagi akan jadi lebih baik”
  Saya membuat agen QA yang menelusuri 200 file Markdown kebutuhan dalam sesi browser, dan itu sistem yang bagus karena sangat meningkatkan efisiensi tim. Tapi ketika alur kontrol tingkat tinggi diserahkan ke model, seperti “lihat file-file kebutuhan di direktori ini, lalu untuk setiap file buat item pekerjaan untuk memeriksa apakah aplikasi memenuhi kebutuhan tersebut”, sistem mulai runtuh sekitar file ke-30
  Ada file yang terlewat, ada juga kelompok file yang diuji tiga kali sehingga pekerjaan yang seharusnya 3 menit jadi 10 menit, atau karena satu error di satu file, empat file sebelumnya diuji ulang tanpa alasan. Bahkan di Opus 4.6 dan GPT 5.4, juga sekilas di Opus 4.7 dan GPT 5.5, kemampuan orkestrasi workflow tetap tidak konsisten
  Akhirnya saya membuat harness deterministik yang sangat sederhana di sekitar model: memanggil model untuk tiap test case, menyimpan hasilnya ke array, lalu menuliskannya ke file. Reliabilitas sistem meningkat drastis. Tapi platform agen terkelola seperti Cursor Cloud Agents atau Anthropic tampaknya terlalu terobsesi dengan gagasan bahwa “agen harus menjalankan semuanya”, sehingga tidak melihat nilai dari menambahkan sedikit determinisme di titik yang tepat

  • Dulu saya kira alasan mereka mendorong orang ke workflow berbasis prompt semata adalah karena mereka bisa menagih biaya token, tapi tidak bisa menghasilkan uang dari scaffolding buatan pengguna. Sekarang saya justru merasa mereka takut pada kenyataan bahwa seseorang harus merancang dan mengimplementasikan scaffolding itu
    Karena itu akan mendinginkan klaim bahwa teknologi ini bisa menggantikan seluruh orang, seluruh workflow, atau seluruh proyek. Saya tetap melihat bahwa ini bisa sangat meningkatkan produktivitas dan berdampak buruk pada pasar kerja developer dan upah, tapi saya tidak yakin versi teknologi saat ini akan sampai ke tingkat yang mereka klaim. Kalau mereka memosisikannya sebagai “alat yang sangat berguna untuk mengurangi banyak pekerjaan remeh tim developer manusia”, para developer akan menginginkannya tetapi para eksekutif mungkin tidak terlalu, dan investor pun mungkin tidak akan membiarkannya
    Selain itu, tahap yang dikendalikan secara rinci dan ketat jauh lebih cocok untuk memasang model yang lebih kecil, lebih murah, dan lebih terspesialisasi, daripada model raksasa yang dipakai untuk otomatisasi pengujian atau menulis lima volume fanfic CSI dalam sekejap
  • Ini mungkin juga berasal dari cara benchmark untuk mengevaluasi model
    Bukankah beberapa benchmark membiarkan beberapa kali percobaan pada satu masalah, lalu mengabaikan tingkat kegagalan dan hanya mengambil hasil yang berhasil setidaknya sekali?
  • Setuju. Satu-satunya cara membuat sistem seperti ini andal adalah memecah masalah menjadi bagian-bagian kecil. Pemeriksaan konsistensi internal pada akhirnya hanya menunjukkan bahwa LLM jauh kurang konsisten daripada yang kita harapkan
  • Performa meningkat drastis setelah saya menggabungkan check_compilation dan run_unit_tests ke alat seperti apply_patch. Nama alatnya masih apply_patch, tetapi sekarang jika patch berhasil, ia juga mengembalikan informasi tambahan tentang build dan test
    Tingkat keberhasilan agen naik dari sekitar 80% ke level yang sejauh ini tampak hampir deterministik. Sekarang saya tidak perlu lagi menjelaskan proses kompilasi dan unit test di prompt; cukup dijalankan dengan prasyarat tertentu lalu hasilnya dikembalikan
    Saya juga merasa makin menjauh dari tren saat ini. Sudah lama saya memakai token prabayar dan harness kustom, dan hasilnya memang bekerja baik. Sebagian besar berita bisa diabaikan. Untuk masalah-masalah yang ditargetkan secara eksplisit, alat jenis Copilot sudah tidak lagi berguna, dan di beberapa codebase, meskipun sama-sama memakai model berbasis GPT 5.4, perbedaan performanya benar-benar beda kelas
  • Rahasianya adalah “mengompilasi” prompt orkestrasi itu. Kalau prompt diubah menjadi kode, kode itu kemudian bisa menjalankan agen, menjalankan kode, atau keduanya, sehingga masalah determinisme terselesaikan
    Semua orang melewatkan pola ini pada skill. Kalau kode diletakkan berdampingan dengan SKILL.md, kita bisa menjamin perilaku tertentu, tapi anehnya semua orang kecanduan menulis prompt. Tidak perlu sampai membuat CLI, skill.py sederhana yang berisi tugas saja sudah cukup. Bisa juga ditambah helper yang memanggil claude -p

• Akan lucu kalau beberapa tahun lagi orang masih memakai LLM, tetapi pada akhirnya hanya bisa memakainya melalui kosakata dan tata bahasa yang terkontrol yang tetap harus dipelajari. Mirip seperti 15 tahun lalu ketika semua orang pindah ke NoSQL lalu tak lama kemudian membuat kembali skema di dalam JSON

• Sebagian masalahnya mungkin karena LLM memang diterapkan secara keliru sejak awal. Seperti yang juga muncul di tempat lain, mungkin prompt untuk agen seharusnya adalah: tulislah kode yang menjalankan tugas dengan cara yang sebisa mungkin dapat diulang, dapat diverifikasi, dan deterministik
  Verifikasi keluaran agen juga harus disertakan. Tujuan akhirnya adalah menyingkirkan LLM dari tugas-tugas yang bisa ditangani program secara lebih efisien dan sering kali lebih akurat

  • 100% setuju. Kita harus memakai alat non-deterministik yang benar 90% untuk membuat alat deterministik yang benar 100%. Salah satu kalimat kunci yang selalu saya masukkan ke prompt adalah, “jika menemui edge case yang ambigu, tanyakan kepada saya”
    Menurut saya buruk jika AI dihubungkan ke produksi lalu dibiarkan melakukan sesuatu secara langsung lewat pemanggilan API. Satu-satunya kegunaan AI dalam aplikasi seharusnya untuk membaca, mengklasifikasi, dan hal serupa. Kurang lebih menggantikan “R” pada aplikasi CRUD lama
    Tidak masalah jika endpoint “R” berbasis AI yang sama, bergantung pada prompt, juga mengisi otomatis formulir “C”, “U”, dan “D”, tetapi tidak boleh mengubah sesuatu untuk pelanggan sebelum ada tinjauan manusia. Aplikasi CRUD tetaplah aplikasi CRUD dan akan tetap begitu; bedanya sekarang ada endpoint “R” yang sangat pintar yang memberi autocomplete formulir atau saran tindakan untuk pelanggan, alat internal, Jenkins pipeline, dan sebagainya. Ia boleh mengusulkan tindakan, tapi tidak boleh mengeksekusinya langsung
  • Di sebagian besar organisasi, alurnya tampaknya bergerak dari llm -> prompt -> result, ke llm -> prompt + prompt encoded as skill -> result, lalu ke llm -> prompt + deterministic code encoded as skill -> result
    Meminta prompt menghasilkan kode sejak awal memang bisa memperpendek jalan menuju kode deterministik, tetapi tetap saja itu berarti menaruh kode deterministik di dalam wrapper non-deterministik. Untuk berhasil pada tugas jangka panjang, dalam banyak kasus dibutuhkan lapisan determinisme yang selama ini hilang
    Melalui agent loop atau framework, kode deterministik harus ditempatkan di luar batas non-deterministik. Dengan begitu, penilaian non-deterministik berada di antara lapisan deterministik, seperti alur agen deterministik -> pengambilan keputusan non-deterministik -> alat deterministik. Dalam eksperimen, itu pola yang sangat kuat, dan akan lebih kuat lagi jika agen dapat membangun determinismenya sendiri dengan alat seperti auto-researcher
  • Kami juga mengalami hal yang sama. Awalnya kami memberi agen daftar alat yang bisa memanipulasi struktur data dengan cara tertentu, tetapi pendekatan itu cukup rapuh
    Sekarang kami memakai bahasa khusus domain kecil dan satu alat tunggal, lalu agen memasukkan skrip yang ditulis dalam bahasa itu. Ini bisa menangani kasus penggunaan yang lebih dinamis, dan sintaks yang salah mudah ditangkap parser lalu dikembalikan ke agen
  • Masalahnya adalah program sering bertemu edge case yang membutuhkan interpretasi, dan pada saat itu kita jadi ingin LLM yang menangani edge case tersebut, lalu dari sana kita terdorong untuk menyerahkan seluruh loop iterasi dan pemanggilan alat kepada LLM
  • Pada proyek terakhir saya, saya melakukan persis ini ketika mengotomatisasi pembuatan library antarmuka antara server pengendali hardware dan aplikasi mobile
    Tim kontrol hardware menyampaikan spesifikasi lewat dokumen dan spreadsheet, lalu tim mobile melihat itu, menulis kode library antarmuka, lalu memverifikasinya terhadap server. Saya mengubah dokumen-dokumen itu menjadi TSV dan mengirim sebagian ke Claude agar ia menulis parser TSV yang mempertahankan nuansa spesifikasi yang ditulis manusia
    Butuh lebih dari 150 iterasi untuk menangani semua edge case dan menghasilkan hasil antara dalam bentuk JSON. Setelah itu Claude membantu menulis code generator yang menambahkan glue code kustom di atas Apollo untuk menghasilkan kode yang dikonsumsi aplikasi mobile
    Seluruh pipeline ini berjalan sebagai bagian dari Github Actions, dan Claude hanya dipanggil ketika validator library gagal. Saat gagal, ada file md yang disertakan dalam request agar Claude menganalisis apa yang salah, mengusulkan solusi, dan membuat PR. Setelah itu manusia meninjau, mengedit, dan merge. Total kredit yang terpakai untuk semuanya kurang dari 350 dolar

• Saya setuju dengan arahnya, tetapi menurut saya kesimpulannya perlu diubah. Ketika kita menabrak batas prompt, alih-alih mencoba membuat LLM melakukan pekerjaan saat runtime, kita seharusnya meminta LLM menulis perangkat lunak yang akan melakukan pekerjaan itu
  Peran LLM saat runtime kemungkinan biasanya akan menyusut menjadi sekadar membantu pengguna memilih input yang cocok untuk sistem perangkat lunak yang sudah menanamkan aturan bisnis ketat

  • Di kantor saya punya beberapa minggu senggang, jadi saya mencoba memasukkan agen ke proses kerja seperti penulisan catatan, pelacakan tugas, dan manajemen dokumen, dan ini benar-benar cocok dengan pengalaman saya
    Minggu pertama prompt terus membesar dan performa malah menurun. Minggu kedua saya fokus mendefinisikan objek seperti catatan, tugas, proyek, dan orang dengan tepat, lalu mendefinisikan metode yang melakukan operasi yang jelas pada objek-objek tersebut. Seperti yang disebutkan, permukaan agen pun menyusut menjadi lapisan terjemahan yang mengubah bahasa alami menjadi perintah dan argumen yang lolos validator input
  • Kalau sistem prompt benar-benar berputar penuh, mungkin bentuknya akan seperti: “cari semua peluang otomasi yang bisa membuatmu kehilangan pekerjaanmu sendiri. Jika menerima pertanyaan yang dapat dijawab dengan kode, tulis dan jalankan kodenya untuk mendapatkan hasil lalu jawab berdasarkan itu”
    LLM seperti itu mungkin akan tampil lebih baik pada strawberry test
  • Di forum ini juga ada pandangan bahwa masa depan software ada pada program yang dibangkitkan dan beradaptasi saat runtime dengan memakai AI generatif. Saya tidak tahu seberapa jauh lagi menuju ke sana
  • Saya pernah melihat kasus ketika model terjebak pada satu cara penyelesaian masalah dan perlu dorongan untuk beralih ke pendekatan lain. Misalnya, untuk menangani hotplug/unplug pada audio stream, alih-alih mengutak-atik banyak konfigurasi system service, yang sebenarnya dibutuhkan hanyalah beberapa puluh baris Python
    Saya membiarkan Claude sendiri menulis beberapa shell script untuk menangani kasus umum dalam workflow saya, seperti menjalankan test. Sekarang ia tinggal menjalankan alat-alat itu dan menyelesaikan pengaturan, bukannya berputar-putar selama 30 menit
    Setiap kali ia meminta izin menjalankan one-liner shell atau Python yang aneh untuk melakukan sesuatu sekali pakai, saya jadi berpikir apakah seharusnya saya membuatnya memakai alat yang bisa di-auto-approve

• Itu sebabnya saya sering memakai ungkapan “AI generasi berikutnya”. Ini bukan sekadar berarti LLM. LLM sendiri cukup keren, dan bahkan tanpa kemajuan dasar lebih lanjut pun saya rasa nilainya akan terus keluar karena dipakai dan dioptimalkan dengan cara yang lebih menarik
  Tetapi untuk beberapa hal, tampaknya dibutuhkan perbaikan generasi berikutnya yang mendasar dalam bentuk apa pun. Fakta bahwa LLM membuat instruksi “jangan pernah lakukan X” menjadi kabur, lalu setelah banyak langkah malah menafsirkannya seperti “tolong lakukan X”, terasa sangat dekat dengan dasar cara kerjanya. Di tengah antusiasme awal untuk mencari tahu apa yang bisa kita lakukan, hal ini mudah terlupakan, tetapi LLM bukanlah seluruh hal yang kita cari dalam AI
  Harus ada arsitektur yang memperlakukan “jangan pernah lakukan X” seperti manusia. Juga harus ada arsitektur dengan lapisan memori yang mirip manusia, bukan sekadar “jendela konteks”. Jika dua orang berbicara cukup lama, walaupun awalnya AI yang sama, pada akhirnya kedua AI itu menjadi entitas yang benar-benar berbeda, bukan sekadar punya jendela konteks yang berbeda
  Tentu saja, tidak ada yang tahu bentuknya akan seperti apa. Tapi tidak ada alasan untuk menganggap LLM adalah jawaban final bagi AI

  • Menurut saya yang dibutuhkan adalah memori sungguhan. Memori saat ini, secara longgar, lebih mirip sistem post-it yang ditulis sendiri lalu dicek setiap kali, bukan sistem terpadu yang memungkinkan pembelajaran dan aktif dengan cara yang lebih fleksibel
  • Ada contoh menarik di sini https://www.youtube.com/watch?v=kYkIdXwW2AE&t=315s

• Sebagai orang yang sudah berputar dari pemaksaan prompt → alur deterministik → kembali ke pemaksaan prompt, saya tidak setuju
  Alasan “jangan dilewati” gagal adalah karena agen memegang terlalu banyak pekerjaan dan hal-hal lain dalam konteks mengalihkan perhatiannya dari instruksi tersebut
  Tetapi tidak ada yang mengatakan bahwa agen yang menangani penegakan harus sama dengan agen yang membangun. Kita memang bisa mengenkode sebagian logika pengambilan keputusan yang pintar ke dalam alur kontrol deterministik, tetapi jika dibuat terlalu kaku hasilnya tidak bagus, dan jika dibuat terlalu kompleks maka biaya setup serta maintenance-nya menjadi lebih murah jika langsung memakai agen
  Pada dasarnya yang dibutuhkan adalah tiga jenis agen: supervisor yang mengelola loop dan menyalakan hal yang tepat ketika ada masalah, orchestrator yang mendelegasikan ke agen yang tepat dan memaksakan guardrail di tempat yang diperlukan, serta worker yang mengeksekusi unit pekerjaan

  • Benar, tinggal tambah lebih banyak agen saja

• Menurut saya semua harness salah dalam aspek ini, dan beberapa sangat salah
  Misalnya, slash command adalah fitur yang salah. Kita seharusnya tidak perlu menunggu chatbot menyelesaikan satu turn untuk memeriksa status jendela konteks atau berapa biaya yang sudah dipakai dalam sesi ini. Kontrol harus ortogonal terhadap loop chat
  Banyak hal yang sama sekali tidak ada hubungannya dengan mengontrol input dan output generator teks justru terikat ke perilaku chat hanya karena “karena ini chat, ayo perlakukan seperti bot IRC”
  Sekarang memang ada sangat banyak agen LLM, tetapi hampir tidak ada yang benar-benar memisahkan kontrol, agent loop, dan lapisan presentasi dengan benar. Beberapa setidaknya punya headless mode, dan itu bagus

  • Saya paham maksud Anda, tetapi membuat arsitektur yang benar-benar diusulkan jauh lebih sulit. Bagaimana kalau Anda bikin sendiri lalu coba melamar ke perusahaan besar?
  • Di codex CLI, /status tetap berfungsi baik di tengah turn
    Yang lain tidak begitu
  • Saya memakai aplikasi desktop Codex. Di GUI saya bisa melihat indikator konteks dan statistik penggunaan
    Juga lebih nyaman untuk bolak-balik antar percakapan dan melihat update. Kadang saya memakai Claude Code atau opencode di terminal, tetapi pengalamannya jauh lebih buruk dibanding aplikasi desktop Codex

• Ucapan “bayangkan bahasa pemrograman di mana kalimat adalah usulan dan fungsi berhalusinasi lalu mengembalikan Success. Penalaran menjadi mustahil, dan ketika kompleksitas meningkat, reliabilitas runtuh” pada dasarnya cukup dekat dengan pemrograman deklaratif
  Sebagian besar pemrograman tradisional bersifat imperatif, yang akrab bagi developer. Kita memberikan kumpulan instruksi yang tepat, lalu berharap mesin mengikutinya persis seperti yang kita tulis. Agen jauh lebih dekat ke deklaratif daripada imperatif: kita memberi hasil yang diinginkan, lalu ia bekerja untuk mencapainya
  Tentu saja, dalam sistem deklaratif seperti SQL, hasilnya cukup konsisten dan terdefinisi baik, tetapi tetap saja kita mempercayai engine internal untuk menentukan caranya. Memikirkan agen sebagai sesuatu yang deklaratif jauh lebih membantu saya daripada mencoba merancang sistem “kontrol” ala Rube Goldberg. Jika hasilnya tidak cocok, verifikasi saja, laporkan bahwa itu salah, lalu coba lagi atau pilih pendekatan lain
  Kalau memang butuh yang benar-benar imperatif, ya tulis secara imperatif. Atau minta agen menulisnya begitu. Ini terdengar seperti memakai alat yang tidak cocok untuk pekerjaannya

  • Rasanya ini satu tingkat lebih abstrak daripada deklaratif. Mungkin bisa disebut pemrograman naratif? Tentu saja, masih bisa diperdebatkan apakah kata “pemrograman” masih tepat
    Ini mungkin tampak deklaratif, tetapi itu hanya terjadi di dalam ilusi. Kita sebenarnya tidak sedang menjelaskan tujuan kepada AI lalu membuatnya menafsirkannya; yang kita miliki adalah dokumen cerita tentang karakter pengganti manusia yang berbicara dengan karakter komputer, dan kita di dunia nyata berharap LLM bisa menyambung cerita yang lebih koheren di baliknya lalu mengekstrak sesuatu yang berguna
    Ini bukan sekadar pembedaan akademis. Jika kita tahu bahwa ada unsur cerita, model untuk memahami hubungan input dan output serta menyusun strategi menjadi lebih baik. Misalnya, itu membantu memahami risiko seperti prompt injection, dan juga memberi arah tentang data pelatihan apa yang perlu dimasukkan atau dikeluarkan
  • Saya juga teringat deklaratif, tetapi yang saya pikirkan bukan SQL melainkan PROLOG. Yang punya alur kontrol dan kemampuan penalaran sungguhan
    Lalu kita bertemu masalah yang mirip dengan LLM: kegagalan diam-diam, pengulangan, dan kontradiksi jika tidak sangat berhati-hati. Mungkin esensinya adalah masalah asumsi closed-world yang sama. Pada LLM ini muncul sebagai halusinasi alih-alih pengakuan bahwa ia tidak tahu
  • Setuju. Tetapi kita juga bisa berbicara secara imperatif kepada agen. Kita bisa bilang, “ini langkah-langkah konkretnya, ikuti”, dan tetap saja ia bisa kacau. Yang kita cari bukanlah sifat imperatif, melainkan determinisme
    Dan seperti yang Anda katakan, jika kita secara deklaratif menyuruh LLM non-deterministik “bawalah aku ke keadaan akhir ini”, peluang melenceng dari jalur jadi lebih besar
  • Sifat deklaratif SQL bertumpu pada matematika aljabar relasional, sehingga mengembalikan hasil yang sama setiap kali. Apakah setiap query kembali dalam waktu yang sama bergantung pada indeks dan ukuran database
    Tetapi query itu sendiri tidak berubah-ubah seperti LLM

• Saya cukup sering memikirkan masalah ini. Ini juga bisa dikaitkan dengan pembahasan soal spesialisasi. Semakin terspesialisasi modelnya, kadang kemampuan dasarnya justru tampak menurun, dan mungkin dengan menargetkan abstraksi yang sangat tipis kita bisa memperoleh keunggulan dari kedua sisi
  Ini contoh yang cukup spesifik, tetapi tetap layak jadi bahan pikir
  Ringkasan podcast 20 menit: https://pub-6333550e348d4a5abe6f40ae47d2925c.r2.dev/EP008.ht...
  Makalah: https://arxiv.org/abs/2605.00225

• Ini sebenarnya sudah terlihat sejak era Auto-GPT pada 2023. Orang-orang membiarkan GPT yang “menyetir”, padahal dalam kebanyakan kasus yang benar-benar dibutuhkan hanyalah sepuluh baris Python dan mungkin beberapa pemanggilan fungsi llm()
  Alternatifnya adalah mengeksekusi Python sepuluh baris itu dengan cara yang semaksimal mungkin paling mahal, paling lambat, dan paling tidak andal. Tentu saja, itu populer
  Misalnya, kebanyakan orang memakai agen untuk riset internet. Ia berjalan berjam-jam, lalu terdistraksi atau lupa apa yang tadinya sedang dikerjakan
  Sementara itu, dengan import duckduckgo dan import llm, kita bisa menulis kode sepuluh baris yang melakukan hal sama dalam 20 detik, benar-benar berjalan deterministik, dan biayanya 50 kali lebih murah
  Model-model saat ini jauh lebih baik, dan sudah cukup bagus sehingga Auto-GPT kini bisa jadi realistis. Tetapi tetap saja ide buruk untuk mengeksekusi alur kontrol yang dispesifikasikan dengan buruk dengan cara yang paling mahal