Ini adalah repository tempat saya belajar AI. Bukan belajar tentang AI — belajar bagaimana AI sebenarnya berperilaku ketika Anda memberinya pekerjaan nyata. Yang pertama saya bangun dengan agen, tempat saya melihat agen merencanakan perubahan, menulisnya, lalu dengan diam-diam melakukan hal yang sama salah untuk keempat kalinya. Semua yang saya tahu tentang agentic AI, saya pelajari dengan merusaknya di sini.

Dan repository itu tumbuh. Ketika saya menilainya dengan saksama, isinya sudah 136 file peran agen, 191 file skill, satu matriks tata kelola, lapisan aturan, lapisan kebijakan, standar pengodean, dan CLAUDE.md yang berubah menjadi daftar perubahan. Sebagian besar tidak terpakai. Sebagian besar tidak optimal. Sebagiannya murni templat — file 240 byte dengan nama domain yang disisipkan.

Tidak ada yang itu terlihat dari dalam repository. Gongnya itu adalah konteksnya. Setiap sesi memuatnya, setiap agen mewarisinya, dan perbedaan antara prompt peran yang ditulis cermat dan placeholder yang tidak pernah disadari orang bukan sesuatu yang bisa saya rasai saat sedang bekerja di dalamnya.

Jadi saya melakukan apa yang sudah saya lakukan sekali untuk situs ini: saya minta seseorang yang tidak bisa melihat satu pun konteks saya untuk membacanya.

Metodenya, dipakai satu level lebih tinggi

Google membuka Elephant-Goldfish Model pada Oktober 2026, dan saya sudah menulis catatan tentangnya ketika saya memakainya untuk mereview dokumen desain situs saya sendiri. Idenya dalam satu paragraf: agen yang memegang konteks proyek menyusun spesifikasi, dan pemeriksa lain yang tidak punya ingatan percakapan itu membaca spesifikasi itu sendirian lalu menyerangnya. Konteks yang menyusun rencana adalah konteks yang tidak bisa melihat titik buta rencana itu.

Diterapkan ke dokumen desain, itu menangkap asumsi buruk dalam sebuah migrasi. Diterapkan ke roster itu sendiri — instruksi yang dibaca setiap agen di dalam workspace sebelum melakukan apa pun — persanya jadi berbeda: apakah instruksi-instruksi ini nyata?

Plugin-nya hanya terpasang untuk Claude Code, Codex, dan Antigravity, sedangkan sesi ini berjalan di harness lain. Jadi saya membangun apa yang sebenarnya adalah EGM, dengan tangan. Empat reviewer konteks baru tanpa transkrip, masing-masing dengan satu sudut pandang, masing-masing diarahkan ke satu file. Satu harus menulis ulang desain saya dengan kalimatnya sendiri sebelum menemukan apa pun, karena reviewer yang tidak bisa memarafrase sebuah bagian belum memahaminya. Satu memeriksa struktur dan aritmetika. Satu adalah orang skeptis yang menanyakan apakah perubahan terkecil yang menghapus cacat itu sudah ditemukan. Satu adalah tech lead yang menerapkan zero-decision rule: kalau Anda harus berhenti dan bertanya "yang mana maksudnya?", dokumennya belum siap.

Isolasi adalah bagian yang harus saya kerjakan sendiri. EGM bersandar pada flag frontmatter Claude Code yang menjaga memori proyek penulis tetap di luar konteks reviewer. Harness saya tidak punya flag itu. Jadi saya menanam satu baris penanda di file memori workspace, menyuruh reviewer membaca hanya desainnya, lalu setelahnya saya cek apakah penanda itu muncul di keempat laporan. Tidak muncul.

Yang dibuktikan adalah instruksinya dipatuhi. Yang tidak dibuktikan adalah jaminan dari tooling, karena tidak ada tooling yang bisa menjaminakannya. Saya akan kembali ke sini, karena ternyata itu hal paling penting dari seluruh putaran ini.

Tiga cara rencana saya salah

Temuan utamanya adalah aritmetika, dan tiga reviewer menemukannya secara independen. Rencana saya menyebut target 109 file agen. Daftar perubahan di dokumen yang sama menurunkan 113. Prosa di antaranya menulis 111. Tiga angka berbeda, tiga rencana berbeda, dan selisihnya adalah apakah saya mencabut 12 peran, 14, atau seluruh 16. Rencana yang metrik keberhasilannya tidak bisa dihitung tidak bisa ditandatangani — dan artikel yang hendak saya tulis akan menerbitkan angka-angka itu.

