Harness Engineering: Era ketika desain lingkungan kerja lebih penting daripada model

Ini adalah analisis tentang “Harness Engineering” yang dirangkum oleh Addy Osmani. Ia menilai bahwa selama dua tahun terakhir, perhatian industri terlalu terpusat pada pertanyaan “model AI mana yang lebih pintar.” Perbandingan tanpa akhir terus berlanjut soal apakah GPT menulis kode yang lebih rapi, atau Claude lebih jarang berhalusinasi, tetapi argumennya adalah bahwa performa AI coding di dunia nyata justru lebih ditentukan oleh harness yang mengelilingi model itu daripada modelnya sendiri. Harness adalah istilah yang mencakup segala sesuatu selain model: system prompt yang memerintahkan AI bekerja, tool dan server eksternal yang bisa digunakan, kebijakan pengelolaan konteks, perangkat pemeriksaan otomatis yang menyela saat eksekusi (hook), ruang eksekusi aman (sandbox), AI pendamping (subagent), feedback loop, hingga alur pemulihan saat pekerjaan menemui hambatan. Viv Trivedy meresmikan konsep ini dalam satu kalimat, “AI agent = model + harness”, dan orang-orang seperti tim engineering Anthropic, HumanLayer, dan Simon Willison terus mematangkannya. Osmani melihat arus ini kini telah mapan sebagai satu bidang rekayasa tersendiri.

Jika dijabarkan, poin-poin utamanya adalah sebagai berikut.

• Apa itu harness Model saja tidak cukup untuk menjadi AI yang bisa benar-benar menyelesaikan pekerjaan. Ia baru menjadi “AI yang bekerja” ketika ditambah kode dan konfigurasi yang memungkinkannya mengingat progres, menjalankan tool, melihat hasilnya lalu menilai ulang, serta mencegah hal-hal yang seharusnya tidak dilakukan. Produk seperti Claude Code, Cursor, Codex, Aider, dan Cline semuanya adalah harness, dan meskipun model di dalamnya sama, perilaku yang kita rasakan ditentukan oleh harness-nya. Meminjam ungkapan Simon Willison, AI agent adalah “sistem yang berulang kali menjalankan tool untuk mencapai tujuan”, dan inti kemampuannya terletak pada bagaimana tool dan struktur pengulangannya dirancang.

• Sudut pandang bahwa masalahnya bukan model, melainkan konfigurasi Ketika AI melakukan hal aneh, engineer sering menyalahkan model dan berakhir pada kesimpulan “tunggu versi berikutnya saja.” Harness engineering menolak reaksi ini. Meminjam ungkapan HumanLayer, “ini bukan masalah model, tapi masalah konfigurasi (skill issue).” Bahkan saat memakai model yang sama, Claude Opus 4.6, ada kasus di mana performanya tetap berada di papan bawah Terminal Bench 2.0 saat dijalankan dalam harness bawaan Claude Code, tetapi melonjak ke papan atas ketika dipindah ke harness yang disetel sendiri. Tim Viv menaikkan model yang sama dari sekitar peringkat 30 ke sekitar peringkat 5 hanya dengan mengganti harness. Artinya, potensi model sering kali justru tergerus oleh harness yang kurang tepat.

• Prinsip “ratchet” yang mengubah kesalahan menjadi aturan permanen Kesalahan yang pernah dibuat AI sekali pun tidak dianggap sekadar kecelakaan, melainkan sinyal permanen. Agar kesalahan yang sama tidak terulang, tim menambahkan satu baris ke dokumen aturan, memasang pemblokir otomatis, atau menugaskan AI pendamping untuk review, sehingga sistem makin diperketat selangkah demi selangkah. Misalnya, jika AI pernah mengomentari test code, maka versi aturan berikutnya akan memuat baris “jangan komentari test; hapus atau perbaiki,” dan tahap pemeriksaan sebelum commit akan ditambah checker yang menangkap pola seperti itu. Intinya, setiap baris dalam dokumen aturan yang baik harus terhubung dengan kegagalan konkret yang pernah terjadi. Karena itu, harness engineering bukan sekadar memakai framework buatan orang lain apa adanya, melainkan lebih dekat dengan “disiplin” yang tumbuh mengikuti riwayat kegagalan codebase sendiri.

• Merancang mundur dari perilaku yang diinginkan Pola pikir paling berguna yang diajukan Viv adalah mendesain secara terbalik: “Saya ingin perilaku seperti ini → komponen harness apa yang memungkinkan perilaku itu?” Jika Anda tidak bisa menjelaskan dalam satu kalimat komponen tertentu itu ada untuk perilaku apa, lebih baik komponen itu dibuang. Secara konkret, file system dan Git dipakai untuk menyimpan pekerjaan jangka panjang dan memulihkannya, bash dan eksekusi kode menjadi tool serbaguna untuk mencoba apa pun, sandbox adalah ruang aman agar kerusakan tidak berdampak pada sistem utama, memory file serta web search dan tool MCP menjadi jalur untuk menumpuk pengetahuan baru, ringkasan kompresi, pemisahan output tool, dan fitur skill memperpanjang batas memori AI, sedangkan Ralph loop dan struktur pemisahan planner-evaluator adalah cara membawa tugas panjang berhari-hari sampai tuntas.

