Pagbaba ng Kuwota ng Claude Code: Gumagawa ba ang mga Agent ng mga Bagong 'Kabundukan ng Legacy Code'?

Ang pagpapalawig ng lingguhang limitasyon ni Claude Code ay nagdulot ng pansin, at ang artikulo ay nag-analisa ng mekanismo ng pagkonsumo ng Token ng Agent. Ang matagal na pagpapatakbo ng Agent ay nagdudulot ng patuloy na paglalawak ng working set, kung saan bawat hakbang ay nag-aakumula ng kasaysayan ng estado, kasama ang katotohanan na ang cache hit ay nananatiling bahagi ng context, na nagiging sanhi ng akumulatibong pagtaas sa gastos sa pagkalkula. Ang paglinis sa sobrang dami ay maaaring magdulot ng “semantic page fault,” kung kailangan ng Agent na muli pang kunin ang impormasyon. Ipinapakita ng artikulo na ang hindi pagkakaayos sa pagitan ng code state at ang antas ng pag-iingat ng design state ay maaaring magresulta sa “legacy code” na nilikha ng AI: ang mga susunod na Agent ay hindi makakaintindi sa mga dahilan at epekto ng dating code, at sa huli ay magbuo ng kompleks na code na binubuo ng queue, bypass, at retry na nagpapalitan.

May-akda ng artikulo, pinagkukunan: Leifeng.com

Totoo ang code ay isinulat ng Agent, ngunit ang mga susunod na Agent ay hindi na alam kung bakit isinulat nang ganito ng dating Agent.

Ang +50% na bonus sa linggong quota para sa Claude Code, na orihinal na iskedyul na matapos noong Agosto 19, ay naextend pa ng Anthropic hanggang Agosto 31. Sa paligid ng orihinal na petsa ng pagtatapos, may isang talakayan sa Hacker News tungkol sa gastos sa paggamit ng Claude Code: marami ang nakakita na kahit isang hindi komplikadong gawain, kung papagana ng Agent nang ilang beses, mabilis na bababa ang quota.

Ang problema ay ang Claude Code ay hindi lamang gumagamit ng mga huling ilang linya ng code na ginawa. Ang pagbabasa ng file, paghahanap sa chain ng pagtawag, pagpapatakbo ng mga pagsubok, at pagproseso ng mga log—bawat hakbang ay patuloy na nagdadala sa susunod na konteksto. Mas mahaba ang task, mas mabigat ang kasaysayan na dala-dala ng Agent, at mas nakasalalay ang sistema sa paglinis at pag-compress.

Ang code ay maaaring manatili nang buo sa repository, ngunit ang mga orihinal na dahilan sa disenyo ay maaaring maging mas mababa sa pag-compress. Kaya ang paggamit ng Token at ang code smell ay nagsasama sa iisang lugar.

Malinaw ang hangganan ng pagkalkula sa karaniwang Chat coding. Ipasok ang isang piraso ng code, basahin ng modelo ang buong ito, at ibibigay ang paliwanag o solusyon sa pagbabago—tapos na ang isang round.

Ang pangunahang yunit ng Claude Code ay naging agent loop. Una ang modelo na obserbahan ang kasalukuyang kalagayan, desisyunan kung anong file ang babasahin o anong utos ang iuupahan; pagkatapos mabigyan ng resulta ng mga kasangkapan, gagawin ng modelo ang susunod na pagtataya.

Basahin ang source code, hanapin ang mga pagbanggit, patakbuhin ang mga pagsubok, tingnan ang Git diff, baguhin ang mga file, tila isang tuloy-tuloy na aksyon, ngunit sa panig ng model, ito ay isang serye ng mga hiwalay na paghuhusga. Ang opisyal na dokumentasyon ng Claude Code ay naglalagay ng ganitong “paghuhusga ng model—pagtawag ng tool—patuloy na paghuhusga batay sa resulta” na siklo bilang pangunahing paraan ng paggawa ng Agent.

