Mengapa Anda harus belajar Teknik Harness? 5 Produk, 3 Aliran, 5 Prinsip Universal Penjelasan lengkap

Sistem Breakdown Harness Engineering 5 Produk, 3 Aliran (OpenAI / Anthropic / ThoughtWorks), 5 Prinsip Universal, dan Mengapa "Kegagalan Harness" Memaksa Anda Memotong Separuh Desain Setiap 6 Bulan. Artikel ini berasal dari tulisan @sairahul1 di artikel X, disusun dan diterjemahkan oleh 動區.
(Penjelasan sebelumnya: Pengantar Harness Engineering (AI Mengendalikan Engineering): Standar Pemrograman Terbaru OpenAI, Mengajarkan Mudah Mencapai Lv.1)
(Penambahan latar belakang: CEO YC berbagi rahasia AI: Masa depan milik mereka yang mampu membangun sistem bunga majemuk informasi)

Daftar Isi Artikel

Toggle

• 1. Definisi Harness
• 2. Metafora OS
• 3. Apa yang benar-benar berubah pada tahun 2026
• 4. File AGENT.md / CLAUDE.md
• 5. Daftar Fitur JSON (Pelacak Kemajuan)
  • Mengapa JSON bukan Markdown?
• 6. Rutinitas Inisialisasi Session
• 7. Kontrak Sprint
  • Mengapa Penting
• 8. Template Tugas Terstruktur
• 9. Aliran OpenAI: Prioritas Lingkungan
  • Cara mereka
  • Bukti
• 10. Aliran Anthropic: Memisahkan "Melakukan" dan "Mengulas"
  • Solusi mereka: 3 agen khusus
  • Hasil (Uji A/B)
• 11. Aliran ThoughtWorks: Kerangka 2×2
  • Wawasan mereka: Mengklasifikasikan setiap kendali harness dengan dua sumbu
  • Matriks 2×2
• 12. Prinsip 1: Konteks Lebih Penting dari Instruksi
• 13. Prinsip 2: Perencanaan dan Eksekusi Harus Dipisah
• 14. Prinsip 3: Umpan Balik Tidak Boleh Dikompromikan
• 15. Prinsip 4: Lakukan Satu Hal Sekaligus
• 16. Prinsip 5: Basis Kode Adalah Dokumen
  • Implikasi Praktis
• 17. Kegagalan Harness (Harness Decay) Benar-Benar Ada
  • Inilah Kegagalan Harness
• 18. Dibangun untuk Dihapus (Build to Delete)
• 19. Realitas Biaya
  • Tapi ini bagian yang jarang dibahas
• Ringkasan Utama
  • Apa itu harness
  • 5 Produk harness
  • 3 aliran
  • 5 prinsip universal
  • Keanehan

Pada Februari 2026, OpenAI dengan tim kecil menghasilkan 1 juta baris kode produksi.

Mereka sama sekali tidak menulis satu baris pun.

Dibuat oleh agen AI.

Dirancang manusia, adalah sistem yang membuat agen dapat diandalkan.

Sistem ini sekarang punya nama—Harness Engineering.

Dalam beberapa minggu, Anthropic merilis 3 makalah terkait. ThoughtWorks menyusun menjadi kerangka. Philipp Schmid dari Hugging Face menyebutnya secara langsung sebagai "Ilmu Terpenting 2026".

Dalam 90 hari, sebuah disiplin engineering baru terbentuk. Dan di luar tim infra AI, hampir tidak ada yang memahaminya.

Artikel ini akan menjelaskannya dengan jelas. Tanpa omong kosong, tanpa istilah akademik, hanya model mental yang benar-benar Anda perlukan untuk digunakan.

1. Definisi Harness

Definisi paling sederhana dari ThoughtWorks:

Agent = Model + Harness

Harness adalah semua hal di luar model.

• Pembatas yang menahan agent agar tetap di jalur
• Umpan balik untuk mendeteksi kesalahan
• Dokumen yang memberi tahu agent di mana dia berada
• Alat yang diizinkan digunakan agent

Menghilangkan harness → sebuah model bahasa mentah yang menebak-nebak di dalam codebase Anda.

Menambahkan harness yang tepat → sebuah sistem yang mampu menghasilkan kode produksi.

