Como estou usando IA no desenvolvimento de software

Publicado em Agosto 15, 2026

No meu post anterior sobre IA e desenvolvimento de software, algumas pessoas entenderam minha posição como se eu estivesse negando as melhorias reais que a IA traz. Esse não era bem o ponto.

Eu uso IA na maioria dos meus projetos pessoais hoje, e uso porque… bem, funciona. Ela melhora velocidade, me ajuda a explorar código, deixa implementações mais rápidas e diminui o custo de transformar ideias em algo que roda.

Mas não acho que a coisa toda virou mágica.

IA mudou bastante o meu dia a dia de desenvolvimento, mas não removeu a necessidade de engenharia de software.

Onde eu mantenho controle

A principal coisa que tento não terceirizar é o design do software.

Ainda mantenho as decisões sobre organização do projeto, fronteiras, dependências e áreas que minha experiência me diz que podem virar problema no longo prazo. A IA pode me ajudar a implementar algo dentro de uma fronteira, mas normalmente sou eu quem decide onde essa fronteira deve estar. E isso acontece porque, mesmo que a ferramenta seja boa, ela fica confortável demais em “ir seguindo em frente”.

Se você deixa uma sessão rodar por muitas iterações sem conferir, as coisas vão “driftando”. De longe, o código ainda pode parecer bom. A explicação ainda pode soar confiante. Mas a direção vai se afastando lentamente do que você quer para o projeto.

Então é preciso continuar corrigindo o rumo.

É por isso que também não sou muito fã de setups totalmente automatizados, com múltiplos agentes alterando múltiplas worktrees ao mesmo tempo. Eu entendo o apelo, e aceito que talvez exista algum cenário útil ali em algum lugar, mas não acho prático para a forma como trabalho. Em algum momento fica difícil acompanhar o que está acontecendo, e uma coisa começa a interferir na outra.

Talvez seja só um “skill issue” do meu lado. Ou talvez a aplicação seja descartável o suficiente para não precisar nem de uma preocupação de manutenção de curto prazo (sem julgamento aqui).

Mas, por enquanto, prefiro um ciclo menor que eu consiga acompanhar.

Os arquivos do projeto

Por um tempo usei uma pasta memory com arquivos Markdown para guardar decisões, e uma pasta specs para planos mais detalhados.

Isso meio que funciona.

O problema é que também fica bagunçado quando os objetivos mudam ou o projeto vai em outra direção. Você termina com bastante contexto histórico, mas nem sempre com uma fonte clara da verdade. Claro, dá para usar o git log para procurar pensamentos antigos, mas isso também é ruim.

Ultimamente, tenho tentado manter três arquivos simples nos projetos em que a assistência de IA importa:

• AGENTS.md, com dicas, convenções e meu jeito de fazer as coisas naquele projeto
• ARCHITECTURE.md, com as principais ideias que sustentam o projeto
• PROJECT.md, com o que o projeto é e por que ele existe

O README normalmente fica pequeno. Ele funciona mais como uma cola entre esses arquivos, com as informações básicas necessárias para rodar o projeto.

Se o projeto é grande o suficiente para precisar de documentação de verdade, então mantenho essa documentação no próprio repositório também, normalmente com algum gerador de site estático. É o que faço em projetos como o DNSao.

Eu não quero um framework de documentação para a IA. Quero um número pequeno de arquivos que possam ser lidos rapidamente e que descrevam o projeto bem o suficiente para evitar os erros mais óbvios.

Meu fluxo atual

A maior mudança no meu fluxo foi tirar a discussão da sessão de IA e colocar em um issue tracker de verdade.

Eu uso Gitea e OpenCode. No começo eu usava o OpenCode de forma direta. Abria uma sessão, discutia a tarefa, ia e voltava, implementava coisas, e só depois percebia que parte do raciocínio ficava basicamente preso dentro daquela sessão. Aí eu perdia o ID da sessão, tentava encontrar, falhava, e ficava bravo comigo mesmo por não ser organizado.

