Pengurangan Kuota Claude Code: Apakah Agen Menciptakan Gunung Kode Warisan Baru?

Kuota mingguan Claude Code diperpanjang, menarik perhatian; artikel menganalisis mekanisme konsumsi Token pada program Agent. Operasi jangka panjang Agent menyebabkan working set terus membesar, setiap langkah akumulasi status historis, ditambah sifat cache yang tetap memakan context meski terjadi cache hit, sehingga biaya komputasi tumbuh secara akumulatif. Pembersihan berlebihan dapat memicu “semantic page fault”, membuat Agent harus mengambil ulang informasi. Artikel menunjukkan ketidaksesuaian antara status kode dan presisi penyimpanan status desain dapat menyebabkan AI menghasilkan “kode turun-temurun”: Agent berikutnya tidak dapat memahami sebab-akibat desain kode awal, akhirnya membentuk kode kompleks yang saling mengompensasi queue, bypass, dan retry.

Penulis artikel, sumber: Leifengwang

Kode memang ditulis oleh Agent, tetapi Agent berikutnya tidak lagi tahu mengapa Agent sebelumnya menulisnya demikian.

Penambahan kuota mingguan +50% untuk Claude Code yang semula dijadwalkan berakhir pada 19 Agustus telah diperpanjang oleh Anthropic hingga 31 Agustus. Sekitar waktu batas aslinya, muncul diskusi di Hacker News mengenai biaya penggunaan Claude Code: banyak pengguna menemukan bahwa tugas yang tidak terlalu rumit pun, jika dijalankan beberapa siklus oleh Agent, kuota akan cepat habis.

Masalahnya adalah, Claude Code tidak hanya mengonsumsi beberapa baris kode terakhir yang dihasilkan. Membaca file, mencari rantai pemanggilan, menjalankan pengujian, dan memproses log—setiap langkah terus memasuki konteks berikutnya. Semakin panjang tugasnya, semakin berat sejarah yang dibawa Agent, dan semakin bergantung sistem pada pembersihan dan kompresi.

Kode dapat tetap utuh di repositori, tetapi alasan desain awal mungkin perlahan memudar selama kompresi. Akibatnya, konsumsi Token dan tumpukan kode kotor mulai bertemu di tempat yang sama.

Batas komputasi untuk coding chat biasa sangat jelas. Masukkan sepotong kode, model membacanya, lalu memberikan penjelasan atau solusi perbaikan, dan putaran ini pada dasarnya berakhir.

Sedangkan unit dasar Claude Code diubah menjadi agent loop. Model terlebih dahulu mengamati status saat ini, menentukan file mana yang akan dibaca atau perintah apa yang akan dijalankan selanjutnya; setelah alat mengembalikan hasil, model melakukan penilaian berikutnya.

Membaca kode sumber, mencari referensi, menjalankan pengujian, melihat Git diff, dan mengubah file tampak seperti satu tindakan berkelanjutan, tetapi di sisi model sebenarnya merupakan serangkaian permintaan inferensi independen. Dokumentasi resmi Claude Code juga menjadikan siklus “penilaian model—memanggil alat—menilai kembali berdasarkan hasil” sebagai inti dari cara kerja Agent.

Misalnya, masalah kehilangan status login secara acak. Agent terlebih dahulu mencari titik masuk, menemukan bahwa status berasal dari service, lalu melanjutkan membaca service; setelah melihat cache, mencari siapa yang menulisnya; kemudian menjalankan pengujian, di mana pengujian menunjukkan anomali lain, sehingga melihat fixture; setelah diperbaiki, dilakukan verifikasi ulang, tetapi pengujian lama kembali menunjukkan masalah kompatibilitas.

Mungkin baru pada saat ini ia benar-benar mulai menulis beberapa baris kode. Oleh karena itu,diff antara ukuran dan jumlah komputasi hampir tidak memiliki proporsi stabil. Di balik 5 baris patch mungkin hanya ada 3 inferensi, atau mungkin sudah melalui 30 interaksi alat.

