Meu fluxo de trabalho de programação com LLM pensando em 2026

• Assistentes de programação com IA se consolidaram como ferramenta central do desenvolvimento prático ao longo de 2025, e, para usá-los com eficácia, um fluxo de trabalho estruturado e a intervenção responsável de humanos são indispensáveis
• Em vez de pedir geração de código imediatamente, começar por definir especificações claras e um plano e, com base nisso, avançar com a implementação em etapas aumenta ao mesmo tempo a qualidade e a produtividade
• Quanto mais o trabalho for dividido em unidades pequenas e receber contexto e restrições suficientes, mais os erros e problemas de consistência dos LLMs podem ser reduzidos
• Em vez de depender de um único modelo, está se difundindo um fluxo de selecionar vários LLMs e ferramentas conforme o objetivo e usar IA como apoio ao longo de todo o ciclo de desenvolvimento
• No fim, quando o ser humano mantém o controle por meio de testes, revisão e controle de versão, a IA funciona como um poderoso amplificador de produtividade

---

Visão geral

• Ao longo de 2025, os assistentes de programação com IA passaram a ser usados em larga escala na escrita de código de produtos reais
• Engenheiros da Anthropic adotaram ativamente o Claude Code e chegaram ao ponto em que cerca de 90% do código do Claude Code é escrito pelo próprio Claude Code
• Usar LLMs em programação não é magia feita com um clique: aprender novos padrões e pensar criticamente é essencial
• É possível usar IA de forma agressiva, mas a responsabilidade pelo software produzido continua sendo do próprio desenvolvedor
• O ponto central é tratar o LLM não como um tomador de decisões autônomo, mas como um poderoso programador em par que precisa de direção clara, contexto e supervisão

Comece com um plano claro (especificação primeiro, código depois)

• Em vez de lançar um pedido vago ao LLM, é preciso começar pela definição do problema e pelo plano da solução
• No caso de um novo projeto, explique a ideia e peça ao LLM para fazer perguntas de forma iterativa, a fim de detalhar requisitos e casos de borda
• No fim, organize tudo em um spec.md com requisitos, decisões de arquitetura, modelo de dados e estratégia de testes
• Insira a especificação em um modelo capaz de raciocinar para gerar um plano de projeto que divida a implementação em tarefas lógicas e pequenas
• Como diz Les Orchard, passar por uma etapa rápida e estruturada de planejamento no estilo "cascata em 15 minutos" faz com que a codificação posterior flua muito melhor
• Com especificação e plano claros, tanto humanos quanto LLMs entendem exatamente o que estão construindo e por quê, evitando retrabalho e ciclos desperdiçados

Divida o trabalho em chunks pequenos e iterativos

• Em vez de exigir uma saída gigantesca do LLM de uma vez, divida o projeto em etapas repetíveis ou tickets menores e processe-os em sequência
  • Ex.: usar prompts em unidades como “implemente o Step 1 do plano” e, após codificar e testar, seguir para o Step 2
• Quando se joga escopo demais de uma vez, o modelo se confunde ou entrega resultados bagunçados, e o custo para consertar dispara
• Ao pedir que ele gerasse partes grandes do app de uma só vez, houve colapso de consistência e acúmulo de código duplicado, com avaliações de que “parecia ter sido feito por 10 pessoas sem conversar entre si”
• A cada iteração, aproveita-se o contexto já construído para adicionar coisas de forma gradual, o que também combina bem com a abordagem TDD (desenvolvimento orientado a testes)
• Algumas ferramentas de agentes de programação dão suporte explícito a esse fluxo em chunks e podem gerar arquivos de plano de prompts para execução sequencial

Forneça contexto amplo e orientação

• Como os LLMs só conseguem performar dentro do escopo do contexto fornecido, é preciso oferecer código, documentação e restrições relevantes em quantidade suficiente
• No modo Projects, o Claude pode carregar um repositório inteiro do GitHub como contexto, e assistentes de IDE como Cursor e Copilot incluem automaticamente os arquivos abertos
• O método de brain dump de passar antecipadamente ao modelo as informações que ele precisa saber é eficaz, incluindo objetivos de alto nível, exemplos de soluções desejáveis e até abordagens a evitar
• Ferramentas como gitingest e repo2txt permitem despejar em um arquivo de texto as partes necessárias do codebase para fornecê-las ao LLM
• Claude Skills é uma abordagem que vai além de depender de prompts repetitivos, reunindo instruções, scripts e especialização de domínio em módulos duráveis e reutilizáveis
  • Também existe uma coleção de Skills com curadoria da comunidade
  • A skill frontend-design pode até corrigir a estética de design excessivamente roxa que costuma aparecer em UIs geradas por LLM
