Ponytail: AI coding agent తక్కువ code రాసేలా చేయడం ఎలా

Ponytail అంటే ఏమిటి

Ponytail అనేది AI coding agent తక్కువ code రాసేలా చేసే నియమాల సముదాయం. ఈ project తనను ఒక వాక్యంలో ఇలా వివరిస్తుంది: "మీ AI agent గదిలో ఉన్న అత్యంత సోమరి senior devలా ఆలోచించేలా చేస్తుంది. మీరు ఎప్పుడూ రాయకపోయిన codeనే ఉత్తమమైన code." దీనికి MIT license ఉంది. దీనికి స్వంత runtime లేదు, ఇందులో ఏదీ execute కాదు. ఇది agent instructionsలోకి వెళ్లే text. Skillsను load చేసే hosts కోసం ఇది skillగా package చేయబడుతుంది. Skillsను load చేయని hosts కోసం ఇది సాధారణ rule filesగా ఉంటుంది.

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 మధ్య మాత్రమే పది tags ఉన్నాయి. ఈ వేగంతో మారుతున్న projectను మీరు చదివే సమయానికి మారి ఉండవచ్చు. అందువల్ల దాని ఆధారంగా ఏదైనా build చేయడానికి ముందు ఒక tagను pin చేయండి.

సాధనానికి ముందు ఆలోచన: నిలిచే మొదటి మెట్టుపైనే ఆగండి

Ponytail యొక్క ప్రధాన సూత్రం నిర్ణయాల మెట్ల వరుస. ఏదైనా రాయడానికి ముందు agent ఈ మెట్లను పరిశీలించి, వర్తించే మొదటి మెట్టుపైనే ఆగుతుంది.

1. ఇది అసలు ఉండాల్సిన అవసరం ఉందా? ఇది YAGNI (మీకు ఇది అవసరం ఉండదు) సూత్రం. సమాధానం లేదు అయితే, దాన్ని వదిలేయండి.
2. ఇది ఇప్పటికే ఈ codebaseలో ఉందా? ఇప్పటికే ఉన్న helper లేదా patternను మళ్లీ ఉపయోగించండి.
3. standard library దీన్ని చేయగలదా? దానినే ఉపయోగించండి.
4. native platform feature దీన్ని అందిస్తుందా? దానినే ఉపయోగించండి.
5. ఇప్పటికే install చేసిన dependencyతో సమస్య పరిష్కారమవుతుందా? దానినే ఉపయోగించండి.
6. దీన్ని ఒకే lineలో రాయగలరా? ఒకే lineలో రాయండి.
7. ఆ తర్వాత మాత్రమే, పనిచేసే కనిష్ఠ codeను రాయండి.

పని చేసేది ఏ ఒక్క మెట్టు కాదు; వాటి క్రమమే. Agentను date picker అడిగితే, అది date pickerనే రాస్తుంది, ఎందుకంటే అదే చేయమని దానికి చెప్పబడింది. ఈ మెట్ల వరుస మొదట 4వ మెట్టును పరిశీలించేలా చేస్తుంది. 4వ మెట్టు browserలో ఇప్పటికే <input type="date"> ఉందని చూపిస్తుంది. ఈ project యొక్క benchmark గమనికలు కూడా ఇదే విషయాన్ని స్పష్టంగా చూపిస్తున్నాయి: ఈ నియమం లేకుండా date picker 404 linesగా తయారైంది; నియమంతో 23 linesకు తగ్గింది. కారణం, agent componentను నిర్మించకుండా native inputను ఉపయోగించింది. ఇదే కారణంతో colour picker కూడా 287 lines నుంచి 23 linesకు తగ్గింది.