Halimbawa, isang problema kung saan ang login status ay minsan ay nabubuwag. Ang agent ay unang natagpuan ang entry point, natuklasan na ang status ay galing sa service, kaya nagpatuloy sa pagbabasa ng service; pagkatapos makita ang cache, tinukoy kung sino ang sumusulat dito; pagkatapos ay isinagawa ang pagsubok, at sa pagsubok ay lumabas ang ibang anomalya, kaya tinignan ang fixture; pagkatapos ay ikinorekta, at muli itong sinuri, ngunit ang lumang pagsubok ay nagpalabas ng problema sa compatibility.

Maaaring hanggang sa point na ito lamang ang nagsisimula na isulat ang ilang mga linya ng code. Kaya,diff ang sukat at dami ng computation ay halos walang matatag na proporsyon. Maaaring mayroon lamang 3 na pag-iisip sa likod ng 5 na linya ng patch, o maaari naman ay mayroon nang 30 na interaksyon sa tool.

Kung ihihiwalay ang isang Agent task, maaari mong makuha ang dalawang variable: ang step count, kung ilang hakbang ang ginawa ng Agent upang matapos ang task; at ang working set, kung ilang item status ang kailangan pa ng model sa kasalukuyang hakbang.

Ang pagdodoble lang ng step count ay magpapataas na sa pagkawala. Kung ang working set ay patuloy na lumalaki habang nagpapalit, iba na ang sitwasyon. Ang hakbang 3 ay maaaring kailanganin lang ang pagproseso ng ilang libo na Token, ngunit ang hakbang 30 ay maaaring naghahatid na ng project rules, kaugnay na source code, mga resulta sa pagsubok, kasaysayan ng pagbabago, at mga tool para sa patuloy na pag-iisip.

Ito rin ang punto kung saan nagbago ang istruktura ng gastos ng Coding Agent: ang pagkalkula ay nagsimulang nakabatay sa “ilang hakbang ang lalakarin × gaano kalaki ang bigat bawat hakbang,” at hindi na sa bilang ng mga linya ng code na isinulat.

Ang isang paghingi ng model ng Agent ay maaaring hatiin sa tatlong bahagi. Ang mga bahaging relatibong stable ay kasama ang system prompt, CLAUDE.md, mga definisyon ng tool, at mga patakaran ng proyekto; ang mga bahaging palaging nagbabago ay kasama ang mga file ng code, mga resulta ng paghahanap, mga log ng pagsubok, Git diff, at nakaraang track ng task; at huli, ang reasoning, teksto, at code na nilikha ng model sa round na ito.

Mayroong karaniwang maling pagkaunawa dito: kung ang nakaraang nilalaman ay nabasa na, hindi dapat maulit ang maraming gastos. Ang problema ay ang walang panloob na memorya na maaaring ma-access nang anumang oras sa pagitan ng dalawang paghingi ng LLM. Kung ang impormasyon na alam sa nakaraang round ay kailangan pa rin sa susunod na round, dapat patuloy na maging bahagi ng available context ang kaugnay na estado.

Ang prompt cache ay makakatulong na lubos na lutasin ang problema. Ipinapaliwanag ng opisyal na dokumentasyon ng Claude Code na kung walang prompt caching, kailangang muli pang prosesuhin ang buong kasaysayan sa bawat request; pagkatapos ng cache hit, maaaring gamitin muli ang mga nakaproseso at matatag na prefix, na nagpapababa sa pag-uulit ng pagkalkula at gastos.

Ngunit ang cache ay tumutugon sa “kaya ba nating gamitin muli nang mas mura ang parehong kasaysayan”, hindi naman sa “kailangan pa ba ng kasaysayang ito”. Pagkatapos makuha ang nakaraang estado ng 100K Token mula sa cache nang mura, nananatili pa rin ito sa context at patuloy na basehan ng kasalukuyang pag-iisip.

