Editor's Note: Noong Enero 2026, ang pag-complain ni Andrej Karpathy tungkol sa pagkakasulat ng code ni Claude ay nagbigay-daan sa isang file na tila maliit ngunit napakahalaga sa AI coding workflow: CLAUDE.md. Pagkatapos ay isinama ni Forrest Chang ang mga problema na ito sa 4 na patakaran sa pag-uugali, na layuning magbigay-limitasyon sa karaniwang mga pagkakamali ni Claude sa pag-code: silent assumptions, over-engineering, accidental damage sa di-kaugnay na code, at kakulangan ng malinaw na pamantayan ng tagumpay.

Ngunit ilang buwan pagkatapos, ang mga paggamit ng Claude Code ay hindi na lamang “pagpapagawa ng isang piraso ng code ng modelo.” Kasabay ng pagiging karaniwan ng multi-step Agent, hook na chain-triggered, pag-load ng skill, at pagtatrabaho sa maraming codebase, nagsimula ring lumabas ang mga bagong uri ng pagkabigo: ang modelo ay nawawala sa habang gawain, nakapasa ang mga pagsubok ngunit hindi pinapatotohanan ang totoong lohika, natapos ang migrasyon ngunit pinagbale-wala ang mga error nang tahimik, at mali ang paghalo ng iba’t ibang istilo ng code.

Ang may-akda ng artikulong ito ay sinubukan ang 30 na code repository sa loob ng 6 linggo at idinagdag ang 8 karagdagang patakaran sa orihinal na 4 na patakaran ni Karpathy upang masakop ang mga bagong hamon sa AI programming mula sa isang pagkakumpleto hanggang sa pagkakasundo bilang isang Agent.

Narito ang orihinal na teksto:

Sa huling bahagi ng Enero 2026, nag-post si Andrej Karpathy ng isang serye ng mga tweet na nagkomento sa paraan ng pag-sulat ng code ni Claude. Tinukoy niya ang tatlong uri ng karaniwang problema: paggawa ng maling aksiyon nang walang paliwanag, pagpapalalim ng proseso, at pagdudulot ng di-kaugnay na pinsala sa code na dapat ay hindi binago.

Nakita ni Forrest Chang ang serye ng tweet at isinama ang mga paghihinga bilang 4 na patakaran ng pag-uugali sa isang hiwalay na CLAUDE.md file at ipinost ito sa GitHub. Nakakuha ang proyektong ito ng 5,828 na Star sa unang araw nito, 60,000 na saves sa loob ng dalawang linggo, at ngayon ay may 120,000 na Star, naging pinakamabilis na lumalaking single-file code repository sa taong 2026.

Pagkatapos, sinubok ko ito sa 30 na code repository sa loob ng 6 linggo.

Ang mga patakarang ito ay epektibo. Bawas ang error na dating may 40% na posibilidad na mangyari sa mga gawain kung saan ang mga patakarang ito ay nakakatulong, sa ilalim ng 3%. Ngunit ang problema ay ang template na ito ay orihinal na nilikha upang lutasin ang mga error na nangyari noong Enero nang isulat ni Claude ang code.

Noong Mayo 2026, iba na ang mga problema na kinakaharap ng Claude Code ecosystem: ang pagkakaroon ng pagkakaubos sa pagitan ng mga agent, ang chain reaction ng mga hook, ang pagkakaubos sa pag-load ng skill, at ang pagkabigo sa maraming hakbang na workflow sa pagitan ng mga sesyon.

Kaya, idinagdag ko muli ang 8 na patakaran. Narito ang kompletong bersyon ng 12 na patakaran ng CLAUDE.md: Bakit bawat isa ay dapat idagdag, at saan mga lugar ang orihinal na template ni Karpathy ay magkakaroon ng malupit na pagkabigo.

Kung nais mong i-skip ang paliwanag at direktang kopyahin at gamitin, ang buong file ay nasa huli.

Bakit ito mahalaga

Ang CLAUDE.md ng Claude Code ay ang pinakamalimitang napapansin na file sa buong AI programming stack. Karaniwan ang mga developer na gumagawa ng tatlong uri ng pagkakamali:

Una, gawin itong basurahan ng pagkakapreferensya, isaksak dito lahat ng iyong mga gawi, at sa huli ay lumalaki ito sa higit sa 4,000 na token, at bumaba ang pagsumbong sa pagsunod sa mga patakaran sa 30%.

Pangalawa, huwag gamitin nang lubos, at i-reprompt lagi. Ito ay magdudulot ng 5 beses na pagkawala ng token, at kulang sa konsistensya sa pagitan ng iba’t ibang sesyon.

Ikatlo, pagkatapos kopyahin ang isang template, hindi na ito pinapansin. Maaaring magtrabaho ito nang dalawang linggo, ngunit maaaring mawalan ng bisa nang hindi mo napapansin habang nagbabago ang codebase.

Sinasabi ng opisyal na dokumentasyon ng Anthropic nang malinaw: ang CLAUDE.md ay batid lamang bilang rekomendasyon. Sasundin ng Claude nang humigit-kumulang 80% ng oras ito. Kapag lumampas sa 200 na linya, bumababa ang antas ng pagsunod dahil ang mahahalagang patakaran ay nabubulok sa ingay.

Ang template ni Karpathy ay naglutas ng problema: isang file, 65 na linya, 4 na patakaran. Ito ang pinakamababang batayan.

Ngunit maaaring mas mataas pa ang limitasyon. Pagkatapos magdagdag ng mga sumusunod na 8 na patakaran, hindi na ito nakakapalibot sa mga problema sa pagsusulat ng code na binanggit ni Karpathy noong Enero 2026, kundi pati na rin ang mga problema sa pag-organisa ng Agent na lumabas lamang noong Mayo 2026—mga problema na wala pa noong isulat ang orihinal na template.

Ang orihinal na 4 na patakaran

Kung hindi pa mo binuksan ang repository ni Forrest Chang, tingnan muna ang basic na bersyon:

Patakaran 1: Isipin muna bago i-encode.

Huwag mag-assume nang tahimik. Ipaliwanag ang iyong mga asumsyon, ipakita ang mga kompromiso. Magtanong bago maghula. Kapag may mas simpleng solusyon, magbigay ng pagtutol.

Patakaran 2: Prioritize simplicity.
Gumamit ng pinakamaliit na code na makakasolusyon sa problema. Huwag magdagdag ng mga function na isipin lamang. Huwag magdesign ng abstraction layer para sa isang beses na code. Kung isang karanasan na engineer ay isipin na sobrang kumplikado, dapat i-simple.

Patakaran 3: Surgical modification.
Baguhin lamang ang kailangang baguhin. Huwag i-optimize ang kapitál na code, komento, o format. Huwag i-restructure ang mga bagay na hindi nasasaktan. Panatilihin ang pagkakasunod sa umiiral na istilo.

Patakaran 4: Magpatupad nang may layunin.
Tukuyin muna ang mga pamantayan ng tagumpay, pagkatapos ay ulitin ang proseso hanggang sa matapos ang pag-verify. Huwag sabihin sa Claude kung ano ang gagawin sa bawat hakbang, kundi ipaliwanag kung ano ang dapat maging resulta ng tagumpay, at hayaan siyang mag-iterate nang sarili.

Ang mga patakaran na ito ay maaaring lutasin ang higit sa 40% ng mga pagkabigo na nakikita ko sa mga sesyon ng Claude Code na walang pagmamasid. Ang natitirang 60% ng mga problema ay nakatago sa mga blankong lugar na ito.

Ang aking 8 bagong patakaran, at bakit

Bawat patakaran ay galing sa isang totoong sandali: Hindi sapat ang orihinal na 4 na patakaran ni Karpathy. Sa ibaba, unang ipapaliwanag ko ang sitwasyon, bago ibigay ang kaugnay na patakaran.

Hindi kasama ng mga patakaran ni Karpathy ang point na ito. Kaya nagsimula ang modelo na magdesisyon sa ilang bagay na dapat ay tratuhin ng deterministic code: kung i-retry ang isang API call, paano i-route ang isang mensahe, at kailan i-upgrade ang proseso. Ang resulta ay iba-iba ang pagdedesisyon bawat linggo. Nagkakaroon ka ng isang unstable na if-else na binabayaran sa halagang $0.003 bawat token.

