> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/pt-br/2026/w38-everything-can-be-engineered.md).

# W38-Tudo pode ser tratado com engenharia

Alguns trabalhos recentes reforçaram minha percepção de que a IA está mudando a forma como lido com problemas complexos.

Antes, quando a complexidade passava de certo ponto, eu só conseguia dedicar mais atenção: lembrar configurações, manter documentos, explicar o contexto repetidamente e investigar depois de erros. Mesmo sabendo que um programa poderia resolver, nem sempre valia construir e manter um sistema.

Agora, prefiro transformar o problema em um projeto de engenharia.

Registrar fatos e regras, entregar operações repetidas a programas, validar mudanças e preservar histórico e caminhos de retorno. Novas necessidades podem crescer sobre essa base.

O método já existia. **A IA reduziu o custo de implementá-lo e mantê-lo, tornando viáveis muitos projetos que antes não compensavam.**

## De configurações de proxy a um sistema que pode ser mantido

O primeiro exemplo é o proxy do meu Mac.

No começo, eu só precisava conectar alguns aplicativos. Com novas necessidades, vieram regras por site, conexão direta à rede da empresa, diferenças de ambiente entre linha de comando e desktop, atualização de configurações e migração entre aparelhos.

Cada ajuste isolado era simples. Somados, os detalhes ficaram difíceis de manter de memória. Eu resolvia algo e, depois de um tempo, já não lembrava o motivo da configuração nem o que a próxima mudança afetaria.

Organizei então a solução em um repositório privado.

Ele contém modelos de configuração, regras de roteamento, scripts de geração e validação e manuais de recuperação, manutenção e diagnóstico. Posso pré-visualizar mudanças, fazer backup antes da instalação e reverter se houver problema. Migrar para outro Mac também tem passos e critérios de aceitação claros.

Já fiz uma migração real para outro computador, verificando a eficácia e a eficiência da solução. O que exigia investigação item a item e configuração manual agora segue as regras e os processos do repositório. O projeto ganhou uma capacidade de reúso testada na prática.

A mudança, para mim, é tratar finalmente essa configuração como um sistema de longo prazo. Ao acrescentar um aplicativo ou ajustar uma regra, há um lugar para mudar, um método para verificar e um histórico para consultar.

**A complexidade continua existindo, mas agora tem um lugar definido e uma forma de tratamento.**

## Uma equipe de agentes também precisa de engenharia

O segundo exemplo é a equipe de agentes que venho operando.

Quando trabalho com um ou dois agentes, conversar e distribuir tarefas diretamente costuma bastar.

Mas, quando vários agentes assumem papéis diferentes e precisam se organizar e colaborar para resolver problemas, é necessário um conjunto explícito de regras.

Quem divide a tarefa, implementa, revisa, faz a passagem e assume quando algo dá errado precisa ser definido. Ao acrescentar automações à equipe ou ao projeto, também é preciso gerir seus gatilhos e execução. Por exemplo, procurar mudanças e revisar PRs automaticamente ou, após integrar uma alteração no repositório principal, projetar o conteúdo correspondente nos sub-repositórios.

Essas necessidades ultrapassaram a manutenção manual de alguns prompts. Por isso, transformei papéis, regras de colaboração e tarefas automáticas em um projeto que pode ser gerido, operado e ampliado continuamente.

Responsabilidades, regras e políticas de execução ficam no repositório. Ele declara como a equipe deve estar, e a ferramenta de sincronização verifica diferenças em relação ao estado real. Mudanças podem ser vistas antes e conferidas depois da aplicação.

Assim, posso ajustar a equipe continuamente sem remontá-la a cada vez.

**Uma experiência de colaboração bem-sucedida pode virar uma regra comum a todos os papéis envolvidos.**

Um problema revelado por uma falha também pode entrar na configuração e na validação, servindo de base para o trabalho seguinte.

Passei a tratar a equipe de agentes como um sistema que precisa de operação e iteração. A capacidade dos modelos é só uma parte. Limites dos papéis, passagens de tarefa e formas de aceitação também precisam melhorar.

## Colocar o contexto da equipe na mesma versão

O terceiro exemplo é o MVP de declaração de impostos em andamento.

Estamos trabalhando no repositório de integração do BFO. Documentos de produto e arquitetura, contratos de interface, critérios de aceitação, código de frontend e backend e ferramentas dos agentes entram no mesmo repositório, formando uma base de versão comum.

