Ponytail: Jinsi ya kufanya AI iandike code kidogo

Ponytail ni nini

Ponytail ni mkusanyiko wa kanuni unaofanya wakala wa AI wa uandishi wa programu kuandika kiasi kidogo cha code. Mradi huu unajielezea kwa mstari mmoja: "Hufanya wakala wako wa AI kufikiri kama msanidi mwandamizi mvivu zaidi chumbani. Code bora ni ile ambayo hukuwahi kuiandika." Ina leseni ya MIT. Haina runtime yake yenyewe, na hakuna kitu ndani yake kinachotekelezwa. Ni matini yanayoingizwa kwenye maelekezo ya wakala, yaliyofungashwa kama ujuzi (skill) kwa ajili ya mifumo inayopakia ujuzi, na kama faili za kanuni za kawaida kwa mifumo isiyofanya hivyo.

Hazina (repository) hiyo ni DietrichGebert/ponytail. Iliundwa tarehe 12 Juni 2026 na ilivuka nyota 90,000 kufikia tarehe 1 Agosti 2026. Toleo la hivi karibuni lililowekewa tag tarehe 1 Agosti 2026 ni v4.8.4, lililochapishwa tarehe 29 Juni 2026, na ukurasa wa matoleo unaorodhesha tag kumi kati ya tarehe 14 na 29 Juni pekee. Mradi unaoendelea kwa kasi hiyo utakuwa umeshabadilika wakati unaposoma hili, kwa hivyo funga (pin) tag kabla ya kujenga chochote juu yake.

Wazo kabla ya zana: simama kwenye ngazi ya kwanza inayoshikika

Msingi wa Ponytail ni ngazi ya maamuzi. Wakala hupanda ngazi hiyo kabla ya kuandika chochote na kusimama kwenye ngazi ya kwanza inayoshikika.

1. Je, hii inahitaji kuwepo kabisa? Hii ni YAGNI (hutaikuhitaji). Ikiwa jibu ni hapana, iruke.
2. Je, tayari ipo kwenye codebase hii? Tumia tena kisaidizi au muundo uliopo.
3. Je, maktaba ya kawaida (standard library) inafanya hivyo? Itumie.
4. Je, kipengele cha asili cha mfumo (native platform feature) kinashughulikia hilo? Kitumie.
5. Je, dependency iliyokwisha kusakinishwa inatatua hilo? Itumie.
6. Je, inaweza kuwa mstari mmoja? Ifanye iwe mstari mmoja.
7. Hapo ndipo uandike msimbo wa chini kabisa unaofanya kazi.

Mpangilio ndio unaofanya kazi, si ngazi yoyote moja. Wakala aliyeombwa date picker ataandika date picker, kwa sababu kuandika moja ndilo aliloambiwa afanye. Ngazi hii inamfanya akague ngazi ya 4 kwanza, na ngazi ya 4 inasema kivinjari tayari kina <input type="date">. Benchmark ya mradi huu inabainisha kisa hiki hasa: date picker iliyokuwa na mistari 404 bila sheria hii ilitoka na mistari 23 ikiwa nayo, kwa sababu wakala alitumia input ya asili badala ya kujenga component. Colour picker ilitoka mistari 287 hadi 23 kwa sababu hiyo hiyo.

Uvivu hapa haumaanishi kutojali, na seti ya sheria inasema hivyo moja kwa moja. Orodha yake ya "usilegee kamwe" inahusu kuelewa tatizo kabla ya kuamua, uthibitishaji wa data (input validation) kwenye mipaka ya uaminifu, ushughulikiaji wa makosa unaozuia upotevu wa data, usalama, ufikivu (accessibility), na chochote ulichokiomba kwa jina. Pia inaomba ukaguzi mmoja mdogo unaoweza kuendeshwa kwa kila kipande cha mantiki isiyo rahisi. Sheria hii inakata uvumbuzi usio wa lazima. Haikati usahihi.

Yaliyomo kwenye repository

