Artificial intelligence has changed the way we build software.

Today, AI-powered tools can generate code, explain errors, create tests, suggest refactorings, document APIs, and even handle tasks that previously required significant manual effort.

This raises an interesting question:

Does our application architecture need to change to take full advantage of AI?

More specifically:

Is a monolith or a microservices architecture better when working with AI?

The answer is not simply “microservices.”

In practice, AI can work very well with both architectures. The difference is mainly related to the amount of context, the clarity of boundaries, and the operational complexity we place between the AI and the problem it needs to solve.

AI Changed the Problem, But Not the Fundamentals of Architecture

Before comparing monoliths and microservices, there is an important premise:

AI does not eliminate the principles of software engineering.

A poorly designed application is still difficult to maintain when AI is involved.

A system with excessive coupling, scattered business rules, unclear responsibilities, and insufficient test coverage does not become well architected simply because we can ask an AI to refactor it.

In fact, there is an additional risk.

The speed provided by AI can cause poor architectural decisions to be made much faster.

Imagine a project where a developer can generate hundreds of lines of code in a few minutes.

If the architecture is well designed, this can represent a significant productivity improvement.

If the architecture is poor, we may simply create more bad code in less time.

Therefore, when discussing architecture for AI-assisted development, the most important question may not be:

“Which architecture does AI prefer?”

A better question might be:

“Which architecture allows us to provide enough context for AI to work without unnecessarily increasing system complexity?”

The Monolith Still Makes a Lot of Sense

There is a recurring idea that modern systems need to be distributed.

That is not necessarily true.

A well-designed monolith can be an excellent architecture for applications developed with AI assistance.

Consider a traditional PHP application using Symfony or Laravel.

It might have a structure such as:

text

src/
├── Controller/
├── Service/
├── Repository/
├── Entity/
├── DTO/
├── Security/
└── Domain/

The entire system lives in a single repository.

This provides an important advantage for AI tools:

the context is relatively close together.

When we ask AI to implement a feature, it can analyze:

controllers;
services;
DTOs;
entities;
repositories;
tests;
configuration;
routes;
templates;
documentation.

All of this can be available within the same project.

For many tasks, this reduces the amount of effort required to explain the architecture.

The Biggest Advantage of a Monolith for AI: Context

AI produces better results when it understands the context of a problem.

Imagine the following request:

“Add validation to prevent a sale from being created when the customer is blocked.”

In a well-structured monolith, AI may quickly find:

text

VendaController
     ↓
VendaService
     ↓
ClienteRepository
     ↓
Cliente

It can follow the business rule within the same project.

Now imagine the same scenario in a distributed architecture:

text

frontend
   ↓
API Gateway
   ↓
sales-service
   ↓
customers-service
   ↓
auth-service
   ↓
notification-service

The same feature may require understanding:

HTTP contracts;
authentication between services;
payloads;
error handling;
service discovery;
message queues;
retries;
timeouts;
observability;
API versioning.

The business feature may still be relatively simple.

But the technical context required to implement the change has increased significantly.

This does not mean microservices are bad for AI.

It means distributed architectures require a better context strategy.

Documentation, explicit contracts, integration tests, OpenAPI specifications, diagrams, and clear rules become even more important.

The Challenge of Distributed Context

This is probably one of the most interesting aspects of the relationship between AI and microservices.

An AI working inside an isolated microservice may not have enough information to understand the entire business flow.

Consider:

text

Order
  ↓
Payment
  ↓
Inventory
  ↓
Shipping
  ↓
Notification

If each component lives in a different service, a seemingly simple change may cross multiple repositories.

The AI needs to understand not only the local code but also the contracts between services.

Again, this does not make microservices inherently worse.

It means that the architecture needs stronger mechanisms for sharing context.

Documentation, contracts, integration tests, domain boundaries, and consistent conventions become essential.

Where Microservices Can Help

Despite the additional complexity, microservices also have interesting advantages for AI-assisted development.

The main one is the ability to work with smaller, more focused boundaries.

For example:

text

payment-service
notification-service
customer-service
inventory-service

Each service has a relatively clear responsibility.

An AI working specifically on payment-service can operate within a much smaller context.

This can be extremely useful when the overall system is large.

The opposite problem can happen with a huge monolith.

Imagine a project containing:

text

src/
  5000 classes
  1200 services
  800 controllers
  400 repositories

Everything is in the same repository, but that does not mean all of that context is relevant.

The challenge is no longer:

“I don’t have enough context.”

It becomes:

“I have too much context.”

AI Also Has to Deal With Too Much Context