Nama ini berasal dari perlengkapan berkuda. Harness adalah tali kekang, pelana, dan pelana kuda—mengarahkan kekuatan besar yang sulit diprediksi ke arah yang berguna.

Anda bukan membuat kuda menjadi lebih pintar, Anda merancang perlengkapannya agar kekuatannya berguna.

2. Metafora OS

Philipp Schmid memberi metafora teknis terbaik: Bayangkan seperti sebuah komputer.

| Peran | | --- | | Model | CPU (daya komputasi dasar) | | Context window | RAM (memori kerja terbatas dan mudah menguap) | | Harness | OS (mengatur apa yang dilihat CPU dan kapan) | | Agent | Aplikasi yang berjalan di atasnya |

Model Anda sangat kuat. Tapi tanpa OS untuk mengelola memori, penjadwalan tugas, dan aturan eksekusi—dia hanyalah sebuah chip silikon.

Kebanyakan orang menjalankan aplikasi tanpa "sistem operasi". Jadi agen mereka langsung rusak saat masuk ke jalur produksi.

3. Apa yang benar-benar berubah pada tahun 2026

LangChain menggunakan model yang sama, menjalankan dua kali di Terminal Bench 2.0:

| Harness | | --- | Skor | | --- | --- | | Harness lama | 52.8% | | Harness baru | 66.5% |

Model yang sama. Harness berbeda. Perbedaan 13.7 poin persentase.

Vercel malah melakukan sebaliknya—mengurangi tool agent sebesar 80%. Hasilnya? Lebih baik, bukan lebih buruk.

Realitas paling tidak nyaman tahun 2026:

• Agent tidak pernah menjadi bagian yang sulit
• Harness adalah bagian yang sulit

Jika 2025 adalah tahun agen AI membuktikan mampu menulis kode, 2026 adalah tahun penemuan bahwa "lingkungan" lebih penting daripada "model".

4. File AGENT.md / CLAUDE.md

Produk harness paling umum.

File markdown tersebar di seluruh codebase. Setiap sesi agent dimulai dengan membacanya—seperti onboarding karyawan baru.

Isi apa?

• Konteks proyek
• Konvensi kode
• Keputusan arsitektur
• Panduan "kami melakukan ini"
• Hal yang sedang dikerjakan saat ini

OpenAI menyebutnya AGENT.md. Anthropic menyebutnya CLAUDE.md. Cursor menggunakan .cursorrules.

Nama berbeda, prinsip sama. Satu file untuk setiap modul utama. Diperbarui sesuai perkembangan proyek.

Tanpa ini: agent setiap sesi seperti menyalakan mesin dalam gelap. Dengan ini: agent setiap sesi membawa informasi dan langsung bekerja.

5. Daftar Fitur JSON (Pelacak Kemajuan)

Ketika agent melintasi beberapa sesi untuk membangun sebuah aplikasi, setiap window konteksnya kosong. Bagaimana dia tahu apa yang sudah selesai?

Sebuah file JSON.

Setiap entri berisi:

• Sebuah fitur
• Cara memverifikasi keberhasilannya
• Status Pass / Fail

Sesi agent dimulai dengan membacanya—memprioritaskan fail tertinggi → implementasi → tandai pass → commit → ulangi.

Mengapa JSON bukan Markdown?

Anthropic menemukan: kemungkinan agent menimpa JSON lebih rendah daripada Markdown.

Detail kecil, tapi sangat penting dalam skenario berjalan otomatis selama 6 jam.

6. Rutinitas Inisialisasi Session

Setiap sesi dimulai dengan cara yang sama. Setiap kali.

7 langkah inisialisasi Anthropic:

2. Verifikasi direktori kerja
3. Baca git log dan file progres
4. Ambil fitur tertinggi prioritas yang belum selesai
5. Mulai dev server
6. Jalankan verifikasi E2E dasar
7. Implementasikan sebuah fitur
8. Commit dengan pesan deskriptif, dan perbarui progres

Tanpa ini: agent 20 menit pertama hanya memahami status saat ini, setiap sesi mengulang dari awal. Dengan ini: agent langsung bekerja dengan informasi yang sudah ada.

7. Kontrak Sprint

Sebelum menulis satu baris kode—dua agent terlebih dahulu bernegosiasi.

Generator agent mengusulkan:

• Apa yang akan dilakukan
• Bagaimana memverifikasi keberhasilan

Evaluator agent meninjau:

• Apakah proposal lengkap?
• Apakah standar keberhasilan jelas?

Jika keduanya setuju, baru mulai implementasi.

Ini adalah review desain. Hanya saja keduanya AI.

Mengapa Penting

Dalam satu putaran, jika agent merencanakan dan melaksanakan secara bersamaan, hasilnya tidak dapat diandalkan. "Perencanaan"—meskipun dilakukan AI—akan sangat meningkatkan kualitas output.

8. Template Tugas Terstruktur

Sebelum menulis kode, harness terlebih dahulu menganalisis codebase yang sesungguhnya.

Hasilnya adalah peta dampak yang grounded:

• Path file nyata (bukan ilusi)
• Nama simbol yang benar-benar ada
• Pola yang sudah ada dan bisa diikuti
• Standar penerimaan yang konkret

Baru setelah itu implementasi dimulai.

Terdengar wajar. Tapi kebanyakan tim melewatkan langkah ini.

Agent menebak struktur file, menciptakan API yang tidak ada, membuat sesuatu yang tidak cocok dengan codebase.

Memiliki konteks grounded terlebih dahulu, lalu eksekusi → kualitas output jauh lebih baik.

9. Aliran OpenAI: Prioritas Lingkungan

Tim Codex OpenAI punya masalah aneh:

1 juta baris kode produksi, tanpa satu baris pun yang ditulis manual.

Dalam skala itu, Anda tidak mungkin melakukan review kode baris demi baris. Jadi mereka tidak melakukannya.

Sebaliknya—mereka mendesain lingkungan sedemikian rupa sehingga agent dari awal mampu menghasilkan output yang "dapat direview".

Cara mereka

• Dependensi yang ketat (Types → Config → Repo → Service → Runtime → UI)
• Seluruh codebase tersebar dalam AGENT.md
• Agent langsung terintegrasi ke pipeline CI/CD

Filosofi: Desain lingkungan. Lalu biarkan agent berjalan.

Bukti

Aplikasi Sora Android. 4 insinyur. 28 hari. Peringkat #1 di Play Store. 99.9% crash-free.

Codex setiap minggu menangani 70% PR internal.

10. Aliran Anthropic: Memisahkan "Melakukan" dan "Mengulas"

Anthropic menghadapi masalah lain:

Ketika mereka meminta agent menilai outputnya sendiri, agen akan dengan percaya diri memuji karya sendiri—meskipun dari sudut pandang manusia, kualitasnya jelas biasa saja.

Self-assessment tidak cukup. Agent adalah siswa dan guru sekaligus, lalu memberi nilai A semua.

Solusi mereka: 3 agen khusus

| Agen | | --- | | Planner | Mengubah prompt 2 kalimat menjadi spesifikasi produk lengkap | | Generator | Implementasi satu sprint sekaligus | | Evaluator | Menggunakan otomatisasi browser untuk pengujian, berperilaku seperti pengguna nyata |

Wawasan: Membuat "Evaluator independen" menjadi lebih cerewet, lebih mudah daripada membuat generator cerewet terhadap karya sendiri.

Hasil (Uji A/B)

| Pengaturan | | --- | Biaya | Waktu | Hasil | | --- | --- | --- | --- | | Agen tunggal (tanpa harness) | $9 | 20 menit | Aplikasi rusak | | Harness lengkap | $200 | 6 jam | Software yang bisa berjalan + UI canggih |

11. Aliran ThoughtWorks: Kerangka 2×2

ThoughtWorks mendekati dari sudut berbeda—bukan membuat produk, tetapi melihat 50+ tim engineering gagal di tempat yang sama.

Wawasan mereka: Mengklasifikasikan setiap kendali harness dengan dua sumbu

Sumbu 1: Kapan berfungsi?

• Feedforward = sebelum aksi agent (petunjuk)
• Feedback = setelah aksi agent (sensor)

Sumbu 2: Bagaimana berfungsi?

• Komputasional = deterministik, milidetik (linter, type checker, test suite)
• Inferensial = menggunakan LLM, detik (review kode, analisis semantik)

Matriks 2×2

| | | --- | | Feedforward (Petunjuk) | | Feedback (Sensor) | | --- | --- | --- | | Computational | sistem tipe, linter, aturan arsitektur | test suite, coverage, mutation test | | Inferensial | dokumen spesifikasi, deskripsi batasan | LLM review kode, verifikasi perilaku |

