A inteligência artificial mudou a forma como desenvolvemos software.

Hoje, ferramentas baseadas em IA conseguem gerar código, explicar erros, criar testes, sugerir refatorações, documentar APIs e até participar de tarefas que antes exigiam bastante trabalho manual.

Diante disso, uma pergunta começa a aparecer com frequência:

Será que a arquitetura da aplicação precisa mudar para aproveitarmos melhor a IA?

Mais especificamente:

É melhor trabalhar com um monólito ou com microsserviços quando usamos IA no desenvolvimento?

A resposta não é simplesmente “microsserviços”.

Na prática, a IA pode trabalhar muito bem com ambas as arquiteturas. A diferença está principalmente na quantidade de contexto, na clareza dos limites e no custo operacional que colocamos entre a IA e o problema que ela precisa resolver.

A IA mudou o problema, mas não eliminou os fundamentos da arquitetura

Antes de discutir monólitos e microsserviços, existe uma premissa importante:

IA não elimina os princípios de engenharia de software.

Uma aplicação mal projetada continua sendo difícil de manter quando usamos IA.

Um sistema com acoplamento excessivo, regras de negócio espalhadas, responsabilidades mal definidas e pouca cobertura de testes não se torna bem arquitetado apenas porque podemos pedir para uma IA refatorá-lo.

Na verdade, existe até um risco adicional.

A velocidade proporcionada pela IA pode fazer com que decisões arquiteturais ruins sejam tomadas muito mais rapidamente.

Imagine um projeto em que um desenvolvedor consegue gerar centenas de linhas de código em poucos minutos.

Se a arquitetura estiver bem definida, isso pode representar um enorme ganho de produtividade.

Se a arquitetura estiver ruim, podemos simplesmente criar mais código ruim em menos tempo.

Por isso, quando falamos de arquitetura para desenvolvimento assistido por IA, a pergunta mais importante não deveria ser:

“Qual arquitetura a IA prefere?”

Talvez a pergunta correta seja:

“Qual arquitetura permite fornecer contexto suficiente para a IA trabalhar sem aumentar desnecessariamente a complexidade do sistema?”

O monólito ainda faz muito sentido

Existe uma ideia recorrente de que sistemas modernos precisam ser distribuídos.

Isso não é verdade.

Um monólito bem projetado pode ser uma excelente arquitetura para aplicações desenvolvidas com auxílio de IA.

Considere uma aplicação PHP tradicional utilizando Symfony ou Laravel.

Podemos ter algo semelhante a:

text

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

Todo o sistema está no mesmo repositório.

Isso traz uma vantagem muito importante para ferramentas de IA:

o contexto está relativamente próximo.

Quando pedimos para a IA implementar uma funcionalidade, ela pode analisar:

controller;
service;
DTO;
entidade;
repository;
testes;
configuração;
rotas;
templates;
documentação.

Tudo isso pode estar disponível dentro do mesmo projeto.

Para muitas tarefas, isso reduz o esforço necessário para explicar a arquitetura.

O grande benefício do monólito para a IA: contexto

Uma IA produz resultados melhores quando entende o contexto do problema.

Imagine a seguinte solicitação:

“Adicione validação para impedir que uma venda seja criada quando o cliente estiver bloqueado.”

Em um monólito bem estruturado, a IA pode encontrar rapidamente:

text

VendaController
     ↓
VendaService
     ↓
ClienteRepository
     ↓
Cliente

Ela consegue acompanhar a regra de negócio dentro do mesmo projeto.

Agora imagine o mesmo cenário em uma arquitetura distribuída:

text

frontend
   ↓
API Gateway
   ↓
vendas-service
   ↓
clientes-service
   ↓
auth-service
   ↓
notification-service

A implementação talvez exija entender:

contratos HTTP;
autenticação entre serviços;
payloads;
tratamento de erros;
service discovery;
filas;
retries;
observabilidade;
timeouts;
versionamento das APIs.

A funcionalidade de negócio continua sendo relativamente simples.

Mas o contexto técnico necessário para implementar a mudança aumentou bastante.

O problema do contexto distribuído

Esse é provavelmente um dos pontos mais interessantes quando relacionamos IA com microsserviços.