Kaya maaaring isulat ang isang mahabang gawain nang lubos bilang: ang sukat ng input sa hakbang t, ay katumbas ng malalaking prefix na S, kasama ang kasalukuyang epektibong workset W_t, at ang bago pang impormasyon na ginawa sa round na ito Δ_t.

Ang totoong problema ay W_t. Kung bawat hakbang, mas maraming source code ang binabasa ng Agent, mas maraming log ang natatanggap, at mas maraming desisyon ang iniiwan, habang ang mga lumang impormasyon ay hindi agad na inalis, W_t ay lalago habang patuloy ang task.

Sa isang extremeng pinasimple, walang cache at cleanup na modelo, kung ang bawat round ay nagdadala ng magkaparehong dami ng epektibong estado, ang kabuuang proseso ay magkakaroon ng akumulatibong istruktura na malapit sa 1 + 2 + 3 + … + n. Ibig sabihin, kahit na tumambahog lang ng isang beses ang step count, ang kabuuang kasaysayan ng mga estado na na-proseso ay maaaring tumataas nang mas mabilis.

Mayroong cache, context editing, at compaction sa tunay na sistema, kaya hindi ito sumusunod nang mekanikal sa kurba ng paglago, ngunit ang hugis ng problema ay hindi nagbabago: habang mas matagal ang pagpapatakbo ng Agent, mas malaki ang posibilidad na bawat bagong aksyon ay batay sa mas mabigat na kasaysayan.

Kaya mabilis na mawawala ang pagkakakilanlan ng maikling user prompt sa mahabang gawain. Ang tunay na nagsisimula na magdomina sa gastos ay ang working set na patuloy na dinala ng modelo upang panatilihin ang kontinuidad ng gawain.

Bakit ganun kalaking ang working set? Ang output ng tool ay isang malaking pinagkukunan. Ang source code ay may kakaibang istruktura kung kaya't ang mga log ay madalas walang.

Isang grep ay maaaring magbalik ng mga hundreds na pagbanggit, isang pagbuo ay maaaring maglabas ng malalaking warning, isang pagkabigo sa pagsubok ay maaaring kasama ang buong stack trace, at ang Docker, compiler, at package manager ay magdadala rin ng maraming teksto na walang matagal na halaga sa task.

Kung ang pagsubok sa hakbang 10 ay nagproduksyon ng 8K Token log, nang una itong maipasok sa context, ito ay 8K Token lamang. Gayunpaman, kailangan pa ng Agent na suriin ang source code, baguhin, at subukang muli; habang nananatili ang log na ito sa epektibong kasaysayan, ito ay magpapataas sa base weight ng maraming susunod na paghingi.

Parang write amplification sa storage system: isang logical write, nagdudulot ng higit pang pagproseso sa ilalim. Sa loob ng Agent, isang tool output ay isinusulat sa execution history, at kasunod nito ay kasama sa susunod na pag-iisip.

Kaya ang parehong 8K Token, kung isisilid sa isang round bago matapos ang gawain at kung isisilid sa simula ng gawain, magdudulot ng iba’t ibang pangkabuuang epekto. Ang Claude Code ay abot na abot na bumawas sa ganitong polusyon. Ang opisyal na rekomendasyon ay gamitin ang sub-agent para i-isolate ang mga gawain na may mataas na output, at malinaw na binanggit na ang mga resulta ng paghahanap, mga log, at malalaking laman ng mga file ay magkakaroon ng pagkakasunod-sunod sa pangunahing sesyon; ang sariling depinisyon ng mga kasangkapan ay kumukuha din ng espasyo, kaya ang sobrang laki ng set ng mga kasangkapan ay magdadagdag din sa bigat ng estado.

Ngunit may isang kabaligtarang problema dito: hindi mo dapat tanggalin ang lahat ng mga log dahil mahal sila. Sa isang 3000-line na log, maaaring mayroon lang 20 na linya na may kinalaman sa root cause. Hindi alam ng sistema kung alin ang 20 na linya. Kung masyadong maaga ang paglinis, at kailangan ng Agent ng isang detalye sa huli, kailangan niya muli pang i-run ang pagsubok o buksan muli ang file.