Sa oras na iyon, may isang code na tumatawag sa Claude upang “tukuyin kung dapat bang i-repeat ang request kapag nakakatagpo ng 503.” Nagsisimula itong mabuti at tumagal ng dalawang linggo, ngunit bigla itong naging hindi matatag dahil ang modelo ay nagsimulang gamitin ang request body bilang bahagi ng konteksto para sa pagpapasya. Ang patakaran sa pagrerepeat ay naging random dahil ang prompt mismo ay random.

Ang CLAUDE.md na walang limitasyon sa budget ay katumbas ng isang blankong check. Bawat siklo ay maaaring mawala sa kontrol at magging isang pagbaha ng 50,000 token. Hindi magpapahinto ang modelo nang sarili nito.

Ang oras ay ganito: tumagal ang isang debugging session ng 90 minuto. Patuloy na umuulit ang modelo sa isang 8KB na error message at paulit-ulit na nakalimutan kung anong mga solusyon na ang kanilang subukang gawin. Sa huli, nagsimula itong magpropose ng mga solusyon na早已 ko nang tinanggihan 40 messages na ang nakalipas. Kung may token budget, dapat na ito ay itigil sa 12th minuto.

Kapag may dalawang bahagi sa codebase na magkakasalungat, subukan ni Claude na pasayahin ang parehong panig, at ang resulta ay isang kalat na code.

Nangangahulugan ito na may dalawang modelo ng pag-handle ng error sa isang codebase: isa ay async/await kasama ang eksplisitong try/catch, at ang isa pa ay global error boundary. Ang bagong code na isinulat ni Claude ay gumamit ng parehong dalawa. Bilang resulta, ang pag-handle ng error ay ginawa nang dalawang beses. Nangalap ako ng 30 minuto upang maunawaan kung bakit tinanggal ang error nang dalawang beses.

Ang "surgical modification" ni Karpathy ay sinabi sa Claude na huwag baguhin ang kapitbahay na code. Ngunit hindi ito sinabi sa Claude: unawain muna ang kapitbahay na code. Walang ito, maglalabas ang Claude ng bagong code na magkakaroon ng konflikto sa mga umiiral na code na 30 na linya ang layo.

Sa oras na iyon, idinagdag ni Claude ang isang bagong function na may parehong functionality sa tabi ng isang umiiral na function, dahil hindi niya binasa ang orihinal na function. Ang dalawang function ay nagpapagawa ng parehong bagay. Ngunit dahil sa pagkakasunod-sunod ng import, ang bagong function ay nag-overwrite sa lumang function, na naging de facto na tanging pamantayan na nasa loob ng 6 buwan.

Ang "goal-oriented execution" ni Karpathy ay nagmumungkahi na ang pagsubok ay maaaring gamitin bilang pamantayan ng tagumpay. Ngunit sa praktika, isasama ni Claude ang "passing tests" bilang tanging layunin, kaya isusulat niya ang ilang code na makakapasa sa mga maliit na pagsubok ngunit magpapabagsak sa iba pang mga bagay.

Ang oras na iyon ay ganito: isinulat ni Claude ang 12 na pagsubok para sa isang function ng pagpapatotoo, at lahat ay nag-pass. Ngunit nasira ang logika ng pagpapatotoo sa production. Ang mga pagsubok na iyon ay nagpapatotoo lamang kung ang function ay “nag-return ng isang bagay,” hindi kung ito ay nag-return ng tamang bagay. Nakapasa ang function sa mga pagsubok dahil ito ay nag-return ng isang constant.

Ang template ni Karpathy ay may default na interaksyon na isang beses lang. Ngunit ang tunay na mga gawain ni Claude Code ay madalas na marami-hakbang: pag-restructure sa 20 mga file, pagbuo ng function sa isang sesyon, at pag-debug sa iba’t ibang commit. Kung walang checkpoint, isang mali sa isang hakbang ay maaaring magwakas sa lahat ng nakamit na progreso.

Ang oras ay ganito: isang 6-hakbang na restructure task ay nagkamali sa hakbang 4. Nang makita ko ito, nagsagawa na ang Claude ng hakbang 5 at 6 sa itaas ng error state. Ang oras na ginugol para i-deconstruct at i-fix ay mas mahaba kaysa sa paggawa muli ng buong task. Kung may checkpoint, maaaring ma-detect ang problema sa hakbang 4.

