Membangun Sistem yang Bisa Dioperasikan Agen

Image generated by Google Gemini

Jika agen AI merusak aplikasi Anda saat refactoring, jika Anda ingin mengubah sistem legacy menjadi lingkungan tempat AI bisa bekerja, jika Anda ingin mengalihkan anggaran pemeliharaan legacy Fortune 500 menjadi anggaran transformasi — artikel ini adalah peta jalannya.

Memori yang Terkunci

Di era gelembung IT, perusahaan mulai menumpuk aset digital. Kode, database, spesifikasi, dokumen, API — memori perusahaan yang terakumulasi selama puluhan tahun.

Memori itu terkunci. Tidak bisa ditelusuri, tidak bisa diverifikasi, tidak bisa dijangkau (unreachable). Satu-satunya cara adalah manusia membacanya langsung, memahaminya langsung, memperbaikinya langsung. Itulah mengapa 60–80% anggaran IT Fortune 500 dihabiskan untuk memelihara memori yang terkunci ini. Tidak bisa dibuka, jadi hanya dijaga.

Sekarang kita berada di tengah-tengah apa yang disebut gelembung AI. Makna sebenarnya dari era ini bukan model yang makin pintar. Memori legacy perusahaan yang lama terkunci mulai berubah menjadi bisa dijangkau (reachable).

Tapi belum sekarang. Tahun 2026, agen AI menulis kode. Membakar jutaan token selama 68 menit, menyelesaikan refactoring. Aplikasinya hancur total. Cerita seperti ini muncul di X setiap hari.

Mengapa ini terus terjadi?

Bukan karena agennya bodoh. Karena lingkungannya bukan tempat agen bisa bekerja. Jangan memasukkan robot ke kantor manusia. Bangun pabrik tempat robot bisa bekerja.

Untuk membuka memori yang terkunci, memori itu harus lebih dulu diubah ke bentuk yang bisa dibuka. Ini bukan soal kode saja. Database, spesifikasi, dokumen, API — seluruh aset digital perusahaan buram bagi agen.

Apa Itu Agent-Operable

Agar agen bisa bekerja secara otonom, tiga syarat harus terpenuhi:

1. Harus bisa dibaca — tanpa noise

Untuk menemukan satu fungsi di file 2.000 baris, 1.950 baris adalah noise. Untuk menemukan data pelanggan di database yang tidak dinormalisasi, harus join tiga tabel. Aturan bisnis yang tersembunyi di spreadsheet Excel tidak terlihat oleh agen.

Bisa dibaca bukan berarti manusia bisa membacanya. Artinya mesin bisa mem-parsing-nya secara struktural.

2. Harus bisa diverifikasi — secara deterministik

Jika agen tidak tahu apa yang rusak setelah perubahan, ia masuk doom loop. Kode butuh test. Database butuh constraint. API butuh schema validation. Spesifikasi butuh cross-verification.

LLM memverifikasi LLM itu seperti bertanya ke teman mabuk, “Aku mabuk nggak?” go test tidak berhalusinasi. CHECK constraint tidak berbohong. JSON Schema tidak hanyut.

3. State harus bertahan — meski agen mati

Agen pasti crash. Batas token, error jaringan, sesi terputus. Jika progres tidak tersimpan, setiap kali mulai dari nol.

Ketika Agen A memproses sampai fungsi ke-200 lalu mati, Agen B harus melanjutkan dari ke-201. Agen itu sekali pakai. Progres harus terakumulasi.

Langkah Nol: Bekukan Bug-nya

Tiga syarat itu adalah tujuan. Titik mulainya berbeda. Tidak ada dokumentasi, tidak ada test, 300 file masing-masing 2.000 baris. Itulah titik mulanya.

Suruh agen “refactor ini” dalam kondisi itu, apa yang terjadi? Ia “memperbaiki” bug berumur sepuluh tahun. Masalahnya, bug itu bukan bug.

Hyrum’s Law: setiap perilaku yang bisa diamati dari API yang cukup tua pasti ada yang bergantung padanya. Error pembulatan desimal yang dibiarkan selama satu dekade terhubung dengan logika pembayaran pelanggan VIP. Bug parsing tanggal melahirkan makro Excel yang menopang seluruh departemen akuntansi. Bug lama adalah spesifikasi bisnis implisit.

Tugas pertama agen bukan memperbaiki kode. Melainkan membekukan perilaku saat ini.

Tusuk API-nya. Catat responsnya. Kunci respons itu sebagai Hurl test. Bug aneh atau perilaku yang disengaja — tidak dibedakan. Bekukan apa adanya. Ini adalah gigi pertama ratchet — mengunci agen agar tidak “memperbaiki” seenaknya.

Perubahan hanya ditentukan oleh orang yang memegang spesifikasi. Agen adalah eksekutor. Bukan hakim.

Setelah pembekuan selesai, transisi menuju tiga syarat — keterbacaan, keterverifikasian, persistensi — baru dimulai.

Bukan Hanya Kode

“Agent-operable codebase” adalah titik awal. Aset digital perusahaan bukan hanya kode.

Jika dilihat satu per satu, masing-masing terlihat seperti “harus dirapikan.” Jika digabungkan, itu adalah sistem.