Ito ay maaaring tawagin bilang semantic page fault, o semantic na kulang sa pahina. Sa tradisyonal na virtual memory, kapag ang isang programa ay nag-access sa isang pahina na hindi na nasa memorya, ang sistema ay muling lalabas mula sa disk; kapag ang Coding Agent ay inalis ang isang nakaraang ebidensya, mangyayari rin ang katulad na pangyayari, ngunit ito ay ipinapakita sa pamamagitan ng pagmumula muli ng paghahanap sa repository, pagbubukas muli ng mga file, pagpapatakbo muli ng mga utos, o kaya ay muling pagdedebate sa isang problema na dating analisado.

Kaya ang mahabang gawain ay nasa isang mahirap na sitwasyon: ang pag-iingat ng maraming kasaysayan ay gumagawa ng bawat susunod na hakbang na mas mabigat; samantalang ang sobrang paglinis ay nagpapakailangan sa Agent na muli at muli pang kunin ang mga impormasyon na dating nakita.

Ito rin ang nagpapaliwanag kung bakit ang pagpapamahala ng context ay hindi maaaring mapasimple sa “mas kaunting Token ang ilalagay”. Ang tunay na dapat lutasin ay ang pagpili ng working set: alin sa mga impormasyon ang dapat manatili sa workspace ngayon, at alin ang mga intermediate product na naitaglay na ang kanilang misyon.

Dito na lang talaga may katotohanan ang compaction, memory, at sub-agent.

Kapag malapit na ang Claude Code sa hangganan ng context, awtomatikong i-compress nito ang session, at kasabay nito, i-clear nito ang ilang mas lumang mga resulta ng tool. Inirerekomenda rin ng opisyal na ang mga hindi kaugnay na usapan, laman ng file, at mga resulta ng command sa mahabang session ay maaaring magpunta sa window at magdulot ng pagkakaantala sa pagganap ng model.

Mula sa pananaw ng sistema, ang compaction ay parang isang semantic garbage collection. Ang problema ay ang karaniwang garbage collection ay tumitingin kung mayroon pa bang reference sa isang object, habang ang Agent ay kailangang matukoy kung may kahulugan pa ba ang impormasyong ito sa hinaharap.

Mas mahirap ang huli. Halimbawa, mayroon itong nakaraang disenyo结论: Hindi makapag-cache ang isang module ng estado ng user, dahil nangangailangan ang sistema na mayroon lamang isang owner ang estado, at lahat ng pagbabago ay dapat dumadaan sa service.

Sa ilang mga hakbang, kung ang impormasyong ito ay pinababa sa: “Naresolba ang problema sa estado sa pamamagitan ng service na pagbabago.” Walang mali sa katotohanan, ngunit nagbago na ang impormasyon. Ang orihinal na nilalaman ay naglalaman ng constraint, samantalang ang sumaryo ay nagtatago lamang ng event.

Kapag makakasalubong ngayon ng Agent ang isang performance issue, at makikita niya na ang service call ay mabagal, malamang ay magdaragdag siya ng cache sa module. Hindi niya sinira ang kanyang kasalukuyang kaalaman; ang sanhi at epekto ng pagbabawal sa cache ay hindi na aktibo.

Ang context document ng Claude Code ay nagtuturo nang malinaw na ang ilang path-scoped na patakaran at ang mga nakapalibot na CLAUDE.md ay iinasar sa pamamagitan ng compaction summary kasama ang sesyon, at kailangan muli pang basahin ang mga file na tumutugma upang muling i-load.

Ang Memory ay nagtatangka na lutasin ang problema ng pangmatagalang pagpapanatili ng kaalaman. Ang CLAUDE.md at auto memory sa root directory ng proyekto ay nakakakuha ng mga nilalaman tulad ng mga utos sa pagbuo, mga spesipikasyon ng proyekto, at mga karanasan sa pag-debug mula sa maikling talakayan at muli itong iloload sa simula ng bawat sesyon. Ngunit malinaw din na isinulat ng Anthropic: ang mga memory na ito ay patuloy na mga context at hindi bahagi ng mandatory configuration.

