Ponytail কী? AI coding agent-এর জন্য অলস senior dev নিয়ম

Ponytail কী

Ponytail হলো এমন একটি নিয়মসমষ্টি, যা AI coding agent-কে কম code লিখতে বাধ্য করে। Project-টি নিজেকে এক লাইনে এভাবে বর্ণনা করে: "আপনার AI agent-কে ঘরে থাকা সবচেয়ে অলস senior developer-এর মতো ভাবতে শেখায়। সেরা code হলো যে code আপনি কখনো লেখেননি।" এটি MIT license-এর অধীনে প্রকাশিত। এর নিজস্ব কোনো runtime নেই এবং এর কোনো কিছুই execute হয় না। এটি agent-এর instructions-এ যোগ করা text। যেসব host skill load করে, তাদের জন্য এটি skill হিসেবে packaged। যেসব host তা করে না, তাদের জন্য এটি সাধারণ rule file হিসেবে দেওয়া হয়।

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

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

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

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

কাজটি কোনো একক ধাপ করে না; ধাপগুলোর ক্রমই কাজটি করে। কোনো agent-কে date picker তৈরি করতে বলা হলে সে date picker-ই লিখবে, কারণ তাকে সেটিই করতে বলা হয়েছে। এই সিঁড়ি তাকে প্রথমে ধাপ 4 পরীক্ষা করতে বাধ্য করে, আর ধাপ 4 জানায় যে browser-এ ইতিমধ্যেই <input type="date"> আছে। প্রকল্পের নিজস্ব benchmark notes-এ ঠিক এই উদাহরণটি দেওয়া হয়েছে: নিয়মটি ছাড়া একটি 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 কমায় না।

Repository আসলে যা সরবরাহ করে

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

Intensity argument-টি rule কতটা কঠোরভাবে প্রয়োগ হবে তা পরিবর্তন করে। lite আপনার অনুরোধ অনুযায়ী তৈরি করে এবং এক লাইনে কম পরিশ্রমের একটি option উল্লেখ করে। 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-টি এর বদলে plugin install নথিবদ্ধ করে, এবং 1 August 2026 তারিখে এই দুইটি line নথি অনুযায়ী ছিল:

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

Plugin path tag-এর বদলে default branch অনুসরণ করে। তাই session-গুলোর মধ্যে আপনার agent-কে পরিচালনা করা instruction পরিবর্তিত হতে পারে। Update command ব্যবহারের সুবিধার জন্য আপনি এই trade-off গ্রহণ করছেন।

VPS-এ অলস agent কেন সাশ্রয়ী

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

Tokens input এবং output—উভয় দিকেই বিল হয়। তাই অর্ধেক আকারের একটি diff দুইবার সাশ্রয় করে: একবার লেখার সময় এবং পরে প্রতিটি turn-এ সেটি আবার পড়ার সময়। আপনি self-hosted setup-এর বিল পর্যবেক্ষণ করলে instruction file এমন একটি নিয়ন্ত্রণ, যা প্রয়োগ করতে কোনো খরচ হয় না। AI agent-এর খরচ নিয়ন্ত্রণ করা শুরু হয় output volume দিয়ে, আর coding agent কীভাবে তার tokens ব্যয় করে ব্যাখ্যা করে কেন পুনরায় পড়ার বিষয়টি মানুষের প্রত্যাশার চেয়ে বেশি গুরুত্বপূর্ণ।

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

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

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

Ponytail-এর নিজস্ব বেঞ্চমার্কের সংখ্যাগুলো কী বলে

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

[
  {
    "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 তারিখে করা পুনরাবৃত্ত রানগুলোর median হিসেবে নেওয়া হয়েছে। agentic কলামের ফলাফল এসেছে একটি headless Claude Code session থেকে। সেটি tiangolo-এর full-stack-fastapi-template সম্পাদনা করেছে। এটি একটি বাস্তব FastAPI এবং React repository। Haiku 4.5-এ 12টি feature ticket-এর প্রতিটির জন্য 4টি করে run করা হয়েছে। মূল্যায়ন করা হয়েছে রেখে যাওয়া git diff-এর ভিত্তিতে।

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

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

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

ল্যাডারটি টেক্সট, তাই ধারণাটি ব্যবহার করতে আপনার প্লাগইনটির প্রয়োজন নেই। আপনার এজেন্ট যে instruction file আগে থেকেই পড়ে, সেখানে এ রকম একটি ব্লক পেস্ট করুন। সেটি 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.

শেষ নিয়মটি আলাদাভাবে বিবেচনা করা উচিত। Ponytail-এর কনভেনশনে tool-এর নাম দিয়ে ট্যাগ করা একটি comment থাকে:

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

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

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

যে অবস্থায় নিয়মটি আর সঠিক থাকে না

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

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, project যে method ব্যবহার করেছে তা-সহ প্রকাশিত। তাই সেভাবেই এগুলো পড়া উচিত। Single shot figure-গুলো এমন একটি bare model-এর সঙ্গে তুলনা করা হয়েছে, যা option ও commentary-সহ উত্তর দেয়। README নিজেই এটিকে দুর্বল baseline হিসেবে চিহ্নিত করেছে। Agentic figure-গুলো একটি FastAPI এবং React repository-তে headless Claude Code session থেকে নেওয়া হয়েছে। এতে ছিল 12টি ticket, প্রতিটির 4টি run, এবং Haiku 4.5। ওই setup-এর জন্য এগুলো নির্ভরযোগ্য সংখ্যা। আপনার codebase-এর জন্য এগুলো পূর্বাভাস নয়, কারণ project-এ আরও বলা হয়েছে যে code আগে থেকেই minimal হলে saving প্রায় শূন্যে নেমে আসে।

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

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

Unattended agent-কে overnight অতিরিক্ত কাজ করা থেকে কীভাবে আটকাব?

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