• AGENTS.md, seti ya sheria inayofanya kazi kila wakati, ambayo ndiyo kiini cha mradi mzima katika faili moja unayoweza kuisoma kwa dakika tano.
• skills/ponytail/SKILL.md, ufafanuzi wa ujuzi (skill definition), ikiwa na dokezo la hoja la lite, full au ultra.
• Faili za sheria chini ya saraka mahususi za editor kama vile .cursor/rules/ na .windsurf/rules/, kwa ajili ya hosts zinazosoma sheria lakini hazipakii ujuzi.
• hooks/, benchmarks/, examples/ na scripts/.

Hoja ya intensity inabadilisha jinsi sheria inavyotekelezwa kwa ukali. lite inajenga ulichoomba na kupendekeza chaguo legevu zaidi katika mstari mmoja. full ndiyo chaguo-msingi na inatekeleza mpangilio wa ngazi. ultra ni mpangilio wa msimamo mkali wa YAGNI: inapendelea kufuta badala ya kuongeza na itahoji hitaji lenyewe.

Hosts zinazoweza kutumia ujuzi pia hupata slash commands. /ponytail huweka kiwango, /ponytail-review hukagua diff ili kuona kama kuna over-engineering, /ponytail-audit hukagua repository nzima, /ponytail-debt hukusanya njia za mkato ulizoziahirisha, na /ponytail-gain huchapisha kadi ya alama ya benchmark. Hosts zinazosoma faili za sheria pekee hupata seti ya sheria bila amri zozote.

Ili kusoma source code kabla ya kuiamini, clone tag badala ya branch:

git clone --depth 1 --branch v4.8.4 https://github.com/DietrichGebert/ponytail.git

Kwenye Claude Code, mradi huu unaelekeza usakinishaji wa plugin badala yake, na mistari hii miwili ni kama ilivyoandikwa mnamo 1 Agosti 2026:

/plugin marketplace add DietrichGebert/ponytail
/plugin install ponytail@ponytail

Njia ya plugin hufuata default branch badala ya tag, kwa hivyo maelekezo yanayouongoza wakala wako yanaweza kubadilika kati ya vipindi vya matumizi. Hiyo ndiyo gharama unayokubali kwa ajili ya urahisi wa amri ya update.

Kwa nini wakala mvivu ni nafuu zaidi kwenye VPS

Tofauti (diff) inayotolewa na wakala haitoki kwenye mazungumzo. Katika hatua inayofuata, hiyo ni muktadha ambao modeli huisoma tena, pamoja na kila faili iliyofunguliwa ili kuizalisha. Kwa hivyo, mabadiliko ya mistari 500 huongeza mzigo katika kila hatua inayofuata ya kikao, si tu katika hatua iliyoizalisha. Hii ndiyo sababu urekebishaji (refactor) usiodhibitiwa huufanya wakala kuhisi kuwa polepole na mjinga kadiri kikao kinavyoendelea: dirisha la muktadha hujazwa na matokeo ya wakala mwenyewe, hivyo nafasi iliyobaki kwa ajili ya msimbo wako halisi hupungua. Kudhibiti hali hiyo ndilo somo zima la kusimamia dirisha la muktadha la wakala wa uandishi wa msimbo.

Tokeni hulipiwa wakati wa kuingia na kutoka, hivyo diff iliyo na ukubwa wa nusu ni nafuu mara mbili; mara ya kwanza inapoandikwa na tena katika kila hatua inayoisoma upya. Ikiwa akiba hiyo itaonekana kwenye bili yako inategemea jinsi unavyolipa, kwa sababu usajili wa Pro au Max wa bei isiyobadilika hufyonza tokeni za ziada, wakati malipo ya API kwa kila tokeni hukutoza kwa kila moja. Ikiwa unafuatilia bili kwenye usanidi wa self-hosted, faili ya maelekezo ni nyenzo ambayo haina gharama kuitumia. Kudhibiti gharama za wakala wa AI huanza na kiasi cha matokeo, na jinsi wakala wa uandishi wa msimbo anavyotumia tokeni zake inaeleza kwa nini kusoma upya ni muhimu zaidi kuliko watu wanavyotarajia.