Sobrang kritikal ang pagkakaiba na ito. Kung isusulat lamang sa memory ang “hindi direktang ma-access ang database dito,” nananatili itong isang natural na wika na kailangang maunawaan at sundin ng model. Kung isusulat naman ang parehong patakaran bilang dependency lint, type constraint, o CI check, naging software invariant na ito na hindi madaling i-evasive.

Ang sub-agent ay tumutugon sa isang iba pang aspeto: pag-isolate ang working set. Ang pagpapagana ng isang hiwalay na Agent upang i-scan ang repository o i-analyze ang mahabang log, at pagkatapos ay ibalik ang komprimo的结果 sa pangunahing Agent, ay nakakaiwas sa orihinal na ingay na pumasok sa pangunahing thread. Ang isa sa mga gamit ng sub-agent ayon sa opisyal na pahayag ni Claude Code ay ang context isolation.

Ang gastos nito ay kakaibang kahulugan: ang pangunahing Agent ay nakakuha ng mas malinis na estado, ngunit nawala ang ilang orihinal na ebidensya; habang ang pagpapatakbo ng maraming Agent nang sabay-sabay ay bumubuo ng kanilang sariling context. Kaya, kapag tingnan natin ang compaction, memory, at sub-agent nang isang sama, ito ay tila isang uri ng hierarchy ng memory sa panahon ng Agent:

Ang kasalukuyang context ay isang mahal na working memory, ang compaction ang responsable sa pag-compress, ang memory ay nag-iimbak ng state na nakapagdaan sa mga session, at ang sub-agent ay gumagamit ng hiwalay na address space para i-isolate ang ingay. Ang problema ay naging ibang antas mula sa “sapat ba ang laki ng context”:

Ano ang mga estado na kailangang i-save nang may mataas na fidelity, at ano ang mga estado na sapat na may abstrak na iwanan. Ang tanong na ito ay direktang magdudulot ng epekto sa kalidad ng code.

Pagkatapos maunawaan ang pagsasagawa na ito, kapag titingin sa lingguhang quota ni Claude Code, makikita na mahirap para sa platform na patuloy na sukatin ang Agent batay sa “bilang ng mensahe” dahil nawala na ang tiyak na kahulugan ng isang mensahe.

Ang pagbabago ng pangalan ng variable ay isang mensahe, at ang pag-restructure ng buong authentication module ay isang mensahe rin. Ang una ay maaaring matapos sa ilang hakbang, habang ang huli ay maaaring mag-run ng maraming siklo, basahin ang maraming file, at i-start ang maraming Agent. Isang parehong request, ngunit ang mga pangangailangan sa yunit sa likod nito ay maaaring ganap na iba-iba.

Ang Claude Code ay nagpapakilos gamit ang mga limitasyon sa scroll at lingguhang quota; ang Codex ay ngayon ay malinaw na nagkakalkula ng credits batay sa input token, cached input token, at output token; habang ang mga package ng Cursor ay nagbibigay ng iba’t ibang usage pool para sa Agent, at ang paggamit sa mga third-party model ay nakaaapekto sa presyo ng model API.

Magkakaiba ang wika ng interface ng tatlong produkto, ngunit malapit ang mga problema na kailangang lutasin sa ilalim: paano mag-alaok ng mga yunit para sa pag-iisip sa isang matalinong programa kung ang pagpapatakbo nito ay hindi matitiyak sa harap. Mahirap malaman kung gaano katagal magpapatakbo ang isang Coding Agent nang unang pagkakataon.

Maaari ng madaling makahanap ng root cause ang model, o maaaring maglagay ng ilang maling aksiyon nang patuloy; maaaring makapasa sa isang pagsubok lamang, o maaaring makapasok sa mahabang debug loop; maaaring kailanganin lamang ang isang Agent, o maaaring hiwalayin sa maraming sub-agent.

