Ponytail কীভাবে AI coding agent-কে কম code লিখতে শেখায়

Ponytail কী

Ponytail হলো এমন একটি rule set, যা AI coding agent-কে কম code লিখতে বাধ্য করে। প্রকল্পটি নিজেকে এক লাইনে এভাবে বর্ণনা করে: "Makes your AI agent think like the laziest senior dev in the room. The best code is the code you never wrote." এটি MIT licensed। এর নিজস্ব কোনো runtime নেই এবং এর মধ্যে কোনো কিছু execute হয় না। এটি agent-এর instructions-এ যুক্ত করার জন্য লেখা text। যেসব host skill load করে, সেগুলোর জন্য এটি skill হিসেবে packaged। যেসব host skill load করে না, সেগুলোর জন্য এটি plain rule file হিসেবে দেওয়া হয়।

Repository-টি হলো DietrichGebert/ponytail। এটি 12 June 2026-এ তৈরি হয় এবং 1 August 2026-এর মধ্যে 90,000 stars অতিক্রম করে। 1 August 2026-এ সর্বশেষ tagged release হলো v4.8.4। এটি 29 June 2026-এ published হয়। Releases page-এ শুধু 14 থেকে 29 June-এর মধ্যেই দশটি tag তালিকাভুক্ত আছে। এই গতিতে চলা কোনো প্রকল্প আপনি এটি পড়ার সময়ের মধ্যে পরিবর্তিত হয়ে যেতে পারে। তাই এর ওপর ভিত্তি করে কিছু তৈরি করার আগে একটি tag pin করুন।

টুলের আগে ধারণাটি: যে প্রথম ধাপটি কার্যকর, সেখানেই থামুন

Ponytail-এর মূল ধারণা হলো একটি সিদ্ধান্তের সিঁড়ি। কিছু লেখার আগে agent এই ধাপগুলো অনুসরণ করে এবং যে প্রথম ধাপটি কার্যকর হয়, সেখানেই থামে।

1. এটি আদৌ থাকা কি প্রয়োজন? এটি YAGNI (you are not going to need it)। উত্তর না হলে, এটি বাদ দিন।
2. এই codebase-এ এটি কি আগে থেকেই আছে? আগে থাকা helper বা pattern পুনরায় ব্যবহার করুন।
3. standard library কি এটি করতে পারে? সেটিই ব্যবহার করুন।
4. native platform feature কি এটি সমাধান করতে পারে? সেটিই ব্যবহার করুন।
5. আগে থেকেই installed dependency কি এটি সমাধান করে? সেটিই ব্যবহার করুন।
6. এটি কি এক লাইনে করা যায়? এক লাইনে করুন।
7. শুধু এরপরই কাজ করে এমন ন্যূনতম code লিখুন।

কাজটি কোনো একক ধাপ করে না; পুরো ক্রমটি কাজটি করে। কোনো agent-কে date picker তৈরি করতে বললে সে date picker-ই লিখবে, কারণ তাকে সেটিই করতে বলা হয়েছে। এই সিঁড়ি তাকে প্রথমে 4 নম্বর ধাপ যাচাই করতে বাধ্য করে, আর 4 নম্বর ধাপ বলে যে browser-এ ইতিমধ্যেই <input type="date"> আছে। প্রকল্পের নিজস্ব benchmark note-এ ঠিক এই উদাহরণ রয়েছে: নিয়ম ছাড়া একটি date picker 404 lines-এর হয়েছিল, আর নিয়মটি প্রয়োগ করলে 23 lines-এর হয়েছে, কারণ agent component তৈরি না করে native input ব্যবহার করেছে। একই কারণে একটি colour picker 287 lines থেকে 23 lines-এ নেমে এসেছে।

এখানে lazy বলতে অসতর্ক বোঝায় না, এবং ruleset-এ বিষয়টি সরাসরি বলা আছে। এর "never lazy about" তালিকায় সিদ্ধান্ত নেওয়ার আগে সমস্যা বোঝা, trust boundary-তে input validation, data loss প্রতিরোধ করে এমন error handling, security, accessibility এবং নাম ধরে চাওয়া যেকোনো বিষয় অন্তর্ভুক্ত রয়েছে। এটি non-trivial logic-এর প্রতিটি অংশের জন্য একটি ছোট runnable check রাখতেও বলে। এই নিয়ম অপ্রয়োজনীয় উদ্ভাবন কমায়। এটি correctness কমায় না।

রিপোজিটরিতে আসলে যা থাকে