Binadamu bado anasoma diff hiyo. Mabadiliko ya mistari 400 ambayo yangepaswa kuwa mistari 20 hugharimu umakini wa mkaguzi, na umakini ndio rasilimali inayoisha kwanza. Hakuna anayekagua diff ya nne ndefu ya siku kwa umakini uleule alioutumia kwenye ya kwanza, hivyo kufanya kazi kupita kiasi hakupotezi muda tu. Kunapunguza kimyakimya ubora wa ukaguzi unaopaswa kubaini makosa.

Kwenye seva, hali hubadilika kwa sababu wakala mara nyingi hufanya kazi bila mtu yeyote anayemwangalia. Wakala anayefanya kazi kwenye kikao cha tmux au kwa kipima muda ana saa nyingi za kujenga juu ya uamuzi mbaya kabla hujauona. Hiyo ndiyo hatari ya kivitendo katika kuendesha wakala wa uandishi wa msimbo kwenye VPS, na ndiyo sababu watu wanaofanya loop engineering hutumia uangalifu mwingi kwenye maelekezo ya kudumu badala ya maelekezo ya mtu binafsi. Kanuni iliyo kwenye faili inayofanya kazi kila wakati inatumika hadi hatua ya 200. Kanuni uliyoiandika kwenye gumzo inatumika hadi hatua ya 3 tu.

Dependencies mpya ni gharama nyingine ya kimyakimya. Kanuni ya 5 inasema tumia kile kilichosakinishwa. Kila kifurushi ambacho wakala huongeza kwa hiari yake ni kitu unachopaswa kukirekebisha baadaye na kitu kinachoishia kwenye kila container image unayounda kutoka kwenye hifadhi hiyo.

Namba za benchmark za Ponytail zinasema nini

Mradi huu huchapisha seti mbili za matokeo, na hazikubaliani kwa kiasi kikubwa. Zote ni namba zilizochapishwa na mradi wenyewe. Hakuna hata moja iliyo jaribio huru.

[
  {
    "label": "Lines of code",
    "single_shot_pct": 93,
    "agentic_pct": 54
  },
  {
    "label": "Cost per run",
    "single_shot_pct": 63,
    "agentic_pct": 20
  },
  {
    "label": "Wall clock time",
    "single_shot_pct": 74,
    "agentic_pct": 27
  }
]

Safu ya single shot inatokana na modeli tupu inayojibu seti ndogo ya prompts ikiwa na sheria na bila sheria, ikichukuliwa kama medians ya majaribio yaliyojirudia ya tarehe 13 na 17 Juni 2026. Safu ya agentic inatokana na kipindi cha headless Claude Code kinachohariri full-stack-fastapi-template ya tiangolo, ambayo ni repository halisi ya FastAPI na React, kupitia tiketi kumi na mbili za vipengele (feature tickets) zikiwa na majaribio manne kila moja kwenye Haiku 4.5, yakipimwa kwa kutumia git diff iliyoachwa nyuma.

Soma safu ya pili. Matokeo ya agentic ni 54 asilimia chache zaidi ya mistari ya msimbo, 20 asilimia ya gharama ya chini, na 27 asilimia ya muda mfupi zaidi wa wall clock, dhidi ya 93 asilimia na 74 asilimia kwa vipimo hivyo hivyo katika usanidi wa single shot. README inasema ukweli kuhusu sababu: baseline ya single shot ni modeli tupu ambayo "inajibu kwa chaguzi kadhaa pamoja na maoni", jambo ambalo ni rahisi kushindwa. Pima dhidi ya agent halisi anayefanya kazi halisi na ushindi hupungua. Pia unabaki kuwa wa kweli, jambo ambalo ni ukweli muhimu zaidi.

Tahadhari moja ni ya mradi wenyewe, na ndiyo inayokusaidia kuamua kama hii inakufaa. Akiba ni kubwa zaidi pale ambapo kuna mtego wa over-build wa kweli na karibu sifuri kwenye msimbo ambao ulikuwa mdogo tayari. Tiketi kumi na mbili katika repository moja ya Python na TypeScript hazitabiri repository yako. Ikiwa namba hiyo ni muhimu kwako, fanya ulinganisho kwenye tiketi zako mwenyewe, ukiwa na sheria na bila sheria, na uhesabu mistari mwenyewe.

Muundo unaoweza kunakili leo bila kusakinisha chochote