Ang tradisyonal na API ay mahilig mag-billing batay sa request dahil ang pagkakaiba sa resources ng isang request ay maaari pa ring kontrolin sa isang tiyak na saklaw. Ang Agent ay nagpapabagsak sa katatagan na ito. Kaya ang Token ay nagsisimula nang magkaroon ng kaunting katulad na anyo ng CPU time.

Hindi maaaring isakatuparan ang parehong pagkakapareho. Magkakaiba ang gastos sa computing power ng iba’t ibang modelo para sa parehong bilang ng Token, at magkakaiba rin ang gastos para sa input, cached input, at output. Ngunit sa pananaw ng developer, ang mga tungkulin nito ay nagsisimula nang magkasingkasing: lahat ay naglalarawan kung gaano karaming computing resource ang ginamit upang magpatuloy ang isang task.

Noong inatake ng Anthropic ang limitasyon sa paggamit ng Claude Code sa taong ito, direktang iugnay nila ang pagtaas ng quota at ang pagdaragdag ng compute capacity. Ito ay magdudulot ng isang interesanteng pagbabago sa indikador. Noon, kapag tinutukoy ang Coding Agent, madaling ihambing kung sino ang nakakasulat nang maayos sa isang problema sa isang pagkakataon. Ngunit sa hinaharap, mas may kahulugan posibleng maging: sino ang gumagamit ng mas kaunting epektibong compute upang makamit ang parehong pagbabago sa estado ng proyekto.

Kung ang isang Agent ay gumagastos ng malaking halaga ng Token para lang ulitin ang pagbubukas ng mga file, pagpapatakbo muli ng mga pagsubok, at pagbabalik ng mga nawawalang konteksto, hindi nagdala ang mga Token na iyon sa katumbas na pag-unlad sa inhinyeriya.

At ang mga hindi epektibong pagbabalik ng katayuan na ito ay tumpak na makakasalubong ang teknikal na utang sa mas mababang antas.

Dito maaaring isabuhay ang isang software na pinapanatili ng isang Coding Agent bilang dalawang magkakasabay na umuunlad na estado. Isa sa mga ito ay ang code state R_t. Ang mga file, type, interface, test, at Git commit ay kabilang sa antas na ito. Ang isang linya na idinagdag ng Agent sa hakbang 20 na retry, kahit na hindi ito tinanggal, ay nananatiling buo at nasa lugar nito kapag binuksan ang file sa hakbang 100. Ang code ay may mataas na antas ng precision sa pag-iingat ng mga nakaraang pagbabago.

Ang isa pang set ay ang estado ng disenyo M_t. Bakit kailangan dito ang retry, bakit maaaring ilagay lamang ang cache sa service, bakit hindi maaaring magkaroon ng dalawang owner ang estado na ito, bakit hindi maaaring tanggalin ang isang tila nadudulot na pagsubok, ang mga impormasyong ito ay bahagi ng dahilan at desisyon sa disenyo.

M_t Walang natural na lossless storage tulad ng Git. Ito ay nakalat sa mga usapan, pag-iisip, mga balik ng mga kasangkapan, memorya, mga file ng patakaran at kompaksiyon na buod. Habang patuloy ang mga gawain, ang ilang mga bahagi ay nalilinis, ang ilan ay binubuod, at ang ilan ay kailangang muli pang hanapin.

Kaya umiiral ang isang mahalagang asimetría: ang mga resulta ay maaaring makalikom ng mataas na katumpakan, ngunit ang mga ugnayang sanhi at epekto na nagbuo sa mga resultang iyon ay patuloy na mababawasan. Mas serio ito kaysa sa simpleng pagsasabi na “ang Agent ay makakalimot.”

Sa isang pagkakaroon ng concurrency issue, ang Agent ay nag-analisa at nagdagdag ng isang queue. Noong panahong iyon, ang kumpletong konklusyon na may-akda nito ay: ang tanging kompetisyon ay nasa write path A, kaya ang queue ay maaaring sakop lamang ang A; ang write path B ay nangangailangan ng mababang latency at hindi maaaring pumasok sa queue na ito.