Jika tugas Agent dibagi menjadi bagian-bagian, Anda dapat memperoleh dua variabel: satu adalah step count, yaitu berapa langkah yang diambil Agent untuk menyelesaikan tugas; yang lainnya adalah working set, yaitu berapa banyak item status yang masih perlu diketahui model hingga langkah saat ini.

Hanya menambahkan step count sudah akan meningkatkan konsumsi. Jika working set masih terus bertambah selama sinkronisasi, situasinya akan sangat berbeda. Langkah ke-3 mungkin hanya perlu memproses ribuan Token, sedangkan langkah ke-30 mungkin sudah membawa aturan proyek, kode sumber terkait, hasil pengujian, riwayat perubahan, dan alat untuk melanjutkan inferensi.

Ini juga menjadi titik awal perubahan struktur biaya Coding Agent: jumlah komputasi mulai bergantung pada "berapa banyak langkah × berapa berat setiap langkah", bukan lagi berdasarkan berapa banyak baris kode yang ditulis.

Memisahkan satu permintaan model Agent dapat dilihat secara kasar menjadi tiga bagian. Bagian yang relatif stabil mencakup system prompt, CLAUDE.md, definisi alat, dan aturan proyek; bagian yang terus berubah mencakup file kode, hasil pencarian, log pengujian, Git diff, dan riwayat tugas sebelumnya; terakhir, ada reasoning, teks, dan kode yang dihasilkan oleh model pada putaran ini.

Di sini mudah terjadi kesalahpahaman: jika konten sebelumnya sudah dibaca, seharusnya tidak perlu menghasilkan biaya berulang. Masalahnya adalah, LLM tidak memiliki memori internal yang dapat diakses kapan saja seperti program tradisional. Informasi yang diketahui pada putaran sebelumnya, jika putaran berikutnya masih bergantung padanya, status terkait harus tetap muncul dalam context yang tersedia.

Prompt cache dapat meredakan masalah ini. Dokumentasi resmi Claude Code secara jelas menyatakan bahwa tanpa prompt caching, setiap permintaan memerlukan pemrosesan ulang seluruh riwayat; setelah cache berhasil, awalan stabil yang telah diproses dapat digunakan kembali, sehingga mengurangi perhitungan berulang dan biaya.

Namun cache menyelesaikan pertanyaan "apakah sejarah yang sama bisa digunakan kembali dengan biaya lebih murah", bukan pertanyaan "apakah sejarah ini masih perlu dilanjutkan". Setelah status lama 100K Token dipenuhi oleh cache dan menjadi lebih murah, ia tetap menempati context, dan tetap menjadi status di mana inferensi saat ini dibangun.

于是可以把一个长任务粗略写成：第 t 步的输入规模，大约等于稳定前缀 S，加上当前有效工作集 W_t，再加这一轮刚产生的新信息 Δ_t。

Yang benar-benar menjadi masalah adalah W_t. Jika setiap langkah, Agent membaca lebih banyak kode sumber, mendapatkan lebih banyak log, dan meninggalkan lebih banyak keputusan, sementara informasi lama tidak dikeluarkan tepat waktu, maka W_t akan terus meningkat seiring berjalannya tugas.

Di dalam model yang sangat disederhanakan tanpa cache dan pembersihan sama sekali, jika setiap putaran menambahkan jumlah status efektif yang kira-kira sama, total pemrosesan akan menghasilkan struktur akumulasi mendekati 1 + 2 + 3 + … + n. Artinya, jumlah langkah hanya meningkat dua kali lipat, tetapi seluruh status historis yang telah diproses oleh tugas mungkin meningkat lebih cepat.

Sistem aktual memiliki cache, pengeditan konteks, dan kompaksi, sehingga tidak mengikuti kurva pertumbuhan ini secara mekanis, tetapi bentuk masalahnya tidak berubah: semakin lama Agent berjalan, semakin besar kemungkinan setiap tindakan baru dibangun di atas sejarah yang lebih berat.