Feedforward dan feedback keduanya harus ada. Tidak bisa hanya salah satu.

12. Prinsip 1: Konteks Lebih Penting dari Instruksi

Berbagai tim, penemuan yang sama:

• OpenAI: Berikan peta, jangan berikan manual 1.000 halaman
• Anthropic: Daftar fitur JSON + file progres, agar agent selalu tahu posisinya
• Red Hat: Sebelum melakukan tugas, analisis codebase nyata
• ThoughtWorks: Disebut "Feedforward"

Mengaitkan agent dengan "status dunia saat ini" selalu lebih unggul daripada memberi instruksi abstrak.

Mengaitkan ke file nyata → menyesuaikan kode dengan codebase. Dari deskripsi samar → jalur ilusi dan API yang dibuat-buat.

Sebelum agent mengetik, pastikan dia tahu di mana dia berada.

13. Prinsip 2: Perencanaan dan Eksekusi Harus Dipisah

• OpenAI: Manusia mendesain lingkungan, agent menjalankan
• Anthropic: Agen Planner khusus menjalankan sebelum Generator
• ThoughtWorks: Memaksa manusia meninjau checkpoint antara perencanaan dan pelaksanaan
• Red Hat: Ada penghalang keras antara Phase 1 (peta dampak) dan Phase 2 (implementasi)

Setiap aliran menyadari: Jika agent merencanakan dan melaksanakan dalam satu putaran, hasilnya tidak dapat diandalkan.

Perencanaan—meskipun dilakukan AI—harus dipisah dan hasilnya harus ditinjau sebelum mulai bekerja.

14. Prinsip 3: Umpan Balik Tidak Boleh Dikompromikan

• OpenAI: agent terintegrasi ke CI/CD dan observability
• Anthropic: agen Evaluator khusus + otomatisasi browser
• ThoughtWorks: formal sebagai "sensor", memperingatkan bahwa hanya feedforward tidak akan pernah memastikan efektivitas petunjuk

Tiga aliran, tiga pendekatan berbeda untuk prinsip yang sama:

| Aliran | | --- | | Sumber Umpan Balik | | --- | --- | | OpenAI | Pengujian otomatis + CI | | Anthropic | LLM lain | | ThoughtWorks | Menggabungkan keduanya |

Mereka berbeda dalam "siapa yang memberi umpan balik". Tapi mereka sepakat: Anda membutuhkan umpan balik.

Tanpa umpan balik, harness hanyalah prompt dengan langkah tambahan.

15. Prinsip 4: Lakukan Satu Hal Sekaligus

• OpenAI: Pecah target menjadi bagian kecil, prioritaskan secara mendalam
• Anthropic: Wajibkan "setiap sprint hanya satu fitur", selesai langsung commit
• ThoughtWorks: Siklus hidup bertahap (pra-integrasi → pasca-integrasi → monitoring terus-menerus)

Membuat banyak agent sekaligus:

• Menghabiskan konteks
• Mengurangi koherensi
• Diam-diam membuang kebutuhan

Rutinitas Anthropic: Baca progres → Pilih SATU fitur → Implementasi → Commit → Ulangi.

"Prinsip kemajuan bertahap" adalah ciri utama harness yang sukses.

16. Prinsip 5: Basis Kode Adalah Dokumen

• OpenAI: AGENT.md tertanam di repo
• Anthropic: daftar fitur, file progres, riwayat git adalah mekanisme kontinuitas agent
• ThoughtWorks: Mengukur "kemampuan harness"—kemudahan agent membaca codebase

Tak satu pun akan memelihara pengetahuan terpisah untuk agent. Repo adalah satu-satunya kebenaran.

Jika sebuah kebijakan, batasan, keputusan arsitektur tidak ada di codebase → agent tidak akan tahu.

Implikasi Praktis

• Tim yang bersedia berinvestasi dalam organisasi kode, secara gratis mendapatkan performa agent yang lebih baik
• Repo yang kotor + AI agent = kekacauan yang membesar

17. Kegagalan Harness (Harness Decay) Benar-Benar Ada

Ketika Anthropic upgrade dari Opus 4.5 ke Opus 4.6—Pembongkaran sprint (yang sebelumnya wajib) berubah menjadi beban berat.

