AI Coding Agents Are Writing the Code—Who Owns the Architecture?

For decades, software architecture was closely tied to the people writing the software.

Developers chose programming languages, frameworks, databases, integration patterns, deployment models, authentication mechanisms, caching strategies, and service boundaries. Architects documented those decisions, and engineering teams implemented them.

AI coding agents are changing that relationship.

Modern coding agents can inspect repositories, create and modify files, execute commands, run tests, diagnose failures, interact with development tools, and iterate on implementation with relatively little human intervention. In other words, they are moving beyond code completion into software engineering workflows.

A 2026 JetBrains survey of more than 15,000 professional developers found that 90% were using AI coding agents at work at least weekly, while 68% were using them daily.

That creates a more interesting question than whether AI can write code:

If an AI coding agent makes dozens of implementation decisions while building a system, who actually owns the architecture?

The answer is still the engineering organization.

But the way architecture is controlled, reviewed, documented, and enforced needs to change.

AI Coding Agents Are Not Just Autocomplete

The first generation of AI programming assistants primarily helped developers write individual pieces of code.

A developer might type:

public async Task<User>

and an AI assistant would suggest the remainder of the method.

That was useful, but the developer still made most of the important decisions.

Modern coding agents operate at a different level.

A developer can provide an instruction such as:

Add multi-tenant authentication to the ASP.NET Core API.
Use the existing identity infrastructure.
Add integration tests.
Update the database schema if necessary.
Run the test suite and fix any failures.

An agent may then:

Inspect the repository.
Identify authentication components.
Find database entities.
Inspect configuration.
Modify multiple files.
Add migrations.
Implement middleware.
Create tests.
Execute the application.
Diagnose failures.
Modify the implementation.
Run tests again.
Produce a commit or pull request.

That is no longer autocomplete.

It is agentic software development.

The fundamental loop looks roughly like this:

Human Goal
    ↓
AI Agent
    ↓
Repository / Context
    ↓
Plan
    ↓
Tool Calls
    ↓
Code Changes
    ↓
Build / Test
    ↓
Observations
    ↓
Agent Iteration
    ↓
Pull Request
    ↓
Human Review

The critical architectural question appears in the middle:

Who decides what the agent is allowed to change?

The Architecture Problem Nobody Talks About

Writing code is not the same as designing a system.

An AI agent can generate a working API while making poor architectural decisions.

For example, suppose an agent is asked to add customer notifications.

It could choose:

API
 ↓
NotificationService
 ↓
Email Provider

That might work.

But another implementation might introduce:

API
 ↓
Message Queue
 ↓
Notification Worker
 ↓
Notification Service
 ↓
Email Provider

Both can satisfy the functional requirement.

But they have very different consequences for:

Scalability
Reliability
Cost
Operational complexity
Failure handling
Observability
Deployment
Future integrations

The agent may optimize for getting the requested task working.

The architect must optimize for the system that will exist six months from now.

This distinction becomes increasingly important as agents take on larger tasks.

Recent research specifically examining AI coding agents argues that agents can make implicit architectural decisions while scaffolding infrastructure, selecting frameworks, and wiring integrations. The authors describe this emerging phenomenon as architecture being shaped by prompts rather than deliberate architectural review.

The Rise of "Vibe Architecting"

There is an emerging failure mode that can be described as vibe architecting.

The idea is simple.

A developer gives an agent a high-level instruction:

"Build a scalable SaaS application with authentication, billing, notifications, analytics, and an admin dashboard."

The agent makes hundreds of small decisions.

Which framework?

Which database?

How should services communicate?

Where should business logic live?

Should the application use background jobs?

Should caching be introduced?

How should authentication state be handled?

How should APIs be versioned?

How should errors propagate?

What belongs in the database?

What belongs in application code?

Each individual decision may look reasonable.

The problem is that the developer may not explicitly review the aggregate architecture.

The resulting system can therefore be functional without being intentionally designed.

That is the architectural danger.

AI Is Good at Local Decisions. Architecture Is About Global Decisions.

This is one of the most important distinctions developers should understand.

AI coding agents are increasingly good at local implementation tasks.

For example:

Write a repository method.
Add an API endpoint.
Create a DTO.
Add unit tests.
Fix a compiler error.
Refactor duplicated code.
Update a database migration.
Add logging.

Architecture deals with global constraints.

For example:

Should this be a monolith or microservices?
Where should tenant isolation occur?
What is the system's source of truth?
Which components can communicate?
Where does authentication terminate?
How should data ownership be defined?
What happens when a downstream dependency fails?
What are the consistency requirements?
How will the system scale?
What are the security boundaries?