Jadi, prompt pengguna yang sangat singkat dalam tugas panjang akan cepat kehilangan keberadaannya. Yang benar-benar mulai mendominasi biaya adalah kumpulan kerja yang terus dibawa oleh model untuk menjaga kontinuitas tugas.

Mengapa working set tumbuh begitu cepat? Output alat adalah sumber utama. Kode sumber setidaknya memiliki struktur, sedangkan log sering kali tidak.

一次 grep dapat mengembalikan ratusan referensi, satu build mungkin menghasilkan banyak peringatan, satu kegagalan pengujian mungkin membawa stack trace lengkap, Docker, compiler, dan manajer paket juga menghasilkan banyak teks yang tidak bernilai jangka panjang bagi tugas.

Misalkan pengujian langkah ke-10 menghasilkan log Token 8K. Saat pertama kali masuk ke context, itu hanya 8K Token. Namun, Agent masih perlu terus memeriksa kode sumber, mengubah, dan menguji ulang; selama log ini tetap berada dalam riwayat yang valid, ia akan meningkatkan bobot dasar banyak permintaan berikutnya.

Ini sangat mirip dengan write amplification dalam sistem penyimpanan: satu penulisan logis menyebabkan lebih banyak pemrosesan di tingkat bawah. Dalam kasus Agent, satu output alat ditulis ke dalam riwayat eksekusi, lalu bergerak bersama inferensi berikutnya.

Jadi, dengan token 8K yang sama, menempatkannya di putaran sebelum akhir tugas dan menempatkannya di awal tugas menghasilkan dampak keseluruhan yang sama sekali berbeda. Claude Code kini juga secara aktif mengurangi pencemaran semacam ini. Rekomendasi resmi menggunakan sub-agent untuk mengisolasi tugas dengan output tinggi, dan secara eksplisit menyebutkan bahwa hasil pencarian, log, dan konten file dalam jumlah besar akan mengonsumsi konteks sesi utama; definisi alat itu sendiri juga memakan ruang, sehingga kumpulan alat yang terlalu besar juga akan menambah beban status.

Namun, muncul masalah arah sebaliknya di sini: tidak bisa menghapus seluruh log hanya karena harganya mahal. Dalam sebuah log 3000 baris, mungkin hanya ada 20 baris yang terkait dengan akar penyebab. Sistem tidak tahu terlebih dahulu mana 20 baris tersebut. Jika pembersihan dilakukan terlalu dini, Agent mungkin tiba-tiba membutuhkan salah satu detail tersebut di kemudian hari, dan hanya bisa menjalankan pengujian ulang atau membuka kembali file.

Ini bisa disebut semantic page fault, atau halaman semantik gagal. Dalam memori virtual tradisional, ketika program mengakses halaman yang sudah tidak lagi berada di memori, sistem akan memuat ulang dari disk; setelah Coding Agent membuang bukti awal tertentu, fenomena serupa juga terjadi, hanya saja muncul dalam bentuk pencarian ulang repositori, membaca ulang file, menjalankan perintah lagi, bahkan menurunkan kembali masalah yang sudah dianalisis sebelumnya.

Jadi tugas panjang terjebak dalam dilema: menyimpan terlalu banyak riwayat membuat setiap langkah selanjutnya semakin berat; membersihkan terlalu agresif membuat Agent terus-menerus mengambil ulang informasi yang sudah pernah dilihat sebelumnya.

Ini juga menjelaskan mengapa manajemen konteks tidak bisa disederhanakan menjadi “kurangi jumlah Token yang dimasukkan”. Yang benar-benar perlu diselesaikan adalah pemilihan working set: informasi apa saja yang harus tetap berada di workspace saat ini, dan mana yang hanyalah produk sampingan yang sudah menyelesaikan tugasnya.

Di sini, compaction, memory, dan sub-agent baru benar-benar memiliki alasan untuk ada.