• AGENTS.md, সব সময় সক্রিয় ruleset। পুরো ধারণাটি একটি ফাইলে আছে, যা পাঁচ মিনিটে পড়ে বোঝা যায়।
• skills/ponytail/SKILL.md, skill definition। এর argument hint হলো lite, full অথবা ultra।
• .cursor/rules/ এবং .windsurf/rules/-এর মতো editor-specific directory-র অধীনে থাকা rule file। এগুলো এমন host-এর জন্য, যেগুলো rule পড়ে কিন্তু skill load করে না।
• hooks/, benchmarks/, examples/ এবং scripts/।

intensity argument নিয়মটি কতটা কঠোরভাবে প্রয়োগ হবে তা নির্ধারণ করে। lite আপনার অনুরোধ অনুযায়ী তৈরি করে এবং এক লাইনে কম পরিশ্রমের একটি বিকল্পের নাম দেয়। full হলো default এবং এটি ladder প্রয়োগ করে। ultra হলো YAGNI-এর সবচেয়ে কঠোর setting। এটি কিছু যোগ করার বদলে মুছে ফেলাকে অগ্রাধিকার দেয় এবং requirement নিজেকেও প্রশ্ন করবে।

Skill-capable host-গুলো slash command-ও পায়। /ponytail level নির্ধারণ করে, /ponytail-review over-engineering আছে কি না তা diff-এ পরীক্ষা করে, /ponytail-audit পুরো repository পরীক্ষা করে, /ponytail-debt পরে করার জন্য রাখা shortcut-গুলো সংগ্রহ করে, এবং /ponytail-gain benchmark scorecard দেখায়। যেসব host শুধু rule file পড়ে, সেগুলো কোনো command ছাড়াই ruleset পায়।

source-কে বিশ্বাস করার আগে পড়তে চাইলে branch নয়, tag clone করুন:

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

Claude Code-এ project-এর documentation-এ এর পরিবর্তে plugin install করার নির্দেশ আছে। 1 August 2026 তারিখে নথিভুক্ত দুটি line হলো:

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

plugin path tag-এর পরিবর্তে default branch অনুসরণ করে। তাই session-এর মধ্যে আপনার agent-কে নির্দেশ দেওয়া নিয়মগুলো আপনার অজান্তে পরিবর্তিত হতে পারে। update command ব্যবহারের সুবিধার বিনিময়ে আপনি এই ঝুঁকি গ্রহণ করছেন।

VPS-এ একটি অলস agent কেন কম খরচের

একজন agent যে diff লেখে, তা conversation থেকে সরে যায় না। পরের turn-এ model সেই diff আবার পড়ে, পাশাপাশি diff তৈরি করতে খোলা প্রতিটি file-ও পড়ে। তাই 500 line-এর একটি change শুধু যে turn-এ তৈরি হয়েছে, সেই turn-এই নয়; session-এর পরবর্তী প্রতিটি turn-এও অতিরিক্ত খরচ তৈরি করে। এই কারণেই একটি নিয়ন্ত্রণহীন refactor session যত এগোয়, agent-কে তত ধীর ও কম কার্যকর মনে হয়: window agent-এর নিজের output-এ পূর্ণ হয়ে যায়, ফলে আপনার আসল code-এর জন্য অবশিষ্ট জায়গা কমে যায়। এই বিষয়ের সম্পূর্ণ আলোচনাই হলো coding agent-এর context window পরিচালনা করা।

Token input এবং output—উভয় দিকেই bill করা হয়। তাই অর্ধেক আকারের একটি diff দুইবার সাশ্রয় করে: একবার লেখার সময়, এবং পরের প্রতিটি turn-এ সেটি আবার পড়ার সময়। এই সাশ্রয় আপনার bill-এ আদৌ প্রতিফলিত হবে কি না, তা আপনি কীভাবে অর্থ পরিশোধ করেন তার ওপর নির্ভর করে। কারণ একটি flat Pro বা Max subscription অতিরিক্ত token-এর খরচ অন্তর্ভুক্ত করে, কিন্তু per-token API billing প্রতিটি token-এর জন্য আপনাকে charge করে। self-hosted setup-এর bill পর্যবেক্ষণ করলে instruction file এমন একটি নিয়ন্ত্রণ, যা প্রয়োগ করতে কোনো খরচ হয় না। একটি AI agent-এর খরচ নিয়ন্ত্রণ শুরু হয় output volume থেকে, আর একটি coding agent কীভাবে তার token ব্যবহার করে ব্যাখ্যা করে কেন পুনরায় পড়ার বিষয়টি প্রত্যাশার চেয়ে বেশি গুরুত্বপূর্ণ।

