Como usar IA para programar sem terceirizar seu raciocínio

A IA pode analisar, explicar, planejar, implementar e testar. Mas a responsabilidade de decidir o que deve ser construído — e por quê — continua sendo do profissional.

Existe uma diferença importante entre usar inteligência artificial para ampliar o raciocínio e permitir que ela raciocine em nosso lugar.

Essa diferença nem sempre é evidente.

Uma IA pode produzir código organizado, sugerir uma arquitetura sofisticada, criar testes e explicar suas decisões com aparente segurança. Ainda assim, toda a implementação pode partir de uma premissa inadequada para o projeto.

Eu aprendi isso na prática.

Quando uma boa execução parte de uma decisão ruim

Em determinado projeto, decidi adotar uma arquitetura de microsserviços. Queria compreender profundamente como esse modelo funcionava: a comunicação entre os serviços, o isolamento, o uso de chamadas diretas ou eventos e a separação dos bancos de dados.

Como sou uma pessoa prática, não queria ficar apenas na teoria. Pedi a construção de uma aplicação que eu pudesse executar, observar e questionar.

A IA incentivou a adoção dos microsserviços e executou bem as premissas que apresentei. O sistema foi implementado e está funcionando.

O problema é que o projeto não precisava daquela arquitetura.

Com o tempo, o deploy e a manutenção ficaram muito mais complexos. A aplicação passou a exigir mais infraestrutura e capacidade computacional, enquanto a consistência dos dados se tornou outro desafio relevante.

A IA não havia necessariamente falhado na implementação. Ela havia executado corretamente uma decisão arquitetural que não era proporcional ao problema.

Hoje, estou refatorando esse sistema para um monólito modular, mantido num monorepo — uma arquitetura mais proporcional às necessidades reais do projeto, e um layout que dispensa a coordenação de deploys independentes.

Essa experiência revelou uma lição incômoda: a IA pode executar muito bem uma premissa ruim.

A IA não elimina a responsabilidade arquitetural

É fácil atribuir à ferramenta a responsabilidade por uma recomendação inadequada. No entanto, a decisão inicial de usar microsserviços foi minha.

A IA pode não ter recebido todo o contexto necessário. Também pode não ter compreendido corretamente as características do projeto. Mesmo assim, isso não transfere para ela a responsabilidade pela decisão.

Decisões arquiteturais não deveriam ser terceirizadas.

A IA pode ajudar a:

analisar requisitos;
comparar alternativas;
explicar um desenho;
levantar vantagens e desvantagens;
criar provas de conceito;
identificar riscos;
questionar premissas;
implementar um plano aprovado.

Mas o profissional precisa compreender o desenho, relacioná-lo ao contexto do projeto e assumir a decisão final.

Microsserviços, por exemplo, não são automaticamente superiores a um monólito modular. Eles podem fazer sentido em sistemas de grande escala, domínios independentes, equipes autônomas ou ambientes com requisitos específicos de isolamento e implantação.

Também introduzem custos reais:

comunicação distribuída;
consistência eventual;
observabilidade;
deploys coordenados;
testes mais complexos;
maior consumo de infraestrutura;
manutenção operacional;
tratamento de falhas entre serviços.

A pergunta correta não é apenas “essa arquitetura funciona?”.

É: essa arquitetura faz sentido para este projeto?

Complexidade sem necessidade é um sinal de alerta

Um dos primeiros sinais de que estamos aceitando uma solução sem compreendê-la aparece quando a complexidade deixa de ser proporcional ao problema.

O sistema começa a exigir mais infraestrutura, processamento e manutenção, mas esse custo adicional não produz um benefício equivalente para o negócio.

Uma arquitetura pode ser tecnicamente interessante e, ainda assim, inadequada.

Esse é um risco recorrente no uso de IA para programação. Modelos conseguem gerar soluções sofisticadas com rapidez. Essa capacidade pode nos levar a confundir sofisticação com adequação.

Quanto mais convincente for a resposta, maior deve ser o cuidado com suas premissas.

Antes de aceitar uma arquitetura sugerida ou reforçada pela IA, vale perguntar:

Qual problema concreto esse desenho resolve?
Esse problema existe hoje ou é apenas uma possibilidade futura?
Qual é a alternativa mais simples?
Quais custos operacionais serão introduzidos?
A equipe consegue manter essa solução?
Como serão realizados deploy, monitoramento e recuperação de falhas?
Como a consistência dos dados será garantida?
O benefício justifica a complexidade?

Se não conseguimos responder a essas perguntas, ainda não compreendemos suficientemente a decisão.

Use a IA para atacar suas próprias premissas

Definir previamente a arquitetura e as tecnologias reduz o risco de deixar a IA decidir tudo. Porém, isso cria outro perigo: transformar uma decisão humana não validada em uma premissa rígida.