Claude Code akan secara otomatis mengompres sesi saat mendekati batas konteks, serta membersihkan sebagian hasil alat yang lebih lama. Pihak resmi juga memperingatkan bahwa percakapan yang tidak relevan, konten file, dan hasil perintah dalam sesi panjang dapat memenuhi jendela dan mengganggu kinerja model.

Dari sudut pandang sistem, compaction sangat mirip dengan garbage collection semantik. Masalahnya adalah, garbage collection biasa menilai "apakah objek ini masih memiliki referensi", sedangkan Agent harus menilai "apakah informasi ini masih akan bermakna di masa depan".

Yang terakhir jauh lebih sulit. Sebagai contoh, ada kesimpulan desain awal: modul tertentu tidak boleh menyimpan sendiri status pengguna, karena sistem mensyaratkan bahwa status hanya memiliki satu pemilik, dan semua perubahan harus melalui layanan.

Setelah beberapa langkah, jika informasi ini diringkas menjadi: "Masalah status telah diselesaikan melalui penyesuaian service." Fakta tidak salah, tetapi informasinya telah berubah. Konten asli berisi constraint, sedangkan ringkasan berikutnya hanya menyimpan event.

Berikutnya kali Agent menghadapi masalah kinerja, melihat panggilan layanan lambat, kemungkinan besar akan menambahkan cache di dalam modul tersebut. Ia tidak melanggar informasi yang saat ini dimilikinya; hubungan sebab-akibat yang melarang cache tidak lagi dalam keadaan berlaku.

Dokumen konteks Claude Code bahkan secara eksplisit menyatakan bahwa sebagian aturan yang berskala path dan CLAUDE.md bersarang akan diringkas bersama sesi, dan perlu membaca ulang file yang sesuai untuk memuat kembali.

Memory berusaha menyelesaikan masalah penyimpanan pengetahuan jangka panjang. File CLAUDE.md dan auto memory di direktori root proyek dapat mengekstrak konten seperti perintah build, spesifikasi proyek, dan pengalaman debugging dari percakapan jangka pendek, lalu memuatnya kembali saat awal sesi. Namun, Anthropic juga secara jelas menyatakan bahwa memory ini tetap merupakan context, bukan konfigurasi wajib.

Perbedaan ini sangat penting. Jika "tidak dapat mengakses database secara langsung di sini" hanya ditulis di memory, ia tetap merupakan kalimat alami yang perlu dipahami dan diikuti oleh model. Jika aturan yang sama ditulis sebagai dependency lint, batasan tipe, atau pemeriksaan CI, barulah ia menjadi invariant perangkat lunak yang tidak bisa dengan mudah dihindari.

Sub-agent menangani aspek lain: isolasi kumpulan kerja. Dengan membiarkan Agent independen memindai repositori atau menganalisis log panjang, lalu mengembalikan hasil yang telah dikompresi ke Agent utama, hal ini dapat mencegah kebisingan asli memasuki thread utama. Salah satu penggunaan resmi sub-agent oleh Claude Code adalah isolasi konteks.

Harganya juga menarik: Agent utama mendapatkan status yang lebih bersih, tetapi kehilangan sebagian bukti asli; menjalankan beberapa Agent secara bersamaan juga akan membangun context masing-masing. Oleh karena itu, jika dilihat secara keseluruhan, compaction, memory, dan sub-agent sebenarnya sudah sangat mirip dengan hierarki memori di era Agent:

Konteks saat ini adalah memori kerja yang mahal, compaction bertanggung jawab untuk kompresi, memory menyimpan status lintas sesi, dan sub-agent menggunakan ruang alamat terpisah untuk mengisolasi noise. Masalahnya juga berubah dari "apakah konteks cukup besar" menjadi tingkat lain:

Status mana yang perlu disimpan dengan presisi tinggi, dan status mana yang hanya perlu menyisakan ringkasan. Pertanyaan ini akan secara langsung memengaruhi kualitas kode selanjutnya.

Setelah memahami struktur eksekusi sebelumnya, saat melihat kuota mingguan Claude Code, akan terlihat bahwa platform sulit terus mengukur Agent berdasarkan "jumlah pesan", karena satu pesan sudah kehilangan makna yang stabil.