This is an important point that is often overlooked.

More available code does not necessarily mean a better result.

A very large monolithic application may contain:

legacy functionality;
duplicated rules;
historical dependencies;
dead code;
multiple integrations;
inconsistent patterns;
classes with multiple responsibilities.

This is already difficult for humans.

It is difficult for AI as well.

In this scenario, internal modularization can be just as important as splitting the application into microservices.

For example:

text

src/
├── Billing/
├── Customers/
├── Orders/
├── Products/
└── Authentication/

We still have a single deployment.

But we have clear logical boundaries.

This creates an architecture that can offer an interesting combination for AI-assisted development:

operational simplicity + logical separation.

Modular Monolith: An Interesting Middle Ground

The concept of a modular monolith becomes even more relevant when we think about AI.

Instead of starting with dozens of independent services, we can build a single application with clearly separated modules.

For example:

text

src/
├── Customer/
│   ├── Controller/
│   ├── Service/
│   ├── Repository/
│   └── DTO/
│
├── Order/
│   ├── Controller/
│   ├── Service/
│   ├── Repository/
│   └── DTO/
│
└── Payment/
    ├── Controller/
    ├── Service/
    ├── Repository/
    └── DTO/

The architecture remains simple to run and deploy.

At the same time, AI can work within clear boundaries.

We can establish rules such as:

text

Order must not directly access Payment's internal tables.

Payment owns its own services.

Controllers do not implement business rules.

External integrations are isolated behind adapters.

These rules are valuable not only for humans.

They can also serve as architectural instructions for AI.

Explicit Architecture Matters More Than Distribution

When AI is used for software development, an explicit architecture becomes even more important.

Consider two applications.

Application A

text

Controller
   ↓
Service
   ↓
Repository

With clearly defined responsibilities.

Application B

text

Controller
   ↓
Helper
   ↓
Utils
   ↓
Manager
   ↓
Service
   ↓
Facade
   ↓
Repository

With no clear rule about where responsibilities belong.

The second application might still be called a “modern monolith” using good technologies.

But it will be much harder for AI to determine where a new feature should be implemented.

This leads to an important conclusion:

AI benefits more from predictable architectures than sophisticated architectures.

Microservices Add Complexity That AI Does Not Eliminate

There is another important consideration.

When we split an application into microservices, we also split the problems.

We no longer have only:

text

code

We now have:

text

code
+
network
+
authentication
+
observability
+
deployment
+
versioning
+
resilience
+
messaging
+
monitoring

AI can help with all of these areas.

It can generate:

Dockerfiles;
CI/CD pipelines;
infrastructure configuration;
API clients;
tests;
retry mechanisms;
documentation;
metrics;
configuration files.

But that does not mean the complexity has disappeared.

It may simply be implemented faster.

This distinction matters.

AI can reduce the effort required to produce software, but it does not eliminate the cost of operating software.

The Most Important Question: How Large Is the System?

This is probably one of the most practical ways to approach the decision.

For a small or medium-sized application, a well-structured monolith can provide a very simple experience:

text

1 repository
1 pipeline
1 deployment
1 database
1 observability stack

As the system grows, requirements may emerge such as:

text

independent deployments
independent scaling
different teams
strongly separated domains
different development cycles
fault isolation

At that point, microservices may become a reasonable architectural option.

Notice that the decision does not happen because:

“Now we use AI.”

It happens because the system reached a level of complexity where distribution addresses concrete needs.

AI Can Actually Favor Monoliths in Some Scenarios

This may sound counterintuitive, but it makes sense.

If a small team uses AI agents to accelerate development, having:

text

one repository
one main domain
one pipeline
one database

can make the development process much simpler.

A developer can ask:

“Implement this complete feature, including the migration, DTO, service, controller, and tests.”

AI can navigate the entire project.

The fewer artificial boundaries we introduce, the less infrastructure needs to be explained.

For many projects, that simplicity is extremely valuable.

But AI Can Also Make Microservices More Viable

There is another side to the discussion.

Microservices have historically required more effort to build and maintain.

Teams need to deal with:

contracts;
documentation;
integrations;
infrastructure;
deployment pipelines;
observability;
distributed testing.

AI can reduce the effort required to produce part of this infrastructure.

This means a distributed architecture that previously required significant manual effort may become more accessible.

But there is a risk:

using AI to justify an architecture that the business does not actually need.

If it used to take two days to create an additional service and AI can now do it in a few hours, that does not mean we should create ten services.

The ease of implementation does not turn unnecessary complexity into necessary complexity.

The Role of Contracts

In distributed architectures, explicit contracts become even more important.

