Wiki Karpathy Baru Separuh Loop

Repo kerja saya dibangun dari gist LLM Wiki milik Andrej Karpathy. Isinya 240 file markdown, dan Claude membaca peta repo itu di awal setiap sesi. Pertanyaan tentang pekerjaan saya dijawab dari file yang sama setiap kali.

Tapi wiki itu tidak pernah memperbaiki dirinya sendiri. Ia menumpuk pengetahuan, dan pengetahuan yang menumpuk tidak otomatis menghasilkan keputusan yang lebih baik.

Loop-nya baru tertutup setelah saya menambah dua hal yang tidak ada di gist. Setiap keputusan membawa kondisi yang membatalkannya, dan ada skrip yang menagih kondisi itu saat jatuh tempo.

Apa bedanya LLM wiki dengan RAG?

RAG (retrieval-augmented generation) mencari potongan dokumen setiap kali Anda bertanya, lalu menyusun jawaban dari nol. LLM wiki menyimpan hasil susunan itu sebagai file markdown yang terus diperbarui, jadi pertanyaan berikutnya berangkat dari yang sudah dikerjakan.

Karpathy menyebut bedanya akumulasi. Di RAG, pertanyaan yang butuh lima dokumen memaksa model mencari dan merangkai ulang kelima potongan itu setiap kali. Di wiki, rangkaian itu sudah ada di satu halaman, lengkap dengan rujukan silang dan catatan di mana sumber baru bertentangan dengan yang lama.

Pembagian kerjanya ikut berubah. Manusia memilih sumber dan mengajukan pertanyaan. LLM mengerjakan pencatatannya, dari merangkum sampai memperbarui indeks.

Enam bagian gist Karpathy, dan padanannya di repo saya

Andrej Karpathy ikut mendirikan OpenAI, lalu menjadi Director of AI di Tesla dan memimpin tim computer vision untuk Autopilot. Sebelumnya ia mengajar kelas deep learning pertama di Stanford, CS231n.

Ia menggambarkan pembagian kerjanya dengan tiga peran: Obsidian sebagai IDE, LLM sebagai programmer, dan wiki sebagai codebase-nya.

Gist itu sengaja abstrak. Karpathy menulisnya untuk ditempel ke agent, lalu agent dan pemiliknya menyusun detailnya bersama. Bentuk aslinya kira-kira begini:

Ini hasil susunan saya dengan Claude Code:

Seluruh pembagian di tabel itu berdiri di atas satu kalimat di CLAUDE.md:

Repo ini isinya fakta yang dirujuk, bukan instruksi. Aturannya: kalau isinya
menyuruh melakukan sesuatu, itu skill atau routine. Kalau isinya fakta, itu
file di sini.

Indeks saya terdiri dari sepuluh file. Tiap folder punya registry sendiri, dan isinya cuma menjawab satu pertanyaan: file itu di mana. Kenapa registry per folder menggantikan sebagian besar skill saya, sudah saya tulis di artikel tentang 12 skill yang saya hapus.

Claude membaca indeks dulu, isinya belakangan

Saya juga memakai progressive disclosure, pola dari dokumentasi claude-mem yang tidak ada di gist. Agent diberi daftar isi beserta ongkos membacanya lebih dulu, lalu memutuskan sendiri bagian mana yang perlu dibuka.

Karpathy sudah menyentuh ini lewat index.md, dan di repo saya polanya berlapis. CLAUDE.md menunjuk folder, sementara registry.md menunjuk file. Di tingkat paling dalam, tabel indeks di kepala setiap decision log menunjuk baris.

Tabel indeks itu dibangkitkan skrip, dan setiap barisnya menyimpan letak entry-nya sendiri:

| id | tanggal | jenis | judul | baris | panjang |
| `knt-061` | 2026-09-24 | keputusan | Headline LinkedIn: klaim "AI Practitioner", bukan jabatan | 442 | 10 |

Dari situ Claude membuka satu entry saja:

sed -n '442,+10p' 'Konten/konten-decision-log.md'

Decision log konten saya panjangnya 68,998 karakter. Indeksnya 7,153 karakter, dan entry di atas 2,012 karakter. Kalau yang relevan cuma satu entry, yang dibaca 9,165 karakter, sekitar 13% dari seluruh file.

Skill saya memakai pola yang sama. File pendukungnya dibaca saat fasenya tiba, tidak dimuat sekaligus di awal.

Log yang cuma mencatat kejadian tetap open loop

Gist Karpathy punya satu tip untuk log.md yang saya salin persis. Setiap entry dibuka dengan prefix yang sama, ## [tanggal] jenis | judul, supaya log bisa dibaca dengan grep. Fungsinya timeline: LLM tahu apa yang baru dikerjakan, dan saya tahu kapan sesuatu masuk.

