Setelah artikel terkait dari AI Times yang membahas 'argumen ketidakgunaan harness engineering di BigTech' dimuat, berbagai pemimpin teknologi berbagi pendapat mereka. Dilaporkan bahwa setelah Google, OpenAI juga memberikan pernyataan senada bahwa model generasi berikutnya dapat menyerap sebagian besar fungsi harness saat ini.
Tulisan ini juga menambahkan perspektif pada diskusi tersebut. Untuk menyatakan kesimpulan terlebih dahulu, saya setuju dengan prospek bahwa sebagian besar harness akan menjadi tidak berguna. Dalam postingan saya sendiri Penjelasan Lengkap Harness Engineering — Asal, Konsep, Kesenjangan, dan Masa Depan Sekaligus, saya juga menulis bahwa harness yang rumit yang dibuat untuk mengatasi kelemahan model akan dengan cepat digantikan ketika model membaik.
Namun, jika kami menggunakan hal ini sebagai dasar untuk mengatakan bahwa semua harness akan segera menjadi tidak perlu, kami akan melewatkan esensi harness itu sendiri. Masalah model yang menyerap fungsi dan masalah manusia serta organisasi yang mendelegasikan pekerjaan kepada AI sambil mengelola tanggung jawab adalah dua hal yang berbeda.