The difference can be summarized as:

AI Coding Task	Architectural Decision
Create an endpoint	Define service boundaries
Write SQL	Design data ownership
Add caching	Define caching strategy
Add authentication	Define security architecture
Create a queue	Define asynchronous architecture
Add retries	Define failure-handling policy
Generate tests	Define quality strategy
Create Docker files	Define deployment architecture

AI can assist with both columns.

But the second column requires system-level accountability.

So Who Owns the Architecture?

The short answer:

Humans own the architecture. AI agents participate in implementing it.

That does not mean developers should manually write every architectural component.

It means the engineering organization must establish boundaries within which agents operate.

A useful model is:

Engineering Leadership
        ↓
Architecture Principles
        ↓
System Design
        ↓
AI Agent Constraints
        ↓
Agent Implementation
        ↓
Automated Verification
        ↓
Human Architectural Review

The agent becomes an extremely productive implementation layer.

It does not become the final authority.

The Developer's Role Is Changing

The biggest misconception about AI coding agents is that developers will simply disappear.

The more realistic transformation is that the nature of software engineering work changes.

Developers historically spent substantial time doing:

Boilerplate implementation
CRUD development
Test writing
Refactoring
Documentation
Debugging
Code search
Configuration

Agents can increasingly perform many of these tasks.

That shifts human attention toward:

Architecture
Requirements
System design
Trade-off analysis
Security
Reliability
Verification
Product decisions
Agent orchestration

Anthropic's 2026 analysis similarly describes engineering moving toward higher-level architecture and strategic decision-making as agents take on more tactical implementation work.

The developer does not necessarily become less important.

The developer becomes responsible for more consequential decisions.

Architecture as a Contract for AI Agents

One of the most useful changes engineering teams can make is to treat architecture as an explicit contract.

Instead of telling an agent:

"Build a customer management API."

Give it constraints.

For example:

Architecture Requirements

- ASP.NET Core 10
- PostgreSQL
- Entity Framework Core
- REST API
- Clean Architecture
- Domain logic must not depend on infrastructure
- Authentication through existing identity service
- No direct database access from controllers
- All external calls must use typed clients
- All write operations require audit logging
- Integration tests required for new endpoints

Now the agent is not inventing the architecture.

It is implementing within an architectural boundary.

This distinction is critical.

Architecture Decision Records Become More Important

Architecture Decision Records, or ADRs, can become particularly valuable in AI-assisted development.

An ADR might state:

Decision:
Use PostgreSQL as the transactional system of record.

Reason:
The application requires relational consistency,
transaction support, and complex reporting queries.

Rejected:
MongoDB

Reason:
The current domain has strong relational dependencies
and transactional requirements.

Constraint:
All persistent business entities must use PostgreSQL.

Now the agent has context.

Without this information, an agent may make a technically valid but strategically inconsistent choice.

ADR files can therefore become part of the agent's working context.

For example:

/docs/architecture/
/docs/architecture/ADR-001-database.md
/docs/architecture/ADR-002-authentication.md
/docs/architecture/ADR-003-messaging.md

A coding agent can inspect those documents before modifying the system.

The Repository Becomes Part of the Architecture Specification

Traditional architecture documentation often lives separately from source code.

AI coding agents change that equation.

An agent can inspect:

Source code
README files
Architecture documentation
ADRs
Tests
CI configuration
API specifications
Infrastructure definitions
Coding standards
Dependency manifests

That means the repository itself can become a machine-readable engineering specification.

A mature AI-native repository might contain:

/
├── src/
├── tests/
├── docs/
│   ├── architecture/
│   ├── ADRs/
│   └── API/
├── .github/
│   └── workflows/
├── AGENTS.md
├── README.md
├── CONTRIBUTING.md
└── SECURITY.md

The important idea is that architecture should be discoverable by both humans and agents.

AGENTS.md and Repository-Level Instructions

One emerging practice is maintaining explicit instruction files for coding agents.

A repository might include:

AGENTS.md

with rules such as:

# Engineering Rules

## Architecture

Use Clean Architecture.

Controllers must not contain business logic.

Domain projects must not reference infrastructure projects.

## Database

Use Entity Framework Core.

Do not modify production migrations without review.

## Testing

Every new business capability requires unit tests.

Every new API endpoint requires integration tests.

## Security

Never hard-code credentials.

Never log access tokens.

Never disable authentication to make tests pass.

## Pull Requests

Explain architectural changes separately from implementation changes.

This changes the agent's role.

The agent is no longer operating against an empty context.

It is operating inside an engineering system with explicit rules.

The New Architecture Stack