Uma IA trabalhando em um microsserviço isolado pode não ter conhecimento suficiente para compreender todo o fluxo de negócio.

Por exemplo:

text

Pedido
  ↓
Pagamento
  ↓
Estoque
  ↓
Entrega
  ↓
Notificação

Se cada parte estiver em um serviço diferente, uma mudança aparentemente simples pode atravessar vários repositórios.

A IA precisará entender não apenas o código local, mas também os contratos existentes entre os serviços.

Isso não significa que microsserviços sejam ruins para IA.

Significa que arquiteturas distribuídas exigem uma estratégia melhor de contexto.

Documentação, contratos bem definidos, testes de integração, OpenAPI, diagramas e regras explícitas tornam-se ainda mais importantes.

Onde microsserviços podem ajudar

Apesar dessa complexidade adicional, microsserviços também apresentam vantagens interessantes para desenvolvimento assistido por IA.

A principal delas é a possibilidade de trabalhar com limites menores e responsabilidades mais específicas.

Considere:

text

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

Cada serviço possui uma responsabilidade relativamente clara.

Uma IA trabalhando especificamente no payment-service pode receber um contexto muito menor.

Isso pode ser extremamente útil quando o sistema é grande.

Em um monólito gigantesco, o problema inverso pode aparecer.

Imagine um projeto com:

text

src/
  5000 classes
  1200 services
  800 controllers
  400 repositories

Embora tudo esteja no mesmo repositório, isso não significa que todo o contexto seja relevante.

O desafio deixa de ser “não tenho contexto suficiente” e passa a ser:

“Tenho contexto demais.”

A IA também precisa lidar com o excesso de contexto

Esse é um ponto frequentemente ignorado.

Mais código disponível não significa necessariamente uma resposta melhor.

Uma aplicação monolítica muito grande pode conter:

funcionalidades antigas;
regras duplicadas;
dependências históricas;
código morto;
integrações diferentes;
padrões inconsistentes;
classes responsáveis por múltiplas coisas.

Para um humano, isso já é difícil.

Para uma ferramenta de IA, também.

Nesse cenário, a modularização interna do monólito pode ser tão importante quanto a separação em microsserviços.

Podemos ter algo como:

text

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

Continuamos tendo um único deploy.

Mas temos limites claros.

Isso cria uma arquitetura que pode oferecer uma das melhores combinações para desenvolvimento assistido por IA:

simplicidade operacional + separação lógica.

Monólito modular: um meio-termo interessante

O conceito de monólito modular ganha ainda mais relevância quando pensamos em IA.

Em vez de começar com dezenas de serviços independentes, podemos construir uma aplicação única, mas com módulos claramente separados.

Por exemplo:

text

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

A arquitetura continua simples para executar e implantar.

Ao mesmo tempo, a IA consegue trabalhar com limites claros.

Podemos inclusive estabelecer regras como:

text

Order não acessa diretamente tabelas internas de Payment.

Payment possui seus próprios services.

Controllers não implementam regras de negócio.

Integrações externas ficam isoladas em adapters.

Essas regras são valiosas não apenas para humanos.

Elas também funcionam como instruções arquiteturais para a IA.

Arquitetura explícita é mais importante que distribuição

Quando utilizamos IA para programar, uma arquitetura explícita se torna ainda mais importante.

Considere duas aplicações.

Aplicação A

text

Controller
   ↓
Service
   ↓
Repository

Com responsabilidades bem definidas.

Aplicação B

text

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

Sem uma regra clara sobre onde as responsabilidades devem ficar.

A segunda pode até ser um “monólito moderno” utilizando boas tecnologias.

Mas será muito mais difícil para a IA entender onde uma nova funcionalidade deve ser implementada.

Por isso, uma conclusão importante é:

A IA se beneficia mais de arquiteturas previsíveis do que de arquiteturas sofisticadas.

Microsserviços adicionam complexidade que a IA não elimina

Existe outro ponto importante.

Quando dividimos uma aplicação em microsserviços, também dividimos problemas.

Não temos apenas:

text

código

Passamos a lidar com:

text

código
+
rede
+
autenticação
+
observabilidade
+
deploy
+
versionamento
+
resiliência
+
mensageria
+
monitoramento