Nakapag-save ang code ng buong queue. Pagkatapos ng mahabang pagpapatakbo, ang disenyo ay maaaring natitira na lamang sa “gagamitin ang queue para lutasin ang race condition”.

Pagkatapos ay lumabas din ang isang pansamantalang error sa B. Kapag binasa ulit ng agent ang code, natural na isinama niya ang B sa umiiral na queue.

Pagkatapos ay tumataas ang delay, kaya idinagdag ang bypass. Ang bypass ay nagdulot ng pagkakamali sa estado sa pagkakataon, kaya idinagdag ang retry sa palibot. Sa punto na ito, walang isang pagbabago ang tiyak na nakakalokal. Bawat patch ay maaaring maging lubos na makatwiran batay sa lokal na estado na nakikita nito sa panahong iyon. Ngunit ang code ay naging mula sa “isang malinaw na concurrent model” patungo sa queue, bypass, at retry na nagpapalit-palit.

Ang AI codebase na isang "code smell" ay maaaring lumikha sa ganitong paraan. Hindi ito laging ipinapakita bilang ang modelo na biglang naglalabas ng isang kalat na basura, kundi mas malamang ay ipinapakita bilang ang patuloy na pagkolekta ng mga lokal na tama, habang ang buong modelo ay unti-unting nawawala.

Sa tradisyonal na software, karaniwang bumubuo ang mga ganitong problema sa pamamagitan ng pagpapasa-pasa ng mga tao. Pagkatapos umalis ang orihinal na may-akda, ang mga bagong developer ay nakakakita ng lumang code ngunit hindi alam kung bakit ito umiiral, kaya naglalagay sila ng isang karagdagang compatibilidad na lohika sa palibot nito.

Ang Coding Agent ay nagbago ng “pagpapasa ng mga tauhan” sa “pagpapasa ng konteksto.” Ang hakbang 20 at hakbang 100 ay tila parehong Claude Code session, ngunit ang kanilang natanggap na estado ng disenyo ay hindi na ganap na magkakatulad. Sa pananaw ng impormasyon, mas tila dalawang engineer na nagpapanatili ng iisang repository sa pamamagitan ng isang dokumento ng pagpapasa na patuloy na bumababa.

Ang pagsubok ay maaaring lutasin lamang ang ilang bahagi. Ang pagsubok ay mahusay sa pagprotekta ng pag-uugali: dapat muling ibalik ng interface, hindi dapat mabagsak ng isang partikular na input, at hindi dapat muling lumabas ang mga nakaraang bug. Maraming mga limitasyon sa arkitektura ay hindi natural na ipinapakita bilang input at output.

Ang bawat limitasyon—tulad ng pagkakaroon lamang ng isang owner sa estado, pag-iwas sa reverse dependency ng domain layer sa UI, pag-prohibido sa isang package na direktang kumonekta sa database, at ang pangangailangan na lahat ng write operation ay dumadaan sa isang magkakasamang transaksyon—ay madaling maipasok muli sa lokal na pagpapabuti kung ito ay nasa dokumento o alaala lamang ng Agent.

Nagiging isang mahirap na estado ng inhinyeriya: ang pagsubok ay patuloy na berde, habang ang code ay nagsisiguro na mas mahirap ipaliwanag. Mas mapanganib na mayroong feedback loop dito.

Nagsisimula nang magkagulo ang arkitektura, kailangan ng susunod na pag-unawa ng Agent na basahin ang mas maraming file; mas kumplikado ang mga pagkakasalig, mas malaki ang working set; mas mabigat ang working set, mas kailangan ng sistemang i-clear at i-compress; mas makitid ang pag-iingat sa sanhi at epekto, mas madaling magdepende ang mga susunod na pagbabago sa kasalukuyang code at lokal na pagsubok.