Kemampuan perencanaan model meningkat, membuat bagian itu menjadi berlebihan.

Pada bulan Maret, komponen harness yang masih menanggung beban, pada bulan April sudah menjadi overhead.

Lalu saat Opus 4.7 dirilis—model mulai memverifikasi output sendiri, tugas agen Evaluator menyusut lagi.

Inilah Kegagalan Harness

Setiap komponen dalam harness mengandung asumsi "model tidak mampu melakukan ini". Ketika model berkembang → asumsi itu usang → komponen menjadi overhead.

| Versi Model | | --- | Status Harness | | --- | --- | | Opus 4.5 | Pembongkaran sprint + evaluasi tiap sprint | | Opus 4.6 | Tanpa pembongkaran sprint + evaluasi tunggal (hemat 38% biaya) | | Opus 4.7 | Model memverifikasi sendiri → peran evaluator menyusut lagi |

18. Dibangun untuk Dihapus (Build to Delete)

Saran Philipp Schmid: "Build to delete."

Saat merancang setiap komponen harness, rancang agar bisa dihapus.

Uji secara berkala setiap komponen—matikan, lihat apakah kualitas output menurun. Tidak menurun → hapus.

| Tim | | --- | Refaktor dalam 6 bulan | | --- | --- | | Manus | Refaktor harness 5 kali | | LangChain | Refaktor 3 kali dalam 1 tahun | | Vercel | Hapus 80% tool → performa membaik |

Ini bukan tanda proyek buruk. Ini adalah konsekuensi alami dari "membangun di atas model yang cepat berkembang".

Komponen harness yang mati setiap kali dijalankan hanya membakar token, tanpa kontribusi kualitas—hanya pemborosan.

19. Realitas Biaya

Angka jujur dari A/B test Anthropic:

| Pengaturan | | --- | Biaya | Waktu | Hasil | | --- | --- | --- | --- | | Agen tunggal (tanpa harness) | $9 | 20 menit | UI rusak, inti rusak | | Harness lengkap (Opus 4.5) | $200 | 6 jam | Perangkat lunak berjalan, UI canggih, fisika benar |

22 kali lipat biaya—beralih ke produk yang benar-benar bisa berjalan, bukan sekadar demo screenshot.

Apakah layak? Tergantung seberapa besar biaya kerusakan rilis terhadap tim Anda.

Tapi ini bagian yang jarang dibahas

Gabungan harness + model adalah evolusioner.

$200 harness, setelah upgrade model, jadi $124.

| Tren Garis | | --- | | Model lebih baik = harness lebih sederhana = biaya satu kali jalan lebih murah = output lebih cepat |

Pemenang tahun 2026 bukanlah yang menulis kode terbaik.

Mereka adalah orang yang merancang "batasan" terbaik.

Dan mereka bersedia membuang batasan itu saat berhenti menguntungkan.

Ringkasan Utama

Apa itu harness

2. Agent = Model + Harness
3. Model = CPU, Harness = OS
4. Model yang sama, harness lebih baik → +13% performa

5 Produk harness

5. CLAUDE.md / AGENT.md — dokumen onboarding agent
6. Daftar fitur JSON — pelacak progres + suite pengujian gabungan
7. Rutinitas inisialisasi session — 7 langkah yang sama
8. Kontrak sprint — negosiasi sebelum agen menulis kode
9. Template tugas terstruktur — path file nyata, pola nyata

3 aliran

10. OpenAI: desain lingkungan, jalankan agent
11. Anthropic: pisahkan "melakukan" dan "mengulas"
12. ThoughtWorks: kerangka 2×2 feedforward/feedback

5 Prinsip Universal

13. Konteks lebih penting dari instruksi
14. Perencanaan dan eksekusi harus dipisah
15. Umpan balik tidak boleh dikompromikan
16. Lakukan satu hal sekaligus
17. Basis kode adalah dokumen

Keanehan

18. Kegagalan Harness — yang efektif bulan lalu, bulan ini menurun
19. Dibangun untuk Dihapus — uji dan hapus komponen mati secara rutin
20. Realitas Biaya — model lebih baik = harness lebih sederhana = biaya lebih murah

Pemenang tahun 2026 bukanlah yang menulis kode terbaik. Mereka adalah orang yang merancang batasan terbaik—dan bersedia membuangnya saat tidak lagi menguntungkan.