Ngazi hii ni matini, kwa hivyo huhitaji programu jalizi (plugin) ili kutumia wazo hili. Bandika kizuizi kama hiki kwenye faili ya maelekezo ambayo wakala wako anaisoma tayari, iwe ni AGENTS.md, CLAUDE.md au faili ya kanuni za kihariri chako.

## Before you write code

Climb this list in order. Stop at the first line that applies.

1. Does this need to exist? If not, say so and stop.
2. Does this repo already have it? Reuse the helper.
3. Does the standard library do it? Use it.
4. Does the platform do it natively? Use it.
5. Does an installed dependency do it? Use it.
6. Can it be one line? Write one line.
7. Otherwise write the minimum that works.

Never take the shortcut on: reading the code before changing it, validating
input that crosses a trust boundary, error handling that would otherwise lose
data, security, accessibility, or anything I asked for by name.

Do not add an abstraction I did not ask for. Do not add a dependency without
saying why in one line. Prefer deleting code to adding it.

Mark a deliberate simplification with a comment naming its ceiling and the
upgrade path.

Kanuni hiyo ya mwisho inafaa kuzingatiwa peke yake. Mkataba wa Ponytail ni maoni (comment) yaliyotambulishwa kwa jina la zana hiyo:

# ponytail: global lock, per-account locks if throughput matters

Maoni hayo ni mistari miwili ya kazi na yanatatua swali ambalo lingeweza kugharimu mzunguko wa mapitio. Inamwambia msomaji anayefuata kuwa toleo rahisi lilikuwa uamuzi, na inataja sharti ambalo uamuzi huo hautaendelea kuwa halali. Bila hivyo, mkaguzi hawezi kutofautisha kati ya njia ya mkato iliyozingatiwa na kitu ambacho wakala alisahau, kwa hivyo inabidi waulize.

Mahali unapoweka kizuizi hicho ni muhimu kama vile kile kinachosemwa. Faili ambayo wakala huipakia katika kila utekelezaji huongoza kila utekelezaji, ikiwemo ile ambayo huangalii. Tofauti hiyo ndiyo mada ya kuandika AGENTS.md ambayo wakala wako anafuata kikweli, na ndiyo sababu muundo huu unapaswa kuwa kwenye faili iliyohifadhiwa (committed) badala ya historia ya shell yako.

Wakati kanuni inapoacha kuwa sahihi

Ngazi hii imesanifiwa kwa ajili ya kazi ya kuongeza vipengele kwenye codebase iliyopo, ambapo utumiaji upya wa msimbo (reuse) mara nyingi huwezekana na ni sahihi. Haifai vizuri kwa mradi mpya (greenfield), kwa sababu ngazi ya 2 haina kitu cha kutumia upya na ngazi ya 5 haina kitu kilichosakinishwa, hivyo wakala huangukia kwenye ngazi ya 7 kila wakati. Pia haifai vizuri wakati unapotaka abstraction kwa dhati. Ikiwa unakaribia kuongeza mwito wa nne wa block ileile iliyonakiliwa, "shortest diff" itakupa nakala ya tano.

Kiwango cha ultra kitahoji mahitaji yako. Hiyo ndiyo kazi ya kiwango hicho, na ni gharama halisi wakati tayari umeshafanya uamuzi na unataka kazi ikamilike. Tumia full kwa kazi za kawaida na ufikie ultra unapohisi ombi la kipengele ndilo tatizo.

Hakuna maelekezo yanayoweza kukuokoa kutokana na kutoelewa tatizo. Kipengele cha kwanza cha kanuni hizi ni kuelewa msimbo kabla ya kufanya uamuzi, ambayo ndiyo sehemu ya gharama kubwa na sehemu ambayo maandishi hayawezi kukufanyia. Diff ndogo katika function isiyo sahihi bado ni marekebisho yasiyo sahihi, na sasa ni marekebisho madogo yasiyo sahihi ambayo ni rahisi kuidhinishwa.