Temuan kedua lebih besar, dan datang dari sang skeptis. Rencana saya adalah penulisan ulang yang menyamar sebagai pembersihan. Menghapus dua belas sampai enam belas file peran berarti mengedit lima permukaan per file — peran itu sendiri, router yang meneruskannya, matriks tata kelola, daftar hard-coded di dalam validator, dan prosa di dokumen entry point yang dibaca setiap CLI. Itu empat puluh lima sampai tujuh puluh titik edit, untuk masalah yang bisa diselesaikan badan tiga baris per file. Yang lebih buruk, menghapus sebuah peran memaksa penggantinya menjadi catch-all multi-domain, atau memaksa deskripsi milik penggantinya sendiri berhenti menyebut cakupan yang baru saja dia serap. Dua-duanya berarti saya akan menciptakan justru kegagalan yang sedang saya hapus: router yang tidak bisa membedakan dua peran.

Jadi review itu mengubah rencananya. Enam belas peran bertemplat mempertahankan nama dan deskripsi rutenya, dan badannya ditulis ulang menjadi yang nyata — scope, skill yang mereka miliki, batas eksplisit yang menyebut spesialis yang benar-benar mengerjakan pekerjaannya, dan apa yang mereka serahkan kembali. Enam belas skill tanpa isi juga mempertahankan namanya, dan masing-masing mendapat daftar periksa nyata bersumber dari dokumen kebijakan yang sudah ada, dengan satu baris yang menamai sumbernya. Metriknya tidak bergeser: peran yang berbagi boilerplate body turun dari enam belas ke nol, begitu juga skill yang tidak punya isi.

Temuan ketiga adalah yang tidak bisa saya delegasikan. Dua klaim faktual saya/about repository itu sendiri, sedangkan reviewer terikat protokol pada dokumen — mereka tidak bisa memeriksanya. Saya memeriksanya sendiri, dan keduanya salah. Saya menulis bahwa satu skill tidak ada; nyatanya ada, milik sub-aplikasi, tiga baris di atas klaim saya sendiri di matriks yang sedang saya kritik. Saya juga menulis bahwa dua skill menanyakan koleksi pencarian yang salah sementara yang lain memakai yang berbeda; distribusi sebenarnya di enam puluh enam skill adalah empat puluh, dua puluh lima, dan satu, dan pemisahannya tidak mengikuti apa yang sebenarnya ditanyakan skill itu. Memaksa satu nilai akan jadi tebakan yang berpakaian perbaikan.

Kedua klaim kini dikoreksi. Yang kedua berubah menjadi ketidakkonsistenan yang tercatat dengan tindak lanjut, bukan sebuah perubahan.

Apa yang sebenarnya berubah

Satu branch, dan angkanya keluar dari validator, bukan dari kepala saya.

File peran di root workspace turun dari 125 ke 123, karena dua dokumen yang sebenarnya tidak pernah jadi peran dipindahkan keluar dari direktori agen ke pohon docs, tempat mereka akhirnya bisa dibaca sebagai dokumen. File skill turun dari 187 ke 186: satu ditambah untuk skrip tes yatim yang punya implementasi berfungsi tapi tanpa SKILL.md, dan dua pasang digabung — dua skill query yang menyentuh enam endpoint yang sama di dua host berbeda, serta dua skill publikasi yang hanya berbeda di format keluaran. Semua 187 skill sekarang membawa nama dan deskripsi yang menyatakan kapan harus dipakai. Semua 16 boilerplate body peran dan semua 16 skill tanpa isi ditulis ulang. Dan setiap satu dari 136 baris di matriks tata kelola kini resolve: setiap peran tepat satu kali, setiap referensi skill ke file yang benar-benar ada.

Gerbang yang harus membuktikan diri

Validator yang tidak pernah gagal bukan validator. Jadi sebelum saya memercayai pemeriksaan baru itu, saya jalankan terhadap matriks seperti sebelum perubahan. Ia melaporkan lima puluh dua error: kedua referensi skill yang menggantung, kedua baris yang salah bentuk, satu baris kembar, dan empat puluh satu peran yang sama sekali tidak punya baris.

