Why Autonomous Software Engineering Requires Rules, Not Just Intelligence
AI agents are becoming increasingly capable.
They can analyze codebases, create files, modify architectures, run tests, investigate failures, interact with APIs, manage infrastructure, and execute increasingly complex engineering workflows.
The trajectory is clear:
AI agents are moving from assistants toward engineering actors.
But there is a fundamental question we need to answer before giving them more autonomy:
What rules should an AI agent follow when it makes engineering decisions?
A more capable agent without stronger engineering constraints does not necessarily produce a better engineering system.
In fact, the opposite can happen.
The more capable the agent becomes, the more important governance becomes.
This is one of the foundational ideas behind NAEOS — Nusantara AI Engineering Operating System.
1. Intelligence Is Not the Same as Engineering Judgment
A powerful AI model can generate an impressive implementation.
But software engineering is not simply the act of producing code.
Engineering decisions involve constraints.
For example:
- Which architecture should be used?
- Which dependency is allowed?
- Which API pattern is mandatory?
- What security model applies?
- What constitutes a breaking change?
- Which database technology is approved?
- What testing coverage is required?
- Which components can communicate?
- What information can an agent access?
- Who is authorized to approve a change?
- When can a deployment happen?
These questions are not solved by code generation alone.
They require engineering judgment within organizational constraints.
Humans already solve this problem through:
Standards
Policies
Architecture Principles
Review Processes
Security Controls
Development Practices
Governance
Organizational Experience
AI agents need an equivalent mechanism.
2. The Missing Contract Between Humans and AI
Imagine an organization gives an AI agent access to a large repository.
The agent receives a task:
"Implement authentication for the new service."
The agent may know how to implement:
- OAuth
- JWT
- session authentication
- API keys
- mTLS
- identity providers
But which one should it choose?
The answer depends on the organization's engineering rules.
Perhaps the organization requires:
External APIs → OAuth 2.1
Service-to-service → mTLS
Internal applications → OIDC
Secrets → Enterprise Secret Manager
Tokens → Short-lived credentials
The model may know these technologies.
But knowing technology is not the same as knowing organizational policy.
This is where an Engineering Constitution becomes useful.
3. What Is an Engineering Constitution?
An Engineering Constitution is a set of high-level principles and non-negotiable engineering rules that define how software should be designed, built, secured, tested, deployed, and maintained.
It acts as a contract between:
Human Engineers
+
AI Agents
+
Engineering Systems
A simplified hierarchy might look like:
Engineering Constitution
↓
Architecture Standards
↓
Engineering Policies
↓
Project Standards
↓
Workflows
↓
Implementation
The constitution establishes the principles.
Policies operationalize those principles.
Workflows enforce them.
Agents execute within them.
4. Why AI Agents Need This
Humans naturally operate within organizational context.
A senior engineer might know:
"We don't introduce a new database unless the architecture team approves it."
Or:
"Every public API must have an OpenAPI contract."
Or:
"Production infrastructure cannot be modified directly."
These rules may never appear in a single prompt.
They are part of the organization's engineering culture.
AI agents do not automatically inherit that culture.
They need it to be explicitly represented.
Therefore:
Organizational engineering culture must become machine-readable.
This is a major shift.
5. From Tribal Knowledge to Machine-Readable Engineering Principles
Many engineering organizations rely on tribal knowledge.
For example:
"Don't touch that service."
"That API is legacy."
"We always use this deployment pattern."
"Security won't approve that dependency."
"That database has a special replication requirement."
"That component cannot be changed without migration planning."
Experienced engineers know these things.
New engineers learn them over time.
AI agents do not.
If these rules remain implicit, every agent starts with an incomplete understanding of the organization.
The Engineering Constitution provides a mechanism to make critical principles explicit.
6. A Constitution Should Define Principles, Not Every Detail
An important architectural distinction is necessary.
The constitution should not become an enormous list of implementation instructions.
It should define stable principles.
For example:
Principle
Production systems must be observable.
The implementation policy might define:
Required:
- structured logging
- metrics
- distributed tracing
- health checks
- alerting
The workflow might define:
Before production deployment:
→ observability validation must pass.
The agent then operates within these constraints.
This creates a hierarchy:
PRINCIPLE
↓
POLICY
↓
STANDARD
↓
WORKFLOW
↓
IMPLEMENTATION
That hierarchy prevents the constitution from becoming a giant configuration file.
7. The NAEOS Constitution Model
A possible NAEOS model can be organized into several constitutional domains.
Engineering Constitution
│
├── Architecture Constitution
├── Security Constitution
├── AI Constitution
├── Testing Constitution
├── Documentation Constitution
├── API Constitution
├── Infrastructure Constitution
├── Data Constitution
├── Reliability Constitution
├── Observability Constitution
└── Governance Constitution
Each domain establishes principles for a particular engineering concern.
8. Architecture Constitution
The Architecture Constitution defines fundamental architectural principles.
For example:
1. Architecture boundaries must be explicit.
2. Dependencies must be intentional.
3. Domain boundaries must be preserved.
4. Infrastructure concerns must not leak into domain logic.
5. Public interfaces must be versioned.
6. Architectural decisions must be documented.
7. Breaking changes require explicit review.
An AI agent implementing a feature should not only know what to build.
It should know which architectural boundaries it must preserve.
9. Security Constitution
The Security Constitution establishes non-negotiable security principles.
For example:
1. Security is mandatory by default.
2. Secrets must never be committed to source control.
3. Least privilege must be enforced.
4. Authentication must use approved mechanisms.
5. Sensitive data must be classified.
6. Production access must be auditable.
7. Security controls must not be bypassed for convenience.
This becomes particularly important as AI agents gain access to tools.
An agent may be technically capable of reading a secret.
That does not mean it should be authorized to do so.
Capability and permission must remain separate.
10. AI Constitution
A particularly important addition for AI-native engineering is the AI Constitution.
Traditional engineering organizations did not need to define rules for autonomous software agents.
AI-native organizations do.
The AI Constitution can define:
Agent Identity
Agent Permissions
Tool Access
Knowledge Access
Execution Boundaries
Human Approval Requirements
Data Handling
Audit Requirements
Escalation Rules
Autonomy Levels
For example:
Level 0
Read-only analysis
Level 1
Generate proposed changes
Level 2
Modify development environment
Level 3
Execute validated workflows
Level 4
Perform controlled deployments
Level 5
Autonomous production operations
Not every agent should receive Level 5 autonomy.
The autonomy level should depend on:
Task Risk
Agent Identity
Environment
Policy
Validation
Human Approval
11. Capability-Based Agent Security
A useful security model is to treat agent capabilities explicitly.
Instead of saying:
"This agent has access to the repository."
Define:
Agent
↓
Capabilities
├── repository.read
├── repository.write
├── tests.execute
├── deployment.prepare
└── deployment.execute
Each capability can have conditions.
For example:
deployment.execute
Allowed:
- staging
Requires:
- approved build
- security scan
- test pass
Forbidden:
- production
Another agent might have:
deployment.execute
Allowed:
- production
Requires:
- human approval
- change ticket
- security validation
- deployment window
This is much more precise than simply granting broad access.
12. The Constitution as a Policy Root
The constitution should sit above individual policies.
Consider:
Engineering Constitution
│
├───────────────┐
▼ ▼
Architecture Policy Security Policy
│ │
▼ ▼
Architecture Rule Security Rule
│ │
└───────┬───────┘
▼
Workflow
│
▼
AI Agent
This creates a policy hierarchy.
When conflicts occur, the system can determine which rule has higher authority.
For example:
Constitution
>
Enterprise Policy
>
Domain Policy
>
Project Policy
>
Local Configuration
The exact hierarchy can vary by organization, but it should be explicit.
13. Policy Conflicts
AI-native systems will inevitably encounter conflicting instructions.
Imagine an agent receives:
Project Instruction:
"Use library X."
Security Policy:
"Library X is prohibited."
Developer Prompt:
"Ignore the restriction for this task."
What should happen?
The answer cannot depend on the model's judgment alone.
There must be an authority model.
For example:
Security Policy
↑
Project Policy
↑
Developer Instruction
↑
User Prompt
The agent should understand that a lower-level instruction cannot override a higher-level policy.
This is one reason why prompt-only AI engineering does not scale.
14. Constitution + Knowledge + Agent
The real power emerges when the constitution is connected to the Knowledge System.
Consider an agent receiving a task.
The system can assemble:
Task
+
Applicable Constitution
+
Applicable Policies
+
Architecture
+
Domain Knowledge
+
Project Context
+
Agent Memory
Then:
Engineering Context
│
┌───────────┼───────────┐
│ │ │
Knowledge Policy Constitution
│ │ │
└───────────┼───────────┘
▼
AI Agent
│
▼
Action
This creates a much more reliable operating model.
15. Engineering Gates
The constitution should not only describe principles.
It should connect to quality gates.
For example:
Task
↓
Planning
↓
Architecture Validation
↓
Security Validation
↓
Implementation
↓
Testing
↓
Policy Validation
↓
Review
↓
Deployment
An agent cannot simply skip a required gate because it believes the change is safe.
The system should enforce the gate.
This is the difference between:
instruction
and
control.
16. Declarative Governance
One of the strongest characteristics of an AI-native engineering system is declarative governance.
Instead of telling every agent:
"Remember to do X."
The organization defines:
X is required.
The system then enforces it.
For example:
policy:
id: security.production-deployment
version: 3.0.0
rules:
require_security_scan: true
require_tests: true
require_approval: true
require_audit: true
scope:
environment:
- production
Now different agents can operate under the same rule.
This produces consistency.
17. The Constitution Should Be Versioned
Engineering principles evolve.
Therefore, the constitution itself must be versioned.
Constitution v1
↓
Constitution v2
↓
Constitution v3
Changes should include:
Version
Change
Reason
Owner
Approval
Effective Date
Impact
Migration Requirements
This provides historical traceability.
It also allows organizations to reproduce the engineering environment that existed at a particular point in time.
18. Constitutional Change Management
Changing an engineering constitution should not be equivalent to editing a README.
A constitutional change can affect:
- developers
- AI agents
- workflows
- CI/CD
- architecture
- security
- compliance
- existing projects
Therefore:
Proposal
↓
Impact Analysis
↓
Review
↓
Approval
↓
Version
↓
Migration
↓
Activation
This is governance as engineering infrastructure.
19. Constitution as an AI Contract
The deeper concept is that the constitution becomes a contract between the organization and its AI agents.
The organization says:
These are our principles.
These are our boundaries.
These are our security requirements.
These are our quality expectations.
These are the actions you may perform.
These are the actions you may not perform.
These are the conditions under which you must ask for human approval.
The agent operates within those boundaries.
This creates a more predictable relationship between autonomy and control.
20. The Human Remains in the Loop — Where It Matters
The goal of governance is not to require human approval for everything.
That would eliminate much of the benefit of autonomous agents.
Instead, human intervention should be proportional to risk.
For example:
| Action | Risk | Approval |
|---|---|---|
| Read source code | Low | None |
| Generate test | Low | None |
| Modify local code | Low | None |
| Modify architecture | Medium | Review |
| Change security policy | High | Approval |
| Modify production infrastructure | High | Approval |
| Rotate production credentials | Critical | Mandatory approval |
This enables risk-based autonomy.
AI agents can operate independently where appropriate while remaining controlled where consequences are significant.
21. From Rules to Engineering Runtime
Once constitutional rules become machine-readable, they can be consumed by runtime systems.
The architecture becomes:
Constitution
↓
Policy Compiler
↓
Policy Runtime
↓
Agent Execution
↓
Policy Evaluation
↓
Allow / Deny / Escalate
This means governance can happen at execution time.
For example:
Agent requests:
production.database.write
The policy engine evaluates:
Agent identity
+
Environment
+
Resource
+
Action
+
Risk
+
Current policy
Result:
DENY
or:
ALLOW
or:
REQUIRE HUMAN APPROVAL
This is a far stronger model than relying on prompts to enforce security.
22. The NAEOS Engineering Control Plane
This is where the broader NAEOS architecture becomes important.
The Engineering Constitution is not isolated.
It connects to:
Governance
↓
Constitution
↓
Knowledge
↓
Policy Engine
↓
Workflow Engine
↓
AI Agents
↓
Validation
↓
Runtime
↓
Audit
The result is an engineering control plane around AI agents.
A simplified architecture:
HUMAN INTENT
│
▼
┌─────────────────┐
│ GOVERNANCE │
└────────┬────────┘
▼
┌─────────────────┐
│ CONSTITUTION │
└────────┬────────┘
▼
┌─────────────────┐
│ KNOWLEDGE │
└────────┬────────┘
▼
┌─────────────────┐
│ POLICY ENGINE │
└────────┬────────┘
▼
┌─────────────────┐
│ WORKFLOW ENGINE │
└────────┬────────┘
▼
┌─────────────────┐
│ AI AGENTS │
└────────┬────────┘
▼
┌─────────────────┐
│ EXECUTION │
└────────┬────────┘
▼
┌─────────────────┐
│ VALIDATION/AUDIT│
└─────────────────┘
23. Why This Becomes More Important With Multi-Agent Systems
Consider a future engineering environment with:
Planner Agent
Coder Agent
Reviewer Agent
Tester Agent
Security Agent
DevOps Agent
Documentation Agent
Each agent has a different responsibility.
Without a common constitution, they may operate according to different assumptions.
The constitution provides a shared engineering contract.
CONSTITUTION
│
┌──────────────┼──────────────┐
▼ ▼ ▼
Planner Coder Security
Agent Agent Agent
│ │ │
└──────────────┼──────────────┘
▼
Shared Rules
│
▼
Engineering
This becomes increasingly important as multi-agent orchestration becomes more autonomous.
24. Constitution + Knowledge + Memory
The three concepts should not be confused.
Constitution
Defines what must be true.
Knowledge
Defines what the organization knows.
Memory
Defines what the system has experienced.
Together:
Constitution
"What must we follow?"
Knowledge
"What do we know?"
Memory
"What have we experienced?"
Then:
Constitution
+
Knowledge
+
Memory
↓
Engineering Context
↓
AI Reasoning
↓
Engineering Action
This provides a much richer foundation for AI agents.
25. The Long-Term Vision
Imagine an AI agent joining an organization for the first time.
Instead of giving it dozens of prompts and asking developers to explain everything manually, the agent connects to the engineering operating system.
It receives:
Organization Constitution
Architecture
Policies
Standards
Domain Knowledge
Project Context
Security Rules
Workflow Rules
Agent Capabilities
Relevant Memory
The agent does not need to "pretend" to be a senior engineer.
It operates inside an environment that encodes many of the rules senior engineers already use.
That is a fundamentally different approach.
26. The Future of AI Engineering Is Not Unrestricted Autonomy
There is a common assumption that the ultimate goal of AI engineering is:
Give agents complete autonomy.
I think the better goal is:
Give agents the right autonomy within the right boundaries.
Autonomy without governance creates risk.
Governance without autonomy creates bureaucracy.
The engineering challenge is to find the correct balance.
AUTONOMY
▲
│
│
┌──────────┼──────────┐
│ │ │
Useful Optimal Risky
│ │ │
└──────────┼──────────┘
│
▼
GOVERNANCE
The objective is not maximum autonomy.
It is controlled autonomy.
27. What NAEOS Is Trying to Build
NAEOS is an exploration of this engineering model.
The objective is to create an environment where:
Humans define intent.
Governance defines boundaries.
The Constitution defines principles.
Knowledge provides context.
Policies define constraints.
Workflows define execution.
AI agents perform engineering tasks.
Quality gates validate results.
Observability measures outcomes.
Memory captures experience.
Knowledge evolves.
This creates a continuous engineering loop:
Intent
↓
Governance
↓
Constitution
↓
Knowledge
↓
Plan
↓
AI Execution
↓
Validation
↓
Outcome
↓
Memory
↓
Knowledge Update
↺
The system becomes capable of learning without losing its engineering principles.
28. The Bigger Question
The important question for the AI engineering industry may not be:
"How autonomous can our agents become?"
A more important question is:
"What engineering system should govern increasingly autonomous agents?"
Because once AI agents can modify real systems, engineering governance can no longer remain implicit.
It must become:
Explicit.
Machine-readable.
Versioned.
Enforceable.
Auditable.
Composable.
AI-native.
That is the purpose of an Engineering Constitution.
Conclusion
AI agents are becoming better at reasoning.
They are becoming better at coding.
They are becoming better at using tools.
They are becoming better at executing complex workflows.
But intelligence alone does not create reliable engineering.
Reliable engineering requires:
Principles.
Constraints.
Policies.
Governance.
Context.
Validation.
Accountability.
As AI agents move from assistants toward autonomous engineering actors, organizations will need a formal mechanism for defining how those agents are allowed to operate.
That mechanism could be an Engineering Constitution.
And this is one of the core ideas behind NAEOS.
Don't just make AI agents more autonomous. Give them an engineering system worthy of that autonomy.
The future of AI-native software engineering will not be defined only by smarter agents.
It will be defined by the systems that surround them.
Top comments (0)