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, saya 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 ada juga cukup banyak buzzword churn yang dibungkus kayak disiplin baru.

Biar saya steelman dulu distinction-nya, karena menurut saya bukan nggak ada sama sekali. 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 sama penulis-penulis yang lebih hati-hati soal ini, itu 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 yang basi atau nggak relevan pas task-nya jalan makin lama. Itu masalah yang beneran beda dari nulis satu prompt yang bagus, dan itu yang beneran saya hadapin tiap kali saya setup coding agent buat project client baru.

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

Tapi ini bagian yang bikin saya skeptis: banyak konten “context engineering” yang saya baca tahun ini itu cuma ndeskripsiin disiplin software engineering yang bagus, diterapin ke input agent AI, pakai vocab baru. Mutusin informasi apa yang dibutuhin satu sistem, jagain informasi 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-ide itu sebelum large language model ada. Nyebutnya “context engineering” pas diterapin ke working memory agent itu nggak salah persis, tapi sebagian konten yang jualan pake istilah ini kerasa kayak lagi bikin-bikin disiplin baru terutama biar ada yang baru buat dijual jadi course atau framework, bukan karena praktiknya beneran berubah.

Yang jadi tanda buat saya itu 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 yang bagus, dan saya nggak nolak satupun, tapi itu udah jadi saran bagus sebelum istilah ini ada juga. Kalau kamu 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 jadi 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 sama 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 saya 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 yang lebih panjang dan surface area yang lebih gede dari satu pesan doang, yang itu 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.