ఇక్కడ lazyగా ఉండటం నిర్లక్ష్యంగా ఉండటం కాదు; ruleset దీన్ని నేరుగా స్పష్టం చేస్తుంది. "never lazy about" జాబితాలో నిర్ణయం తీసుకునే ముందు సమస్యను అర్థం చేసుకోవడం, trust boundaries వద్ద input validation, data lossను నివారించే error handling, security, accessibility, అలాగే పేరుతో స్పష్టంగా అడిగిన ప్రతిదీ ఉన్నాయి. Non-trivial logicలోని ప్రతి భాగానికి ఒక చిన్న runnable check ఉండాలని కూడా ఇది కోరుతుంది. ఈ నియమం అవసరం లేని ఆవిష్కరణను తగ్గిస్తుంది. Correctnessను తగ్గించదు.

రిపాజిటరీ వాస్తవంగా విడుదల చేసేవి

• AGENTS.md, ఎల్లప్పుడూ అమలులో ఉండే ruleset. ఇది మొత్తం భావనను ఐదు నిమిషాల్లో చదవగల ఒకే ఫైల్‌లో అందిస్తుంది.
• skills/ponytail/SKILL.md, skill definition. దీనికి lite, full లేదా ultra అనే argument hint ఉంటుంది.
• .cursor/rules/ మరియు .windsurf/rules/ వంటి editor-specific directories కింద ఉండే rule files. Rules చదివి skills లోడ్ చేయని hosts కోసం ఇవి ఉపయోగపడతాయి.
• hooks/, benchmarks/, examples/ మరియు scripts/.

Intensity argument, rule ఎంత కఠినంగా అమలు కావాలో మార్చుతుంది. lite మీరు కోరినదాన్ని రూపొందించి, ఒకే పంక్తిలో తక్కువ శ్రమతో కూడిన ఎంపికను సూచిస్తుంది. full default ఎంపిక. ఇది ladder ను తప్పనిసరిగా అమలు చేస్తుంది. ultra అనేది YAGNI యొక్క అత్యంత కఠినమైన setting. ఇది చేర్చడం కంటే తొలగించడానికే ప్రాధాన్యం ఇస్తుంది మరియు requirement‌నే ప్రశ్నిస్తుంది.

Skills‌కు మద్దతు ఉన్న hosts‌కు slash commands కూడా లభిస్తాయి. /ponytail స్థాయిని సెట్ చేస్తుంది. /ponytail-review over-engineering ఉందో లేదో diff‌లో తనిఖీ చేస్తుంది. /ponytail-audit మొత్తం repository‌ని తనిఖీ చేస్తుంది. /ponytail-debt మీరు వాయిదా వేసిన shortcuts‌ను సేకరిస్తుంది. /ponytail-gain benchmark scorecard‌ను చూపిస్తుంది. Rule files మాత్రమే చదివే hosts‌కు commands లేకుండా ruleset లభిస్తుంది.

Source‌ను నమ్మే ముందు చదవాలంటే, branch‌కు బదులుగా tag‌ను clone చేయండి:

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

Claude Code‌లో project దీనికి బదులుగా plugin install‌ను document చేస్తుంది. 1 August 2026 నాటికి ఈ రెండు పంక్తులు document చేసిన విధంగానే ఉన్నాయి:

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

Plugin path tag‌కు బదులుగా default branch‌ను అనుసరిస్తుంది. అందువల్ల sessions మధ్య మీ agent‌కు మార్గనిర్దేశం చేసే instructions మారవచ్చు. Update command సౌలభ్యం కోసం మీరు అంగీకరించే trade-off ఇదే.

VPSలో lazy agent ఎందుకు తక్కువ ఖర్చుతో ఉంటుంది

Agent రాసిన diff conversation నుంచి తొలగిపోదు. తదుపరి turnలో model దాన్ని మళ్లీ చదివే contextగా ఉపయోగిస్తుంది. Diffను రూపొందించడానికి అది తెరిచిన ప్రతి file కూడా అదే contextలో ఉంటుంది. అందువల్ల 500 line మార్పు దాన్ని రూపొందించిన turnకే కాకుండా, sessionలోని ప్రతి తరువాతి turnకూ ఖర్చును పెంచుతుంది. అందుకే runaway refactor వల్ల session కొనసాగుతున్న కొద్దీ agent నెమ్మదిగా, తక్కువ సామర్థ్యంతో పనిచేస్తున్నట్లు అనిపిస్తుంది. Window agent స్వయంగా రూపొందించిన outputతో నిండిపోతుంది. దాంతో మీ అసలు codeకు మిగిలే స్థలం తగ్గుతుంది. దీన్ని నియంత్రించడమే coding agent యొక్క context windowను నిర్వహించడం అనే అంశం యొక్క పూర్తి ఉద్దేశ్యం.

