Your AI Has No Org Chart

Open your AI coding tool. Look at where your instructions live. A system prompt. Custom instructions. Project rules. Maybe a markdown file in the repo root.

Now sort them. Which of those are company standards? Which are team conventions? Which belong to this one project? Which are just your taste?

If they all sit in the same place, you have found the problem.

Everything Is Flat

Most AI coding tools carry one context. One user, one bucket, one set of instructions.

The tool cannot tell the difference between "our company requires explicit null checks" and "I like var." It reads both as true. It applies both with the same confidence. When they disagree, it picks one and never tells you which.

The model is fine. The org chart is missing.

Three Ways This Bites

Company policy loses to personal taste. A developer adds a preference to their AI context. That preference overrides the company standard, and nobody sees it happen until a code review three weeks later.

Personal experiments leak into shared work. A developer tries a new pattern. It works great on their side project. The AI starts applying it to the team's production code. Now there is a pattern in the codebase nobody agreed to and nobody else understands.

There is no governance at all. Twelve developers, twelve AI configurations, twelve readings of your architecture. The code looks like it was written by twelve different people, because it was.

One line covers all three. Your developers have AI. Your organization does not.

The Fix You Reach For

If you have shipped .NET for any length of time, you have built scoped configuration.

appsettings.json sets the base. appsettings.Production.json overrides for the environment. User secrets add developer values. Environment variables win when they need to.

The shape is familiar. Layers, inheritance, overrides. Reach for it and you get four obvious scopes for your AI: company, team, project, person.

That is the right shape. I built it that way first.

It was wrong.

Config Has One Rule, And It Is The Wrong One

Scoped configuration runs on a single rule: the most specific scope wins.

User secrets beat the environment file. The environment file beats the base. Whoever sits closest to the developer takes it.

That rule is correct for a connection string. Now run it on a company coding standard.

The company requires explicit null checks. A developer puts "skip the null checks, they are noisy" in their personal scope. Most-specific-wins says the developer takes it.

You did not build governance. You built a suggestion with extra steps.

Read the opening problem again: company policy loses to personal taste. Copy appsettings.json straight across and that is not a bug you forgot to handle. That is the documented behavior, working as designed.

Real Orgs Solved This Long Ago

I have worked in small companies, medium ones, and spent six years at one of the big four banks. Each had its own hierarchy, and its own rules about who can overrule whom. The developer who has to move fast and the developer handling a break-glass situation do not get the same answer. The scope of authority is never flat.

Your AI is the one place we forgot that.

Two Rules That Point Opposite Ways

Hold two instructions next to each other.

"Use PostgreSQL 16." A project should override this. A developer testing something local should override it again. You want the closest scope to win. Anything else is friction with no payoff.

"Never call eval." Nobody below the company gets to reverse this. Not a team lead in a hurry. Not a developer whose personal instructions happen to load last. If a scope underneath can turn it off, it was never a policy. It was a default with good intentions.

Same four scopes. Opposite directions.

Few teams have designed that part. They argue about which scopes to have. The scopes were never the hard part. The hard part is who can overrule whom, and it is not the same answer for every kind of rule.

The Question To Ask

Take any instruction you have given your AI and ask:

Can a scope below this one override it?

Three things happen when you run it.

Some instructions answer yes, and you feel fine about it. Those are settings. Let the closest scope win and move on.

Some answer no, and you feel a small jolt when you realize the tool would let it happen anyway. Those are your actual standards, and right now they are running on the honor system.

And some you cannot answer at all. Those are the ones to worry about, because an instruction nobody has classified drifts, and it drifts in whatever direction the last person to prompt happened to push it.

Run it on your five most repeated AI instructions this week. My bet is two of them are in the wrong bucket, and one of them is a policy you assumed was being enforced.

Governance Without Bureaucracy

The pushback is the same each time. Add governance and you slow everyone down.

That holds when governance means one rigid rule applied to everything. It stops holding when the direction is chosen per rule.

Most of what a developer touches should let them win. That is the majority of the day, and it should stay frictionless. The small set that must not be overridden is small on purpose. Nobody fills out a form. Nobody files a ticket.

What you lose is the ability to quietly beat a company standard from your personal scope. That was never a feature.

The developer keeps their speed and gains a backstop.

It Needs an Org Chart

Intelligent Engineering is the operating model for engineering organizations in the AI era. One of its pillars: retain context across sessions so work never restarts from scratch. Your standards are context too. They have to outlive any single session, any single developer, and any single prompt. Scope is where that knowledge lives. Direction is what stops it being overwritten by whoever prompted last.

Your AI does not need more features. It does not need a better model. It doesn't even need a bigger context window.

It needs an org chart.

And an org chart is not a list of levels. Anyone can draw four boxes. An org chart tells you who can overrule whom.

If you want the short version, the video is on YouTube.

If you ran the question and did not like your answers, that is worth a conversation. Book the Intelligent Engineering Assessment. It is free, and it is two calls. The first call is a diagnosis. I learn how your team builds today and where the drift is coming from. The second call is a prescription: the best path forward I can see, and whether I have a role in it. Sometimes I do not, and I will tell you so.

Curious how this site was built?
Watch the 5-minute walkthrough on YouTube →