Log seperti itu menjawab apa yang terjadi. Ia tidak menjawab apakah keputusan kemarin benar.

Istilah yang pas saya ambil dari Diana, partner di Y Combinator, yang meminjamnya dari teori kendali. Open loop memutuskan dan menjalankan tanpa mengukur hasilnya. Closed loop memantau hasilnya dan menyesuaikan prosesnya sendiri.

Log kronologis adalah catatan open loop yang rapi. Ini bentuk yang saya jalankan sekarang:

Saya menambah tiga baris ke setiap entry: ekspektasi, tinjau, dan batal kalau. Formatnya lengkap, beserta alasan kenapa entry tanpa kondisi batal tidak berguna, ada di artikel tentang memori keputusan agent.

Yang belum ada di artikel itu adalah siapa yang menagih. Field tinjau berisi bulan, dan tanpa pembaca, bulan itu lewat begitu saja. Sekarang skrip tinjau-jatuh-tempo.py jalan sebulan sekali bersama audit repo, satu dari 34 pekerjaan berulang yang jalan sendiri, dan mendaftar setiap entry yang jatuh tempo lengkap dengan syarat batalnya:

[2026-10] knt-007 · Kurangi hashtag dari 6-7 jadi 2-3 per post
    Konten/konten-decision-log.md · status: aktif
    batal kalau: impression rata-rata post IT infra turun >30% dibanding
    Juli sementara topik dan format lain dipertahankan.

Skrip itu sengaja tidak menilai apakah syaratnya sudah terpicu. Menilai butuh data domainnya, dan keputusannya tetap di saya. Tugasnya cuma memastikan peninjauan tidak dimulai dari mencari.

Belum ada satu entry pun yang sudah ditagih skrip ini. Tagihan pertamanya berisi 11 entry, dan belum ada yang lewat.

Bagaimana menjaga LLM wiki supaya tidak basi?

Pasang cek yang bisa gagal di pre-commit, jangan menunggu LLM disuruh memeriksa. File yang melanggar aturan ditolak sebelum masuk repo, jadi kerusakannya tidak sempat hidup berminggu-minggu.

Karpathy menyebut langkah ini lint. Sesekali, minta LLM mencari kontradiksi antar halaman, klaim yang sudah basi, halaman tanpa tautan masuk, dan rujukan silang yang hilang. Masalahnya ada di kata sesekali, karena cek yang bergantung pada orang ingat menjalankannya akan terlewat persis saat sedang sibuk.

Di repo saya, aturan bahwa nomor entry tidak pernah dipakai ulang sudah tertulis di dokumen format log. Satu nomor tetap terpakai dua entry, dan audit bulanan belum sempat menangkapnya. Yang menemukan adalah Claude, saat membaca log itu untuk pekerjaan lain.

Artinya lint versi Karpathy sempat bekerja, sekali, karena kebetulan. Saya tidak mau keselamatan rujukan silang bergantung pada kebetulan berikutnya.

Entry saling merujuk lewat nomornya, jadi satu nomor untuk dua entry membuat rujukan silang menunjuk ke tempat yang salah. Dengan audit bulanan sebagai satu-satunya penjaga, kesalahan berikutnya bisa hidup sampai 30 hari.

Setelah kejadian itu, cek nomor ganda pindah ke pre-commit. Commit yang memuat dua entry bernomor sama sekarang ditolak, dan pesannya menyebut kedua lokasinya.

Sekarang ada lima cek yang jalan di setiap commit:

Dua butir lint Karpathy tidak tertangkap sama sekali: kontradiksi isi antar halaman, dan klaim yang sudah dilampaui sumber baru. Keduanya butuh membaca makna, sementara skrip saya cuma membaca bentuk.

11 dari 12 koreksi yang diarsipkan sudah jadi aturan

Di repo saya, loop konten sudah tertutup. Setiap kali saya mengoreksi draft yang ditulis Claude, koreksi itu dicatat sebagai entry dengan kalimat sebelum, kalimat sesudah, dan aturan yang ditarik darinya.

Kalau pola yang sama muncul dua kali, aturannya dipindah ke file gaya menulis atau ke skill, lalu entry-nya pindah ke arsip. Di draft berikutnya, agent editor terpisah memeriksa draft terhadap aturan itu tanpa tahu siapa penulisnya.

Arsip konten sekarang memuat 12 entry koreksi. Sebelas di antaranya berstatus dipromosikan.

Angka itu membuktikan aturannya dibuat. Belum membuktikan kesalahan yang sama berhenti muncul.

