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. I’ve been maintaining one called ai-dev-methodologies — and I’ve recently made it public.

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 run a bootstrap script that copies the methodology bundle into the repo — thin entry points like AGENTS.md and .cursor/rules, plus a .agents/instructions/ directory the agent reads from — rather than assembling instructions from scratch.

The repo itself is versioned (VERSION, CHANGELOG.md). Each bootstrapped project pins its copy in .agents/METHODOLOGY.lock. When the methodology updates, agents follow framework-adoption.md: read what changed upstream, replace framework-owned files only, leave project-specific customizations alone.

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

In my repo, the contents are organized as a tiered catalog in METHODOLOGIES.md: Karpathy’s coding discipline, decision authority (when the agent should ask rather than decide), lane-based development for multi-module work, API-first layering, session handoff docs, and a few optional founder defaults for deployment. Some of it came directly from Karpathy; some was absorbed from projects like Ponytail; the rest grew out of my own AI-first habits.

But the specific contents aren’t the point. What matters is having a gate that reflects your own judgment — not someone else’s judgment in a different container.

Public, but not for adoption

I decided to make ai-dev-methodologies public — but the point is not for you to adopt it directly.

What I’m sharing is what a gate can look like in practice: how to tier a catalog, pin versions, filter new techniques in, and keep projects aligned. Use it as reference. Study the structure. Pick the rules you agree with, and write them into your own methodology repo.

I still believe the best setup is one you maintain yourself. If you take my repo wholesale, you’re not really doing anything different from installing skill after skill, or chasing Ponytail and then Caveman — you’ve just swapped a pile of fragments for one bigger bundle.

And this repo serves me, not you. I update it whenever my own habits shift. I won’t always publish a separate announcement explaining why I changed this file or dropped that rule. If you follow the whole thing, you’re treating someone’s evolving personal preferences as a stable standard to depend on.

Treat it as reference, not product. The prompts below are meant to help you build your own gate — not mine.

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 against our own development methodology (if we don’t have one yet, study https://github.com/jackyckma/ai-dev-methodologies to see how a gate repo can be organized — but don’t copy its contents wholesale). 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:

Study https://github.com/jackyckma/ai-dev-methodologies for how a methodology repo can be structured and versioned — but do not copy its rules wholesale. Ask me a few questions about this project’s stack and habits, then help me bootstrap our own development methodology, starting with .agents/instructions/project-guidelines.md.

Syncing an existing project to a new version:

Our own development methodology repo has a new version. Please read CHANGELOG.md and follow framework-adoption.md to sync this project — replace framework-owned files only, update .agents/METHODOLOGY.lock, and flag anything that conflicts with our project-specific customizations.

---

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.