For example:

http

POST /payments

Request:

json

{
    "orderId": 123,
    "amount": 150.50
}

Response:

json

{
    "id": 789,
    "status": "approved"
}

The more explicit the contract, the easier it becomes for AI to understand how systems interact.

This makes practices and technologies such as:

OpenAPI;
JSON Schema;
DTOs;
API versioning;
contract testing;
automated documentation;

even more valuable in environments where AI participates in software development.

Predictable Code Is Also a Form of Documentation

When AI works on a codebase, consistent patterns are extremely helpful.

For example, if all PHP services follow a pattern like:

php

final class CreateOrderService
{
    public function execute(CreateOrderDto $dto): Order
    {
        // ...
    }
}

AI can quickly recognize the pattern.

If every feature follows a different structure, we need to provide much more guidance.

This applies to:

naming conventions;
directory structure;
exception handling;
DTOs;
validation;
tests;
data access;
external integrations.

The fewer arbitrary decisions a project contains, the less context is required to guide AI.

The Future Architecture May Be Hybrid

In practice, many applications do not need to choose between:

text

monolith

and:

text

microservices

in absolute terms.

We can have:

text

                    ┌── Notification Service
                    │
Main Monolith ──────┼── Payment Service
                    │
                    └── External API

Or:

text

                    Modular Monolith
                           │
          ┌────────────────┼────────────────┐
          ↓                ↓                ↓
       Orders           Customers         Billing
                                             │
                                             ↓
                                      Payment Provider

The architecture can evolve according to actual needs.

We can start with a monolith.

Create clear modules.

Identify a component that needs independence.

Extract that component.

Then evaluate the architecture again.

This gradual evolution can be much healthier than distributing everything from day one.

How I Would Evaluate an Architecture for AI-Assisted Development

Before choosing an architecture, I would look at several factors.

1. Can AI understand the context?

Is the code organized in a predictable way?

2. Are responsibilities clear?

Is it easy to determine where a business rule should be implemented?

3. Are contracts explicit?

Do APIs and integrations have well-defined formats?

4. Is there enough automated testing?

Can AI make changes and automatically validate the behavior?

5. Is the infrastructure proportional to the problem?

Is there an actual reason to have multiple services?

6. Is the system observable?

When an AI-assisted change introduces a problem, can we identify it quickly?

7. Can the architecture evolve?

Can we start simple and distribute components later?

These questions are probably more useful than simply asking:

“Monolith or microservices?”

What About PHP Applications?

For a typical PHP application, especially in a small or medium-sized team, an interesting approach might be:

text

PHP
Symfony / Laravel
Modular Monolith
DTOs
Services
Repositories
Automated Tests
OpenAPI
CI/CD
Observability

From there, specific components can be extracted when there is a concrete reason.

For example:

text

PHP Application
      │
      ├── Customers
      ├── Orders
      ├── Billing
      └── Reports

And later:

text

PHP Application
      │
      ├── Customers
      ├── Orders
      └── Reports

Billing Service

There is no requirement to turn every module into a separate service.

Distribution should solve a concrete problem.

The Real Value of AI Is in Engineering, Not Architecture

There is an important conclusion here.

AI is making code cheaper to produce.

That means other aspects of software engineering become even more important.

Architecture.

Testing.

Security.

Observability.

Documentation.

Code review.

Contract quality.

Governance.

The easier it becomes to generate code, the more important it becomes to know which code should actually be generated.

So, Monolith or Microservices?

Perhaps the most useful answer is:

it depends on the problem you are trying to solve.

A well-modularized monolith can provide:

simpler context;
faster development;
less infrastructure;
lower operational complexity;
easier testing;
easier navigation for AI tools.

Microservices can provide:

stronger domain boundaries;
independent deployments;
independent scaling;
component isolation;
greater autonomy between teams.

AI can help with both models.

It can write monolithic application code.

It can create microservice endpoints.

It can generate Dockerfiles.

It can write tests.

It can document APIs.

It can help with observability.

But it still depends on an architecture that makes sense.

The Question to Ask Before Adopting Microservices

Instead of asking:

“Which architecture works best with AI?”

Perhaps it is more useful to ask:

“What is the smallest amount of architectural complexity capable of solving my current problem?”

If the answer is a modular monolith, that’s fine.

If the answer is a distributed architecture, that’s fine too.

The important thing is that the decision should be driven by the system’s actual needs, rather than by the technology of the moment.

Because AI may dramatically change how we write software.

But one thing remains true:

unnecessary complexity is still complexity.

And no AI can remove it simply because it can write the code faster.