Tokensను inputగా పంపినప్పుడు, outputగా వచ్చినప్పుడు కూడా billing జరుగుతుంది. అందువల్ల సగం పరిమాణంలో ఉన్న diff రెండు సార్లు తక్కువ ఖర్చు అవుతుంది. ఒకసారి అది రాయబడుతున్నప్పుడు, మళ్లీ దాన్ని తిరిగి చదివే ప్రతి turnలో. మీరు self-hosted setupలో billను గమనిస్తుంటే, instruction file మార్చడానికి ఎటువంటి అదనపు ఖర్చు ఉండదు. AI agent మీకు కలిగించే ఖర్చును నియంత్రించడం output volumeతో ప్రారంభమవుతుంది. coding agent తన tokensను ఎలా ఖర్చు చేస్తుందో కూడా వివరిస్తుంది. తిరిగి చదవడం ఎందుకు చాలామంది ఊహించినదానికంటే ఎక్కువ ప్రభావం చూపుతుందో అక్కడ తెలుస్తుంది.

Diffను మనిషి ఇంకా చదవాల్సిందే. 20 lines ఉండాల్సిన మార్పు 400 linesగా ఉంటే, reviewer యొక్క శ్రద్ధపై అదనపు భారం పడుతుంది. మొదటిదానికి ఇచ్చినంత జాగ్రత్తతో రోజులోని నాలుగో పొడవైన diffను ఎవరూ review చేయరు. అందువల్ల అవసరానికి మించి code నిర్మించడం సమయాన్ని మాత్రమే వృథా చేయదు. తప్పులను గుర్తించాల్సిన review నాణ్యతను కూడా ఇది నెమ్మదిగా తగ్గిస్తుంది.

Serverపై పరిస్థితి మరింత తీవ్రమవుతుంది. Agent తరచుగా ఎవరూ పర్యవేక్షించని విధంగా పనిచేస్తుంది. tmux sessionలో లేదా timer ద్వారా పనిచేస్తున్న agent, మీరు గమనించేలోపు తప్పు నిర్ణయంపై గంటల పాటు మరిన్ని మార్పులు నిర్మించవచ్చు. ఇదే VPSపై coding agentను అమలు చేయడంలోని ఆచరణాత్మక ప్రమాదం. అందుకే loop engineering చేసే వారు individual promptsకంటే standing instructionsపై ఎక్కువ శ్రద్ధ పెడతారు. ఎల్లప్పుడూ అమలులో ఉండే fileలోని rule turn 200కూ వర్తిస్తుంది. మీరు chatలో టైప్ చేసిన rule turn 3కే వర్తిస్తుంది.

కొత్త dependencies మరో నిశ్శబ్ద ఖర్చు. Rung 5లో ఇప్పటికే installedగా ఉన్న వాటినే ఉపయోగించమని చెబుతుంది. Agent తన నిర్ణయంతో జోడించే ప్రతి packageను మీరు తరువాత patch చేయాలి. అలాగే ఆ repository నుంచి నిర్మించే ప్రతి container imageలో కూడా ఆ package చేరుతుంది.

Ponytail స్వంత బెంచ్‌మార్క్ సంఖ్యలు ఏమి చెబుతున్నాయి

ప్రాజెక్ట్ రెండు ఫలితాల సమితులను ప్రచురించింది. వాటి మధ్య చాలా పెద్ద తేడా ఉంది. రెండూ ప్రాజెక్ట్ స్వయంగా ప్రచురించిన గణాంకాలే. ఏదీ స్వతంత్ర పరీక్ష కాదు.

