Context Engineering: Beneran Beda Sama Prompt Engineering, Apa Cuma Rebranding?

“Context engineering” itu ada di mana-mana di konten AI sekarang — course, newsletter, thread yang nyebutnya “skill beneran” yang katanya bikin prompt engineering kelihatan kuno. Saya pakai AI coding agent buat kerjaan client hampir tiap hari, udah pernah nulis di blog ini soal efisiensi token dan gimana saya nyusun instruksi agent, dan reaksi jujur saya baca banyak konten ini itu campur aduk: ada distinction yang beneran berguna di dalemnya, dan cukup banyak juga buzzword churn yang dibungkus kayak disiplin baru.

Biar saya steelman dulu, karena menurut saya distinction-nya bukan nggak ada. Prompt engineering, setidaknya cara istilah itu dipake beberapa tahun lalu, kebanyakan soal satu pesan — gimana kamu nulis satu instruksi biar model-nya ngelakuin apa yang kamu mau. Context engineering, kayak yang dijelasin penulis-penulis yang lebih hati-hati soal ini, soal sesuatu yang lebih luas: informasi apa yang ada di context model di titik manapun sepanjang satu session agentic multi-turn, itu datang dari mana, gimana cara refresh atau dibuang, dan gimana biar nggak bikin model kebanjiran materi basi pas task-nya jalan makin lama. Itu masalah yang beneran beda dari nulis satu prompt bagus, dan itu yang beneran saya hadapin tiap kali setup coding agent buat project client baru.

Tempatnya beneran kepake di kerjaan saya sendiri: mutusin apa yang masuk system prompt, apa yang masuk deskripsi tool, dan apa yang masuk file yang harus di-fetch aktif sama agent-nya. Tiga mekanisme beda dengan cost dan failure mode beda, dan milih yang paling pas buat satu informasi tertentu itu skill beneran yang butuh waktu saya kembangin lewat trial and error — bukan sesuatu yang bakal saya sebut “prompt engineering” setahun lalu walaupun masih deket sama itu. File instruksi ala CLAUDE.md yang kepanjangan bikin tiap turn lambat; deskripsi tool yang terlalu vague bikin agent milih tool yang salah; context yang basi di tengah session karena saya lupa refresh setelah refactor besar bikin agent pede salah soal keadaan codebase. Nggak ada dari itu yang keselesain cuma dengan nulis prompt lebih pinter.

Tapi ini yang bikin saya skeptis

Banyak konten “context engineering” yang saya baca tahun ini cuma ndeskripsiin disiplin software engineering yang bagus, diterapin ke input agent AI, pakai vocab baru. Mutusin informasi apa yang dibutuhin satu sistem, jagain itu tetep update, nggak numpukin satu komponen dengan state yang nggak relevan — nggak ada dari itu yang baru. Kita udah punya nama buat kebanyakan ide ini sebelum LLM ada. Nyebutnya “context engineering” pas diterapin ke working memory agent nggak salah persis, tapi sebagian konten yang jualan pake istilah ini kerasa kayak bikin-bikin disiplin baru biar ada yang baru buat dijual jadi course atau framework, bukan karena praktiknya beneran berubah.

Tandanya buat saya: seberapa banyak saran “context engineering” yang setahun sebelumnya bakal disebut cuma “prompting yang bagus” atau “system design yang bagus,” tanpa perubahan substansial di teknik beneran. “Bikin instruksi kamu concise,” “jangan masukin informasi yang nggak relevan,” “cuma retrieve apa yang dibutuhin buat step sekarang” — itu semua saran bagus, saya nggak nolak satupun, tapi itu udah jadi saran bagus sebelum istilah ini ada juga. Lepasin framing-nya, sebagian dari itu lebih ke rebrand daripada rethink beneran.

Saya juga ngaku bias saya sendiri di sini karena relevan: saya sering diminta client non-teknis buat jelasin apa yang saya kerjain pas setup workflow agent project mereka, dan buzzword churn bikin percakapan itu lebih susah, bukan lebih gampang. Tiap kali vocab-nya geser, saya harus milih antara adopsi istilah baru dan jelasin dari nol, atau pake bahasa saya sendiri yang lebih plain dan risiko kedengeran ketinggalan zaman buat client yang baca headline soal “context engineering” jadi skill wajib baru. Nggak ada dari dua pilihan itu yang beneran soal hasil lebih baik buat project mereka — itu overhead yang dibikin industri yang kelihatannya seneng ganti nama hal-hal.

Kesimpulan saya

Praktik dasarnya — sengaja ngatur apa yang masuk context agent, kapan, dan lewat mekanisme apa — itu nyata, berguna, dan layak dikuasain, dan saya beneran jadi lebih baik di kerjaan client sendiri gara-gara mikirin ini secara eksplisit ketimbang cuma intuisi. Tapi saya bakal nolak kalau ini diperlakukan sebagai pengganti total prompt engineering, atau disiplin yang sebelumnya nggak diketahui yang baru ditemuin. Ini lebih deket ke prompt engineering yang “gede” buat nyakup jangka waktu lebih panjang dan surface area lebih gede dari satu pesan doang — evolusi beneran dan layak, cuma nggak butuh packaging marketing sebanyak yang dia dapetin sekarang.

Saya bisa aja salah soal seberapa banyak ini beneran baru versus dikemas ulang — saya baca konten publik yang sama kayak orang lain, bukan ngejalanin eksperimen terkontrol soal ini. Kalau ada teknik spesifik di balik label ini yang beneran novel ketimbang versi ganti nama dari sesuatu yang udah saya lakuin, saya lebih milih belajar dan pake itu daripada nolak seluruh kategorinya cuma karena keras kepala. Skeptisisme saya di sini soal volume konten yang didorong buzzword dibandingin sama jumlah teknik yang beneran baru di dalamnya, bukan klaim blanket kalau nggak ada apapun di bawah label ini yang layak diperhatiin.