AI-native software development introduces an additional layer to traditional architecture.

A conventional stack might look like:

Business Requirements
        ↓
Architecture
        ↓
Application
        ↓
Infrastructure
        ↓
Deployment

An AI-assisted stack increasingly looks like:

Business Requirements
        ↓
Architecture Principles
        ↓
Agent Instructions
        ↓
Context / Repository
        ↓
AI Coding Agent
        ↓
Tools
        ↓
Implementation
        ↓
Automated Verification
        ↓
Human Review
        ↓
Deployment

The new components—agent instructions, context, tool permissions, and verification—become part of the engineering architecture.

Tool Access Is an Architectural Decision

Coding agents can execute tools.

That creates another important question:

What should an AI agent be allowed to do?

Consider these permissions:

Read source code       → Low risk
Edit source code       → Medium risk
Run tests              → Low risk
Run local build        → Low risk
Create Git branch      → Medium risk
Open pull request      → Medium risk
Modify database        → High risk
Deploy application     → High risk
Access production DB   → Very high risk
Delete cloud resource  → Extremely high risk

Not every agent should have every permission.

This is where least privilege becomes important for AI agents just as it is for human and service identities.

AI Agents Need Sandboxes

A production engineering environment should not assume that an AI agent can safely execute arbitrary commands.

A safer architecture can provide:

AI Agent
   ↓
Sandbox
   ↓
Temporary Workspace
   ↓
Test Environment
   ↓
Automated Verification
   ↓
Pull Request
   ↓
Human Approval
   ↓
Production

This separates experimentation from production infrastructure.

Agent platforms are already treating workspace isolation, tool execution, control planes, and security posture as explicit architectural concerns.

Pull Requests Become More Important, Not Less

Some people assume AI coding agents eliminate code review.

The opposite is more likely.

When an agent generates more code, review becomes a higher-leverage activity.

But reviewing 5,000 AI-generated lines line-by-line is not realistic.

The review process therefore needs layers.

Layer 1: Automated checks

Compilation
Unit tests
Integration tests
Static analysis
Dependency scanning
Security scanning
Formatting
Type checking

Layer 2: AI-assisted review

Another model or agent can analyze:

Changed files
Architectural violations
Security risks
Missing tests
API inconsistencies
Potential regressions

Layer 3: Human review

Humans focus on:

Architecture
Business correctness
Security boundaries
Data ownership
Long-term maintainability
Operational consequences

The human review becomes less about:

"Did the agent write valid C#?"

and more about:

"Did the agent change the system in a way we actually want?"

Testing Becomes the Agent's Feedback Loop

AI agents work best when they can observe objective feedback.

For example:

Implement Feature
       ↓
Run Tests
       ↓
Tests Fail
       ↓
Inspect Failure
       ↓
Modify Code
       ↓
Run Tests Again
       ↓
Pass

This is effectively a feedback loop.

The better the test suite, the better the agent's ability to work autonomously.

That means organizations adopting coding agents should invest heavily in:

Unit tests
Integration tests
Contract tests
End-to-end tests
Static analysis
Security testing
Performance tests

AI coding does not eliminate engineering discipline.

It makes engineering discipline more valuable.

The Architecture Review Checklist for AI-Generated Code

Before merging substantial AI-generated changes, architects and senior developers should ask:

Architecture

Does this change follow the existing architecture?
Does it introduce unnecessary dependencies?
Does it create inappropriate coupling?
Are service boundaries still clear?

Data

Is data ownership correct?
Are transactions handled appropriately?
Has the database schema changed unnecessarily?
Are migrations safe?

Security

Are authorization boundaries preserved?
Are secrets protected?
Is sensitive data logged?
Can the new functionality be abused?

Reliability

What happens when dependencies fail?
Are retries appropriate?
Could retry logic create duplicate operations?
Is idempotency required?

Performance

Does the implementation introduce unnecessary database calls?
Could it create N+1 queries?
Is caching appropriate?
Will this scale with traffic?

Maintainability

Can another developer understand the generated code?
Does it follow existing conventions?
Has unnecessary abstraction been introduced?
Is the implementation more complicated than necessary?

Architecture Tests May Become More Important

Traditional tests verify behavior.

Architecture tests verify structure.

For example, in a .NET application, architectural tests can enforce rules such as:

Domain
  ↓
Application
  ↓
Infrastructure

while preventing:

Domain
  ↓
Infrastructure

This matters because an AI agent may unintentionally introduce dependencies that violate architectural principles.

Tools such as architecture-testing frameworks can turn architectural decisions into executable rules.

That is a powerful idea:

If an architecture rule matters, make the build enforce it.

