Back in 2008, I joined a team of architects building what we called a framework. The goal was to improve quality across development teams by giving everyone the same way of building software.

When the pilot project started, productivity did not improve. Developers felt constrained, creativity suffered, and employee turnover increased. Years later, I helped build another framework for internet banking systems. The same story repeated itself.

Watching the recent excitement around AI-assisted development and .md files brought these memories back. I can't help but wonder if we are still trying to solve the same problem, just with different tools.

The goal never changed

The goal behind frameworks was about quality assurance. If every developer followed the same approach, the software would become easier to maintain, and less dependent on individual talent.

Today, I see the same goal behind .md files, AI workflows, skills, and instructions. We are trying to capture experience and share it across teams so people do not have to rediscover the same lessons over and over again.

There is nothing wrong with that. In fact, some of the best engineering organizations are built on shared practices. The question is how far we should take them before they start getting in the way.

This time we are constraining AI Agents

The main difference today is that we are guiding AI agents.

We create instructions that apply to every session. We create workflows that define the steps to accomplish a task. We create skills that capture experience that can be reused across projects. The goal is to improve quality and consistency.

In many ways, this is more powerful than the frameworks we built years ago. The flexibility is much higher with md files.

Still, I think we should be careful. As human beings, we have a tendency to take good ideas to the extreme.

The token story feels familiar

Meet ai token consumption.

A few months ago, companies were encouraging everyone to use AI as much as possible. Experiment with it. Integrate it into your daily work. The message was: use more.

Then the bills arrived.

Recently, we received an email showing the top token consumers in the company. As a team, we had consumed roughly 25% of our quota in just two days. Suddenly, everyone started paying attention to every prompt they wrote.

The whole thing reminds me of the cloud story. First comes the excitement. Then comes the usage report. Then comes the meeting about costs.

The reuse trap

Throughout my career, I have seen many teams start with the best intentions. Team A and Team B are building similar systems. They discover some business logic that can be shared. The obvious solution is to create a shared NuGet package so nobody duplicates code.

A few months later, that shared package becomes a dependency for multiple teams. Every change requires coordination. Every release affects several projects.

This does not mean shared packages are bad. Some things are stable enough to deserve sharing. Logging, security, and pub/sub infrastructure are good examples. But sharing business logic? A road that does not end well.

Over time, I learned to prefer low coupling over eliminating every piece of duplication. A little duplication is often cheaper than a dependency that everybody is afraid to touch.

The Meta repository problem

This is why I become nervous when I hear discussions about creating a central repository for sharing .md files across every service.

At first, the idea sounds reasonable. Put the workflows, skills, and instructions in one place so everyone can benefit from them.

Sooner or later, one team wants to change a workflow. Another team depends on the existing version. A third team has different needs altogether. Before long, somebody becomes responsible for approving every change, and that person slowly turns into a bottleneck.

I would rather see some duplication between teams than create a system where every product evolves at the speed of a central repository.

Going to the extreme

What worries me is our tendency to take a good idea and push it further than it should go.

We have done this with frameworks. We have done it with inheritance. We have done it with shared libraries. We have done it with microservices. In each case, the original idea solved a real problem. The trouble started when we assumed more of it must be better.

The same risk exists here: the goal should not be to make every developer, every AI agent, and every team work exactly the same way. The goal should be to share experience while preserving enough flexibility for people to solve problems in their own context.

The take

I have nothing against AI-assisted development. In fact, I think the ability to share knowledge through workflows, skills, and instructions is one of the most interesting things happening in software development today.

I just hope we remember a lesson that many of us learned years ago. Standardization and quality assurance are valuable, but they come with a cost. The moment they start reducing flexibility, and creativity, the benefits begin to disappear.

People making these decisions need to possess a balanced character.