Kenapa Micromanaging AI Agent Justru Membuat Mereka Makin Bodoh
Banyak developer memperlakukan LLM modern layaknya skrip regex yang rapuh. Dengan mengganti aturan kaku menjadi prinsip dasar, Anda bisa meningkatkan performa agen AI secara drastis. Inilah alasan mengapa *less is actually more*.

Coba buka file system_prompt.txt acak dari repo GitHub modern hari ini, apa yang kamu lihat? Biasanya, isinya berupa rentetan teks yang terkesan panik. "JANGAN lakukan X. Kamu HARUS mengeluarkan tepat tiga poin. JANGAN PERNAH gunakan library ini."
Para developer memperlakukan mesin penalaran (reasoning engines) paling canggih dalam sejarah manusia layaknya skrip regex yang rapuh.
Secara historis, paranoia ini sebenarnya sangat masuk akal. Satu atau dua tahun yang lalu, LLM generasi awal memang butuh "dituntun" habis-habisan (extreme hand-holding) hanya agar tidak melenceng dari topik. Tapi zaman sudah berubah. Model-model modern sekarang luar biasa pintar, namun kita masih menulis prompt seolah-olah sedang memprogram microwave tahun 1980-an. Kita mencoba melakukan hardcode pada sebuah kecerdasan.
Ada hal menarik yang baru-baru ini terjadi di Vercel yang membuktikan poin ini. Tim engineering mereka mempublikasikan analisis tentang bagaimana mereka meningkatkan produk v0 mereka, merinci sebuah langkah yang counterintuitive (berlawanan dengan intuisi): mereka menghapus 80% tools dari agent mereka.
Hasilnya? Sistemnya tidak rusak. Malah menjadi jauh lebih baik. Dengan membuang tools yang terlalu mengatur dan batasan yang kaku, mereka mengurangi kebingungan dan membiarkan model melakukan apa yang paling dikuasainyaâbernalar untuk memecahkan masalah. Lebih sedikit friksi menghasilkan kode yang lebih baik.
Ada pelajaran mendalam di sini bagi siapa saja yang sedang membangun produk dengan AI saat ini: Berikan prinsip, bukan aturan kaku.

Ketika kamu memberi tahu LLM secara persis apa yang harus dilakukan langkah demi langkah, kamu memaksanya untuk menghabiskan attention (komputasi) yang terbatas pada kepatuhan (compliance) alih-alih kualitas. Kamu merampas kemampuannya untuk menggunakan data training-nya yang masif demi menemukan solusi yang lebih elegan daripada yang kamu hardcode.
Untuk melihat perbedaannya, coba perhatikan bagaimana mayoritas developer menulis prompt untuk agent dibandingkan dengan bagaimana mereka seharusnya menulisnya.
Cara yang Buruk (Aturan Kaku):
"Tulis fungsi Python untuk mengambil data user. Kamu harus menggunakan library
requests. Kamu harus menangani error dengan blok try/except. Kamu harus mengembalikan dictionary dengan keys yang persis berisi 'name', 'email', dan 'status'. Jangan gunakan async. Tambahkan komentar di setiap baris."
Cara yang Baik (Prinsip & Tujuan):
"Tulis fungsi Python yang robust untuk mengambil data user. Utamakan library standar yang modern. Kode harus production-ready, artinya bisa menangani kegagalan jaringan dan edge cases dengan baik. Prioritaskan readability dan clean architecture daripada kode yang terlihat 'pintar' (cleverness). Sistem downstream mengharapkan profil user standar (name, email, status)."
Sadar akan perubahannya? Contoh pertama memperlakukan AI seperti junior developer yang tidak bisa dipercaya. Contoh kedua memperlakukannya seperti senior engineer yang memahami tujuan dan konteksnya. Kamu memberi tahu seperti apa output yang bagus itu dan mengapa, lalu kamu mundur selangkah dan membiarkannya mencari tahu bagaimana cara mencapainya.
Tentu saja, ada satu pengecualian besar untuk aturan ini.
Ketika agent berkomunikasi dengan agent lainâatau ketika upstream agent meneruskan data ke database parser downstream yang kakuâkamu butuh aturan yang sangat ketat (absolute strictness). Serah terima (handoffs) machine-to-machine membutuhkan JSON schemas yang presisi dan tidak bisa ditawar. Tapi untuk reasoning, generation, dan problem-solving? Longgarkan sedikit kendalimu.
Jika kamu ingin langsung meng-upgrade coding assistants kamu hari ini, copy dan paste blok ini persis ke dalam claude.md, memory.md, atau core system prompt dari agent kamu:
## Prompt Writing Philosophy
When writing LLM prompts (system prompts, skill specs, subagent prompts): **give principles, not rigid rules.**
- Tell the LLM what good output looks like and why â let it figure out how
- Avoid prescribing exact fields, counts, or formats unless the output is a machine-consumed intermediate
- Exception: structured handoffs between agents can be rigid because downstream agents need consistent field names
Berhentilah mencoba melakukan micromanage pada mesin. Percayalah pada LLM modern. Mereka lebih cepat, lebih pintar, dan jauh lebih mampu ketika kita berhenti memperlakukan mereka layaknya anak balita.

Bagikan ini

Feng Liu
shenjian8628@gmail.com