• Também é muito eficaz incluir comentários e regras diretamente no prompt para guiar a IA
  • Ex.: “Aqui está a implementação atual de X. Expanda isso para Y, mas sem quebrar Z”
• Como os LLMs têm uma característica literal de seguir instruções ao pé da letra, quanto mais detalhadas e contextualizadas forem as instruções, menores tendem a ser as alucinações e sugestões sem sentido

Escolha o modelo certo (e use vários, se necessário)

• Nem todos os LLMs de programação estão no mesmo nível, e é importante selecionar intencionalmente o modelo ou serviço de acordo com a natureza da tarefa
• Em alguns casos, usar dois ou mais LLMs em paralelo para validar abordagens diferentes para o mesmo problema é eficaz
• Cada modelo tem tendências e pontos fortes próprios, então é preciso saber trocar de modelo quando um emperra ou entrega um resultado mediano
• A abordagem de “cadeiras musicais de modelos”, em que o mesmo prompt é levado e testado em outro serviço, ajuda a evitar pontos cegos de um modelo específico
• Se possível, usar os modelos mais recentes da camada Pro oferece vantagem clara em qualidade
• Quando a colaboração será longa, a “vibe” do programador em par de IA — o tom das respostas e a sensação da interação — combinar com você também é um critério importante de escolha

Use IA ao longo de todo o ciclo de vida

• Em ambientes de linha de comando, agentes de IA como Claude Code, OpenAI Codex CLI e Google Gemini CLI surgiram permitindo ler arquivos, executar testes e fazer correções em múltiplas etapas dentro do diretório do projeto
• Jules, do Google, e Copilot Agent, do GitHub, podem ser usados como agentes assíncronos de programação que clonam o repositório em uma VM na nuvem, trabalham nele e depois abrem um PR
• Essas ferramentas não são perfeitas, e entender suas limitações antes de usá-las é essencial
  • Elas aceleram bastante tarefas mecânicas como geração de boilerplate, aplicação de mudanças repetitivas e execução automática de testes, mas a qualidade ainda depende fortemente da orientação humana
• Ao usar agentes, fornecer um plano ou lista de tarefas logo no início ajuda muito no reconhecimento da ordem correta do trabalho
• Ainda não estamos no estágio em que um agente de IA implementa sozinho uma funcionalidade inteira e entrega um resultado perfeito; o uso supervisionado continua sendo a abordagem realista
• Estão em andamento experimentos com ferramentas de orquestração como Conductor para executar vários agentes em paralelo e tratar funcionalidades diferentes ao mesmo tempo

Manter o humano no loop — validar, testar e revisar com rigor

• A IA gera código plausível sem hesitar, mas a responsabilidade pela qualidade e pelos resultados é inteiramente do desenvolvedor
• Como diz Simon Willison, o LLM como pair programmer deve ser visto como algo excessivamente confiante e propenso a errar, escrevendo bugs ou código sem sentido com total convicção
• Snippets de código gerados por IA devem ser tratados como código de um desenvolvedor júnior; é preciso ler, executar e testar o código conforme necessário
• Inclua testes naturalmente no fluxo de trabalho e, desde a fase de planejamento, desenhe uma lista de testes e um plano de testes para cada etapa
• Em ferramentas como Claude Code, instrua explicitamente a execução da suíte de testes após implementar a tarefa e, se houver falha, prossiga com a análise da causa e a correção
• Os casos em que agentes de código funcionam melhor costumam ser os de equipes e indivíduos com uma cultura de testes sólida
• Em ambientes sem testes, existe o risco de o agente assumir que está tudo certo mesmo tendo quebrado várias partes do sistema
• Além dos testes automatizados, mantenha a revisão de código como etapa obrigatória, combinando revisão manual e revisão com IA
  • Use uma sessão de IA separada ou outro modelo para pedir que critique ou revise o código escrito pela primeira IA
  • Ex.: depois que Claude escrever o código, pedir ao Gemini que revise erros ou possibilidades de melhoria daquela função
