Mengapa Software Factories Gagal: Harness Engineering Saja Tidak Cukup

Konsep software factory bukan hal baru. Istilah ini sebenarnya berasal dari konferensi NATO tahun 1968, acara yang sama melahirkan istilah "software engineering" itu sendiri. Namun pada 2026, dengan maraknya AI coding agent, narasi software factory tanpa manusia kembali mencuat dengan kekuatan yang belum pernah terjadi sebelumnya. Artikel dari HumanLayer yang menjadi viral di Hacker News dengan lebih dari 382 upvotes menantang narasi tersebut dengan data nyata: harness engineering saja tidak cukup, dan kecepatan tanpa kualitas akan menghancurkan codebase lebih cepat dari yang pernah terjadi dalam sejarah software development.

OpenAI sendiri mempromosikan konsep harness engineering melalui software factory internal mereka yang bernama Symphony. Ryan Lopopolo dari OpenAI telah menulis dan berbicara tentang praktik ini. Begitu pula StrongDM dengan lights-off software factory mereka, di mana tidak ada manusia yang membaca atau menulis kode. Narasi yang beredar adalah: kamu adalah bottleneck, model sudah cukup baik, kode menjadi gratis, dan yang perlu dilakukan hanyalah mengirim lebih banyak fitur. Namun data dari laporan Faros AI menunjukkan tren yang mengkhawatirkan sejak perusahaan mulai menggunakan AI coding tools secara massal pada awal 2026.

Data Nyata: Kualitas Kode Menurun Drastis di Produksi

Laporan Faros AI mengungkapkan statistik yang signifikan dan mengkhawatirkan sejak Januari dan Februari 2026 ketika perusahaan mulai mengadopsi AI coding tools secara luas. Jumlah komentar review pull request meningkat 25%, yang mengindikasikan bahwa reviewer menemukan lebih banyak masalah. Panjang komentar naik 22.7%, yang berarti masalah yang ditemukan semakin kompleks untuk dijelaskan. Dan yang paling mencolok, 31.3% pull request disetujui tanpa review sama sekali, menciptakan celas besar di mana kode berkualitas rendah bisa masuk ke produksi tanpa penyaringan.

Lebih mengkhawatirkan lagi, insiden produksi per pull request melonjak 242.7%, insiden bulanan naik 57.9%, dan bug per developer meningkat 54%. Angka-angka ini bukan sekadar fluktuasi normal: ini adalah degradasi sistemik dalam kualitas software yang terjadi dalam waktu singkat setelah adopsi AI tools. Mario Zechner, yang berbicara di AI Engineer Europe, memperingatkan bahwa perusahaan yang seharusnya tidak mengalami outage karena kesalahan coding agent justru mengalaminya. Matt Pocock mengamati bahwa codebases runtuh lebih cepat dari sebelumnya, sebuah fenomena yang ia sebut sebagai destruksi lebih cepat daripada konstruksi.

Mengapa Model AI Bisa Lolos Benchmark Tetap Gagal di Produksi

Masalah fundamentalnya terletak pada cara model AI dilatih dan dievaluasi. Model-model coding dilatih menggunakan reinforcement learning dan dievaluasi berdasarkan benchmark yang seringkali tidak merepresentasikan kompleksitas codebase production. Model bisa menghasilkan kode yang lolos benchmark dengan sempurna, namun tetap menghasilkan mountain of slop ketika dihadapkan dengan konteks nyata yang tidak pernah muncul dalam data training. Benchmark mengukur kemampuan sintaksis dan pattern matching, bukan kemampuan memahami business logic yang tersembunyi di balik jutaan baris code legacy.

