Como organizo engenharia de software com inteligência artificial

Eu não trato cada conceito como uma receita isolada. SDD, engenharia de contexto, avaliações e revisão humana resolvem partes diferentes do mesmo problema: como transformar uma intenção em software confiável sem perder rastreabilidade.

A combinação muda conforme o projeto. Um site institucional não precisa do mesmo processo de um sistema financeiro, de uma automação com acesso a dados de clientes ou de um agente capaz de executar ações externas.

No desenvolvimento orientado por especificações, a equipe registra o que precisa ser construído, os limites, os critérios de aceite e as decisões relevantes antes de depender do código como única fonte de verdade.

Na prática, trabalho com uma sequência próxima de intenção, especificação, plano, tarefas, implementação e validação. O nível de detalhe cresce junto com o risco. Uma boa especificação não precisa ser longa; precisa eliminar as ambiguidades que gerariam retrabalho.

Loop Engineering organiza ciclos em que um agente planeja, executa, observa testes ou resultados e decide o próximo passo. O valor não está em repetir comandos, mas em desenhar um ciclo com sinais confiáveis de sucesso e falha.

Harness Engineering amplia essa ideia. O foco passa a ser o ambiente em que o agente trabalha: documentação, ferramentas, permissões, testes, observabilidade, limites e pontos de revisão. Humanos definem intenção e controles; agentes executam dentro desse espaço.

Context Engineering cuida das informações que chegam ao modelo: instruções, arquivos, histórico, ferramentas, memória e dados recuperados. Mais contexto não significa necessariamente melhor resultado. A qualidade depende de selecionar o que é relevante para a decisão atual.

RAG é uma das formas de recuperar informações externas antes de gerar uma resposta. Ele é útil quando o sistema precisa consultar documentação, conhecimento interno ou dados que mudam. Não é obrigatório em todo produto e não substitui autorização, validação da fonte ou regras de acesso.

Um workflow segue caminhos definidos pelo software. Um agente decide dinamicamente como usar ferramentas e alcançar um objetivo. Eu prefiro workflows quando o processo é previsível e agentes quando a flexibilidade compensa custo, latência e risco.

Multi Agent Collaboration pode dividir planejamento, implementação, segurança e avaliação entre agentes especializados. Essa arquitetura só faz sentido quando a divisão melhora o resultado. Para muitos problemas, um único agente com ferramentas claras é mais simples e confiável.

Antes de alterar prompts, modelos ou regras, defino exemplos representativos do comportamento esperado. As avaliações podem verificar respostas, uso de ferramentas, segurança, custo, latência e conclusão correta de uma tarefa.

Casos reais que falharam viram novos testes. Assim, o sistema aprende com a operação sem depender apenas da percepção de que uma resposta parece boa.

Revisão humana não precisa interromper cada ação. Ela deve existir nos pontos em que uma decisão pode afetar dinheiro, dados, clientes, segurança ou outras pessoas.

O sistema também precisa limitar quais ferramentas o agente pode usar, exigir confirmação para ações sensíveis e registrar o que aconteceu. Autonomia útil é autonomia com limites compreensíveis.

Tarefas longas atravessam janelas de contexto e sessões diferentes. Para manter continuidade, uso planos, registros de progresso, estado verificável e artefatos que permitam ao próximo ciclo entender o que já foi feito.

Uma arquitetura recente combina agentes de planejamento, execução e avaliação. O avaliador transforma critérios subjetivos ou funcionais em verificações concretas. Isso pode elevar a qualidade, mas também aumenta custo e complexidade, por isso deve ser proporcional ao valor da tarefa.

Começo pelo problema e pelo risco, não pela ferramenta. Defino o que precisa ser verdade para considerar a entrega concluída, organizo o contexto, escolho o nível de automação e crio sinais que permitam avaliar o resultado.

O método deve tornar o trabalho mais claro para o cliente e para quem dará continuidade ao produto. Se uma prática adiciona cerimônia sem melhorar decisão, segurança ou capacidade de entrega, ela precisa ser simplificada.