• Use o Chrome DevTools MCP como ferramenta central do loop de depuração e qualidade, fechando a lacuna entre análise estática e execução real no navegador
  • Dê ao agente de IA acesso para observar diretamente a estrutura do DOM, traces de performance, logs do console e requisições de rede
  • Isso permite executar testes automatizados de UI com LLM sem precisar transferir contexto manualmente
  • Também viabiliza um fluxo de diagnosticar e corrigir bugs com precisão com base em dados reais de runtime
• Um desenvolvedor relatou que o resultado de depender demais de geração por IA em um projeto urgente foi uma bagunça inconsistente
  • Lógica duplicada, nomes de método diferentes entre si e uma arquitetura não integrada foram se acumulando
  • Ele refletiu que só continuou gerando mais e mais, sem dar um passo atrás para inspecionar a estrutura geral montada pela IA
  • No fim, concluiu com um grande refactoring e a decisão de nunca mais deixar tudo sem supervisão
• Independentemente do volume de uso de IA, o desenvolvedor deve continuar sendo um engenheiro responsável até o fim
• Na prática, faça merge ou deploy só depois de entender o código e, se a IA produzir uma implementação complexa, peça comentários explicativos ou uma reescrita mais simples

Fazer commits frequentes e usar controle de versão como rede de segurança

• Quanto mais você trabalha com uma IA que gera grandes volumes de código rapidamente, mais precisa de hábitos de versionamento detalhados
• Sempre que concluir uma pequena tarefa ou uma correção automática der certo, faça um commit git com mensagem clara para garantir um checkpoint ao qual voltar imediatamente se a próxima mudança causar problema
• Trate commits como save points de jogo, para poder retornar ao último estado estável sempre que uma sessão com LLM sair dos trilhos
• O controle de versão também tem papel importante na colaboração com IA; quando a janela de contexto não consegue lembrar de todas as mudanças, o histórico do git vira um log confiável do trabalho
• Ao passar os commits recentes, é possível fazer um briefing rápido das mudanças para a IA ou para você mesmo
• Se incluir git diff ou o log de commits no prompt, o LLM entende com precisão o novo código e o estado anterior
• LLMs são bons em interpretar diffs e usar ferramentas como git bisect, podendo rastrear com persistência o ponto em que um bug foi introduzido ao longo do histórico de commits
• Commits pequenos e mensagens claras documentam naturalmente o processo de desenvolvimento, o que ajuda muito em code review
• Mesmo quando um agente de IA faz várias mudanças de uma vez, se elas estiverem separadas por commit, fica mais fácil identificar exatamente o ponto que causou o problema
• Use branches ou worktrees para isolar experimentos com IA do código principal
  • Inspirado por Jesse Vincent, crie um git worktree novo para cada novo recurso ou subprojeto
  • Rode várias sessões de coding com IA em paralelo no mesmo repositório, sem interferência entre elas, e faça merge dos resultados seletivamente
  • Isso faz com que cada tarefa de IA fique em sua própria branch sandbox; experimentos fracassados podem ser descartados sem afetar a main
• Mantenha a regra de nunca fazer commit de código que você não entende ou não consegue explicar

Customizar o comportamento da IA com regras e exemplos

• Em vez de aceitar o estilo ou a abordagem padrão da IA, dar diretrizes claras já tem grande impacto na qualidade e na consistência da saída
• Mantenha periodicamente o arquivo CLAUDE.md para explicitar as regras de processo e preferências que o Claude deve seguir e, ao usar Gemini CLI, adote o mesmo padrão com GEMINI.md
  • Ex.: escrever código de acordo com o estilo do projeto, seguir regras de lint, proibir o uso de certas funções, preferir estilo funcional a OOP etc.
  • A ideia é fornecer esse arquivo ao Claude no início da sessão para alinhar todo o trabalho às convenções
  • Segundo Jesse Vincent, essa abordagem reduz a frequência com que a IA desvia para direções indesejadas ou introduz padrões estranhos