A IA pode ajudar em todos esses aspectos.

Ela pode gerar:

Dockerfiles;
pipelines;
manifests;
configurações;
testes;
clientes HTTP;
documentação;
regras de retry;
métricas.

Mas isso não significa que a complexidade desapareceu.

Ela apenas pode ser implementada mais rapidamente.

Essa diferença é importante.

IA reduz o esforço de produzir software, mas não elimina o custo de operar software.

A pergunta mais importante: qual é o tamanho do sistema?

Talvez essa seja uma das formas mais práticas de decidir.

Em uma aplicação pequena ou média, um monólito bem estruturado costuma oferecer uma experiência muito simples:

text

1 repositório
1 pipeline
1 deploy
1 banco
1 observabilidade

À medida que o sistema cresce, podem surgir necessidades como:

text

deploy independente
escalabilidade independente
times diferentes
domínios altamente separados
ciclos de desenvolvimento diferentes
isolamento de falhas

Nesse momento, microsserviços podem começar a fazer sentido.

Observe que a decisão não acontece porque:

“Agora usamos IA.”

Ela acontece porque o sistema atingiu um nível de complexidade que justifica a distribuição.

IA pode até favorecer o monólito em alguns cenários

Isso parece contraintuitivo, mas faz sentido.

Se uma equipe pequena utiliza agentes de IA para acelerar o desenvolvimento de uma aplicação, ter:

text

um repositório
um domínio principal
uma pipeline
um banco

pode tornar o processo muito mais simples.

O desenvolvedor consegue pedir:

“Implemente essa funcionalidade completa, incluindo migration, DTO, service, controller e testes.”

E a IA pode navegar pelo projeto inteiro.

Quanto menor a quantidade de fronteiras artificiais, menor a quantidade de infraestrutura que precisa ser explicada.

Para muitos projetos, essa simplicidade é extremamente valiosa.

Mas IA também pode tornar microsserviços mais viáveis

Existe o outro lado.

Microsserviços historicamente exigem mais trabalho para criar e manter.

É necessário implementar:

contratos;
documentação;
integrações;
infraestrutura;
pipelines;
observabilidade;
testes distribuídos.

A IA pode reduzir significativamente o esforço necessário para produzir parte dessa infraestrutura.

Isso significa que uma arquitetura distribuída que antes exigia muito trabalho manual pode se tornar mais acessível.

Porém, existe um risco:

usar IA para justificar uma arquitetura que o negócio ainda não precisa.

Se antes seriam necessários dois dias para criar um serviço adicional e agora uma IA consegue fazer isso em algumas horas, isso não significa que devemos criar dez serviços.

A facilidade de implementação não transforma complexidade desnecessária em complexidade necessária.

O papel dos contratos

Em arquiteturas distribuídas, contratos claros se tornam ainda mais importantes.

Por exemplo:

http

POST /payments

Request:

json

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

Response:

json

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

Quanto mais explícito for o contrato, mais fácil será para uma IA entender como os sistemas se relacionam.

Por isso, tecnologias e práticas como:

OpenAPI;
JSON Schema;
DTOs;
versionamento;
testes de contrato;
documentação automática;

podem ter um papel ainda maior em ambientes onde IA participa do desenvolvimento.

Código previsível também é uma forma de documentação

Quando uma IA trabalha em uma base de código, padrões consistentes ajudam muito.

Por exemplo, se todos os serviços PHP seguem:

php

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

a IA consegue reconhecer rapidamente o padrão.

Se cada funcionalidade segue uma estrutura diferente, será necessário fornecer muito mais instruções.

Isso vale para:

nomenclatura;
estrutura de diretórios;
tratamento de exceções;
DTOs;
validações;
testes;
acesso a dados;
integrações externas.

Quanto menos decisões arbitrárias existirem no projeto, menor será a quantidade de contexto necessário para orientar a IA.

A arquitetura do futuro talvez seja híbrida

Na prática, muitas aplicações não precisam escolher entre:

text

monólito

text

microsserviços

de forma absoluta.

Podemos ter:

text

                    ┌── Notification Service
                    │
Monólito Principal ─┼── Payment Service
                    │
                    └── External API

Ou até:

text

                    Monólito Modular
                           │
          ┌────────────────┼────────────────┐
          ↓                ↓                ↓
       Orders           Customers         Billing
                                             │
                                             ↓
                                     Payment Provider

A arquitetura pode evoluir de acordo com as necessidades reais.

Começamos com um monólito.

Criamos módulos claros.

Identificamos um componente que precisa de independência.

Extraímos esse componente.

Depois avaliamos novamente.

Essa evolução gradual pode ser muito mais saudável do que começar distribuindo tudo.

Como eu avaliaria uma arquitetura para trabalhar com IA

Antes de escolher uma arquitetura, eu observaria alguns fatores.

1. A IA consegue entender o contexto?

O código está organizado de forma previsível?

2. As responsabilidades estão claras?

É fácil descobrir onde uma regra de negócio deve ser implementada?

3. Existem contratos explícitos?

APIs e integrações possuem formatos bem definidos?

4. Existem testes suficientes?

A IA pode fazer mudanças e validar o comportamento automaticamente?

5. A infraestrutura é proporcional ao problema?

Existe uma justificativa real para múltiplos serviços?

6. O sistema é observável?

Quando uma mudança feita com auxílio de IA introduz um problema, conseguimos identificar rapidamente?

7. A arquitetura pode evoluir?

É possível começar simples e distribuir componentes posteriormente?

Essas perguntas provavelmente são mais importantes do que simplesmente perguntar:

“Monólito ou microsserviços?”

E para aplicações PHP?

Para uma aplicação PHP típica, especialmente em equipes pequenas ou médias, uma estratégia bastante interessante pode ser:

text

PHP
Symfony / Laravel
Monólito modular
DTOs
Services
Repositories
Testes automatizados
OpenAPI
CI/CD
Observabilidade

A partir daí, determinados componentes podem ser extraídos quando houver uma razão concreta.

Por exemplo:

text

Aplicação PHP
      │
      ├── Customers
      ├── Orders
      ├── Billing
      └── Reports

E posteriormente:

text

Aplicação PHP
      │
      ├── Customers
      ├── Orders
      └── Reports

Billing Service

Não existe obrigação de transformar cada módulo em um serviço.

A distribuição deve resolver um problema concreto.

O verdadeiro ganho da IA está na engenharia, não na arquitetura

Existe uma conclusão que considero especialmente importante.

A IA está tornando o código mais barato de produzir.

Isso significa que outros aspectos da engenharia de software passam a ter ainda mais importância.

Arquitetura.

Testes.

Segurança.

Observabilidade.

Documentação.

Revisão de código.

Qualidade dos contratos.

Governança.

Quanto mais fácil fica gerar código, mais importante fica saber qual código deveria ser gerado.

Então, monólito ou microsserviços?

Talvez a melhor resposta seja:

depende do problema que você está tentando resolver.

Um monólito bem modularizado pode oferecer:

contexto mais simples;
desenvolvimento mais rápido;
menos infraestrutura;
menor custo operacional;
facilidade de teste;
facilidade para ferramentas de IA navegarem pelo projeto.

Microsserviços podem oferecer:

separação mais forte entre domínios;
deploy independente;
escalabilidade independente;
isolamento entre componentes;
autonomia entre equipes.

A IA pode ajudar nos dois modelos.

Ela pode escrever código para um monólito.

Pode criar endpoints de microsserviços.

Pode produzir Dockerfiles.

Pode gerar testes.

Pode documentar APIs.

Pode ajudar na observabilidade.

Mas continua dependendo de uma arquitetura que faça sentido.

A pergunta que devemos fazer antes de adotar microsserviços

Em vez de perguntar:

“Qual arquitetura funciona melhor com IA?”

Talvez seja mais útil perguntar:

“Qual é a menor complexidade arquitetural capaz de resolver meu problema atual?”

Se a resposta for um monólito modular, ótimo.

Se for uma arquitetura distribuída, ótimo também.

O importante é que a decisão seja consequência das necessidades do sistema, e não da tecnologia do momento.

Porque a IA pode mudar muito a forma como escrevemos software.

Mas uma coisa continua válida:

complexidade desnecessária continua sendo complexidade.

E nenhuma IA consegue removê-la simplesmente porque agora consegue escrever o código mais rápido.