মানুষকে এখনও diff পড়তে হয়। যে 400 line-এর change 20 line হওয়া উচিত ছিল, তা reviewer-এর মনোযোগের ওপর চাপ ফেলে; আর সবার আগে যে resource শেষ হয়ে যায়, তা হলো মনোযোগ। দিনের চতুর্থ দীর্ঘ diff কেউ প্রথমটির মতো যত্ন নিয়ে review করে না। তাই অতিরিক্ত নির্মাণ শুধু সময় নষ্ট করে না। ভুল ধরার কথা যে review-এর, তার quality-ও এটি নিঃশব্দে কমিয়ে দেয়।

server-এ ঝুঁকির মাত্রা বদলে যায়, কারণ agent প্রায়ই কারও নজরদারি ছাড়াই চলে। tmux session-এ বা timer-এর মাধ্যমে চলা একটি agent আপনার দেখার আগে একটি ভুল সিদ্ধান্তের ওপর ঘণ্টার পর ঘণ্টা কাজ চালিয়ে যেতে পারে। VPS-এ coding agent চালানোর বাস্তব ঝুঁকি এটাই। এ কারণেই loop engineering করা মানুষ individual prompt-এর চেয়ে standing instruction-এ বেশি গুরুত্ব দেয়। always-on file-এর একটি rule turn 200-এও কার্যকর থাকে। chat-এ লেখা একটি rule কেবল turn 3-এ প্রযোজ্য।

নতুন dependency-গুলো আরেকটি নীরব খরচ। Rung 5 বলে, যা installed আছে সেটিই ব্যবহার করুন। agent নিজের উদ্যোগে যে package যোগ করে, পরে আপনাকেই সেটি patch করতে হয়। সেই package ওই repository থেকে তৈরি করা প্রতিটি container image-এও যুক্ত হয়।

Ponytail-এর নিজস্ব benchmark সংখ্যাগুলো যা দেখায়

প্রকল্পটি দুই সেট ফলাফল প্রকাশ করে, এবং সেগুলোর মধ্যে ব্যবধান অনেক বড়। উভয় সেটই প্রকল্পের নিজস্ব প্রকাশিত পরিসংখ্যান। কোনোটিই স্বাধীন পরীক্ষা নয়।

[
  {
    "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
  }
]

single shot কলামের ফল এসেছে একটি bare model-কে নিয়মটি ব্যবহার করে এবং নিয়মটি ছাড়া অল্পসংখ্যক prompt-এর উত্তর দিতে দিয়ে। এই ফলাফল 13 এবং 17 June 2026 তারিখে করা একাধিক run-এর median। agentic কলামের ফল এসেছে একটি headless Claude Code session থেকে। এই session-এ tiangolo-এর full-stack-fastapi-template, একটি বাস্তব FastAPI এবং React repository, Haiku 4.5-এ প্রতিটি ক্ষেত্রে চারটি করে run সহ বারোটি feature ticket সম্পাদনা করা হয়েছে। পরে রেখে যাওয়া git diff-এর ভিত্তিতে ফলাফল মূল্যায়ন করা হয়েছে।

দ্বিতীয় কলামটি দেখুন। agentic ফলাফলে code-এর line 54 শতাংশ কম, খরচ 20 শতাংশ কম এবং wall clock time 27 শতাংশ কম। একই মাপের জন্য single shot setup-এ এই হার যথাক্রমে 93 শতাংশ এবং 74 শতাংশ। কেন এমন হয়েছে, README-তে তা স্পষ্টভাবে বলা আছে: single shot baseline একটি bare model, যা “বেশ কয়েকটি option এবং commentary সহ উত্তর দেয়”—এমন কাজকে হারানো সহজ। বাস্তব কাজ করা একটি বাস্তব agent-এর সঙ্গে তুলনা করলে সুবিধাটি কমে যায়। তবে সুবিধাটি বাস্তবই থাকে, এবং এটিই বেশি কার্যকর তথ্য।

একটি caveat প্রকল্পটি নিজেই উল্লেখ করেছে, এবং এই ফল আপনার কাজে লাগবে কি না তা মূলত এটিই নির্ধারণ করে। যেখানে অপ্রয়োজনীয়ভাবে বড় implementation করার প্রকৃত ঝুঁকি আছে, সেখানে সাশ্রয় সবচেয়ে বেশি। যে code আগে থেকেই minimal, সেখানে সাশ্রয় প্রায় শূন্য। একটি Python এবং TypeScript repository-র বারোটি ticket আপনার repository সম্পর্কে নির্ভরযোগ্য পূর্বাভাস দেয় না। এই সংখ্যা আপনার কাছে গুরুত্বপূর্ণ হলে, নিজের ticket-এ নিয়মটি ব্যবহার করে এবং নিয়মটি ছাড়া comparison চালান, তারপর line নিজেই গুনুন।