• Masalah context rot AI memiliki batas jumlah teks yang bisa dibaca sekaligus, dan saat mendekati batas itu, kemampuan menilainya turun secara nyata. Karena itu, harness juga merupakan kumpulan mekanisme untuk memakai ruang terbatas tersebut seefisien mungkin. Pertama, ketika batas mulai penuh, isi lama diringkas secara cerdas dan dikompresi. Kedua, output besar seperti log 2.000 baris hanya menyisakan bagian awal dan akhir, sementara isi tengah dipindahkan ke file agar dibaca lagi hanya saat perlu. Ketiga, tool dan instruksi tidak ditampilkan semuanya sejak awal, melainkan memakai pendekatan “pengungkapan bertahap” yang hanya mengeluarkan hal yang benar-benar dibutuhkan untuk tugas tersebut pada saatnya. Untuk tugas yang benar-benar panjang, pekerjaan bahkan bisa dimulai ulang di jendela baru hanya dengan membawa dokumen serah terima. Anthropic menekankan bahwa “untuk tugas panjang, kompresi ringkasan saja tidak cukup; ada saatnya harus mulai ulang dengan dokumen handoff yang terstruktur.” Ini mirip seperti menyiapkan dokumen rapi saat menyerahkan pekerjaan kepada pegawai baru.

• Pola-pola untuk membawa tugas panjang sampai selesai Salah satu kelemahan model saat ini adalah cenderung ingin cepat-cepat mengakhiri pekerjaan, tidak pandai memecah masalah besar menjadi bagian kecil, dan alurnya mudah putus saat jendela konteks berubah. Harness harus menutupi kelemahan ini. Ralph loop adalah teknik sederhana di mana setiap kali model mencoba mengakhiri pekerjaan, hook akan mencegat dan menyuntikkan kembali tujuan awal ke jendela konteks baru agar pekerjaan terus berjalan. Tiap iterasi dimulai dari keadaan bersih, tetapi hasil pekerjaan sebelumnya tetap diteruskan lewat file system. Sementara itu, Anthropic menekankan bahwa “pembuat” dan “penilai” sebaiknya dipisahkan ke AI yang berbeda, karena AI cenderung memberi nilai terlalu murah hati pada hasil buatannya sendiri. Selain itu, pola “sprint contract” yang menyepakati sejak awal seperti apa kondisi “selesai” efektif mencegah tujuan melar diam-diam di tengah pekerjaan.

• Peran hook “Memberi tahu AI agar melakukan sesuatu” berbeda dengan “membuat sistem memaksanya melakukan itu.” Hook adalah mekanisme otomatis yang menjembatani perbedaan itu, dengan menyela pada momen seperti sebelum memakai tool, setelah mengubah file, sebelum commit, atau saat sesi dimulai. Misalnya, setiap kali kode diubah, sistem otomatis menjalankan pemeriksaan sintaks, lint, dan test; memblokir perintah berbahaya seperti rm -rf atau git push --force; atau mewajibkan persetujuan manusia sebelum mengajukan PR. Prinsipnya adalah “keberhasilan senyap, kegagalan berisik.” Jika pemeriksaan lolos, AI tidak mendengar apa-apa; jika gagal, pesan error itu sendiri disuntikkan ke alur agar AI bisa memperbaikinya. Strukturnya nyaris tidak menambah biaya pada kondisi normal, tetapi memberikan bantuan yang sangat tepat hanya saat masalah benar-benar muncul.

• Dokumen aturan dan pemilihan tool harus singkat dan jelas AGENTS.md yang ditempatkan di root proyek adalah file konfigurasi paling berpengaruh karena masuk ke system prompt di setiap giliran. HumanLayer menyarankan agar dokumen ini dijaga di bawah 60 baris. Semakin panjang, bobot tiap baris makin memudar, jadi ini bukan panduan untuk menuliskan gaya umum, melainkan daftar cek penting layaknya checklist pilot. Tool juga sama: karena nama, deskripsi, dan schema-nya masuk ke prompt di setiap request, 10 tool yang dipoles dengan baik lebih baik daripada 50 tool yang mirip-mirip. HumanLayer juga menyoroti sisi keamanan. Karena deskripsi tool adalah teks yang dibaca AI, menghubungkan server MCP eksternal yang tidak tervalidasi bisa menjadi jalur penyuntikan instruksi tersembunyi yang ditulis orang lain sebelumnya.