Sa isang codebase na mayroon nang matatag na modelo, gusto ni Claude na ipakilala ang kanyang sariling paraan. Kahit na mas mabuti ang kanyang paraan, ang pagpapakilala ng pangalawang modelo mismo ay mas masama kaysa sa anumang iisang modelo.

Nangyari iyon nang si Claude ay nagdagdag ng hooks sa isang React codebase na batay sa class component. Tumatakbo nga ito, ngunit nasira nito ang dating testing pattern ng codebase dahil ang mga pagsubok ay nakadepende sa componentDidMount. Nangalap ng kalahating araw ang pag-alis at pagsusulit nito.

Ang pinakamahal na pagkabigo ni Claude ay kadalasang mga pagkabigo na tila tagumpay. Isang function na “nakakapagpatakbo,” ngunit nagbigay ng maling data; isang migration na “natapos,” ngunit iniwan ang 30 na rekord; isang pagsubok na “nakapasa,” ngunit dahil sa mali ang assertion mismo.

Nangyari iyon nang sabi ni Claude na "natapos nang matagumpay" ang paglipat ng database. Sa katotohanan, itinuloy nito nang tahimik ang 14% ng mga rekord na nagdulot ng pagkabigo sa trigger constraint. Ang pagtataliwas ay isinulat sa log, ngunit hindi ito malinaw na ipinakita. 11 araw pagkatapos, nang magsimula ang mga anomali sa data ng report, natuklasan namin ang problema.

Sa loob ng 6 linggo, sinunod ko ang parehong grupo ng 50 mga representatibong gawain, na nakakapalibot sa 30 mga code repository, at sinubukan ang tatlong konfigurasyon.

Ang rate ng pagkakamali ay tumutukoy sa: kailangan ng task na i-correct o i-rewrite upang makatugma sa orihinal na intensyon. Kasama sa pagkakamali ang: tahimik na pagmamaliw ng aksiyon, sobrang pagpapalawak, di-kaugnay na pagkasira, tahimik na pagkabigo, paglabag sa kasunduan, konflikto sa kompromiso, at pagkakalimutan ng checkpoint.

Ang compliance rate ay tumutukoy sa probabilidad na gamitin nang eksplisito ng Claude ang isang patakaran kapag ito ay naglalapat.

Hindi lang interesante ang pagbaba ng rate ng error mula sa 41% patungo sa 3%. Mas mahalaga na ang pagpapalawig mula sa 4 na patakaran patungo sa 12 na patakaran ay halos hindi nagdulot ng dagdag na presyon sa pagtupad; ang rate ng pagtupad ay mula sa 78% ay naging 76% lamang, ngunit bumaba ulit ang rate ng error ng 8 puntos. Ang mga bagong patakaran ay sumasakop sa mga uri ng pagkabigo na hindi kasama sa mga orihinal na 4 na patakaran, at hindi sila nag-aaway sa iisang budget ng atensyon.

Saan tatanggalin nang tahimik ang Karpathy template

Kahit hindi idinadagdag ang mga bagong patakaran, ang orihinal na 4 na template ng patakaran ay hindi sapat sa hindi bababa sa 4 na lugar.

Una, ang matagal na pagpapatakbo ng mga gawain ng Agent.
Ang mga patakaran ni Karpathy ay nakatuon sa sandaling isusulat ni Claude ang code. Ngunit ano ang mangyayari kapag ginagawa ni Claude ang isang multi-step pipeline? Wala ang orihinal na template sa mga patakaran tungkol sa budget, checkpoint, o "fail loudly". Kaya ang pipeline ay magkakaroon ng paulit-ulit na pagkilos.

Ikalawa, pagkakasunod-sunod ng maraming codebase.
Ang “pagpapareho sa umiiral na istilo” ay default na may isang istilo lamang. Ngunit sa isang monorepo na may 12 serbisyo, kailangan ng Claude na piliin kung aling istilo ang pipiliin. Hindi sinasabi ng orihinal na patakaran kung paano piliin. Kaya ito ay o random na pumipili, o naghihigpit ng ilang istilo nang pantay-pantay.

