Harness vs context engineering: apa bedanya rekayasa harness dengan prompt dan context engineering

Ringkasnya: tiga tingkat dari satu tugas

Prompt engineering menjawab pertanyaan «bagaimana cara meminta», context engineering menjawab «apa yang harus diketahui model saat ini juga», dan harness engineering menjawab «di lingkungan seperti apa agen bekerja dan bagaimana ia tahu bahwa ia keliru». Ini bukan tiga pendekatan yang bersaing, melainkan tingkat-tingkat yang bersarang: prompt yang baik adalah bagian dari konteks yang baik, dan konteks yang dirancang dengan matang adalah salah satu subsistem harness.

Kebingungan muncul karena ketiganya sama-sama mengubah perilaku model. Tetapi tuasnya berbeda. Jika agen tidak bisa menjalankan tes, rumusan prompt apa pun tidak akan memperbaikinya. Jika agen melupakan keputusan kemarin, masalahnya bukan pada kata-kata permintaan, melainkan di mana status disimpan. Memahami perbedaan harness vs context engineering menghemat berminggu-minggu kerja: Anda berhenti menulis ulang instruksi di tempat yang sebenarnya lingkungannya yang rusak.

Prompt engineering: rumusan satu permintaan

Prompt engineering adalah pekerjaan dengan teks permintaan: peran, tugas, format jawaban, contoh (few-shot), batasan, dan urutan langkah. Satuan kerjanya adalah satu pemanggilan model. Hasilnya dinilai dari jawaban: benar atau tidak, sesuai format atau tidak, apakah model melenceng.

Teknik yang lazim:

• mendeskripsikan format keluaran secara eksplisit (skema JSON, tabel, daftar);
• memberi 2–3 contoh «masukan → keluaran yang benar»;
• meminta penalaran langkah demi langkah sebelum jawaban;
• memisahkan instruksi dan data dengan pembatas yang jelas;
• menyebutkan apa yang tidak boleh dilakukan.

Prompt engineering bekerja baik untuk tugas «satu masukan — satu jawaban»: klasifikasi, ekstraksi data, terjemahan, pembuatan teks menurut templat. Batasnya terlihat ketika model mulai bertindak: memanggil alat, mengubah file, bekerja puluhan langkah berturut-turut. Di sana kualitas tidak lagi bergantung pada satu kalimat, melainkan pada seluruh yang mengelilingi model.

Context engineering: apa yang masuk ke jendela model

Context engineering adalah pengelolaan isi jendela konteks pada setiap langkah. Jendelanya terbatas, sedangkan agen dalam sesi panjang menumpuk keluaran perintah, isi file, dan riwayat percakapan. Tujuannya: di setiap saat, yang ada di jendela adalah yang dibutuhkan, dan tidak ada yang berlebih.

Termasuk di dalamnya:

• seleksi: file, dokumen, dan potongan kode mana yang dimuat untuk tugas (pencarian, RAG, pembacaan sesuai kebutuhan);
• pemadatan: ringkasan riwayat yang panjang, pemangkasan keluaran perintah, pemadatan sesi;
• struktur: file masukan instruksi sebagai daftar isi, dan rincian di dokumen terpisah yang dibuka agen saat dibutuhkan;
• isolasi: memindahkan subtugas ke subagen dengan konteks bersih sendiri, agar alur utama tidak tercemar.

Metrik context engineering adalah apakah agen menemukan aturan atau fakta yang tepat pada saat yang tepat, dan apakah ia tidak tenggelam dalam derau. Gejala khasnya: aturan sudah tertulis di CLAUDE.md, tetapi agen melanggarnya, karena file itu lima halaman dan aturan tersebut hilang di antara nada suara dan gaya favorit ketua tim.

Harness engineering: semua yang mengelilingi model

Harness («tali kekang») adalah lingkungan tempat agen bekerja. Model di dalamnya hanyalah satu komponen yang masuk ke lingkaran sekali. Semua yang lain — instruksi, alat, lingkungan, status, dan umpan balik — dirancang oleh insinyur. Harness engineering bertanggung jawab agar agen tidak hanya bisa menulis kode, tetapi juga menjalankannya, memeriksanya, mengetahui kesalahannya, dan melanjutkan pekerjaan di sesi berikutnya dari titik yang sama.

Harness mudah dibagi menjadi lima subsistem:

Context engineering dalam skema ini hidup di dalam dua subsistem pertama: ia memutuskan bagaimana instruksi dan keluaran alat masuk ke jendela. Harness menambahkan hal-hal yang tidak bisa dimasukkan ke konteks: perintah verifikasi yang berfungsi, lingkungan yang dapat direproduksi, file status yang bertahan setelah dimulai ulang.

Tabel perbandingan

Mengapa prompt dan konteks saja tidak cukup

Kisah klasik: tim melihat agen sering salah dan menghabiskan seminggu menulis AGENTS.md setebal lima halaman. Agen tetap tidak menjalankan linter sebelum commit. Penyebabnya bukan teks: agen memang tidak punya akses shell dengan izin yang diperlukan, dan linter tidak terpasang di image. Ini masalah alat dan lingkungan, tetapi yang diperbaiki adalah instruksinya.

Kisah kedua: agen mengerjakan bug yang sama untuk ketiga kalinya berturut-turut, karena setelah dimulai ulang ia tidak ingat apa yang sudah dicoba. Context engineering di dalam sesi tidak membantu di sini: jendelanya dibersihkan. Yang dibutuhkan adalah subsistem status — file tempat agen mencatat percobaan dan keputusan, plus aturan untuk membacanya di awal pekerjaan.