• Mesmo sem um arquivo de regras separado, é possível definir o tom e o comportamento geral com custom instructions ou system prompts
  • Tanto GitHub Copilot quanto Cursor oferecem recursos para configurar globalmente o comportamento da IA por projeto
  • Especifique o estilo de código em um parágrafo curto: “usar indentação de 4 espaços, evitar arrow functions em React, usar nomes de variáveis descritivos, o código deve passar no ESLint”
  • Ben Congdon comentou que ficou surpreso com o fato de o recurso de custom instructions do Copilot ser tão pouco usado; segundo ele, apenas fornecer alguns exemplos e preferências com antecedência já permite gerar código alinhado aos idiomatismos da equipe
• Fornecer exemplos inline é uma técnica especialmente poderosa
  • Se quiser uma função implementada de certa forma, primeiro mostre uma função parecida que já existe no codebase e oriente: “X foi implementado assim, então use a mesma abordagem para Y”
  • Se quiser alinhar o estilo de comentários, escreva você mesmo uma linha e depois peça para seguir aquele padrão
  • No fim, trata-se de priming do modelo com o padrão a ser seguido, e os LLMs são muito bons nesse tipo de imitação
• A comunidade compartilha diversos conjuntos de regras para refinar o comportamento de LLMs
  • Como as regras "Big Daddy" ou a adição, no prompt, de uma cláusula do tipo “proibido alucinar ou enganar”
  • São mecanismos para reduzir o comportamento de a IA inventar código inexistente ou agir com confiança excessiva
  • Ex.: adicionar no começo do prompt “se houver incerteza ou faltar contexto do codebase, não invente uma resposta; peça esclarecimentos” para reduzir alucinações
  • Outra regra útil é: “ao corrigir bugs, sempre explique brevemente o motivo em um comentário”; assim, a IA deixa junto comentários como // Fixed: changed X to Y to prevent Z according to spec

Adotar testes e automação como amplificadores de força

• Quanto mais CI/CD, linters e bots de code review forem usados ativamente, melhor a IA funciona em um ambiente que filtra erros automaticamente
• Quanto maior a proporção de código gerado por IA em um repositório, mais essencial se torna um ambiente robusto de integração contínua
  • Executar testes automaticamente a cada commit ou PR, exigir verificações de estilo de código como ESLint e Prettier e, se possível, incluir até deploy de staging por branch
  • É possível configurar para que a própria IA dispare isso e avalie os resultados
  • Ex.: quando Jules ou GitHub Copilot Agent abre um PR, o CI executa os testes e reporta falhas → os logs de erro são enviados à IA para conectar com algo como “o teste de integração falhou em XYZ, vamos depurar juntos”
  • O processo de correção de bugs se transforma em um loop colaborativo com feedback rápido, ao qual a IA responde especialmente bem
• As verificações automatizadas de qualidade de código também funcionam como leme para a IA
  • Incluir a saída do linter diretamente no prompt e, se a IA escrever um código que falhe no lint, copiar a mensagem de erro e pedir “resolva estes problemas”
  • É como ter um professor rigoroso observando a IA por cima do ombro
  • Quando a IA percebe uma saída de ferramenta, como falha em teste ou aviso de linter, ela tenta corrigir com persistência
• Os próprios agentes de codificação com IA estão incorporando cada vez mais hooks de automação
  • Alguns agentes não reconhecem o trabalho como “concluído” até que todos os testes passem
• Bots de code review, sejam IA ou humanos, também podem ser usados como filtro adicional
  • Usar os comentários da revisão diretamente como prompt de melhoria
  • Ex.: se o CodeRabbit ou outro revisor deixar “esta função está fazendo X, mas isso não é o ideal”, pedir à IA “você pode refatorar isso incorporando esse feedback?”
• Ao combinar IA e automação, forma-se um ciclo virtuoso
  • A IA escreve código → as ferramentas de automação detectam problemas → a IA corrige → repete, enquanto o desenvolvedor supervisiona apenas a direção de alto nível
  • É como o trabalho de um desenvolvedor júnior extremamente rápido sendo validado de imediato por um engenheiro de QA incansável
  • Porém, esse ambiente precisa ser construído pelo próprio desenvolvedor e, em projetos sem testes ou automação, há o risco de bugs sutis e queda de qualidade causados pela IA só aparecerem muito depois
• Uma das metas rumo a 2026 é fortalecer os quality gates ao redor das contribuições de código feitas por IA
  • Mais testes, mais monitoramento e, se necessário, até uma estrutura em que IA revise IA
  • Já foram observados casos reais em que um modelo detecta problemas que outro deixou passar