Ikatlo, ang kalidad ng pagsubok.
Ang "pagganap batay sa layunin" ay itinuturing ang "nakapasa ang pagsubok" bilang tagumpay, ngunit hindi ito ipinapaliwanag na ang pagsubok mismo ay dapat may kahulugan. Bilang resulta, isinusulat ni Claude ang ilang pagsubok na halos walang pinapatotohanan, ngunit ang mga pagsubok na ito ay nagpapakalat sa kanya na may tiwala siya.

Ikaapat, ang pagkakaiba sa pagitan ng production environment at prototype stage.
Ang parehong 4 na patakaran ay maaaring pigilan ang pag-over-engineer ng production code, ngunit maaari ring magdulot ng pagiging mabagal sa pag-unlad ng prototype. Dahil sa ilang pagkakataon, kailangan talaga ng 100 na linya ng exploratory scaffolding sa phase ng prototype upang maunawaan ang direksyon. Ang "simple first" ni Karpathy ay madaling masyadong ma-trigger sa mga maagang code.

Hindi iniiwan ng 8 bagong patakaran ang orihinal na 4 na patakaran ni Karpathy, kundi pinapakinabangan ang kanilang mga kulang: ang orihinal na template ay nakatuon sa sitwasyon ng pagkakasulat ng code na may pagkukumpleto ng awtomatiko noong Enero 2026; ngunit noong Mayo 2026, ang Claude Code ay nasa loob na ng isang kapaligiran na pinapagana ng Agent, maraming hakbang, at kooperasyon sa maraming codebase, at iba ang mga problema na kanilang kinakaharap.

Ano ang mga paraan na hindi nagtagumpay

Bago matukoy ang 12 na patakaran na ito, sinubukan ko rin ang ilang iba pang mga solusyon.

Sumali sa mga patakaran na nakita ko sa Reddit / X.
Karamihan sa kanila ay nag-uulit lamang ng orihinal na 4 na patakaran ni Karpathy gamit ang iba’t ibang pagsasalaysay, o mga patakaran na spesipiko sa larangan na hindi maaaring ma-generalize, tulad ng “laging gamitin ang Tailwind class.” Tinanggal lahat ng ito.

Higit sa 12 na patakaran.
Pinakamaraming sinubok kong 18. Pagkalampas sa 14, bumaba ang pagkakasunod mula sa 76% patungo sa 52%. Ang limitasyon ng 200 na linya ay totoo. Pagkalampas sa haba na ito, sisimulan ni Claude ang pattern matching na “mayroong mga patakaran dito” kesa sa pagbabasa ng bawat patakaran nang isa-isa.

Mga patakaran na nakasalalay sa ilang mga kasangkapan.
Halimbawa, "laging gamitin ang eslint", kapag wala ang eslint sa proyekto, magiging walang bisa ang patakaran na ito, at nagiging silent na walang bisa. Pagkatapos, binago ko ito sa isang pagpapahayag na hindi nakadepende sa isang partikular na tool, tulad ng pagbabago sa "gamitin ang eslint" patungo sa "sumunod sa istilo na ipinapataw na nasa codebase".

Ilan sa halimbawa sa CLAUDE.md, hindi ang mga patakaran.
Ang mga halimbawa ay may mas malaking konteksto kaysa sa mga patakaran. Ang tatlong halimbawa ay naglalaman ng halos katumbas na konteksto ng 10 na patakaran, at madaling masyadong umaangkop ang Claude sa mga halimbawa. Ang mga patakaran ay abstrakto, habang ang mga halimbawa ay konkretong. Kaya, dapat gamitin ang mga patakaran.

Maging maingat. Isipin nang mabuti. Mag-focus ka.
Ito ay lahat ng ingay. Ang pagkakasunod sa mga instruksiyong ito ay bumaba sa halos 30% dahil hindi ito maaaring i-verify. Pagkatapos, isinubstitu ko ito ng mas tiyak na mga utos, tulad ng “Ispesipikuhin ang mga aksiyon.”

Sabihin sa Claude na mag-isip tulad ng «senior engineer».
Hindi ito gumagana. Ang Claude ay nagmamaliw na siya ay isang karanasan na inhinyero. Ang totoong problema ay hindi kung ano ang kanyang iniisip, kundi kung ano ang kanyang ginagawa. Ang mga imperatibong patakarang maaaring maliit ang pagkakaiba, ngunit hindi ang mga pagtukoy sa pagkakakilanlan.

