Two GitHub repositories went viral within days of each other recently. The first, Caveman, teaches agents to speak like a caveman: strip out all pleasantries, output directly, cut token usage by sixty or seventy percent. The second, Ponytail, tells your agent to behave like the most senior — and laziest — engineer at the company. Ask for a date picker, and instead of installing a package and writing a wrapper component, it says: the native browser input works fine. The two projects are neatly complementary. One covers how the agent talks; the other covers how it writes code. Their READMEs even reference each other and suggest using them together.

Pull the camera back and these are just the latest two peaks in a wave that has been building for most of the past year. Last October there was Superpowers, which took the opposite approach entirely: interview requirements first, write the spec, write the plan, then work through a strict red-green TDD cycle without skipping a step. Earlier this year, someone packaged up a few of Karpathy’s complaints about AI agents — guessing at requirements, over-engineering, touching unrelated code — into a set of instructions that reached over a hundred thousand stars in a few weeks. Caveman itself started similarly: a throwaway Reddit comment became a several-thousand-star draft, then a maintainer added tiering and multi-tool support, and three weeks later it had fifty or sixty thousand stars.

The pace is almost absurd. While Ponytail was still trending, someone had already launched a meme coin off the hype. This isn’t engineering wisdom. It’s this week’s fashion.

What the methodological clash is really about

After watching this cycle for a while, what these projects have taught me is less about any specific technique and more about something more fundamental: most of the time, a technique isn’t simply right or wrong. It reflects a philosophical difference about engineering.

Superpowers treats the test cycle as non-negotiable: you write tests first, and you do not skip the red step. Ponytail takes nearly the opposite position: don’t write abstractions nobody asked for, and keep exactly one working test — the minimum. These are not two versions of the same common sense. They are two different professional judgments that happen to be packaged in the same format.

If you don’t have your own framework, these conflicts are hard to absorb. You might follow Superpowers one week and find yourself persuaded by Ponytail the next. But the underlying tension never gets resolved. You’re just quietly inheriting other people’s positions.

The cost of adopting everything

Pulling in each new methodology as it appears can save effort in the short term. But it doesn’t hold up. What you’re copying is someone else’s judgment, not your own.

The more practical problem emerges as your projects multiply. You start losing track of which project uses which rules, which instructions came from which methodology, and whether they’re even compatible with each other. Those potentially contradictory rules sit quietly in your .cursorrules or system prompts, waiting to interfere with each other at some unexpected moment. Managing the configuration itself becomes overhead — before you’ve even started the real work.

Chasing what’s trending is easy. Building something consistent with your own engineering philosophy takes more intention, but it’s what compounds.

The idea of a gate

My own approach is to write that judgment down in a dedicated repository and treat it as my personal development methodology.

The mechanic is simple. When something new appears, I ask my agent to research it and then discuss it with me — comparing it against what I’ve already written down, looking for where it fits and where it conflicts. When there’s genuine disagreement with my existing approach, I don’t let the agent decide. That becomes a conversation. When I start a new project, I simply ask the agent to import that methodology rather than assembling instructions from scratch.

The repo itself is versioned. It includes notes on how an agent should apply it correctly, and how to synchronize projects when the methodology updates.

Its real function is to serve as a gate: filtering and absorbing new techniques from the outside, while providing every project with a consistent internal structure.

What goes inside

My own methodology contains things borrowed directly from Karpathy, elements absorbed from projects like Ponytail, and habits I’ve developed from working AI-first — API-first development, building feature by feature rather than layer by layer, and so on.

But the specific contents aren’t the point. Everyone has a different stack, different project types, and different standards for what counts as good enough. What you ultimately need is something that reflects your own judgment, not someone else’s judgment in a different container.

The important thing is to have the gate itself.

A few starting prompts

If you want to try this with your own coding agent, here are a few prompts you can use directly or adjust to fit your situation.

Building your own methodology repo:

I want to create a personal development methodology repository that I can apply across all my projects. Start by asking me a few questions about my current tech stack, project management habits, and the rules I’m already following but haven’t written down — like how I decide whether to write tests or when to add an abstraction layer. Based on my answers, organize this into a methodology document and design a simple versioning mechanism so I can apply it to new projects later.

Evaluating a new methodology:

I came across two coding agent instructions called Ponytail and Caveman. Please research them and compare them to our existing development methodology. Where do they overlap, where do they differ, and is there anything worth absorbing? For anything that clearly conflicts with our current approach, don’t decide on your own — flag it so we can discuss it.

Applying the methodology to a new project:

Please review https://github.com/your-org/dev-methodology — that’s the development methodology I use across all my projects. Help me import this methodology into this project.

Syncing an existing project to a new version:

Our development methodology repository has been updated. Please read what changed and help me sync this project to the latest version.

---

This whole approach is still evolving. A personal methodology isn’t something you build once and leave alone. It’s more like a mirror for your engineering judgment — it gets more accurate as you work through more projects and encounter more ideas. What matters isn’t what it says right now. What matters is whether you have somewhere for your judgment to land.