We Need a Config Standard for AI Coding Tools. We Won't Get One.

AI Coding Tools Need a Config Standard (And No One Is Going to Give Us One)

This needs to get off my chest.

I am tired of every AI coding tool doing its own thing. Claude, OpenCode, Codex, GitHub Copilot, you name it. They all store configs in different locations, use different formats, and cannot agree on something as basic as how to define a skill or an agent prompt. There is no standard. There is just noise.

What this looks like in practice

At my company right now: I have an OpenCode repository with my SDLC flow. I maintain a Pi agent setup because it is easier to develop flows in. The rest of the team uses Copilot, but not the CLI version, the VS Code editor version. Different YAML headers, different folder structures, different everything.

It is a mess.

What we actually need

Something like XDG folder standards, but for agentic frameworks. An .agents/ directory. An .agents/skills/ subfolder. A defined schema for skill and prompt YAML files. One repo you check out and it works regardless of which agentic coding framework your team uses.

We cannot agree on editors and we never will. The same is going to be true for AI coding tools. Accepting that and building a shared config layer instead would be a real win for end users. But no one wants to share the pie. So we get lock-in, and an enshittified landscape.

Agentic frameworks are not better

I played with Spec-kitty. Nothing wrong with it. But a new framework drops every week and I was just looking at Fabro. Dozens of these exist. I cannot keep up, and I will not implement one in a production environment.

Here is why. You invest time setting one up, it works, and then the team behind it quietly gives up. Or it supports Claude but not Pi, so you are forced into their ecosystem anyway. On top of that, the integration story is always painful. We use Jira. Do I now also use theirs? We have CI/CD on GitHub Actions. Does everything run twice because the framework cannot just pull the results? Same question for SonarQube. How does it handle multiple microservices? Legacy systems with outdated documentation?

The answer is usually: badly, or not at all.

What I did instead

I wrote my own lightweight framework, hooked directly into our existing SDLC pipeline. No new tools to introduce. No team buy-in required. No convincing anyone to change how they work.

Maybe these frameworks make sense somewhere. Greenfield projects, small teams, orgs with no existing tooling. But for legacy software teams with established pipelines and practices, they solve a problem you do not have while creating several you did not.