Don't rely entirely on documentation.

The New Role of the Software Architect

The software architect's job is likely to become less about drawing diagrams and more about creating systems that constrain and guide intelligent implementation agents.

The architect increasingly needs to define:

System boundaries
Architectural principles
Technology standards
Security policies
Data ownership
Integration patterns
Agent permissions
Testing requirements
Deployment boundaries
Observability requirements

The architect becomes, in part, an orchestrator of both humans and AI agents.

What Happens to Junior Developers?

This is one of the harder questions.

AI agents can already perform many tasks traditionally assigned to junior developers:

Boilerplate
Simple CRUD endpoints
Basic tests
Documentation
Refactoring
Configuration
Bug fixes

That creates a potential problem.

Junior developers traditionally learned architecture by implementing small features and gradually understanding why systems were designed a certain way.

If an agent does all the implementation, junior engineers may receive fewer opportunities to develop that intuition.

Recent research has even described a potential "knowledge debt" problem: developers can become productive with AI while accumulating changes they do not fully understand, potentially weakening the learning that normally happens through hands-on problem solving.

The answer should not be to stop using AI.

Instead, organizations should deliberately use agents as teaching systems.

For example:

"Implement this feature, but explain the architectural trade-offs before making changes."

Or:

"Propose three designs and explain why you recommend one."

This turns AI from an implementation shortcut into an engineering mentor.

Architecture Skills Become More Valuable

If AI can produce implementation quickly, the scarce skill becomes knowing what should be built and how it should fit into the larger system.

That increases the value of skills such as:

Distributed systems
Database design
Security architecture
Cloud architecture
API design
Domain modeling
Reliability engineering
Performance engineering
Observability
Systems thinking

A developer who understands these areas can supervise AI far more effectively than someone who only knows how to generate code.

The Danger of Measuring AI Productivity by Lines of Code

One of the worst metrics for AI-assisted development is:

Lines of code generated.

More generated code does not necessarily mean more business value.

An agent can generate 20,000 lines of code quickly.

But if the system becomes:

Harder to maintain
More expensive
Less secure
Over-engineered
Poorly documented
Difficult to deploy

then the productivity gain is questionable.

Better metrics include:

Lead time
Deployment frequency
Defect rate
Change failure rate
Mean time to recovery
Test coverage
Review time
Incident rate
Cost per feature
Business outcome

The objective should be better software, not more code.

AI Coding Agents Will Change Architecture Reviews

Traditional architecture reviews often happen before implementation.

AI-assisted development creates a second requirement:

continuous architecture review.

Why?

Because an agent can introduce architectural changes incrementally.

One pull request adds a new dependency.

Another adds a queue.

Another adds a caching layer.

Another introduces an external API.

Individually, each change may be reasonable.

Collectively, the architecture may drift.

This means teams should periodically analyze the architecture as it exists, not just the architecture that was originally designed.

A Better AI-Native Development Workflow

A mature workflow could look like this:

1. Define business requirement
          ↓
2. Human creates architectural constraints
          ↓
3. Agent proposes implementation plan
          ↓
4. Human approves plan
          ↓
5. Agent implements
          ↓
6. Automated tests execute
          ↓
7. Agent fixes failures
          ↓
8. Static/security/architecture checks
          ↓
9. AI-assisted code review
          ↓
10. Human engineering review
          ↓
11. Pull request approval
          ↓
12. CI/CD deployment
          ↓
13. Production monitoring

This model gives the AI substantial autonomy without giving up engineering accountability.

The Future: Developers Become System Directors

The most useful way to think about AI coding agents is not:

"AI replaces programmers."

It is:

AI changes what programming work consists of.

The implementation layer is becoming increasingly automated.

The responsibility for defining the system remains human.

A future engineering team might look like:

Product Manager
      ↓
Architect
      ↓
AI Planning Agent
      ↓
 ┌───────────────┐
 │ Coding Agent  │
 │ Test Agent    │
 │ Review Agent  │
 │ Security Agent│
 └───────────────┘
      ↓
Human Engineers
      ↓
Production

The humans become responsible for direction, constraints, validation, and accountability.

The agents become responsible for increasingly large portions of implementation.

Final Answer: Who Owns the Architecture?

Humans do.

AI coding agents can write code, modify repositories, run tests, debug failures, create pull requests, and increasingly participate across the software development lifecycle.

But architecture is not simply the sum of the code.

Architecture is the collection of decisions about:

Boundaries
Data
Security
Reliability
Scalability
Dependencies
Deployment
Integration
Maintainability
Business requirements

Those decisions have consequences that extend far beyond the current coding task.

