Who Sets the Rules for AI Engineers?
AI Doesn't Just Need Knowledge. It Needs Rules.
The more I build with AI coding agents, the more I think about something we rarely talk about:
What should the AI be allowed to do?
Giving an AI access to your architecture and documentation is useful.
Giving it project memory is useful.
But knowledge alone doesn't guarantee good engineering decisions.
Imagine giving a new engineer access to your entire company's documentation without telling them:
Which principles are mandatory.
Which security practices are non-negotiable.
Which architectural patterns are approved.
Which dependencies are prohibited.
When they need human approval.
What quality gates must pass before deployment.
They might have all the information.
But they still don't have the rules.
I think AI agents face the same problem.
Today, we often put these rules inside prompts:
"Always write tests."
"Don't expose secrets."
"Follow our architecture."
"Use this coding style."
"Ask before making destructive changes."
But these instructions are usually scattered across prompts, README files, configuration files, and tribal knowledge.
That's fragile.
If AI is becoming part of the engineering team, I think engineering principles should become explicit, versioned, and enforceable.
Something closer to an Engineering Constitution.
A set of principles that defines how software should be designed, implemented, tested, secured, documented, and deployed.
And importantly, it shouldn't belong to one AI tool.
It should be independent of the model or coding agent being used.
That's one of the ideas I'm exploring with NAEOS.
The AI agent can change.
The model can change.
The IDE can change.
But the engineering principles shouldn't disappear with them.
Maybe the future isn't:
"Give AI a better prompt."
Maybe it's:
"Give AI a better engineering system."
I'm curious:
What is one engineering rule you would never allow an AI coding agent to violate?
