A IA tornou a geração de código rápida. O desafio de engenharia mudou de lugar — para antes e para depois do código: definir o problema certo, montar o contexto certo, decidir com critério e verificar o que chega a produção.
Uso IA no ciclo inteiro de desenvolvimento — da especificação à implementação, até agentes embarcados em produto — com um processo de engenharia em volta. Este ensaio descreve esse processo como ele roda hoje, com os números que ele produziu.
Definir antes de gerar.
Features começam com requisitos, decisões de arquitetura, restrições, critérios de aceite e tarefas de implementação. Os agentes trabalham contra especificações explícitas, em vez de inferir intenção de prompts espalhados.
Requisitos → Design → Tarefas → Implementação → Validação
No ERP Riavor, essa abordagem produziu quase 4 mil linhas de especificação em 15 documentos — arquitetura, controle de acesso, estoque, compras, vendas, fiscal, financeiro — antes de a implementação começar. Quando o agente escreve a primeira linha de código, o contrato já existe; a discordância aparece na revisão da spec, que é barata, e não na revisão do sistema, que não é.
Contexto certo vale mais que prompt esperto.
Decisões de arquitetura, regras de domínio, convenções de código e conhecimento operacional viram contexto estruturado que o agente carrega quando a tarefa pede. No meu setup, isso toma a forma de skills reutilizáveis: cada uma empacota uma fatia de conhecimento do projeto — a topologia do servidor, o checklist de sanitização, o procedimento de deploy — e o agente puxa a certa na hora certa, em vez de reconstruir contexto a cada sessão.
Fontes → Skills → Recuperação → Contexto → LLM
O objetivo não é dar mais informação ao modelo — é dar a informação certa no momento certo, com fontes rastreáveis.
Para bases de conhecimento maiores, o próximo passo é RAG — recuperação sobre embeddings em vez de contexto curado à mão. Hoje, do meu lado, isso é estudo aplicado, não algo que rodo em produção; entra nesta lista no dia em que estiver no ar, com números próprios.
Saída gerada é não-confiável até ser verificada.
Tudo que a IA produz — código ou ação de agente — passa pelos mesmos controles de engenharia: revisão de código, testes automatizados, checagem de tipos, varredura de segurança e validação de schema nas saídas estruturadas. Fluxos com agentes somam permissões de ferramenta e rastreamento por cima. Para operações de maior risco — qualquer coisa que toque dados de produção ou dinheiro — a execução fica atrás de aprovação humana explícita.
Revisão → Testes → Segurança → Schema → Aprovação
A regra é chata de propósito. Confiança é propriedade do pipeline, não do modelo.
IA também é parte da arquitetura.
Integro capacidades de LLM onde elas resolvem problema real de usuário ou de operação: automação de atendimento, agentes orientados a tarefa, extração estruturada, fluxos que conversam com sistemas existentes. Em produção, a automação de atendimento já criou 2,5 mil+ tickets numa operação de órgão público federal — triagem, classificação e abertura de chamados, rodando como parte do service desk.
Trato o LLM como mais uma dependência de sistema distribuído:
LLM APIs → Tool calling → Saídas estruturadas → Retries → Observabilidade → Guardrails
O modelo cuida de raciocínio e linguagem. O sistema em volta controla contexto, permissões, estado, validação e execução.
IA acelera a execução. A engenharia decide direção e qualidade.
Eu entendo e respondo pelos sistemas que entrego. A alavancagem vem de combinar IA com fundamentos: arquitetura, design de sistemas, debugging, segurança, conhecimento de domínio e ownership de produção.
Perfil em T — engenheiro de ponta a ponta, com profundidade em backend, integração de sistemas, automação e arquitetura resiliente.
Ownership — entendo o problema de negócio, avalio trade-offs, desenho a solução e sigo responsável pelo comportamento dela em produção.
AI-native — specs, engenharia de contexto, skills e harness de agentes fazem parte do fluxo diário de engenharia, não são experimentos isolados de IA.
Jogo global — comunicação técnica em inglês em specs, documentação, code review e colaboração assíncrona, com a conversação em desenvolvimento contínuo.