Complete 12-rule version CLAUDE.md

Narito ang buong bersyon na maaaring kopyahin at idikit nang direkta.

Hindi makikita ang nilalaman na ito sa labas ng Feishu Document

I-save it bilang CLAUDE.md sa root ng repository. Sa ibaba ng 12 na patakaran, idagdag ang mga patakaran na espesipiko sa proyekto, tulad ng teknikal na stack, mga utos sa pagsubok, mga pattern ng error, atbp. Huwag lalampas sa 200 na linya, dahil pag lumampas, bababa ang pagsumbong sa patakaran.

Paano i-install

Dalawang hakbang lang:

1. Idagdag ang 4 na pangunahing patakaran ni Karpathy sa iyong CLAUDE.md
curl https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md >> CLAUDE.md

2. I-paste ang mga patakaran 5–12 sa ibaba

I-save ang file sa root ng repository. Mahalaga dito ang >>, dahil ito ay nagdadagdag sa existing na CLAUDE.md, hindi nagpapalit sa mga project-specific na patakaran na iyong naisulat.

Hindi ang CLAUDE.md isang wishlist, kundi isang kontrata ng pag-uugali na naglalayong i-block ang mga partikular na pattern ng pagkabigo na iyong napanood.

Bawat patakaran ay dapat sagutin ang isang tanong: Ano ang maaaring maiwasan nito?

Ang 4 na patakaran ni Karpathy ay naglalayong pigilan ang mga pagkabigo na nakita niya noong Enero 2026: silent assumptions, over-engineering, irrelevant destruction, at weak success criteria. Ito ay mga pundasyon; huwag i-skips.

Ang aking 8 bagong patakaran ay para pigilan ang mga bagong uri ng pagkabigo pagkatapos ng Mayo 2026: ang loop ng Agent na walang limitasyon sa budget, ang marami-lahat na gawain na walang checkpoint, ang mga pagsubok na tila sinubok ngunit hindi talaga sinubok ang mahahalagang lohika, at ang pagpapakita ng silent failure bilang silent success. Ito ay mga incremental patch.

Tama, ang epekto ay nagkakaiba-iba batay sa indibidwal. Kung hindi mo ginagamit ang marami-lakas na pipeline, ang patakaran 10 ay hindi gaanong mahalaga para sa iyo. Kung ang iyong codebase ay may iisang magkakatulad na istilo na pinipigilan ng lint, ang patakaran 11 ay redundant. Pagkatapos basahin ang 12 na patakaran, panatilihin ang mga patakaran na talagang tumutugon sa mga pagkakamali na iyong naganap, at tanggalin ang mga natitira.

Isang 6-panuntunan na bersyon ng CLAUDE.md na nakabatay sa tunay na pagkabigo, mas mabuti kaysa sa isang 12-panuntunan na bersyon kung saan ang 6 sa kanila ay hindi mo maiiwasang gamitin.

Wakas

Ang tweet ni Karpathy noong Enero 2026 ay isang paghihinga ng lungkot. Ginawang 4 na patakaran ni Forrest Chang. Sa wakas, 120,000 na developer ang nag-Star sa resultang ito. At karamihan sa kanila, hanggang ngayon ay nagpapatakbo pa rin lamang ng mga patakaran na iyon.

Nagkaroon ng pag-unlad ang model, at nagbago na ang ecosystem. Ang mga multi-step Agent, hook na chain-trigger, pag-load ng skill, at pagtatrabaho sa maraming codebase—lahat ng ito ay hindi pa umiiral noong isulat ni Karpathy ang tweet na iyon. Ang orihinal na 4 na patakaran ay hindi nalutas ang mga problema na ito. Hindi sila mali, kundi hindi kompletong.

Idinagdag ang 8 na bagong patakaran. 6 linggo, nakakapag-coverage ng 30 code repositories. Bumaba ang rate ng error mula 41% patungo sa 3%.

Iingatan ang artikulong ito ngayong gabi, i-paste ang 12 na patakaran sa iyong CLAUDE.md. Kung nakatulong ito upang maiwasan mo ang isang linggo ng pagkakamali sa Claude, maaari mong i-share.