**Quero um modo de trabalhar em que documentação seja código e código seja produto.**

Quando uma regra muda, documentos, contratos, implementação e aceitação podem mudar e ser revisados juntos. Podemos voltar a uma versão e ver quais eram as exigências, como foram implementadas e como verificamos sua correção.

Antes, esse contexto ficava espalhado por documentos, conversas e memórias. A colaboração entre papéis exigia transportar e explicar tudo várias vezes. Produto explicava, desenvolvimento interpretava e testes reconstruíam. Depois de uma mudança, era preciso confirmar novamente que todos tinham a mesma versão.

O repositório de integração oferece uma base comum.

Ele não elimina diferenças de compreensão, mas reduz o custo de encontrar material, conferir versões e repetir contexto. As discussões se concentram em mudanças concretas, e as conclusões têm onde ficar.

A IA também lê esses materiais. Ao receber uma tarefa, consegue seguir requisitos, contratos, implementação e testes para encontrar contexto, sem depender apenas das informações temporárias da conversa.

O MVP ainda está em andamento, e o retorno de longo prazo precisa ser verificado. O que mais valorizo são as iterações cotidianas futuras. Se mantivermos esses ativos junto com o produto, cada rodada poderá deixar uma base mais completa para a próxima.

**O trabalho já feito pode continuar reduzindo o custo do trabalho futuro.**

## Fatos e formas de apresentação na gestão financeira

O quarto exemplo ainda não foi implementado: meu projeto planejado de finanças pessoais e investimentos.

Hoje, mantenho no Google Drive materiais de revisão semanal, mensal e trimestral das finanças da família e acompanho o mercado continuamente.

Pretendo organizar isso aos poucos em um projeto privado: situação financeira básica, ativos, canais de investimento, observações de mercado e registros das revisões.

**O que mais me atrai é separar a fonte dos fatos da forma de apresentá-los.**

Antes, ao escolher planilha, documento ou apresentação, eu já pensava no aspecto final. A ferramenta de exibição acabava determinando a organização dos dados.

Quero primeiro manter um registro básico com fontes, datas e versões e depois gerar a apresentação conforme a pergunta.

Para ver a composição dos ativos, gero um gráfico. Para a revisão mensal, um relatório. Para entender uma mudança, sigo o histórico. Todas as formas vêm da mesma base e podem voltar a ela para conferência.

Assim, não preciso reorganizar os fatos para cada apresentação. Gráficos e relatórios podem ser gerados e ajustados a qualquer momento. A manutenção de longo prazo se concentra em precisão, completude e atualidade da informação.

Isso também mudou minha visão de engenharia. Um projeto pode guardar fatos, regras e decisões e gerar, conforme a necessidade, interfaces para pessoas lerem e usarem.

## A IA facilita recuperar o investimento em engenharia

Os casos têm algo em comum: acumularam complexidade e exigem manutenção contínua.

Antes, talvez eu não quisesse criar projetos para eles. Scripts, documentação, validação e ferramentas custam trabalho. Muitas necessidades pessoais são pequenas demais para pagar esse custo, e acabam continuando manuais.

A IA reduziu o investimento necessário.

Quando organizar configurações, escrever scripts, acrescentar testes e manter documentos fica mais barato, mais problemas merecem uma abordagem de engenharia. Proxy, colaboração de agentes, contexto da equipe e até finanças familiares entram nesse campo.

**Confiabilidade continua exigindo mecanismos concretos.**

Fatos precisam ser conferidos, mudanças validadas, falhas detectadas e, quando necessário, revertidas. A IA ajuda a criar e manter esses mecanismos, mas não os substitui.

Com essa base, tenho mais confiança para acrescentar capacidades. **O sistema pode resolver mais problemas sem exigir que minha memória e atenção cresçam na mesma proporção.**

Minha conclusão fica cada vez mais clara: tudo pode ser tratado com engenharia.

Mais precisamente, **se há em um problema uma parte que pode ser descrita, calculada e verificada, tenho a chance de organizá-la em um projeto que possa ser mantido continuamente.**

Julgamento e escolhas continuam humanos, mas a organização da informação, a execução e o feedback ao redor deles podem melhorar sem parar.

Antes, diante da complexidade, eu pensava primeiro em quanto esforço investir. Agora, pergunto se posso criar um sistema que continue crescendo depois.