Aprendizado e adaptação contínuos (a IA amplifica habilidades)

• Ao tratar toda sessão de programação com IA como uma oportunidade de aprendizado, forma-se um ciclo virtuoso em que, quanto mais o conhecimento cresce, maior também é a ajuda da IA
• Ao usar LLMs no desenvolvimento, a exposição a novas linguagens, frameworks e técnicas que normalmente não seriam tentados acontece de forma natural
• Quando há uma base sólida de engenharia de software, a IA amplifica a produtividade em várias vezes; quando essa base é fraca, a confusão também é amplificada
• Uma observação comum entre desenvolvedores experientes é que os LLMs tendem a reforçar as melhores práticas existentes
  • Especificações claras, testes bem estruturados e code review constante geram ainda mais efeito conforme a IA entra no processo
• Enquanto a IA cuida do boilerplate, o desenvolvedor pode se concentrar em abstrações de alto nível como design, interfaces e arquitetura, mas isso exige que essa capacidade já exista
• Como aponta Simon Willison, quase tudo o que forma um engenheiro sênior — design de sistemas, gestão de complexidade, julgamento entre automação e trabalho manual — agora leva aos melhores resultados quando combinado com IA
• O uso de IA de fato estimula a melhoria da capacidade de engenharia
  • A pessoa se torna mais rigorosa na fase de planejamento e pensa de forma mais consciente sobre arquitetura
  • Ao assumir o papel de gerenciar uma IA que programa muito rápido, mas é um tanto ingênua, o discernimento também se fortalece
• Sobre a preocupação de que a IA possa reduzir habilidades, quando usada corretamente o resultado tende a ser o oposto
  • Aprender novos idiomatismos e formas de resolver problemas por meio da revisão do código gerado pela IA
  • Aprofundar o entendimento da linguagem e do domínio do problema ao depurar erros da IA
  • Pedir que ela explique o código ou o motivo das mudanças, fazendo perguntas constantes como em uma entrevista com um candidato e extraindo insights
  • Quando houver dúvida sobre uma biblioteca ou abordagem, usar a IA como assistente de pesquisa para comparar opções e trade-offs
• No panorama geral, ferramentas de IA amplificam a especialização
  • À medida que 2026 se aproxima, em vez do medo de perder o emprego, cresce a expectativa de passar menos tempo em tarefas repetitivas e monótonas e mais tempo em problemas criativos e complexos
  • Por outro lado, sem uma base sólida, também existe o risco de a IA levar a um efeito Dunning-Kruger turbinado por esteroides
• Como conselho, é preciso um equilíbrio deliberado: continuar refinando as habilidades técnicas, acelerar aprendizado e produtividade com IA e periodicamente programar sem IA para manter os fundamentos afiados
• No fim, a combinação entre desenvolvedor e IA é muito mais poderosa do que qualquer um dos dois isoladamente, e nessa combinação o lado humano precisa cumprir plenamente seu papel

Conclusão

• A IA foi adotada ativamente em todo o fluxo de trabalho de desenvolvimento, mas mantendo uma abordagem cuidadosa e liderada por especialistas
• A direção desejada não é um desenvolvimento em que a IA automatiza tudo, e sim “engenharia de software aumentada por IA”
• Os melhores resultados surgem quando se aplica à colaboração com IA a mesma disciplina clássica da engenharia de software
• Todas as práticas conquistadas com esforço — como projetar antes de programar, escrever testes, usar controle de versão e manter padrões de código — continuam válidas e, quando a IA escreve metade do código, tornam-se ainda mais importantes
• As ferramentas continuarão evoluindo, e o fluxo de trabalho também deve evoluir junto
  • “Estagiários de desenvolvimento com IA” totalmente autônomos assumirão mais tarefas simples, enquanto humanos focam em problemas de alto nível
  • Novas formas de depuração e novos paradigmas de exploração de código podem surgir
• Em qualquer mudança, a postura é permanecer sempre dentro do loop
  • Guiar a IA, validar os resultados, aprender durante o processo e expandir a produtividade com responsabilidade
• A conclusão final é clara: assistentes de programação com IA são amplificadores poderosos, mas o diretor do palco continua sendo o engenheiro humano até o fim

[gracefullight]

Quanto mais tudo é abstraído, mais a engenharia parece se tornar importante.