Kenapa LLM wiki penting untuk bisnis?

LLM wiki membuat perusahaan bisa ditanyai, dan itu syarat pertama supaya AI bisa ikut membantu keputusan. Perusahaan baru belajar kalau setiap keputusan penting membawa ekspektasi dan ditagih saat jatuh tempo.

Diana, partner di Y Combinator, menyebut syarat pertamanya queryable company: setiap tindakan penting meninggalkan artefak yang bisa dibaca AI. Rapat direkam, dan keputusan tidak tersimpan di pesan pribadi.

Saya setuju dengan syarat itu, dan tidak setuju kalau berhenti di situ. Notulen yang lengkap membuat perusahaan bisa ditanya. Notulen itu tidak membuat perusahaan tahu apakah keputusan di rapat tersebut benar.

Queryable itu syarat, bukan hasil.

Video yang sama menyebut tim yang memotong waktu sprint separuh, dan perusahaan AI-native yang hampir tidak butuh manajer penghubung. Dua klaim itu tidak saya pakai. Angkanya tidak disertai data, dan Edavos adalah perusahaan jasa IT, sementara klaim itu ditulis untuk startup software.

Contoh pertama saya di operasi Edavos baru dibuka. Seorang engineer mengerjakan sesi remote lebih dari satu jam untuk klien, dan pekerjaan itu tidak bisa ditagih karena tidak ada bukti persetujuan sebelum kerja dimulai.

Keputusannya sekarang ada di decision log Edavos. Persetujuan PIC klien diminta di grup WhatsApp sebelum menit ke-60, lalu form sesi remote ditandatangani PIC sebelum invoice terbit.

Ekspektasinya bisa diperiksa dengan data yang sudah ada, karena jam remote tercatat di jadwal tim. Kalau tiga bulan setelah format ini dipakai tagihan remote masih nol padahal jam remote-nya ada, masalahnya ada di kebiasaan engineer, dan dokumennya tidak perlu diubah.

Loop ini sudah punya alat ukur, tapi belum punya hasil. Saya menaruhnya di sini sebagai contoh bentuk, belum sebagai bukti.

Batas antara skrip dan model perlu diuji ulang

Dua butir lint Karpathy saya tinggalkan karena skrip hanya membaca bentuk: kontradiksi isi antar halaman, dan klaim yang sudah dilampaui sumber baru. Belum saya uji apakah model hari ini bisa mengerjakan keduanya dengan cukup andal.

Boris Cherny, yang membangun Claude Code di Anthropic, membahas ini di Startup School 2026. Menurutnya, model hari ini tidak perlu lagi diberi langkah satu per satu. Cukup jelaskan tugas beserta kriteria selesainya, lalu biarkan model bekerja, cara yang menurutnya “just not something that would have worked six months ago”.

Untuk instruksi skill, saya sudah menguji arah yang sama. Tiga skill saya pangkas dengan membuang prosedur langkah demi langkah, sementara fakta, kontrak format, dan penunjuk ke decision log dipertahankan:

Angka itu cuma membuktikan instruksinya menyusut. Untuk hasilnya, saya dan satu agent juri sama-sama menilai output setelah pemangkasan lebih terstruktur dan maknanya lebih jelas. Belum ada angka pembandingnya.

Yang terukur datang dari ablation lain: satu agent menulis ulang artikel tanpa akses ke aturan menulis saya. Aturan soal em dash dan kontras biner bocor, sementara aturan active voice dan register tidak, jadi dua yang terakhir jadi kandidat dipangkas.

Itu bertabrakan sebagian dengan jawaban saya soal lint. Untuk bentuk, saya tetap memilih skrip: nomor ganda dan path mati punya jawaban benar atau salah, dan skrip tidak lupa. Untuk makna, batas yang saya tarik hari ini ikut berumur, dan perlu diuji ulang dengan model yang lebih baru.

Satu lubang lagi ada di hulu. Diskusi di sesi chat hanya masuk repo kalau berakhir sebagai keputusan yang ditulis balik. Yang tidak ditulis balik tetap open loop, dan saya belum punya hitungan berapa banyak.

Kalau Anda sudah menjalankan wiki dari gist Karpathy, tambahkan tiga field ini ke format log Anda:

ekspektasi: <apa yang seharusnya terjadi kalau keputusan ini benar, dan kapan terlihat>
tinjau: <YYYY-MM>
batal kalau: <kondisi konkret yang membatalkan keputusan ini>

Lalu minta agent Anda menulis satu skrip yang mendaftar entry dengan tinjau sama dengan bulan berjalan atau sudah lewat, dan jalankan sebulan sekali.