Isso não é prático para projetos mais longos, então migrei para issues do Gitea para acompanhar o trabalho e integrei o agente usando MCP para conseguir acompanhar e documentar as issues. Isso foi útil, mas percebi que, quando as coisas estão “no caminho certo”, eu basicamente faço um prompt no OpenCode, espero, confiro a saída, faço outro prompt, e assim por diante, o que também não era um bom fluxo.

Então, construí um pequeno daemon que verifica issues nos meus repositórios Gitea. Quando marco uma issue com a label ai, o daemon envia uma requisição para um servidor OpenCode auto-hospedado, e esse servidor roda um agente de triagem. O agente de triagem lê a issue, verifica o código do repositório e comenta de volta. Às vezes ele faz perguntas. Às vezes escreve um plano. Às vezes aponta que o pedido não está claro ou que existe um caminho mais simples, e eu respondo na issue.

Isso pode ir e vir por um tempo, até que o desenho esteja claro o suficiente e o plano pareça razoável. Depois disso, eu comento approved, e o daemon envia outra requisição para o servidor OpenCode, dessa vez usando um agente de build. O agente de build lê a discussão inteira, segue o plano aprovado, implementa a solução e abre um pull request para eu revisar.

Então eu reviso como revisaria qualquer outro pull request.

Hoje existe uma limitação: se eu quiser pedir mudanças, ainda preciso comentar de volta na issue, não no pull request. Isso é só porque estou com preguiça de atualizar o daemon para também ler comentários de pull requests. Meh, funciona agora, e o agente consegue pegar todo o contexto pela issue, então fica “mais fácil” assim.

Onde funciona bem

Eu diria que cerca de 90% dos meus pedidos fluem relativamente bem depois da discussão na issue. A etapa de triagem força a tarefa a ficar mais clara, e a etapa de implementação tende a ser bem razoável.

É aqui que a IA é forte para mim. Ela consegue ler mais código do que eu gostaria de ler para uma tarefa pequena e produzir um pull request próximo o suficiente para que revisar seja mais barato do que escrever eu mesmo.

Isso é uma melhoria real em relação às minhas experiências anteriores. E isso já não vale só para projetos greenfield. Ajuda em manutenção também, desde que o problema esteja bem delimitado e a base de código dê sinais suficientes.

Onde ainda quebra

Os 10% restantes são onde o otimismo fica caro.

Quando existe um problema mais profundo em uma base de código maior, o modelo pode desviar tanto na análise quanto na criação de uma “correção”. Mesmo modelos bons fazem isso. Eles seguem um caminho plausível, depois outro caminho plausível, e de repente você está longe da causa raiz real. Nesses casos, normalmente preciso dar uma orientação mais profunda, ou debugar e corrigir o problema eu mesmo de uma forma menor e mais controlada.

Também existe uma dinâmica ruim quando tento terceirizar o pensamento durante uma emergência, ou quando algo está quebrado em produção. Nesse contexto, esperar a resposta da IA pode virar uma armadilha. Você pergunta, espera, lê a resposta confiante, e, como quer que o problema seja resolvido, pode aceitar o plano com mais facilidade do que deveria.

E isso é especialmente frustrante quando a resposta é confiante e você sabe que está errada.

Ultimamente, quando isso acontece, tento mandar um bom prompt, mas continuo investigando eu mesmo. A IA vira mais uma ferramenta de debug.

O equilíbrio atual

Então minha conclusão é parecida com a anterior, mas um pouco atualizada.

IA resolve muitos problemas. Ela é realmente útil, e em muitos casos provavelmente é o principal artefato na minha caixa de ferramentas agora. Ajuda com protótipos, manutenção, busca em código, refatoração, implementação chata e bastante do trabalho de cola que existe em volta do desenvolvimento de software.

Também admito que ela resolve mais problemas agora do que resolvia antes.

Mas o mantra de “você precisa estudar IA ou vai ficar para trás” ainda não faz sentido para mim. Se você já sabe programar, usar essas ferramentas não é muito difícil.

É por isso que não acho que engenharia de software morreu. Eu ainda acho que alguém precisa realmente entender o sistema.