Itulah angka yang akan saya terbitkan seandainya tidak ada yang meminta reviewer konteks nol membaca rencana saya. File tata kelola itu bukan ketidaktepatan kecil. Itu file yang sudah berhenti menggambarkan sistemnya, dan tidak ada apa pun di repository yang sedang melihat.

Sekarang validasi memeriksa baris matriks — tiga kolom, setiap peran tepat satu kali, setiap referensi skill resolve — dan memeriksa bahwa setiap skill punya frontmatter dengan name dan description yang tidak kosong. Aturan yang menjaga dua pohon aturan yang saling mencerminkan tetap selaras sudah ada sebelumnya; yang itu layak dijaga.

Apa yang tidak saya ubah

Tujuh puluh enam skill query skema terlihat seperti duplikat, dan memang bukan. Mereka berbagi templat, masing-masing membawa Cypher sendiri di atas graph skema, dan tidak ada yang yatim — semuanya terjangkau oleh agen navigator domain. Menggabungkannya berarti menukar kontrak routing dengan penghematan token. Lima belas navigator juga mempertahankan snapshot nama tabel statisnya, meski skill-nya adalah front end yang lebih kaya, karena menurunkan mereka mengubah kontrak routing yang menghadap produk, dan itu pekerjaan lain dengan risiko lain.

Saya juga tidak menyentuh isi skill-skill itu kecuali dua query duplikat yang terbukti, dan saya membiarkan pertanyaan koleksi pencarian ketiga tetap terbuka alih-alih menebak. Keduanya tercatat sebagai perubahan yang sengaja tidak dilakukan, dan itulah yang mencegah reviewer berikutnya membukanya lagi.

Metodenya sekarang tinggal di repository

Tujuan menjalankan EGM pada roster itu bukanembersihkannya. Tujuannya adalah perubahan berikutnya tidak lagi bergantung pada saya ingat untuk meminta opinions kedua. Jadi metodenya sekarang jadi bagian dari workspace itu sendiri, bukan sesuatu yang saya lakukan sekali saja.

Perubahan berukuran fitur sekarang dimulai dari dokumen desain, bukan dari edit kode, dan reviewer konteks nol membaca dokumen itu sebelum apa pun diimplementasikan — diperiksa terhadap seluruh isi lapisan aturan repository, dengan reviewer keamanan ditambahkan setiap kali perubahan menyentuh autentikasi, kredensial, data pasien, atau sistem eksternal baru. Reviewer itu menerima path dokumen dan tidak ada yang lain. Laporan disimpan, setiap temuan ditriase satu per satu, dan setiap perbaikan diterapkan ke dokumen desain, bukan ke kodenya.

Ada dua peran reviewer, bukan satu, dan itu disengaja. Reviewer umum bekerja terhadap lapisan aturan; reviewer keamanan bekerja terhadap aturan kredensial dan penanganan data, dengan skala severity yang berbeda, karena temuan keamanan dan temuan yang soal tatakata tidak seharusnya berebut label yang sama. Keduanya tidak opsional pada sistem rumah sakit.

Catatan kritis

Isolasi ini instruksi, bukan tooling. Probe penanda membuktikan reviewer tidak membaca memori proyek saya. Ia tidak akan menangkap reviewer yang membaca file yang tidak terpikir untuk saya tandai. Di bawah Claude Code, itu properti runtime. Di tempat lain, itu sebuah janji.

Reviewer tidak bisa memeriksa repository. Dua dari klaim faktual saya salah dan lolos dari empat reviewer. Betapa pun independensi konteks baru memberi Anda, ia tidak memberi Anda akses pada kebenaran tentang kodenya.

Reviewer berisik. Mereka memberi nilai temuan yang sama sebagai Blocker di satu laporan dan Major di laporan lain, dan satu dari mereka memberi tahu seluruh rencana saya terlalu besar — yang benar, dan yang tidak akan saya putuskan sendiri. Kira-kira sepertiga dari yang kembali butuh triase, bukan tindakan.

Ada biaya token dan waktu. Empat reviewer konteks baru, masing-masing membaca satu dokumen dari awal sampai akhir, tidak murah. Ini sepadan ketika dokumen itu menentukan apa yang dilakukan 136 agen untuk sistem rumah sakit, dan tidak sepadan untuk perbaikan satu baris.

Sumber

Baca juga