Kisah ketiga adalah yang paling mahal: agen menulis «selesai», tes unit hijau, tetapi fitur tidak berfungsi. Tidak ada prompt «periksa dengan teliti» atau dokumen tambahan di konteks yang akan memberi agen pemeriksaan independen. Pemeriksaan itu hanya datang dari umpan balik mesin: tes end-to-end, skrip verifikasi, atau penilai terpisah tanpa akses ke penalaran pelaksana.

Kesimpulan umum: prompt dan konteks memengaruhi apa yang dipikirkan model. Harness memengaruhi apa yang bisa dilakukan model dan apa yang diketahuinya setelah bertindak.

Mengapa mengganti model tidak membantu

Reaksi umum terhadap agen yang tidak stabil adalah mengambil model yang lebih kuat. Biasanya ini tidak menyelesaikan masalah: model yang sama di repositori yang tertata dengan baik bekerja seperti senior yang percaya diri, tetapi di repositori tanpa perintah verifikasi dan tanpa deskripsi stack ia kebingungan. Model yang lebih kuat tidak akan menebak konvensi tim Anda, tidak mendapatkan akses ke basis data yang memang tidak tersedia, dan tidak tahu bahwa migrasi rusak jika tidak ada yang menjalankannya.

Harness juga tidak menjadi usang dengan rilisnya model baru. Instruksi, lingkungan yang dapat direproduksi, dan pemeriksaan tetap dibutuhkan oleh model apa pun. Yang berubah hanyalah seberapa banyak micromanagement manual yang bisa dihapus: model yang kuat cukup diberi invarian («data divalidasi di batas domain»), bukan instruksi langkah demi langkah.

Cara memutuskan tingkat mana yang diperbaiki

Diagnosis berdasarkan gejala lebih cepat daripada eksperimen apa pun:

Dari mana memulai harness

Jika membangun dari nol, urutan praktisnya adalah: umpan balik → instruksi → status → lingkungan → alat. Umpan balik didahulukan karena tanpanya dampak perubahan lain tidak bisa diukur. Selama belum ada perintah yang jujur menjawab «berfungsi atau tidak», setiap perbaikan instruksi hanya dinilai dengan perasaan.

Titik awal minimal terlihat seperti ini:

# AGENTS.md (cuplikan)
## Cara memeriksa
- make check   # lint, tipe, tes unit
- make e2e     # skenario end-to-end
Fitur dianggap siap hanya jika kedua perintah selesai dengan kode 0.

## Aturan
- MUST: semua kueri SQL diparameterisasi
- MUST: sebelum commit jalankan make check
- Rincian pembayaran: docs/payments.md (baca ketika tugas menyentuh pembayaran)

Perhatikan baris terakhir: itu adalah context engineering di dalam harness. File masukan adalah peta, bukan buku pelajaran; rincian dimuat berdasarkan kondisi «kapan».

Cara mengukur kontribusi setiap bagian

Harness memiliki metrik yang tidak dimiliki prompt: proporsi tugas yang dinyatakan selesai oleh agen tetapi tidak dikonfirmasi pemeriksaan independen. Metrik ini disebut verification gap. Ambil 10 tugas berturut-turut, dan setelah setiap tugas catat apakah agen menyatakan «selesai» dan apakah pemeriksaan lulus — Anda mendapatkan angka yang bisa dibandingkan setelah setiap perubahan.

Untuk mengetahui subsistem mana yang memberi dampak, dipakai ablasi: model dan kumpulan tugas dipertahankan, lalu satu bagian harness dinonaktifkan dan penurunan kualitasnya diamati. Ada dua hal yang perlu diingat. Mulailah bukan dari ablasi, melainkan dari log kegagalan: penandaan di lapisan mana sesuatu rusak lebih cepat menunjukkan titik hambatan. Dan penurunan nol tidak membuktikan bahwa komponen itu tidak berguna: bisa jadi set tugas ini tidak pernah menggunakannya.

Kesalahan umum

• Menganggap harness sama dengan file prompt. Instruksi hanyalah satu dari lima subsistem. Rak resep belum berarti dapur.
• Memperbaiki ketiadaan alat dengan teks. «Selalu jalankan tes» tidak berguna jika tes tidak bisa dijalankan di lingkungan agen.
• Memperbesar instruksi. Semakin panjang file masukan, semakin besar kemungkinan aturan penting tidak terbaca. Aturan penting sebaiknya diubah menjadi pemeriksaan yang bisa dijalankan.
• Mempercayai laporan diri agen. Model yang menilai pekerjaannya sendiri cenderung melebih-lebihkan. Pemeriksaan harus dilakukan oleh skrip atau agen terpisah dengan konteks bersih.
• Mengonfigurasi harness sekali saja. Harness menjadi usang seperti kode: aturan melenceng dari kenyataan, perintah berubah. Ia perlu ditinjau secara berkala.

Kesimpulan

Prompt engineering memperbaiki rumusan, context engineering memilih informasi di jendela model, dan harness engineering membangun seluruh lingkungan agen, termasuk alat, lingkungan, status, dan pemeriksaan. Ketika agen bekerja lama dan mengubah kode sendiri, harnesslah yang menjadi penentu: ia mengubah «agen bilang selesai» menjadi «sistem memastikan ini berfungsi». Jadi dalam perdebatan harness vs context engineering, pilihannya bukan salah satu: konteks adalah bagian dari harness, dan subsistem yang harus diperbaiki ditunjukkan oleh gejalanya. Topik ini dibahas langsung dalam praktik di kursus harness engineering dengan proyek backend pembayaran sebagai contoh utuh.