Symbolic Feedback Loop

Ada struktur umum yang memungkinkan transisi ini.

LLM menghasilkan → alat deterministik menilai → hasil dikembalikan ke LLM → ulangi

Di kode, di test, di spesifikasi, di data — loop yang sama bekerja:

Struktur kode:       filefunc validate → umpan balik pelanggaran → LLM perbaiki → ulangi
Test:                go test + coverage → umpan balik baris tak tercover → LLM perkuat → ulangi
Konsistensi spec:    yongol check → umpan balik drift → LLM perbaiki → ulangi
Aturan pengguna:     rulecat evaluate → umpan balik pelanggaran → LLM perbaiki → ulangi

Satu-satunya hal yang dilakukan LLM adalah menghasilkan. Apa yang harus diperbaiki, apakah lolos, apa selanjutnya, apakah sudah selesai — semuanya diputuskan mesin. LLM tidak diberi otoritas pengambilan keputusan.

Ini bukan penemuan. C. elegans mendedikasikan 60 dari 302 neuronnya (20%) untuk input sensorik. Untuk verifikasi, bukan generasi. Lima ratus juta tahun evolusi sampai pada kesimpulan ini: meningkatkan kualitas feedback lebih menguntungkan untuk bertahan hidup daripada menambah neuron.

Industri sedang membuat kereta (model) lebih cepat. Model lebih besar, agen lebih pintar, prompt lebih baik. Tapi semakin cepat keretanya, semakin penting relnya.

80/20

Dalam kondisi akhir, sistem terbagi menjadi dua lapisan.

SSOT (80–90%)
├── OpenAPI, DDL, SSaC, FuncSpec, Rego, Hurl, React TSX, Mermaid, manifest
└── Dihasilkan dari spec. Drift dieliminasi di sumbernya. Agen bebas memodifikasi.

Custom (10–20%)
├── Aturan bisnis, logika domain, perhitungan hukum/kebijakan
└── Distrukturkan dengan filefunc, diuji dengan tsma. Manusia mereview.

Kode yang benar-benar perlu diperhatikan manusia terkompresi menjadi 10–20%. Sisanya dihasilkan agen yang membaca spec, diverifikasi mesin.

60% dari Fortune 500

60–80% anggaran IT Fortune 500 dihabiskan untuk pemeliharaan legacy. 42% waktu developer dihabiskan untuk utang teknis. 70% migrasi legacy manual gagal.

Anggaran ini sudah dikeluarkan. Tidak perlu anggaran baru. Cukup arahkan ulang. Ubah anggaran pemeliharaan menjadi anggaran transformasi.

Masukkan legacy secara utuh, dan sistem agent-operable keluar. Itulah janji Building Agent-Operable Systems.

Mengapa Big Tech Tidak Melakukan Ini

Anthropic dan OpenAI membangun model general-purpose. Tingkatkan model 10% dan berlaku untuk semua pelanggan. Tapi bangun Go test feedback loop dan hanya berlaku untuk developer Go. Bangun alat coverage Python dan hanya berlaku untuk proyek Python.

Symbolic verification secara inheren bersifat domain-specific. Setiap bahasa, setiap framework, setiap spesifikasi membutuhkan verifier yang berbeda. Tidak ada generalitas berarti tidak cocok dengan ROI big tech.

Itulah mengapa ruang ini kosong. Orang yang membangun kereta dan orang yang memasang rel bukan pesaing. Mereka saling melengkapi.

Pertanyaan

Agen Anda menulis kode. Tapi siapa yang memeriksa apakah kode itu benar?

Agen lain? Atau go test?

Apakah LLM Anda benar-benar membaca semua 100.000 baris?

Atau hanya berpura-pura?

Yang dibutuhkan era agen bukan agen yang lebih pintar. Melainkan sistem tempat agen bisa bekerja.

Sources

• Gartner, “IT Budget and Cost Optimization” — 60–80% of enterprise IT budgets consumed by legacy maintenance
• Stripe & Harris Poll, The Developer Coefficient (2018) — 42% of developer time spent on technical debt
• McKinsey & Company, Why do most transformations fail? (2019) — ~70% of digital transformation projects fall short of goals
• Hyrum Wright, Hyrum’s Law — “With a sufficient number of users of an API, all observable behaviors of your system will be depended on by somebody”
• Winters, Manshreck, Wright, Software Engineering at Google (O’Reilly, 2020) — Formal book source for Hyrum’s Law
• White et al., “The structure of the nervous system of C. elegans”, Phil. Trans. R. Soc. Lond. B 314 (1986) — 302-neuron connectome
• Inglis et al., The sensory cilia of C. elegans, WormBook (2007) — 60 sensory neurons (~20% of total)
• METR, Early-2025 AI Developer Productivity Study (2025) — AI tools made experienced developers 19% slower, yet developers perceived 24% speedup
• GitClear, AI Copilot Code Quality 2025 (2025) — 211M lines analyzed, refactoring down 60%, copy-paste code up 48%
• Mehtiyev & Assuncao, Beyond Resolution Rates (2026) — 19 agents, 9,374 trajectories; 12.4% of total compute spent on zero-yield tasks