Bagian yang bisa dilihat sebagai kelebihan.

• Menjadi jelas di mana upaya harus difokuskan Data benchmark menunjukkan bahwa harness adalah titik di mana perilaku bisa ditingkatkan besar-besaran tanpa mengganti model. Artinya, alih-alih berharap samar “tunggu model berikutnya”, ada area konkret yang bisa dibenahi sekarang juga.
• Struktur yang membuat know-how menumpuk Berkat pendekatan ratchet yang mengubah kesalahan menjadi aturan, pelajaran yang didapat sekali akan tinggal sebagai aset tim. Walau orangnya berganti, dokumen aturan dan hook tetap ada untuk melindungi orang berikutnya.
• Munculnya harness siap pakai (HaaS) Arus yang disebut Viv sebagai “Harness-as-a-Service” cepat menguat. Produk seperti Claude Agent SDK, Codex SDK, dan OpenAI Agents SDK mulai membundel loop kerja, tool, pengelolaan konteks, hook, dan sandbox, sehingga tim bisa fokus pada pengetahuan domain mereka tanpa harus membangun semuanya dari nol.

Ada juga bagian yang terasa membebani.

• Cakupan yang harus diperhatikan luas Instruksi, tool, ruang eksekusi aman, pemeriksaan otomatis, hingga observasi log semuanya harus ditangani sendiri. Intinya, ini bukan area yang akan dibereskan otomatis oleh penyedia model.
• Risiko keterikatan antara model dan harness Model saat ini dilatih pascapemrosesan dalam harness tertentu, sehingga ketika dipindah ke harness lain performanya bisa tiba-tiba turun. Mengubah satu nama tool atau satu format argumen saja bisa menggoyahkan hasil. Jika model benar-benar umum, seharusnya nama tool tidak berpengaruh, tetapi karena struktur pelatihannya berjalan bersama, muncullah semacam overfitting.
• Risiko keamanan dari tool eksternal Karena deskripsi tool di server MCP dibaca AI apa adanya, begitu tool yang tidak tervalidasi dihubungkan, bahkan sebelum pengguna mengetik satu huruf pun, teks eksternal sudah mulai memengaruhi AI.

Sudut pandang yang membedakan.

• Menjaga jarak dari wacana yang berpusat pada model Alih-alih menunggu GPT yang lebih pintar, pendekatan ini menawarkan cara rekayasa untuk mendorong batas kemampuan model yang sudah dimiliki saat ini. Diagnosisnya adalah bahwa kesenjangan antara keterbatasan AI yang kita lihat hari ini dan kemampuan nyata model sebagian besar adalah kesenjangan harness.
• Harness tidak hilang, hanya pindah tempat Saat model membaik, beberapa komponen harness menjadi tidak perlu. Misalnya, Opus 4.6 hampir menghilangkan kecenderungan terburu-buru yang umum pada Claude Sonnet 4.5, seperti “konteksnya sebentar lagi habis, jadi saya harus cepat menyelesaikan ini,” sehingga perangkat pengaman yang dulu dipakai menjadi dead code. Namun, di wilayah baru yang kini bisa dijangkau model, muncul kelemahan baru, dan harness baru kembali dibutuhkan untuk menutupinya. Ungkapan Anthropic, “setiap komponen harness memuat asumsi tentang hal apa yang belum bisa dilakukan model sendirian,” sangat pas di sini.
• Siklus belajar antara model dan harness Arus lain yang disorot Viv adalah loop umpan balik antara desain harness dan pelatihan model. Ketika pola yang berguna ditemukan di harness, pola itu distandardisasi, lalu generasi model berikutnya dilatih berdasarkan pola tersebut, dan di atas model baru itu lahir lagi pola harness baru. Karena itu, kesimpulannya bukan bahwa “harness yang baik” adalah harness tempat model itu dilatih, melainkan harness yang disesuaikan ulang dengan pekerjaan Anda sendiri.
• Industri mengerucut ke bentuk yang mirip Coding AI seperti Claude Code, Cursor, Codex, Aider, dan Cline memakai model yang berbeda di dalamnya, tetapi bentuk harness-nya makin mirip. Fakta bahwa modelnya berbeda namun harness-nya serupa bisa dibaca sebagai sinyal ke mana bidang ini sedang mengendap.