আজই কোনো কিছু ইনস্টল না করে যে পদ্ধতিটি কপি করতে পারেন

এই ladder-টি text, তাই ধারণাটি ব্যবহার করতে আপনার plugin-এর প্রয়োজন নেই। আপনার agent ইতিমধ্যে যে instruction file পড়ে, সেখানে এই ধরনের একটি block paste করুন। সেটি AGENTS.md, CLAUDE.md অথবা আপনার editor-এর rules file হতে পারে।

## 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.

শেষের rule-টি আলাদাভাবে মনে রাখা উচিত। Ponytail-এর convention হলো tool-এর name দিয়ে tag করা একটি comment:

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

এই comment-টি দুই লাইনের কাজেই এমন একটি প্রশ্নের নিষ্পত্তি করে, যার জন্য অন্যথায় একটি review cycle লাগত। এটি পরবর্তী reader-কে জানায় যে simple version-টি একটি সিদ্ধান্ত ছিল। একই সঙ্গে এটি বলে দেয়, কোন condition-এ সেই সিদ্ধান্ত আর প্রযোজ্য থাকবে না। এটি না থাকলে reviewer বুঝতে পারেন না যে এটি ভেবে নেওয়া একটি shortcut, নাকি agent-এর বাদ পড়ে যাওয়া কোনো বিষয়। তাই তাকে প্রশ্ন করতে হয়।

আপনি block-টি কোথায় রাখছেন, তা এর বিষয়বস্তুর মতোই গুরুত্বপূর্ণ। Agent যদি প্রতিটি run-এ যে file load করে, সেটি প্রতিটি run-এর আচরণ নিয়ন্ত্রণ করে। আপনি যেসব run পর্যবেক্ষণ করছেন না, সেগুলিও এর অন্তর্ভুক্ত। এই পার্থক্যটি আপনার agent যে AGENTS.md সত্যিই অনুসরণ করে তা লেখা-এর বিষয়। এই কারণেই pattern-টি আপনার shell history-তে না রেখে committed file-এ রাখা উচিত।

যেখানে এই নিয়ম আর প্রযোজ্য নয়

এই ladder এমন একটি বিদ্যমান codebase-এ feature work-এর জন্য তৈরি, যেখানে সাধারণত পুনর্ব্যবহারযোগ্য code থাকে এবং তা ব্যবহার করাই সঠিক হয়। greenfield project-এ এটি ভালোভাবে খাটে না, কারণ rung 2-এ পুনর্ব্যবহারের মতো কিছু থাকে না এবং rung 5-এ ইনস্টল করা কিছু থাকে না; ফলে agent প্রতিবারই rung 7-এ চলে যায়। আপনি যখন সত্যিই abstraction যোগ করতে চান, তখনও এটি ভালোভাবে খাটে না। একই copied block-এর চতুর্থ caller যোগ করার আগে "shortest diff" বেছে নিলে সেটি আপনাকে পঞ্চম copy-টি তৈরি করতে দেবে।

ultra level আপনার requirements নিয়ে প্রশ্ন তুলবে। level-টির উদ্দেশ্যই এটি, এবং আপনি যখন সিদ্ধান্ত নিয়ে কাজটি সম্পন্ন করতে চান, তখন এটি বাস্তব ব্যয় তৈরি করে। সাধারণ কাজের জন্য full ব্যবহার করুন এবং কোনো feature request-ই সমস্যার কারণ বলে সন্দেহ হলে ultra বেছে নিন।

সমস্যাটি ভুলভাবে বোঝা থেকে কোনো instruction block আপনাকে রক্ষা করতে পারে না। সিদ্ধান্ত নেওয়ার আগে code বোঝা ruleset-এর প্রথম নির্দেশনাই; এটিই সবচেয়ে ব্যয়বহুল অংশ, আর এই কাজটি text আপনার হয়ে করতে পারে না। ভুল function-এ minimal diff করলেও সেটি ভুল fix-ই থাকে, শুধু এখন সেটি ছোট এবং সহজে অনুমোদনযোগ্য একটি ভুল fix।

সৎ সারাংশ হলো, Ponytail হলো একটি যত্নসহকারে লেখা prompt, সঠিকভাবে বিতরণ করা হয়েছে এবং এর সঙ্গে কিছু সংখ্যা যুক্ত আছে। এটি ব্যবহারের জন্য plugin অপরিহার্য নয়। project আপনাকে যা দেয়, তা হলো কেউ তালিকাটি সঠিকভাবে লিখেছে, একটি বাস্তব repository-তে পরীক্ষা করেছে এবং ফলাফলের পাশেই পদ্ধতিটি প্রকাশ করেছে।