Pertama, kita harus melihat cara istilah kunci tersebar
Namun, terlebih dahulu, istilah teknologi sering dikonsumsi dengan cara dan makna yang jauh berbeda antara pasar domestik dan global. Oleh karena itu, kami terlebih dahulu melakukan verifikasi terhadap hal ini. Kali ini juga, kami perlu membedakan antara pernyataan asli, diskusi teknis sebenarnya, dan kerangka kerja yang dibuat di pasar domestik.
Dari postingan Penjelasan Lengkap Harness Engineering — Asal, Konsep, Kesenjangan, dan Masa Depan Sekaligus, berikut perbandingan konsumsi istilah harness engineering antara global dan domestik.
| Kategori | Global | Korea |
|---|---|---|
| Pemimpin Diskusi | Pusat pada analisis publik oleh insinyur dan praktisi. Tulisan dan kasus dari praktisi seperti Hashimoto dan Martin Fowler membentuk sumbu. | Artikel, ringkasan, dan penjelasan dari platform media, pendidikan, dan beberapa influencer teknologi tersebar dengan cepat. |
| Saluran Utama | GitHub, blog teknologi, X (Twitter), studi kasus resmi | YouTube, Brunch, blog, artikel berita |
| Materi Mendalam | Seperti studi kasus OpenAI dan analisis Martin Fowler, kami melihat teks asli, kode, dan pengalaman operasional bersama-sama. | Sebagian besar konten adalah terjemahan dan ringkasan, dan produksi kasus utama relatif sedikit. |
| Berbagi Penggunaan Aktual | Perusahaan seperti Stripe yang menangani lebih dari 1.000 PR per minggu dan Salesforce mengungkapkan angka operasional dan pengalaman kegagalan mereka secara terbuka. | Beberapa perusahaan terdepan seperti Toss dan Channel Talk berbagi pengalaman penggunaan aktual mereka, tetapi belum bisa digeneralisasikan menjadi kasus umum di seluruh industri. |
Apa yang perlu diperhatikan kali ini adalah bahwa tidak ada bukti yang jelas bahwa "harness is dead" atau "harness is useless" adalah slogan yang tersebar luas dalam komunitas bahasa Inggris. Diskusi yang lebih dekat adalah tentang bagaimana kemampuan tool use model membaik, beberapa scaffolding diserap ke dalam model atau platform, dan umur panjang lapisan orkestrasi kompleks yang dibangun secara manual mungkin menjadi lebih pendek. Saya tidak secara langsung mengonfirmasi pernyataan dari VP Noam Brown hingga sumbernya, dan saya mengenalnya melalui liputan media domestik dan internasional. Oleh karena itu, saya akan mempertimbangkan kerangka kerja 'argumen ketidakgunaan harness' yang dengan cepat mengeras di pasar domestik itu sendiri.
Harness yang akan hilang dan harness yang harus tetap adalah hal yang berbeda
Jelas ada harness yang akan hilang. Cara memecah prompt menjadi beberapa tahap, aturan sementara untuk mengatasi cacat model tertentu, alur kerja dangkal di mana urutan pemanggilan tool dipaksa tetap oleh manusia — ini semua dapat diserap oleh model yang lebih baik. Harness jenis ini memang seharusnya hilang.
Namun, seperti ringkasan dari Dong-su Lee, CEO A2Sys, saya berpikir berbahaya untuk memperluas ini ke semua harness. Untuk dirangkum, berikut adalah poinnya:
- Harness prompt dan alur kerja dapat diserap oleh model. Saya setuju.
- Harness eksekusi tool menangani otorisasi, persetujuan, dan pemulihan kegagalan. Apakah ini benar-benar harness yang akan hilang?
- Harness runtime, memori, dan infrastruktur menangani konteks, cache, routing model, biaya, latensi, dan jejak audit. Saya merasa sulit untuk mengatakan ini juga adalah harness yang akan hilang dengan cara yang sama.
Inti dari apa yang saya katakan dalam bab 7 hingga 11 dari 『Harness Engineering: Re:Memulai Rekayasa Perangkat Lunak AI dari Nol』 juga ada di sini. Kontrak menetapkan batasan yang diizinkan, struktur dan isolasi mempersempit ruang lingkup perubahan, dan traceability serta verifikasi menghubungkan tujuan asli dengan hasil aktual. Pengukuran dan operasi mengelola biaya, otorisasi, gangguan, dan pemulihan. Harness engineering dalam kisaran ini bukan sesuatu yang diselesaikan ketika model membaik.
Di sisi lain, argumen bahwa harness, loop, dan prompt engineering adalah heuristik manusia juga benar. Semua metodologi dimulai dari heuristik. Tipe, pengujian, CI, tinjauan kode, dan pemisahan otorisasi semua adalah metode yang dibuat manusia untuk menangani sistem yang kompleks. Tetapi yang lebih penting di sini adalah: bisakah kami mendelegasikan transparansi dan tanggung jawab ke model flagship? AI sendiri tidak dapat mengawasi apakah pekerjaan yang diberikan dilakukan dengan benar dan sesuai dengan niat, atau apakah ada kecelakaan yang melampaui tanggung jawab. Tentu saja, mungkin ada AI yang mengawasi dan mengoreksi ini, tetapi kemudian itulah harness.
Dalam komentar pada posting Profesor Han Sang-ki, saya menulis posisi saya seperti ini:
Tampaknya akan tergantung pada seberapa jauh kita melihat harness engineering. Dengan adanya niat organisasi dan pengembang, saya pikir sulit untuk hilang.
Semakin pintar model menjadi, semakin besar kemungkinan AI menyelesaikan sesuatu yang tidak terduga dengan lebih elegan hingga akhir. Itulah mengapa harness bukan perangkat koreksi kelemahan model, tetapi perangkat operasi yang menetapkan arah dan tanggung jawab.
Dalam operasi sebenarnya, batas tanggung jawab datang sebelum kemampuan model
Nextain beroperasi dengan klien pengembangan melalui Discord. Dan hari ini, di sini, saya telah mengintegrasikan agen dari Claude Code yang menyelesaikan masalah tertentu. Agen Nextain yang berpartisipasi di Discord (sebenarnya Claude Code yang berjalan di server) membaca saluran Discord dan memberikan jawaban.
Operator non-pengembang yang berada di saluran tersebut menyampaikan hasil pengujian, kekurangan, dan persyaratan. Dan ketika berbicara tentang hal-hal yang dapat ditangani, ketika perlu memodifikasi deployment penting atau resource yang tidak boleh disentuh, agen tersebut menanyakan persetujuan saya.
Juga, karena awalnya saya memasukkan ini dan agen segera mulai bekerja setelah mendengar persyaratan, mereka menjadi frustrasi dari perspektif orang-orang yang memberikan persyaratan. Kemudian saya memberikan instruksi untuk proses kerja. Ketika mendengar persyaratan, jawab dengan mengakui bahwa Anda telah mendengarnya, lakukan analisis, buat rencana, kemudian laporkan rencana kembali ke saluran Discord, dan lanjutkan pekerjaan. Dan pada akhirnya, ketika pekerjaan selesai, buat laporan akhir, dan jika ada masalah di tengah jalan, hubungi saya (pemimpin pengembangan) untuk membuat keputusan yang diperlukan melalui Discord.
Inti dari harness ini adalah proses pengembangan Nextain dan otorisasi setiap anggota. Jika ini adalah model flagship, apakah akan bekerja dengan cara terbaik secara otomatis? Apakah ada satu cara terbaik? Konsistensi proses organisasi dan kerja adalah, pada akhirnya, harness. Batas tanggung jawab ini terpisah dari kemampuan model. Semakin banyak pekerjaan yang dapat dilakukan model, semakin ketat kita harus membedakan apa yang boleh dilakukan dan di mana harus berhenti.
Masalah dalam praktik adalah drift dan biaya
Masalah yang dihadapi pengembang yang menggunakan Codex dan Claude dalam praktik masih tetap drift. Bahkan ketika tujuannya diperketat, ia bocor ke jalan lain, membuat perubahan yang tidak boleh dilakukan, mengubah pengujian dan mengatakan itu lulus, dan kehilangan batas otorisasi operasional. Semakin canggih model, semakin halus masalah ini dapat tersembunyi.
Pada saat ini, jawaban "jalankan lebih banyak" mungkin untuk BigTech. Mereka dapat memperpanjang waktu inferensi, membuat lebih banyak kandidat, membuang jalur yang gagal, dan menambahkan validasi eksternal. Namun, pengembang praktis dan startup kecil yang harus menghemat setiap uang tidak dapat melakukan ini. Situasi perusahaan domestik juga sama.
Dalam komentar dengan Profesor Han Sang-ki yang ditautkan di atas, "efisiensi biaya token total" yang disebutkan oleh mantan Sekretaris Senior Perencanaan AI Masa Depan Ha Jung-woo adalah standar yang tepat. Harness bukan perangkat yang menolak model flagship. Ini adalah perangkat pengendalian biaya untuk menggunakan model mahal hanya untuk keputusan yang benar-benar diperlukan dan memisahkan pekerjaan berulang ke dalam model kecil, alat lokal, skrip, dan verifikasi deterministik.
Pencapaian terbaru OpenAI yang terkait dengan matematika juga perlu dibedakan dalam dua momen. Saya menilai tinggi pencapaian pertama terkait penyangkalan konjektur jarak satuan bidang Erdős sebagai kemungkinan menemukan koneksi matematika yang berbeda dari pendekatan yang ada. Ini adalah kasus yang menunjukkan kemungkinan penemuan baru yang hanya dapat dihasilkan AI.
Sebaliknya, Test-Time Computing yang lebih disoroti kemudian adalah arah memasukkan lebih banyak komputasi, eksplorasi kandidat, verifikasi, dan iterasi pada waktu inferensi. Ini juga merupakan teknologi penting. Namun, jika kita hanya berbicara tentang itu sebagai peningkatan intelijen murni satu model, struktur biaya menghilang. Ini juga merupakan teknologi yang beroperasi berdasarkan kuantitas, tetapi teknologi yang sangat menguntungkan BigTech khususnya.
Harness adalah garis pertahanan terhadap biaya dan data
Pernyataan "model akan memakan harness" bersifat sensasional. Namun, siapa dan berapa banyak yang menggunakan model tersebut adalah masalah yang terpisah. Semakin banyak fungsi yang diserap model, semakin sederhana kode pengguna mungkin. Pada saat yang sama, kami mungkin menjadi lebih bergantung pada pemanggilan model yang lebih berat dan mahal. Kompleksitas tidak hilang, tetapi pindah dari area kerja pengguna ke lapisan penagihan penyedia model.
Data juga sama. Untuk agen benar-benar berguna, mereka perlu melihat dokumen, kode, jadwal, email, log operasional, riwayat gangguan, alur persetujuan, dan data pelanggan. Saat agen menjadi area kerja, seluruh pekerjaan pengguna menjadi input.
Harness yang baik hanya mengirim konteks yang diperlukan ke model eksternal dan menyimpan sisanya di area kerja pengguna. Kami routing model, menggunakan kembali cache, membagi otorisasi, dan melampirkan verifikasi yang dapat direproduksi. Oleh karena itu, harness adalah garis pertahanan biaya dan garis pertahanan data.
Dari perspektif ini, ada kemungkinan bahwa perusahaan model global mungkin merasa tidak nyaman dengan harness pengguna yang kuat. Jika pengguna terlebih dahulu memproses dengan model kecil dan alat lokal, dan hanya memanggil flagship pada saat yang diperlukan, volume panggilan dan konteks yang ditransmisikan berkurang. Sebenarnya, ini bukan pernyataan, tetapi kepentingan yang harus secara alami dipertimbangkan dalam struktur industri di mana biaya pengembangan model frontier, inferensi, GPU, dan daya meningkat.
OpenAI dan Anthropic berada di garis depan kompetisi harness melalui Codex dan Claude Code. Google, di sisi lain, adalah perusahaan model sekaligus penyedia cloud. Kami tidak dapat mengatakan bahwa setiap perusahaan memiliki kepentingan yang sama persis, tetapi alasan mengapa sulit untuk mendengarkan perdebatan ini hanya sebagai prediksi teknologi murni jelas. Harness yang baik mengurangi 'keinginan BigTech untuk memindahkan area kerja ke model, mengumpulkan data, dan mengurangi ketergantungan penggunaan flagship'.
Loop bukanlah nilai default generasi berikutnya
Loop juga hal yang sama. Saya menggunakan loop, tetapi saya pikir sebagian besar misi sebaiknya tidak menggunakan loop. Jika ini adalah pekerjaan di mana hasil yang tepat dapat diperoleh bahkan ketika dipercayakan kepada pengembang umum, kemungkinan menggunakan model yang baik sekali dengan benar lebih murah dan lebih cepat. Kejutan saya adalah bahwa loop benar-benar efektif hanya dalam kasus yang sempit.
Yang pertama adalah penelitian dan pengembangan. Pekerjaan di mana tidak ada jawaban yang jelas, hipotesis berubah sesuai dengan hasil eksperimen, dan eksperimen berikutnya harus berubah secara aktif membaca hasil sebelumnya. Penelitian suara dan lagu yang kami lakukan secara internal adalah seperti itu. Dalam hal ini, hasil eksperimen dan data keseluruhan ditinjau oleh beberapa AI, dan kami menilai kontinuitas dengan eksperimen yang ada, apakah ada drift, dan apakah diperlukan siklus berikutnya. Kriteria penyelesaian bukan hasil yang kredibel, tetapi penilaian bahwa indikator tidak lagi meningkat. Karena tujuannya adalah konvergensi eksplorasi, loop adalah yang tepat.
Yang kedua adalah ketika menggunakan model kecil di lingkungan terbatas. LLM kecil mudah menyusutkan tujuan dan berhenti dengan "ini sudah cukup". Namun, dalam hal ini, yang diperlukan bukan loop panjang tetapi mekanisme yang menutup tujuan dan kondisi penghentian. Ini lebih dekat ke fitur goal Claude Code daripada loop. Jika kita menggunakan loop berlebihan di area kerja harian pengguna umum, itu menjadi pemborosan biaya. Loop digunakan untuk konvergensi eksplorasi, dan harness digunakan untuk menetapkan tujuan dan tanggung jawab. Keduanya bukan hubungan substitusi.
Naia bermaksud untuk menyimpan area kerja di sisi pengguna
Naia tidak menolak model flagship. Kami berencana menggunakan flagship cloud secara menyeluruh dalam pengembangan. Model yang baik harus digunakan.
Namun, kami tidak berencana menyerahkan semua area kerja dan data ke platform BigTech. Apa yang ditujukan Naia adalah struktur yang menggunakan lokal, P2P, open-weight, model kecil, verifikator deterministik, dan harness otorisasi eksplisit bersama-sama. Kami menggunakan flagship mahal untuk keputusan yang diperlukan, tetapi area kerja dasar harus tetap di tangan pengguna.
Dari perspektif ini, pengembangan model open-weight seperti DeepSeek, Qwen, Kimi, dan GLM sangat penting. Dimungkinkan untuk menggabungkan model sesuai tujuan, menjaga data secara lokal, dan hanya memanggil flagship closed-source pada saat yang tepat. Di Korea, strategi model independen dari Upstage dan Naver juga bermakna dalam tren ini. Daripada hanya mengikuti flagship BigTech global, menggabungkan open-weight, model independen, harness spesialis, dan konteks pekerjaan domestik mungkin lebih realistis.
Model dapat dipinjam. Namun, tidak perlu meminjamkan area kerja dan data juga.
Kesimpulan: Yang dibutuhkan adalah diskusi tentang tingkat teknis, bukan argumen ketidakgunaan
Harness yang akan hilang akan hilang. Fungsi yang akan diserap model juga akan meningkat. Tidak ada alasan untuk menyangkal hal ini. Namun, saya tidak berpikir fungsi yang diserap model, sistem eksekusi yang menetapkan niat dan tanggung jawab organisasi, sistem operasi yang menjaga batas biaya dan data akan hilang. Jika subjek yang memberikan pekerjaan kepada AI adalah manusia dan subjek yang bertanggung jawab atas hasil juga manusia, kontrak, struktur, traceability, verifikasi, dan operasi tidak akan hilang.
Saya berharap kami dapat berhenti dari perdebatan kata kunci tentang apakah harness sudah mati atau hidup. Saya ingin diskusi yang sebenarnya berpusat pada teknologi terlebih dahulu, seperti apa yang akan kita masukkan ke dalam model, apa yang akan kita simpan di bawah kontrol pengguna dan organisasi, bagaimana kita memverifikasi dan membalikkan drift, dan siapa yang akan menanggung biaya token dan eksposur data.
Referensi dan Sumber
Tulisan dan buku saya
- 『Harness Engineering: Re:Memulai Rekayasa Perangkat Lunak AI dari Nol』
- 「Penjelasan Lengkap Harness Engineering — Asal, Konsep, Kesenjangan, dan Masa Depan Sekaligus」
- 「Peluncuran Harness Engineering」
Pemicu langsung diskusi ini
- AI Times, "Google diikuti OpenAI 'harness uselessness argument'... Model generasi berikutnya akan menyerap fungsionalitas"
- AI Times, "[25 Juni] 'Model akan memakan harness'..."
- Posting Facebook dan diskusi komentar Profesor Han Sang-ki
- Dong-su Lee, CEO A2Sys, "Argumen ketidakgunaan harness? Separuhnya benar dan separuhnya salah"
Dokumen teks asli dan teknis
- OpenAI, "Learning to Reason with LLMs"
- OpenAI, "An OpenAI model has disproved a central conjecture in discrete geometry"
- OpenAI, "Introducing Codex"
- OpenAI, "Introducing OpenAI o3 and o4-mini"
- Google, "Gemini 2.0: our new AI model for the agentic era"
- "The Interplay of Harness Design and Post-Training in LLM Agents"
- "More Is Not Always Better: Cross-Component Interference in LLM Agent Scaffolding"
- "AutoHarness"