Tulisan Osmani mengajukan pandangan bahwa daya saing coding AI lebih banyak ditentukan oleh desain harness di sekeliling model daripada pemilihan model itu sendiri, dan bahwa harness bukan file konfigurasi yang diatur sekali lalu selesai, melainkan sistem hidup yang terus diperbarui mengikuti riwayat kegagalan. Saat model membaik, harness tidak lenyap, melainkan lapisan masalah yang ditanganinya naik satu tingkat dan harness baru mengisi tempat itu. Seperti kata Viv yang dikutipnya, “membangun agent yang baik adalah seni iterasi, dan tanpa versi pertama, tidak akan ada iterasi,” yang dapat dibaca sebagai bahwa bidang ini pada akhirnya adalah soal siapa yang lebih cepat memulai dan lebih sering menyempurnakan. Pada akhirnya, tempat engineer seharusnya mencurahkan waktu bukanlah terus-menerus mengganti model yang sedang ramai dibicarakan, melainkan terus menyesuaikan harness yang cocok untuk pekerjaannya agar batas kemampuan model bisa dinaikkan selangkah demi selangkah.

[kimjoin2]

Rasanya makin banyak sekali istilah marketing yang bermunculan.

[dongho42]

Namun, jika saat diberi prompt seperti "tolong lakukan A, jangan lakukan B" AI benar-benar bisa memahaminya dengan baik, pendekatan seperti ini tampaknya akan efektif. Tetapi jika AI menjalankan prompt secara probabilistik tergantung pada kondisi server AI, apakah pendekatan seperti ini tetap efektif?

[dongho42]

Dulu saya sudah menulis dengan jelas di prompt untuk melakukan A, tapi tetap saja dengan probabilitas tertentu model sering tidak mematuhinya, jadi saya mencoba macam-macam hal seperti menekankannya dengan bold mrkdwn, menuliskannya dua kali, menuliskannya dalam bahasa Inggris, menuliskannya dengan struktur yang saling mengapit, menuliskannya dalam XML, tetapi tetap saja dengan probabilitas tertentu prompt-nya diabaikan...

[kurthong]

Saya juga memasukkan semua hal yang mirip dengan yang dibicarakan Osmani
saat sedang membuat aplikasi, lalu topik ini muncul jadi saya agak buru-buru menulisnya,
tapi rasanya akan lebih baik kalau Osmani juga tidak cuma bicara
melainkan memasukkan apa yang dia bicarakan ke Google Anti-Gravity.
Begitu juga dengan Kaparthy, sekarang rasanya mereka tidak benar-benar berniat membuat sesuatu dan hanya melempar tulisan begitu saja, entahlah!

https://github.com/hang-in/tunaFlow

[tangokorea]

Daripada melihat model dan harness dari sudut pandang mana yang lebih baik, bagaimana kalau kita mundur selangkah dan mempertimbangkan model mana yang lebih cocok dipasangkan dengan harness tertentu?

[jimmy2056]

Semakin bagus modelnya, semakin ringan juga beban perancangan harness.

[akapwhd]

Meski hal seperti ini diterapkan, saat benar-benar dipakai untuk coding rasanya tetap tidak banyak membantu... mungkin karena level pengembangannya cuma sebatas menjalankan agen dengan plan Codex ya haha

[blackfabric]

Ringkasan 3 baris

• Sistem (harness), bukan model, yang menentukan keberhasilan atau kegagalan: kinerja AI lebih ditentukan oleh desain lingkungan kerja yang disebut 'harness'—seperti prompt, alat, sandbox, dan feedback loop yang mengelilinginya—daripada model itu sendiri seperti GPT atau Claude
• Prinsip 'Ratchet' yang mengubah kesalahan menjadi aturan: kesalahan AI tidak boleh dianggap sekadar insiden, tetapi harus segera dicerminkan ke dokumen aturan (seperti AGENTS.md) atau hook agar sistem menjadi makin kokoh seiring waktu
• Masalahnya sering ada pada konfigurasi (skill), bukan pada model: ketika AI tidak mampu bekerja dengan baik, penyebabnya sering kali bukan kurangnya kecerdasan model melainkan buruknya desain harness, sehingga pendekatan rekayasa yang merancang komponen dan batasan yang diperlukan secara mundur dari hasil yang diinginkan menjadi sangat penting

[yungoun]

Tapi Harness sampai minggu lalu masih laris banget dipakai, lalu mulai minggu ini jadi sepi ya.. entah karena Anthropic bikin blunder dan Codex 5.5 memang lebih unggul........

[click]

Hal seperti SDD sudah lama kehilangan hype, jadi sekarang tampaknya giliran harness.
Bagian yang agak menarik dari harness adalah, meski jelas tidak ada di data pelatihan, model ternyata cepat memahami konsep harness.
Mungkin karena memakai makna kata yang memang sudah ada, meski saya tidak menyebutkannya, ia bahkan lebih dulu mengatakan hal-hal seperti memperbarui harness.

[kurthong]

Ini bahkan sampai menganalisis tulisan developer senior yang membuat omongan tanpa isi yang berarti terdengar meyakinkan (maaf, saya pribadi memang tidak suka Google). Tentu saja, saya rasa pendekatan untuk memahami fenomena ini adalah upaya yang bagus.