Como trabalho com IA: eu não peço código, eu configuro o ambiente onde a IA trabalha

Quando me perguntam como uso IA no dia a dia do desenvolvimento mobile, a resposta curta é que parei de tratá-la como um autocomplete mais esperto. Acredito que o ganho real não veio de escrever prompts melhores, veio de mudar a pergunta. Em vez de "o que essa IA consegue fazer por mim hoje", passei a perguntar "que ambiente eu preciso construir pra que ela trabalhe dentro dos meus padrões, sempre". Eu chamo isso de harness.

O que é o harness

Um harness é a estrutura ao redor do agente. Não é um prompt, é uma configuração. São as regras que ele carrega antes de começar, a memória que ele consulta, os checks que ele precisa passar e as travas que o impedem de fazer besteira. A diferença é sutil mas muda tudo. Sem harness, cada sessão depende da sorte do prompt e da minha paciência de repetir contexto. Com harness, o agente já abre sabendo a arquitetura do projeto, o que ficou pendente da última vez e o que ele não tem permissão de fazer.

Os pilares

Contrato auto-carregado. Toda sessão começa lendo as regras de arquitetura e qualidade do projeto, sem eu pedir. O agente já sabe a direção de dependência das camadas, os limites entre módulos e o que é inegociável. Isso evita aquele código que funciona mas nasce fora do padrão.

Memória de trabalho. Mantenho um registro vivo do estado do projeto. Cada sessão continua de onde a anterior parou, sem depender do histórico do chat. Acredito que esse seja um dos pontos mais subestimados, porque o que mata produtividade com IA não é a IA errar, é eu ter que reconstruir contexto toda vez.

Sensores automáticos. O agente não considera uma tarefa pronta só porque o código compila. Ele precisa passar por verificações de arquitetura, tipos, lint, testes e consistência da documentação. Se algo quebra, ele mesmo vê e corrige antes de me entregar.

Gates de confirmação. Leitura roda livre, mas qualquer ação que muda ou destrói algo para e espera minha confirmação. Nada irreversível acontece sozinho. Isso me deixa rodar o agente com mais autonomia justamente porque sei que ele não vai me surpreender no que importa.

Fluxo disciplinado. Antes de escrever código, a gente conversa a ideia, escreve um plano, executa em partes e revisa. Parece burocrático, mas é o que transforma uma boa intenção em entrega previsível.

Conectores MCP: o agente age na fonte da verdade

Aqui mora um dos maiores ganhos. Conectei o agente, via MCP, ao GitHub e ao Atlassian. Isso muda a natureza do trabalho de duas formas.

A primeira é margem de erro. Em vez de eu copiar e colar contexto e torcer pra ele entender, o agente lê a fonte da verdade direto: a issue real, o PR, o código, o ticket. Menos suposição, menos alucinação, menos retrabalho. Ele trabalha com o que existe, não com o que imagina que existe.

A segunda é report e autoavaliação. Como ele enxerga o que o ticket pedia e o que foi efetivamente entregue, consigo gerar status reports honestos e, principalmente, uma autoavaliação da própria entrega. Ele cruza o combinado com o feito e aponta as lacunas. Acredito que isso seja raro de ver, é onde a IA deixa de ser só execução e vira também controle de qualidade.

Skills especializadas

Por cima do harness, ativo skills específicas conforme a tarefa: para o próprio harness e a disciplina de trabalho, para planejamento e escrita de specs, para testes, para revisão de código (inclusive revisão adversarial), para UX, para Swift e SwiftUI e para decisões de arquitetura.

Uso também uma skill de produto, no estilo PM, e essa talvez seja a que mais mudou a forma como penso entrega. Ela me ajuda a olhar além do código e perguntar o que costuma ficar de fora: isso move alguma métrica, resolve uma dor real, vale o esforço que vai custar? Acredito que muito desenvolvedor para no "ficou pronto e funciona", e eu queria conseguir responder antes disso se era a coisa certa de construir. Trazer a lente de produto pra dentro do fluxo de IA me deixa priorizar melhor, justificar o que entrego e enxergar o trabalho do ponto de vista de quem vai usar, não só de quem escreve o código.

No dia a dia do mobile

No ecossistema Claude, uso o Claude Code pra feature nova, debug, refactor e testes, e a Claude API quando o próprio app precisa de inteligência embarcada. Mas o que faz diferença não é a ferramenta, é o harness em volta dela. A mesma feature que antes eu pediria solta, hoje nasce dentro do contrato, passa pelos sensores e chega revisada.

Qualidade e velocidade, juntas

A intuição diz que disciplina é freio. Na prática foi o contrário. Acredito que fiquei mais rápido justamente porque parei de perder tempo com retrabalho, contexto perdido e código que precisava ser desfeito. A qualidade subiu porque os padrões deixaram de depender da minha memória e passaram a ser garantidos pela estrutura. Não é mágica, e nem sempre sai perfeito... já tive tropeços, decisões que precisei reverter, coisas que o agente entendeu errado. A diferença é que o harness transforma esses tropeços em algo barato de corrigir, em vez de caro.

Pra fechar

Acredito que o futuro do desenvolvimento não é sobre quem digita mais rápido, é sobre quem constrói o melhor ambiente pra IA trabalhar com segurança e consistência. Foi isso que mudou as minhas entregas.

Se algum desses temas interessar, posso me aprofundar em qualquer um:

• como funcionam os gates de confirmação na prática
• como mantenho memória entre sessões
• como uso subagentes pra executar planos em partes
• como garanto veracidade e evito que a IA invente fatos
• como os MCPs viram report e autoavaliação de entrega
• como combino skills especializadas, de Swift e arquitetura a produto, conforme a tarefa