The engineering challenge of the AI era therefore isn't preventing AI from writing code.

It is building an engineering environment in which AI can write a lot of code without silently becoming the architect.

The winning organizations will not necessarily be the ones that give agents the most autonomy.

They will be the ones that give agents the right autonomy, the right context, the right tools, strong verification, and clearly defined architectural boundaries.

AI can increasingly be the implementation engine.

But humans still need to decide what system should exist when the code is finished.

For decades, software architecture was closely tied to the people writing the software.

AI coding agents are changing that relationship.

A 2026 JetBrains survey of more than 15,000 professional developers found that 90% were using AI coding agents at work at least weekly, while 68% were using them daily.

That creates a more interesting question than whether AI can write code:

If an AI coding agent makes dozens of implementation decisions while building a system, who actually owns the architecture?

The answer is still the engineering organization.

But the way architecture is controlled, reviewed, documented, and enforced needs to change.

AI Coding Agents Are Not Just Autocomplete

The first generation of AI programming assistants primarily helped developers write individual pieces of code.

A developer might type:

public async Task<User>

and an AI assistant would suggest the remainder of the method.

That was useful, but the developer still made most of the important decisions.

Modern coding agents operate at a different level.

A developer can provide an instruction such as:

Add multi-tenant authentication to the ASP.NET Core API.
Use the existing identity infrastructure.
Add integration tests.
Update the database schema if necessary.
Run the test suite and fix any failures.

An agent may then:

Inspect the repository.
Identify authentication components.
Find database entities.
Inspect configuration.
Modify multiple files.
Add migrations.
Implement middleware.
Create tests.
Execute the application.
Diagnose failures.
Modify the implementation.
Run tests again.
Produce a commit or pull request.

That is no longer autocomplete.

It is agentic software development.

The fundamental loop looks roughly like this:

Human Goal
    ↓
AI Agent
    ↓
Repository / Context
    ↓
Plan
    ↓
Tool Calls
    ↓
Code Changes
    ↓
Build / Test
    ↓
Observations
    ↓
Agent Iteration
    ↓
Pull Request
    ↓
Human Review

The critical architectural question appears in the middle:

Who decides what the agent is allowed to change?

The Architecture Problem Nobody Talks About

Writing code is not the same as designing a system.

An AI agent can generate a working API while making poor architectural decisions.

For example, suppose an agent is asked to add customer notifications.

It could choose:

API
 ↓
NotificationService
 ↓
Email Provider

That might work.

But another implementation might introduce:

API
 ↓
Message Queue
 ↓
Notification Worker
 ↓
Notification Service
 ↓
Email Provider

Both can satisfy the functional requirement.

But they have very different consequences for:

Scalability
Reliability
Cost
Operational complexity
Failure handling
Observability
Deployment
Future integrations

The agent may optimize for getting the requested task working.

The architect must optimize for the system that will exist six months from now.

This distinction becomes increasingly important as agents take on larger tasks.

The Rise of "Vibe Architecting"

There is an emerging failure mode that can be described as vibe architecting.

The idea is simple.

A developer gives an agent a high-level instruction:

"Build a scalable SaaS application with authentication, billing, notifications, analytics, and an admin dashboard."

The agent makes hundreds of small decisions.

Which framework?

Which database?

How should services communicate?

Where should business logic live?

Should the application use background jobs?

Should caching be introduced?

How should authentication state be handled?

How should APIs be versioned?

How should errors propagate?

What belongs in the database?

What belongs in application code?

Each individual decision may look reasonable.

The problem is that the developer may not explicitly review the aggregate architecture.

The resulting system can therefore be functional without being intentionally designed.

That is the architectural danger.

AI Is Good at Local Decisions. Architecture Is About Global Decisions.

This is one of the most important distinctions developers should understand.

AI coding agents are increasingly good at local implementation tasks.

For example:

Write a repository method.
Add an API endpoint.
Create a DTO.
Add unit tests.
Fix a compiler error.
Refactor duplicated code.
Update a database migration.
Add logging.

Architecture deals with global constraints.

For example:

Should this be a monolith or microservices?
Where should tenant isolation occur?
What is the system's source of truth?
Which components can communicate?
Where does authentication terminate?
How should data ownership be defined?
What happens when a downstream dependency fails?
What are the consistency requirements?
How will the system scale?
What are the security boundaries?

The difference can be summarized as:

AI Coding Task	Architectural Decision
Create an endpoint	Define service boundaries
Write SQL	Design data ownership
Add caching	Define caching strategy
Add authentication	Define security architecture
Create a queue	Define asynchronous architecture
Add retries	Define failure-handling policy
Generate tests	Define quality strategy
Create Docker files	Define deployment architecture