FAQ

Ponytail কি Claude Code ছাড়া অন্য agent-এর সঙ্গে কাজ করে?

হ্যাঁ। এটি এমন host-এর জন্য skill হিসেবে প্রকাশিত হয়েছে, যেগুলো skill load করে। এই তালিকায় Claude Code, Codex, OpenCode, Gemini এবং README-তে উল্লেখিত আরও কয়েকটি host রয়েছে। Cursor, Windsurf, Cline এবং Copilot-এর মতো যেসব editor rule file পড়ে কিন্তু skill load করে না, সেগুলো সংশ্লিষ্ট rules directory থেকে always-on ruleset নেয় এবং কোনো slash command পায় না। উভয় ক্ষেত্রেই text একই থাকে। প্রকৃত পার্থক্য হলো, আপনার host প্রতি turn-এ text-টি context-এ রাখে কি না, নাকি skill trigger হলে শুধু তখন রাখে।

কোনো lazy agent কি test, validation বা security বাদ দেবে?

না। ruleset-এ এটি সরাসরি বলা আছে। এর "never lazy about" তালিকায় trust boundary-তে input validation, data loss প্রতিরোধকারী error handling, security এবং accessibility অন্তর্ভুক্ত রয়েছে। প্রতিটি non-trivial logic অংশের জন্য একটি ছোট runnable check রাখতে বলা হয়েছে। rule যে বিষয়টি বাদ দেয়, তা হলো বানানো structure: কেউ চায়নি এমন abstraction এবং কারও প্রয়োজন ছিল না এমন dependency। এটি install করার পরে আপনার agent test বাদ দিতে শুরু করলে, কারণটি সম্ভবত আপনার নিজের config-এর অন্য কোনো instruction, যা এই rule-কে অগ্রাধিকার দিচ্ছে। তাই agent সর্বশেষ যে file load করে, সেটি পড়ুন।

প্রকাশিত speed এবং cost-এর সংখ্যা কি নির্ভরযোগ্য?

এগুলো project-এর নিজস্ব measurement। পদ্ধতিসহ প্রকাশ করা হয়েছে, তাই সেভাবেই পড়া উচিত। single shot figure-গুলো এমন একটি bare model-এর সঙ্গে তুলনা করে, যা options ও commentary-সহ উত্তর দেয়। README নিজেই এটিকে দুর্বল baseline হিসেবে চিহ্নিত করেছে। agentic figure-গুলো একটি FastAPI এবং React repository-তে headless Claude Code session থেকে নেওয়া। এতে twelveটি ticket, প্রতিটির fourটি run এবং Haiku 4.5 ব্যবহার করা হয়েছে। ওই setup-এর জন্য এগুলো সৎ measurement। আপনার codebase-এর জন্য এগুলো forecast নয়, কারণ project-টি আরও বলেছে যে আগে থেকেই minimal থাকা code-এ saving প্রায় zero-তে নেমে আসে।

সুবিধা পেতে কি আমাকে কিছু install করতে হবে?

না। ladder-টি text হিসেবে কাজ করে। আপনার agent যে instruction file ইতিমধ্যে পড়ে, সেখানে সমতুল্য block paste করলেই বেশিরভাগ সুবিধা পাওয়া যায়। plugin আপনাকে maintained wording, intensity level, review command এবং update path দেয়। আগে copied block ব্যবহার করে দেখা হলো rung 1 অনুযায়ী install আদৌ দরকার কি না, সেই প্রশ্নের উত্তর।

unattended agent-কে overnight অতিরিক্ত কাজ করা থেকে কীভাবে থামাব?

rule-টি chat message-এর বদলে always-on instruction file-এ রাখুন। তাহলে এটি দীর্ঘ run-এর turn 200-এও প্রযোজ্য থাকবে, শুধু turn 3-এ নয়। এরপর ক্ষতির পরিমাণ আলাদাভাবে সীমাবদ্ধ করুন। agent-কে এমন একটি checkout দিন, যেটি নষ্ট করার অনুমতি আছে; আপনার একমাত্র copy দেবেন না। merge করার আগে human diff review বাধ্যতামূলক করুন। minimal diff rule আপনাকে কম পড়তে সাহায্য করে। তবে কোন পরিবর্তন merge হবে, তা এটি নির্ধারণ করে না এবং করা উচিতও নয়।