Kaya umuunlad ang kompleksidad ng code at tumataas ang gastos sa Token, at ang presyur sa Token ay bumabalik upang hikayatin ang mas maikling pagpanatili ng estado at mas lokal na pagpapabuti. Ito ang mas makabuluhang mekanismo sa likod ng “mas maraming problema habang mas maraming iterasyon” sa Agent coding.

Hindi ito isang problema sa kakayahan ng isang magkakaibang modelo, kundi isang sistema problema kung saan ang pagpapanatili ng precision sa code state at design state ay hindi magkakasundo.

Ang Coding Agent ay nagsisigla na sa pagpapalawak ng oras ng pagkilos, ngunit ang “makapagpapatakbo ng ilang oras” ay hindi lamang isang mabuting tukoy ng kakayahan.

Kung ang isang Agent ay nagtatrabaho ng 3 oras at kailangan magbasa muli ng sariling file na binago nito 2 oras na ang nakalipas, mag-reason muli kung bakit umiiral ang isang abstrak, at mag-run muli ng isang test na dating ginawa, ang malaking bahagi ng computation sa loob ng 3 oras na iyon ay ginugol sa pagbabalik ng estado.

Ang susunod na tanong ay magiging: Gaano karaming mga sanhi at epekto na may halaga sa paggawa ng mga susunod na desisyon ang maaaring panatilihin ng isang Agent pagkatapos ng 50 hakbang, 100 hakbang?

Maaari itong tawaging state fidelity.

Ito ay nagmamasid hindi kung gaano karaming Token ang maaaring isama sa context, kundi kung gaano karaming mahalagang impormasyon sa disenyo ang nananatili sa isang magagamit na anyo pagkatapos ng pagtawag sa mga kasangkapan, pag-compress, pagpapalipat sa iba’t ibang session, at paghahanap ng memorya. Ito ay nangangahulugan na ang pangmatagalang memorya ng Agent ay hindi maaaring batay lamang sa mas mahabang context.

Ang ilang kaalaman ay angkop na i-store sa memory, tulad ng paraan ng pagbuo ng proyekto at mga gawi sa pag-develop; ang ilang desisyon ay dapat maipasok sa structured na ADR o code index; habang ang mga bagay na kapag sinira ay babagsak ang mga architectural boundary ng sistema, ay mas angkop na isulat nang direkta sa mga uri, pagsubok, lint, mga patakaran sa dependency, at CI.

Kapag isang patakaran ay naging isang pagkakabawas na maaaring isagawa ng software, hindi na kailangan ng Agent na “tandaan” ito. Sa susunod na round, maaaring kalimutan ng Agent ang isang talakayan, ngunit hindi maaaring madaling laktawan ang compiler at pagsubok.

Kung mababa ang fidelity, mas matagal ang pagpapatakbo ng Agent, mas maraming pambobomba ito ang inilalagay sa sistema.

Maaari rin itong maging isang hangganan na kailangang lapitan ng Coding Agent mula sa “nakakasulat ng code” patungo sa “makakapagpanatili ng software nang matagal”: ang paglikha ng kaalaman sa disenyo mula sa probabilistiko na pagtanda sa wika, at ang paglipat nito sa isang software state na maaaring i-retrieve, i-verify, at i-execute.

Kung hindi ito pinapatakbo nang awtomatiko, mas matagal ang oras, mas kakaibang sitwasyon ang mangyayari. Mas mabilis ang pagkasulat ng code ng Agent, at mas mabilis din ang pagbabago ng proyekto, ngunit sa bawat tiyak na panahon, kailangan niya muli na maunawaan ang mundo na itinirai ng nakaraang panahon.

Karaniwang pangungusap sa tradisyonal na legacy code: “Huwag galawin ito, hindi alam kung bakit ito lalabas.”

Ang mga lumang code na gawa ng AI ay maaaring mas kakaiba: ang code ay totoo nang gawa ng Agent, ngunit ang mga susunod na Agent ay hindi na alam kung bakit ganoon isinulat ng dating Agent.