[
  {
    "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 ఇచ్చిన సమాధానాల నుంచి వచ్చాయి. rule లేకుండా, rule‌తో చేసిన పునరావృత రన్‌లలో 13 మరియు 17 June 2026 తేదీలకు లెక్కించిన median విలువలు అవి. agentic కాలమ్‌లోని ఫలితాలు headless Claude Code session నుంచి వచ్చాయి. ఆ session tiangolo యొక్క full-stack-fastapi-template అనే నిజమైన FastAPI మరియు React repositoryలో మార్పులు చేసింది. Haiku 4.5పై నాలుగు రన్‌ల చొప్పున పన్నెండు feature ticket‌లను పరీక్షించారు. మిగిలిన git diff ఆధారంగా స్కోర్ చేశారు.

రెండవ కాలమ్‌ను చూడండి. agentic ఫలితంలో code lines 54 శాతం తక్కువగా ఉన్నాయి, ఖర్చు 20 శాతం తక్కువగా ఉంది, wall clock సమయం 27 శాతం తక్కువగా ఉంది. అదే కొలతల కోసం single shot setupలో ఈ సంఖ్యలు వరుసగా 93 శాతం మరియు 74 శాతం. కారణాన్ని README స్పష్టంగా చెబుతోంది: single shot baseline అనేది “అనేక ఎంపికలతో పాటు వ్యాఖ్యానాన్ని ఇచ్చే” bare model. దాన్ని అధిగమించడం సులభం. నిజమైన పని చేస్తున్న నిజమైన agent‌తో పోల్చితే లాభం తగ్గుతుంది. అయినా ఆ లాభం వాస్తవమే. అదే మరింత ఉపయోగకరమైన విషయం.

ఒక పరిమితిని ప్రాజెక్ట్ స్వయంగా పేర్కొంది. మీకు ఇది ఉపయోగపడుతుందో నిర్ణయించేది అదే. నిజంగా అవసరానికి మించి code నిర్మించే అవకాశం ఉన్న చోట saving ఎక్కువగా ఉంటుంది. ఇప్పటికే minimalగా ఉన్న codeలో saving దాదాపు ఉండదు. ఒకే Python మరియు TypeScript repositoryలోని పన్నెండు ticket‌లు మీ repository ఫలితాలను అంచనా వేయలేవు. ఈ సంఖ్య మీకు ముఖ్యమైతే, మీ స్వంత ticket‌లపై rule లేకుండా మరియు rule‌తో పోలికను నడపండి. Lines‌ను మీరే లెక్కించండి.

ఈరోజే ఏదీ ఇన్‌స్టాల్ చేయకుండా కాపీ చేసుకోగల నమూనా

ఈ ladder పాఠ్యరూపంలో ఉంటుంది. అందువల్ల ఈ ఆలోచనను ఉపయోగించడానికి plugin అవసరం లేదు. మీ agent ఇప్పటికే చదివే instruction file లో ఇలాంటి block ను చేర్చండి. అది 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 యొక్క convention ప్రకారం, ఇది tool పేరు ఉన్న comment:

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

ఈ comment రెండు పని పంక్తులను కలిగి ఉంటుంది. సాధారణంగా review cycle అవసరమయ్యే ప్రశ్నకు ఇది స్పష్టమైన సమాధానం ఇస్తుంది. సరళమైన version ఉద్దేశపూర్వక నిర్ణయం అని, ఆ నిర్ణయం ఇక వర్తించని పరిస్థితి ఏమిటో ఇది తదుపరి reader కు తెలియజేస్తుంది. ఇది లేకపోతే, review చేసే వ్యక్తి ఆలోచించి చేసిన shortcut ను agent మరచిపోయిన విషయంగా వేరు చేయలేరు. అందువల్ల వారు ప్రశ్నించాల్సి వస్తుంది.

ఈ block ను ఎక్కడ ఉంచుతారో, అది ఏమి చెబుతుందో అంతే ముఖ్యమైనది. agent ప్రతి run లో load చేసే file, మీరు గమనించని run లతో సహా ప్రతి run ను ప్రభావితం చేస్తుంది. ఈ తేడా మీ agent నిజంగా అనుసరించే AGENTS.md రాయడం అనే అంశానికి సంబంధించినది. అందుకే ఈ నమూనాను మీ shell history లో కాకుండా committed file లో ఉంచాలి.

నియమం సరైనది కాకపోయే సందర్భాలు

ఇప్పటికే ఉన్న codebaseలో feature పనుల కోసం ఈ మెట్టు విధానం రూపొందించబడింది. అక్కడ code reuse సాధారణంగా అందుబాటులో ఉంటుంది మరియు సాధారణంగా సరైనదే ఉంటుంది. Greenfield projectకు ఇది సరిగా సరిపోదు. ఎందుకంటే rung 2లో reuse చేయడానికి ఏదీ ఉండదు, rung 5లో install చేయబడినదీ ఏదీ ఉండదు. అందువల్ల agent ప్రతిసారీ rung 7కు చేరుతుంది. మీరు నిజంగా abstractionను కోరుకునే సమయంలో కూడా ఇది సరిగా పనిచేయదు. అదే copy చేసిన blockకు నాలుగో callerను చేర్చబోతున్నట్లయితే, "shortest diff" మీకు ఐదో copyని అందిస్తుంది.

ultra స్థాయి మీ requirementsను సవాలు చేస్తుంది. ఆ స్థాయి ఉద్దేశం అదే. మీరు ఇప్పటికే నిర్ణయం తీసుకుని పని పూర్తవాలని కోరుకున్నప్పుడు ఇది నిజమైన ఖర్చుగా మారుతుంది. సాధారణ పనికి fullను ఉపయోగించండి. Feature requestే సమస్య కావచ్చని అనుమానించినప్పుడు ultraను ఎంచుకోండి.

సమస్యను తప్పుగా అర్థం చేసుకోవడం నుంచి ఏ instruction block కూడా మిమ్మల్ని రక్షించదు. నిర్ణయం తీసుకునే ముందు codeను అర్థం చేసుకోవడం rulesetలోని మొదటి అంశమే. అదే ఖరీదైన భాగం, మరియు ఆ భాగాన్ని text మీ తరఫున చేయలేదు. తప్పు functionలో చేసిన minimal diff అయినా తప్పు fixగానే ఉంటుంది. ఇప్పుడు అది ఆమోదించడం సులభమైన చిన్న తప్పు fixగా మారుతుంది.

నిజాయితీగా చెప్పాలంటే, Ponytail అనేది జాగ్రత్తగా రాసిన prompt. ఇది సమర్థంగా పంపిణీ చేయబడింది మరియు దానికి సంఖ్యలు జతచేయబడ్డాయి. ఇందులో plugin అవసరమని చెప్పే ఏ అంశమూ లేదు. ఈ project అందించేది ఏమిటంటే, ఎవరో ఈ జాబితాను సరిగ్గా రాశారు, నిజమైన repositoryపై పరీక్షించారు, మరియు ఫలితంతో పాటు ఆ విధానాన్ని ప్రచురించారు.

FAQ

Ponytail Claude Code కాకుండా ఇతర agents‌తో పనిచేస్తుందా?

అవును. Skills‌ను load చేసే hosts కోసం ఇది skill‌గా విడుదలవుతుంది. ఆ hosts‌లో Claude Code, Codex, OpenCode, Gemini మరియు README‌లో పేర్కొన్న మరికొన్ని ఉన్నాయి. Rule files‌ను చదివి skills‌ను load చేయని Cursor, Windsurf, Cline మరియు Copilot వంటి editors, సరిపోలే rules directory నుంచి ఎల్లప్పుడూ అమలులో ఉండే ruleset‌ను తీసుకుంటాయి. వీటికి slash commands లభించవు. రెండు సందర్భాల్లోనూ text ఒకటే. అసలు తేడా ఏమిటంటే, ప్రతి turn‌లో host ఆ text‌ను context‌లో ఉంచుతుందా లేదా skill trigger అయినప్పుడు మాత్రమే ఉంచుతుందా అనేది.

Lazy agent tests, validation లేదా security‌ను వదిలేస్తుందా?

లేదు. Ruleset దీన్ని నేరుగా చెబుతుంది. దీని "never lazy about" జాబితాలో trust boundaries వద్ద input validation, data loss‌ను నిరోధించే error handling, security మరియు accessibility ఉన్నాయి. Non-trivial logic‌లోని ప్రతి భాగానికి అమలు చేయగల ఒక చిన్న check ఉండాలని కూడా ఇది కోరుతుంది. Rule తొలగించేది ఊహించి జోడించిన structure మాత్రమే: ఎవరూ కోరని abstractions మరియు ఎవరికీ అవసరం లేని dependencies. దీన్ని install చేసిన తర్వాత మీ agent tests‌ను వదిలేస్తే, కారణం మీ స్వంత config‌లోని మరొక instruction దీనికంటే ఎక్కువ ప్రాధాన్యాన్ని పొందడం. కాబట్టి agent చివరిగా load చేసే file‌ను చదవండి.

ప్రచురించిన speed మరియు cost సంఖ్యలను నమ్మవచ్చా?

అవి project స్వయంగా చేసిన కొలతలు. వాటి method‌తోనే ప్రచురించబడ్డాయి. కాబట్టి వాటిని ఆ సందర్భంలోనే అర్థం చేసుకోవాలి. Single shot గణాంకాలు options మరియు commentaryతో సమాధానం ఇచ్చే bare model‌తో పోలుస్తాయి. README స్వయంగా దీన్ని బలహీనమైన baseline‌గా పేర్కొంటుంది. Agentic గణాంకాలు ఒక FastAPI మరియు React repositoryపై headless Claude Code session నుంచి వచ్చాయి. ఇందులో పన్నెండు tickets, ఒక్కోదానికి నాలుగు runs, Haiku 4.5 ఉపయోగించబడ్డాయి. ఆ setup‌కు అవి నమ్మదగిన సంఖ్యలు. అయితే అవి మీ codebase‌కు forecast కావు. ఇప్పటికే minimal‌గా ఉన్న codeపై saving దాదాపు సున్నాకు పడిపోతుందని project కూడా చెబుతుంది.

ప్రయోజనం పొందడానికి ఏదైనా install చేయాలా?

లేదు. Ladder అనేది text మాత్రమే. మీ agent ఇప్పటికే చదివే instruction file‌లో సమానమైన block‌ను paste చేస్తే, చాలా వరకు అదే ప్రభావం లభిస్తుంది. Plugin నిర్వహించబడే wording, intensity levels, review commands మరియు update path‌ను అందిస్తుంది. Install అసలు అవసరమా అనే ప్రశ్నకు, ముందుగా copy చేసిన block‌ను ప్రయత్నించడం rung 1 సమాధానం.

రాత్రంతా unattended agent ఎక్కువగా నిర్మించకుండా ఎలా ఆపాలి?

Rule‌ను chat message‌లో కాకుండా always-on instruction file‌లో ఉంచండి. అప్పుడు అది దీర్ఘ run‌లోని turn 3 వద్ద మాత్రమే కాకుండా turn 200 వద్ద కూడా వర్తిస్తుంది. తర్వాత నష్టాన్ని విడిగా పరిమితం చేయండి: మీ ఏకైక copyకి బదులుగా, నాశనం చేయడానికి agent‌కు అనుమతించిన checkout‌ను ఇవ్వండి. ఏదైనా merge చేయడానికి ముందు human diff review తప్పనిసరి చేయండి. Minimal diff rule మీరు చదవాల్సిన పరిమాణాన్ని తగ్గిస్తుంది. ఏది merge కావాలో అది నిర్ణయించదు, నిర్ణయించకూడదు కూడా.