Mengganti nama variabel adalah satu pesan, merekonstruksi seluruh modul otentikasi juga satu pesan. Yang pertama mungkin selesai dalam beberapa langkah, sementara yang kedua bisa berjalan selama puluhan siklus, membaca puluhan file, lalu memulai beberapa Agent. Satu permintaan yang sama bisa memiliki kebutuhan sumber daya yang sama sekali berbeda skalanya.

Claude Code mengemas hal ini dengan batasan gulir dan kuota mingguan; Codex sekarang secara jelas menghitung kredit berdasarkan token input, token input yang di-cache, dan token output; paket Cursor menyediakan pool penggunaan berbeda untuk Agent, dan konsumsi model pihak ketiga akan dipengaruhi oleh harga API model.

Tiga produk memiliki bahasa antarmuka yang berbeda, tetapi masalah dasar yang perlu diatasi sangat mirip: bagaimana mengalokasikan sumber daya inferensi untuk program cerdas yang jalur eksekusinya tidak dapat ditentukan sebelumnya. Berapa lama sebuah Coding Agent akan berjalan sulit ditentukan pada awal tugas.

Model mungkin segera menemukan akar penyebab, atau mungkin mengajukan beberapa asumsi salah secara berurutan; mungkin lulus dalam satu pengujian, atau masuk ke dalam loop debug yang panjang; mungkin hanya memerlukan satu Agent, atau mungkin memisahkan menjadi beberapa sub-agent.

API tradisional suka membebankan berdasarkan permintaan, karena fluktuasi sumber daya satu permintaan masih dapat dikendalikan dalam batas tertentu. Agent menghancurkan stabilitas ini. Oleh karena itu, Token di sini mulai memiliki sedikit nuansa waktu CPU.

Perbandingan ini tidak bisa disamakan. Model yang berbeda memiliki biaya komputasi berbeda untuk memproses jumlah token yang sama, dan input, input yang di-cache, serta output juga memiliki biaya yang berbeda. Namun dari sisi pengembang, fungsinya semakin mirip: semuanya menggambarkan berapa banyak sumber daya komputasi yang digunakan untuk melanjutkan suatu tugas.

Anthropic saat meningkatkan batas penggunaan Claude Code tahun ini juga secara langsung menghubungkan peningkatan kuota dengan penambahan kapasitas komputasi. Ini akan membawa perubahan indikator yang menarik. Sebelumnya, saat melihat Coding Agent, mudah membandingkan "siapa yang menyelesaikan soal yang sama dengan baik dalam satu kali upaya". Ke depan, mungkin lebih bermakna untuk melihat: siapa yang mengonsumsi komputasi efektif lebih sedikit untuk mencapai perubahan status proyek yang sama.

Jika sebuah Agent menghabiskan sejumlah besar Token hanya untuk membuka ulang file, menjalankan ulang pengujian, dan memulihkan kembali konteks yang sudah hilang, Token tersebut tidak menghasilkan kemajuan teknis yang sepadan.

Dan kondisi pemulihan yang tidak efisien ini tepat bertemu dengan utang teknis di lapisan berikutnya.

Di sini, perangkat lunak yang dipertahankan oleh Coding Agent dapat diabstraksikan menjadi dua set status yang berkembang secara bersamaan. Satu set adalah status kode R_t. File, tipe, antarmuka, pengujian, dan Git commit semuanya termasuk dalam lapisan ini. Satu baris retry yang ditambahkan pada langkah ke-20 oleh Agent, selama tidak dihapus, tetap ada secara utuh saat membuka file pada langkah ke-100. Presisi penyimpanan perubahan masa lalu pada kode sangat tinggi.

Satu set lainnya adalah status desain M_t. Mengapa di sini diperlukan retry, mengapa cache tersebut hanya bisa ditempatkan di service, mengapa status ini tidak bisa memiliki dua pemilik, mengapa pengecekan yang tampaknya berlebihan belum bisa dihapus, informasi-informasi ini termasuk dalam sebab-akibat desain.