Pemilik HumanLayer, Dex, menjelaskan bahwa meskipun ia sendiri telah lama mendalami penggunaan coding agent dan menemukan teknik yang banyak orang anggap berguna, ia akhirnya menyadari bahwa tidak ada jumlah harness engineering atau loop maxxing yang bisa mengatasi masalah fundamental training model. AI companies memang sudah berinvestasi dalam kemampuan defensive seperti deteksi serangan dan penulisan kode aman, namun benchmark paling visible mereka tetap berfokus pada menemukan vulnerability dan membangung exploit. Kultur industri yang didorong oleh kecepatan dan demonstrasi kemampuan membuat defensive capabilities seringkali kurang mendapat spotlight.

Software Factory 2022 versus Agentic Software Factory 2026

Pada 2022, sebelum AI masuk secara massal, software factory manusia memiliki siklus alami yang terukur. Orang memutuskan apa yang akan dibangun, tiket dimasukkan ke tracker, seseorang mengambil dan membangunnya, pull request direview manusia dengan cermat, lalu di-ship ke produksi dengan monitoring komprehensif. Loop ini memang lambat, namun front-loading alignment melalui planning bersama dan architecture proposal mengurangi rework secara signifikan. Sebuah jam planning di awal bisa menghemat berjam-jam review dan rework di kemudian hari.

Dengan agentic software factory, loop menjadi jauh lebih cepat dan frekuensi shipping meningkat drastis. Perusahaan seperti Ramp, Stripe, WorkOS, dan Brex melaporkan bahwa agent mereka menulis sekitar 75% kode dalam codebase. Namun kecepatan ini datang dengan biaya tersembunyi: review quality menurun, incident meningkat, dan codebase yang sudah berusia 3-6 bulan mulai menunjukkan tanda-tanda degradation. Agent-built codebase yang awalnya berjalan cepat justru mulai melambat dan memerlukan pendekatan berbeda untuk menambah fitur baru. Brownfield dalam konteks AI tidak lagi berarti Java legacy dari 10 tahun lalu: codebase yang dibangun agent bisa mulai bermasalah hanya dalam 3-6 bulan.

Diskusi ini juga menimbulkan pertanyaan mendasar tentang definisi kualitas dalam era AI. Jika benchmark tidak bisa dipercaya dan human review seringkali dilewati, bagaimana sebuah organisasi bisa memastikan bahwa kode yang masuk ke produksi memenuhi standar? Salah satu jawaban yang muncul adalah pendekatan adversarial review, di mana reviewer sengaja mencari kelemahan dalam kode sebelum disetujui. Namun adversarial review memerlukan waktu dan keahlian yang justru semakin langka ketika perusahaan memangkas posisi senior dan mengandalkan AI untuk mengisi gap. Hasilnya adalah review yang lebih dangkal dan defect yang lolos ke produksi dalam volume yang lebih besar.

Muncul juga konsep baru yang disebut loop engineering, di mana tim sengaja merancang siklus iterasi yang lebih cepat dengan asumsi bahwa AI bisa memperbaiki kesalahan lebih cepat daripada manusia. Teori ini terdengar menarik, namun dalam praktiknya menciptakan culture di mana kode dengan defect dikirim dengan harapan akan diperbaiki di iterasi berikutnya. Hasilnya adalah accumulation of technical debt yang tidak terlihat dalam dashboard sprint, tetapi membayangi setiap deployment di bulan-bulan berikutnya. Developer yang bekerja di lingkungan semacam ini seringkali merasa bahwa mereka menghabiskan lebih banyak waktu untuk memperbaiki bug AI daripada menulis fitur baru, sebuah fenomena yang mengurangi morale dan produktivitas tim secara keseluruhan.

Bagi developer Indonesia yang bekerja di codebases kompleks dan legacy, pesannya jelas dan tidak bisa diabaikan. AI adalah accelerator yang powerful, tetapi tidak menggantikan kebutuhan akan arsitektur yang matang, review yang teliti, dan monitoring produksi yang ketat. Harness engineering tanpa disiplin software engineering yang solid adalah resep untuk technical debt yang akan meledak di masa depan. Seperti yang dikatakan Dex: kita sedang berpacu untuk memasukkan AI coding ke produksi, namun data menunjukkan bahwa banyak yang terbakar di tengah perjalanan.