AI can assist with both columns.

But the second column requires system-level accountability.

So Who Owns the Architecture?

The short answer:

Humans own the architecture. AI agents participate in implementing it.

That does not mean developers should manually write every architectural component.

It means the engineering organization must establish boundaries within which agents operate.

A useful model is:

Engineering Leadership
        ↓
Architecture Principles
        ↓
System Design
        ↓
AI Agent Constraints
        ↓
Agent Implementation
        ↓
Automated Verification
        ↓
Human Architectural Review

The agent becomes an extremely productive implementation layer.

It does not become the final authority.

The Developer's Role Is Changing

The biggest misconception about AI coding agents is that developers will simply disappear.

The more realistic transformation is that the nature of software engineering work changes.

Developers historically spent substantial time doing:

Boilerplate implementation
CRUD development
Test writing
Refactoring
Documentation
Debugging
Code search
Configuration

Agents can increasingly perform many of these tasks.

That shifts human attention toward:

Architecture
Requirements
System design
Trade-off analysis
Security
Reliability
Verification
Product decisions
Agent orchestration

Anthropic's 2026 analysis similarly describes engineering moving toward higher-level architecture and strategic decision-making as agents take on more tactical implementation work.

The developer does not necessarily become less important.

The developer becomes responsible for more consequential decisions.

Architecture as a Contract for AI Agents

One of the most useful changes engineering teams can make is to treat architecture as an explicit contract.

Instead of telling an agent:

"Build a customer management API."

Give it constraints.

For example:

Architecture Requirements

- ASP.NET Core 10
- PostgreSQL
- Entity Framework Core
- REST API
- Clean Architecture
- Domain logic must not depend on infrastructure
- Authentication through existing identity service
- No direct database access from controllers
- All external calls must use typed clients
- All write operations require audit logging
- Integration tests required for new endpoints

Now the agent is not inventing the architecture.

It is implementing within an architectural boundary.

This distinction is critical.

Architecture Decision Records Become More Important

Architecture Decision Records, or ADRs, can become particularly valuable in AI-assisted development.

An ADR might state:

Decision:
Use PostgreSQL as the transactional system of record.

Reason:
The application requires relational consistency,
transaction support, and complex reporting queries.

Rejected:
MongoDB

Reason:
The current domain has strong relational dependencies
and transactional requirements.

Constraint:
All persistent business entities must use PostgreSQL.

Now the agent has context.

Without this information, an agent may make a technically valid but strategically inconsistent choice.

ADR files can therefore become part of the agent's working context.

For example:

/docs/architecture/
/docs/architecture/ADR-001-database.md
/docs/architecture/ADR-002-authentication.md
/docs/architecture/ADR-003-messaging.md

A coding agent can inspect those documents before modifying the system.

The Repository Becomes Part of the Architecture Specification

Traditional architecture documentation often lives separately from source code.

AI coding agents change that equation.

An agent can inspect:

Source code
README files
Architecture documentation
ADRs
Tests
CI configuration
API specifications
Infrastructure definitions
Coding standards
Dependency manifests

That means the repository itself can become a machine-readable engineering specification.

A mature AI-native repository might contain:

/
├── src/
├── tests/
├── docs/
│   ├── architecture/
│   ├── ADRs/
│   └── API/
├── .github/
│   └── workflows/
├── AGENTS.md
├── README.md
├── CONTRIBUTING.md
└── SECURITY.md

The important idea is that architecture should be discoverable by both humans and agents.

AGENTS.md and Repository-Level Instructions

One emerging practice is maintaining explicit instruction files for coding agents.

A repository might include:

AGENTS.md

with rules such as:

# Engineering Rules

## Architecture

Use Clean Architecture.

Controllers must not contain business logic.

Domain projects must not reference infrastructure projects.

## Database

Use Entity Framework Core.

Do not modify production migrations without review.

## Testing

Every new business capability requires unit tests.

Every new API endpoint requires integration tests.

## Security

Never hard-code credentials.

Never log access tokens.

Never disable authentication to make tests pass.

## Pull Requests

Explain architectural changes separately from implementation changes.

This changes the agent's role.

The agent is no longer operating against an empty context.

It is operating inside an engineering system with explicit rules.

The New Architecture Stack

AI-native software development introduces an additional layer to traditional architecture.

A conventional stack might look like:

Business Requirements
        ↓
Architecture
        ↓
Application
        ↓
Infrastructure
        ↓
Deployment

An AI-assisted stack increasingly looks like:

Business Requirements
        ↓