M_t Tidak ada penyimpanan lossless alami seperti Git. Ia tersebar di dalam percakapan, penalaran, hasil alat, memori, file aturan, dan ringkasan compaction. Setelah tugas terus berlanjut, sebagian konten dibersihkan, sebagian diringkas, dan sebagian perlu diambil kembali.

Akibatnya muncul ketidakseimbangan kritis: hasil yang dicapai dapat terakumulasi dengan presisi tinggi, sedangkan hubungan sebab-akibat yang menghasilkan hasil tersebut terus-menerus mengalami downsampling. Ini jauh lebih serius daripada sekadar mengatakan “Agen akan lupa sesuatu”.

Dalam kasus masalah konkurensi ini, setelah analisis oleh Agent, sebuah antrian ditambahkan. Pada saat itu, kesimpulan lengkap yang dimiliki Agent adalah: hanya jalur tulis A yang mengalami persaingan, sehingga antrian hanya dapat menangkap A; jalur tulis B memerlukan latensi rendah dan tidak boleh masuk ke antrian ini.

Kode telah menyimpan queue secara utuh. Setelah dijalankan dalam waktu lama, status desain mungkin hanya tersisa "di sini gunakan queue untuk menyelesaikan race condition".

Kemudian, B juga mengalami kesalahan sewaktu-waktu. Ketika agen membaca kode lagi, secara alami B juga dihubungkan ke antrian yang ada.

Kemudian penundaan meningkat, jadi ditambahkan bypass. Bypass memicu ketidaksesuaian status sesekali, jadi ditambahkan retry di luar. Sampai di sini, tidak ada satu pun perubahan yang pasti absurd. Setiap patch tampak sangat masuk akal dalam konteks lokal yang terlihat pada saat itu. Namun kode telah berubah dari “model konkurensi yang jelas” menjadi queue, bypass, dan retry yang saling mengkompensasi.

Gunung sampah kode AI kemungkinan besar tumbuh seperti ini. Ini tidak selalu terlihat sebagai model yang tiba-tiba menghasilkan sampah, tetapi lebih mungkin terlihat sebagai akumulasi bagian-bagian yang benar secara lokal, sementara model keseluruhan perlahan menghilang.

Masalah semacam ini biasanya terbentuk perlahan melalui peralihan personel di perangkat lunak tradisional. Pengembang asli pergi, dan pengembang baru melihat kode lama tetapi tidak tahu mengapa kode itu ada, sehingga mereka menambahkan lapisan logika kompatibilitas di luarannya.

Agen pemrograman mengubah "serah terima personil" menjadi "serah terima konteks". Langkah ke-20 dan langkah ke-100 tampaknya masih sesi Claude Code yang sama, tetapi status desain yang mereka dapatkan sebenarnya sudah tidak sepenuhnya sama. Dari sudut pandang informasi, ini lebih mirip dua insinyur yang memelihara repositori yang sama melalui dokumen serah terima yang terus menyusut.

Pengujian hanya dapat menyelesaikan sebagian dari masalah tersebut. Pengujian unggul dalam melindungi perilaku: antarmuka harus mengembalikan apa, input tertentu tidak boleh menyebabkan kegagalan, dan bug sebelumnya tidak boleh muncul kembali. Banyak batasan arsitektur tidak secara alami terwujud sebagai input dan output.

Status hanya boleh memiliki satu owner, lapisan domain tidak boleh bergantung secara terbalik pada UI, suatu package tidak diizinkan terhubung langsung ke database, operasi tulis harus melewati batas transaksi terpusat; batasan-batasan ini jika hanya ada dalam dokumen atau ingatan Agent, mudah terlewatkan saat perbaikan lokal.

Hasilnya adalah keadaan teknis yang sangat merepotkan: pengujian masih hijau, tetapi kode semakin sulit dijelaskan. Lebih berbahaya lagi, ada umpan balik di dalamnya.