Muhtasari wa kweli ni kwamba Ponytail ni prompt iliyoandikwa kwa uangalifu, iliyosambazwa vizuri, na yenye namba zilizounganishwa. Hakuna kitu ndani yake kinachohitaji plugin. Kile ambacho mradi huu unakupa ni kwamba mtu aliandika orodha hiyo vizuri, akaipima dhidi ya repository halisi, na kuchapisha mbinu hiyo kando ya matokeo.

FAQ

Je, Ponytail inafanya kazi na mawakala wengine zaidi ya Claude Code?

Ndiyo. Inatolewa kama skill kwa ajili ya hosts zinazopakia skills, orodha inayojumuisha Claude Code, Codex, OpenCode, Gemini na nyingine kadhaa zilizotajwa kwenye README. Wahariri wanaosoma faili za sheria lakini hawapakii skills, kama vile Cursor, Windsurf, Cline na Copilot, huchukua ruleset inayofanya kazi kila wakati kutoka kwenye saraka ya sheria inayolingana na hawapati slash commands. Maandishi ni yaleyale kwa njia yoyote ile, kwa hivyo tofauti ya kweli ni kama host yako inahifadhi maandishi hayo kwenye muktadha katika kila hatua au pale tu ambapo skill inapoanzishwa.

Je, wakala mvivu ataruka majaribio, uthibitishaji au usalama?

Hapana, na ruleset inasema hivi moja kwa moja. Orodha yake ya "never lazy about" inataja uthibitishaji wa data ya kuingiza kwenye mipaka ya uaminifu, ushughulikiaji wa makosa unaozuia upotevu wa data, usalama na ufikiaji, na inaomba ukaguzi mmoja mdogo unaoweza kuendeshwa kwa kila sehemu ya mantiki isiyo ya kawaida. Kile ambacho sheria huondoa ni muundo wa kubuni: mambo ya kufikirika ambayo hakuna aliyeomba na utegemezi ambao hakuna aliyeuhitaji. Ikiwa wakala wako ataanza kuacha majaribio baada ya kuifunga, sababu ni maagizo mengine katika usanidi wako mwenyewe yanayozidi haya, kwa hivyo soma faili ambayo wakala huipakia mwisho.

Je, namba zilizochapishwa za kasi na gharama zinaaminika?

Hizo ni vipimo vya mradi wenyewe, vilivyochapishwa pamoja na mbinu yake, na vinapaswa kusomwa kama hivyo. Takwimu za single shot hulinganisha dhidi ya modeli tupu inayojibu kwa chaguzi na maoni, ambayo README yenyewe inaiashiria kama msingi dhaifu. Takwimu za wakala zinatoka kwenye kikao cha headless Claude Code kwenye hazina moja ya FastAPI na React, tiketi kumi na mbili, majaribio manne kila moja, kwenye Haiku 4.5. Hizo ni namba za kweli kwa usanidi huo. Sio utabiri kwa codebase yako, kwa sababu mradi pia unasema kuwa akiba inashuka hadi karibu sifuri kwenye msimbo ambao tayari ulikuwa mdogo.

Je, ninahitaji kusakinisha chochote ili kupata manufaa?

Hapana. Ngazi ni maandishi, na kizuizi sawa kilichobandikwa kwenye faili ya maagizo ambayo wakala wako tayari anaisoma kinakupa sehemu kubwa ya athari. Plugin inakupa maneno yaliyodumishwa, viwango vya ukali, amri za ukaguzi na njia ya kusasisha. Kujaribu kizuizi kilichonakiliwa kwanza ndilo jibu la ngazi ya 1 kwa swali la kama usakinishaji unahitaji kuwepo kabisa.

Ninawezaje kuzuia wakala asiyesimamiwa asijenge kupita kiasi usiku kucha?

Weka sheria kwenye faili ya maagizo ya always-on badala ya ujumbe wa gumzo, ili itumike kwenye hatua ya 200 ya mchakato mrefu na si kwenye hatua ya 3 pekee. Kisha zuia uharibifu kando: mpe wakala checkout ambayo anaruhusiwa kuiharibu badala ya nakala yako pekee, na uhitaji ukaguzi wa diff wa binadamu kabla ya kitu chochote kuunganishwa. Sheria ya minimal diff hupunguza kiasi unachopaswa kusoma. Haiamui nini kinaingia, na haipaswi kufanya hivyo.