Architecture Principles
        ↓
Agent Instructions
        ↓
Context / Repository
        ↓
AI Coding Agent
        ↓
Tools
        ↓
Implementation
        ↓
Automated Verification
        ↓
Human Review
        ↓
Deployment

The new components—agent instructions, context, tool permissions, and verification—become part of the engineering architecture.

Tool Access Is an Architectural Decision

Coding agents can execute tools.

That creates another important question:

What should an AI agent be allowed to do?

Consider these permissions:

Read source code       → Low risk
Edit source code       → Medium risk
Run tests              → Low risk
Run local build        → Low risk
Create Git branch      → Medium risk
Open pull request      → Medium risk
Modify database        → High risk
Deploy application     → High risk
Access production DB   → Very high risk
Delete cloud resource  → Extremely high risk

Not every agent should have every permission.

This is where least privilege becomes important for AI agents just as it is for human and service identities.

AI Agents Need Sandboxes

A production engineering environment should not assume that an AI agent can safely execute arbitrary commands.

A safer architecture can provide:

AI Agent
   ↓
Sandbox
   ↓
Temporary Workspace
   ↓
Test Environment
   ↓
Automated Verification
   ↓
Pull Request
   ↓
Human Approval
   ↓
Production

This separates experimentation from production infrastructure.

Agent platforms are already treating workspace isolation, tool execution, control planes, and security posture as explicit architectural concerns.

Pull Requests Become More Important, Not Less

Some people assume AI coding agents eliminate code review.

The opposite is more likely.

When an agent generates more code, review becomes a higher-leverage activity.

But reviewing 5,000 AI-generated lines line-by-line is not realistic.

The review process therefore needs layers.

Layer 1: Automated checks

Compilation
Unit tests
Integration tests
Static analysis
Dependency scanning
Security scanning
Formatting
Type checking

Layer 2: AI-assisted review

Another model or agent can analyze:

Changed files
Architectural violations
Security risks
Missing tests
API inconsistencies
Potential regressions

Layer 3: Human review

Humans focus on:

Architecture
Business correctness
Security boundaries
Data ownership
Long-term maintainability
Operational consequences

The human review becomes less about:

"Did the agent write valid C#?"

and more about:

"Did the agent change the system in a way we actually want?"

Testing Becomes the Agent's Feedback Loop

AI agents work best when they can observe objective feedback.

For example:

Implement Feature
       ↓
Run Tests
       ↓
Tests Fail
       ↓
Inspect Failure
       ↓
Modify Code
       ↓
Run Tests Again
       ↓
Pass

This is effectively a feedback loop.

The better the test suite, the better the agent's ability to work autonomously.

That means organizations adopting coding agents should invest heavily in:

Unit tests
Integration tests
Contract tests
End-to-end tests
Static analysis
Security testing
Performance tests

AI coding does not eliminate engineering discipline.

It makes engineering discipline more valuable.

The Architecture Review Checklist for AI-Generated Code

Before merging substantial AI-generated changes, architects and senior developers should ask:

Architecture

Does this change follow the existing architecture?
Does it introduce unnecessary dependencies?
Does it create inappropriate coupling?
Are service boundaries still clear?

Data

Is data ownership correct?
Are transactions handled appropriately?
Has the database schema changed unnecessarily?
Are migrations safe?

Security

Are authorization boundaries preserved?
Are secrets protected?
Is sensitive data logged?
Can the new functionality be abused?

Reliability

What happens when dependencies fail?
Are retries appropriate?
Could retry logic create duplicate operations?
Is idempotency required?

Performance

Does the implementation introduce unnecessary database calls?
Could it create N+1 queries?
Is caching appropriate?
Will this scale with traffic?

Maintainability

Can another developer understand the generated code?
Does it follow existing conventions?
Has unnecessary abstraction been introduced?
Is the implementation more complicated than necessary?

Architecture Tests May Become More Important

Traditional tests verify behavior.

Architecture tests verify structure.

For example, in a .NET application, architectural tests can enforce rules such as:

Domain
  ↓
Application
  ↓
Infrastructure

while preventing:

Domain
  ↓
Infrastructure

This matters because an AI agent may unintentionally introduce dependencies that violate architectural principles.

Tools such as architecture-testing frameworks can turn architectural decisions into executable rules.

That is a powerful idea:

If an architecture rule matters, make the build enforce it.

Don't rely entirely on documentation.

The New Role of the Software Architect

The software architect's job is likely to become less about drawing diagrams and more about creating systems that constrain and guide intelligent implementation agents.

The architect increasingly needs to define:

System boundaries
Architectural principles
Technology standards
Security policies
Data ownership
Integration patterns
Agent permissions
Testing requirements
Deployment boundaries
Observability requirements

The architect becomes, in part, an orchestrator of both humans and AI agents.

What Happens to Junior Developers?

This is one of the harder questions.

AI agents can already perform many tasks traditionally assigned to junior developers:

Boilerplate
Simple CRUD endpoints
Basic tests
Documentation
Refactoring
Configuration
Bug fixes

That creates a potential problem.

Junior developers traditionally learned architecture by implementing small features and gradually understanding why systems were designed a certain way.

If an agent does all the implementation, junior engineers may receive fewer opportunities to develop that intuition.

The answer should not be to stop using AI.

Instead, organizations should deliberately use agents as teaching systems.

For example:

"Implement this feature, but explain the architectural trade-offs before making changes."

Or:

"Propose three designs and explain why you recommend one."

This turns AI from an implementation shortcut into an engineering mentor.

Architecture Skills Become More Valuable

If AI can produce implementation quickly, the scarce skill becomes knowing what should be built and how it should fit into the larger system.

That increases the value of skills such as:

Distributed systems
Database design
Security architecture
Cloud architecture
API design
Domain modeling
Reliability engineering
Performance engineering
Observability
Systems thinking

A developer who understands these areas can supervise AI far more effectively than someone who only knows how to generate code.

The Danger of Measuring AI Productivity by Lines of Code

One of the worst metrics for AI-assisted development is:

Lines of code generated.

More generated code does not necessarily mean more business value.

An agent can generate 20,000 lines of code quickly.

But if the system becomes:

Harder to maintain
More expensive
Less secure
Over-engineered
Poorly documented
Difficult to deploy

then the productivity gain is questionable.

Better metrics include:

Lead time
Deployment frequency
Defect rate
Change failure rate
Mean time to recovery
Test coverage
Review time
Incident rate
Cost per feature
Business outcome

The objective should be better software, not more code.

AI Coding Agents Will Change Architecture Reviews

Traditional architecture reviews often happen before implementation.

AI-assisted development creates a second requirement:

continuous architecture review.

Why?

Because an agent can introduce architectural changes incrementally.

One pull request adds a new dependency.

Another adds a queue.

Another adds a caching layer.

Another introduces an external API.

Individually, each change may be reasonable.

Collectively, the architecture may drift.

This means teams should periodically analyze the architecture as it exists, not just the architecture that was originally designed.

A Better AI-Native Development Workflow

A mature workflow could look like this:

1. Define business requirement
          ↓
2. Human creates architectural constraints
          ↓
3. Agent proposes implementation plan
          ↓
4. Human approves plan
          ↓
5. Agent implements
          ↓
6. Automated tests execute
          ↓
7. Agent fixes failures
          ↓
8. Static/security/architecture checks
          ↓
9. AI-assisted code review
          ↓
10. Human engineering review
          ↓
11. Pull request approval
          ↓
12. CI/CD deployment
          ↓
13. Production monitoring

This model gives the AI substantial autonomy without giving up engineering accountability.

The Future: Developers Become System Directors

The most useful way to think about AI coding agents is not:

"AI replaces programmers."

It is:

AI changes what programming work consists of.

The implementation layer is becoming increasingly automated.

The responsibility for defining the system remains human.

A future engineering team might look like:

Product Manager
      ↓
Architect
      ↓
AI Planning Agent
      ↓
 ┌───────────────┐
 │ Coding Agent  │
 │ Test Agent    │
 │ Review Agent  │
 │ Security Agent│
 └───────────────┘
      ↓
Human Engineers
      ↓
Production

The humans become responsible for direction, constraints, validation, and accountability.

The agents become responsible for increasingly large portions of implementation.

Final Answer: Who Owns the Architecture?

Humans do.

AI coding agents can write code, modify repositories, run tests, debug failures, create pull requests, and increasingly participate across the software development lifecycle.

But architecture is not simply the sum of the code.

Architecture is the collection of decisions about:

Boundaries
Data
Security
Reliability
Scalability
Dependencies
Deployment
Integration
Maintainability
Business requirements

Those decisions have consequences that extend far beyond the current coding task.

The engineering challenge of the AI era therefore isn't preventing AI from writing code.

It is building an engineering environment in which AI can write a lot of code without silently becoming the architect.

The winning organizations will not necessarily be the ones that give agents the most autonomy.

They will be the ones that give agents the right autonomy, the right context, the right tools, strong verification, and clearly defined architectural boundaries.

AI can increasingly be the implementation engine.

But humans still need to decide what system should exist when the code is finished.