Foi exatamente o que aconteceu no meu projeto.

Por isso, hoje faço questão de usar a IA também como uma adversária técnica. Peço que ela questione minhas decisões, apresente riscos e demonstre por que determinada alternativa poderia ser melhor.

Mas uma objeção não deve ser aceita apenas porque foi escrita de forma convincente.

Para rever uma decisão, procuro uma combinação de evidências:

documentação oficial;
prova de conceito executável;
testes;
métricas do projeto;
casos comparáveis.

Nenhum desses elementos deveria sustentar sozinho uma mudança importante. Se fôssemos atribuir notas, eu esperaria que todos alcançassem pelo menos 7 antes de abandonar uma decisão já fundamentada.

Isso não é uma fórmula científica. É uma heurística para evitar que uma única evidência aparentemente forte determine todo o rumo do projeto.

A IA pode desafiar a decisão. A decisão muda quando as evidências sustentam a mudança.

Delegar execução não é delegar pensamento

Existem atividades que podem ser delegadas com muito mais segurança:

implementação de planos estruturados;
criação de testes;
documentação;
parte da pesquisa;
revisão de código.

A diferença é que essas atividades acontecem dentro de limites previamente definidos.

O profissional continua responsável por compreender a necessidade, estruturar o plano, definir os critérios de aceite e avaliar o resultado.

Meu fluxo de trabalho com IA costuma seguir esta sequência:

Peço que a IA analise e resuma a necessidade.
Solicito o levantamento dos pontos importantes.
Estruturo o plano com a ajuda da IA.
A IA implementa o plano.
A implementação é testada.
O resultado é comparado com o Definition of Done.

A IA participa do pensamento, mas não recebe autoridade irrestrita sobre ele.

Testes técnicos não são suficientes

Testes são o principal mecanismo para verificar se uma implementação atende aos critérios definidos. Porém, não basta testar somente detalhes técnicos.

Também são necessários testes de negócio.

Considere uma regra simples: depois do cadastro, o usuário deve receber uma notificação.

Não basta testar se o cadastro foi persistido corretamente, se o serviço retornou o status esperado ou se um método foi chamado. O teste precisa representar o comportamento negocial: o usuário foi efetivamente notificado?

Se não foi, a implementação falhou do ponto de vista do negócio, mesmo que os testes internos tenham passado.

Essa distinção é especialmente importante quando a IA escreve o código e os próprios testes. Caso ambos sejam produzidos a partir da mesma interpretação incompleta, é possível obter uma suíte verde para uma solução errada.

Os testes precisam refletir critérios definidos conscientemente pelo profissional.

Para considerar uma implementação pronta, verifico três pontos:

os critérios de aceite foram atendidos;
as regras do negócio foram respeitadas;
os testes passaram.

Esse conjunto compõe o Definition of Done. O trabalho não termina quando a IA conclui a geração do código. Termina quando o resultado foi confrontado com aquilo que precisava ser entregue.

Aprender com IA exige executar e questionar

Quando comecei a estudar microsserviços, pedir uma aplicação executável foi fundamental. Eu queria observar como as partes se comunicavam e entender por que determinadas decisões haviam sido tomadas.

A execução transformou conceitos abstratos em consequências concretas.

Foi possível perceber que isolamento, eventos, bancos separados e deploys independentes não eram apenas elementos elegantes de um diagrama. Cada escolha criava custos, falhas possíveis e responsabilidades operacionais.

Esse é um uso produtivo da IA para aprendizagem:

peça uma explicação;
solicite uma implementação observável;
execute a solução;
questione cada decisão relevante;
altere as premissas;
compare os resultados;
formule sua própria conclusão.

Compreensão não nasce da resposta pronta. Ela surge no ciclo entre construir, executar, questionar e reconstruir.

A regra que orienta meu uso de IA

A melhor síntese que encontrei para esse modo de trabalhar é:

Você pensa e planeja com a ajuda da IA, e a IA executa.

A frase não significa que o profissional precisa trabalhar sozinho durante a análise. A IA pode contribuir ativamente, apresentar alternativas e identificar pontos que não foram considerados.

Também não significa tratar toda sugestão da IA com desconfiança automática.

Significa preservar a responsabilidade.

Quem define o problema continua sendo você. Quem relaciona a solução ao contexto continua sendo você. Quem decide quais trade-offs são aceitáveis continua sendo você. E quem responde pelas consequências da implementação também continua sendo você.

A IA amplia nossa capacidade de produzir software. Mas velocidade de execução não substitui clareza de pensamento.

Quando usamos a ferramenta para explorar, questionar, testar e executar decisões conscientes, ela se torna uma extensão poderosa do nosso trabalho.

Quando permitimos que ela escolha o problema, defina as premissas e valide a própria solução, não estamos apenas automatizando a programação.

Estamos terceirizando o raciocínio.