Arsitektur mulai berantakan, Agent berikutnya yang memahami fitur perlu membaca lebih banyak file; semakin rumit ketergantungan, semakin besar working set; semakin berat working set, semakin besar kebutuhan sistem akan pembersihan dan kompresi; semakin tipis penyimpanan sebab-akibat desain, semakin mudah modifikasi berikutnya bergantung pada kode saat ini dan pengujian lokal.

Karena itu, kompleksitas kode mulai meningkatkan biaya token, dan tekanan token pada gilirannya mendorong penyimpanan status yang lebih pendek dan perbaikan yang lebih lokal. Inilah mekanisme yang lebih perlu diwaspadai di balik “semakin banyak iterasi, semakin banyak masalah” dalam agent coding.

Ini bukan masalah kemampuan model tunggal, tetapi masalah sistem yang melibatkan ketidaksesuaian presisi dalam penyimpanan status kode dan status desain.

Coding Agent semakin mampu bertindak dalam waktu lama, tetapi "mampu berjalan selama beberapa jam" sendiri belum tentu menjadi indikator kemampuan yang baik.

Jika sebuah Agent bekerja selama 3 jam, lalu perlu membaca kembali file yang telah diubahnya 2 jam yang lalu, menalar ulang mengapa suatu abstraksi ada, dan menjalankan kembali pengujian yang sebelumnya sudah dijalankan, maka sebagian besar komputasi selama 3 jam tersebut sebenarnya dihabiskan untuk pemulihan status.

Masalah berikutnya akan menjadi: Seberapa banyak informasi kausal yang bernilai untuk keputusan selanjutnya masih dipertahankan oleh sebuah Agent setelah 50 langkah, 100 langkah.

Dapat disebut sebagai state fidelity.

Karena itu mengukur bukan seberapa banyak Token yang bisa dimasukkan ke dalam konteks, tetapi berapa banyak informasi desain kunci yang tetap tersedia setelah pemanggilan alat, kompresi, lintas sesi, dan pencarian memori. Ini juga berarti bahwa memori jangka panjang Agent tidak bisa hanya bergantung pada konteks yang lebih panjang.

Beberapa pengetahuan lebih cocok disimpan di memory, seperti cara membangun proyek dan kebiasaan pengembangan; beberapa keputusan sebaiknya dimasukkan ke dalam ADR terstruktur atau indeks kode; sementara yang melanggar batas arsitektur sistem akan lebih tepat ditulis langsung ke dalam tipe, pengujian, lint, aturan dependensi, dan CI.

Jika sebuah aturan telah menjadi batasan yang dapat dieksekusi oleh perangkat lunak, Agent tidak perlu "mengingat"nya. Pada putaran berikutnya, Agent dapat melupakan sebuah percakapan, tetapi tidak dapat dengan mudah melewati compiler dan pengujian.

Jika tingkat keakuratan rendah, semakin lama Agent berjalan, semakin banyak ranjau yang ditanamkan ke dalam sistem.

Ini mungkin juga merupakan batas yang harus dilalui Coding Agent untuk berpindah dari “bisa menulis kode” menuju “mampu memelihara perangkat lunak dalam jangka panjang”: memindahkan pengetahuan desain dari ingatan bahasa yang bersifat probabilitas, secara bertahap ke dalam keadaan perangkat lunak yang dapat diambil, diverifikasi, dan dieksekusi.

Semakin lama berjalan mandiri, akan muncul skenario yang sangat absurd. Agent semakin cepat menulis kode, dan proyek pun berubah dengan cepat, tetapi setiap beberapa waktu, ia harus memahami kembali dunia yang ditinggalkan dari periode sebelumnya.

Kalimat umum dalam kode turun-temurun adalah: "Jangan sentuh bagian ini, tidak tahu kenapa bisa meledak."

Kode turunan AI mungkin lebih aneh lagi: kode memang ditulis oleh Agent, tetapi Agent berikutnya sudah tidak tahu mengapa Agent sebelumnya menulisnya seperti itu.