Além da programação baseada em vibração: melhores práticas em 2026

Nesta postagem, você aprenderá as melhores práticas de programação em IA, os fluxos de trabalho e os padrões de engenharia de agentes que equipes reais estão utilizando em 2026.

Introdução

Nos últimos oito meses, mudei-me gradualmente de Tel Aviv para Nova York. A mudança valeu a pena, mas não consegui acompanhar o turbilhão semanal de tendências em programação de IA.

E, na programação de IA, oito meses parecem uma década.

A última vez que atualizei seriamente meu fluxo de trabalho foi por volta de dezembro de 2025. Eu estava usando o Windsurf com o Cascade (agora chamado de Devin), mudei para os modelos Claude, e a principal conclusão naquela época foi implementar um CLAUDE.md : planejar primeiro, manter as alterações simples, escrever testes, executar testes e não pular a análise da causa raiz.

A regra mais útil era também a menos glamorosa:

Primeiro, analise bem o problema, leia os arquivos relevantes e elabore um plano com uma lista de verificação para tasks/todo.md antes de começar a programar.

Essa mudança, por si só, impulsionou bastante meu desenvolvimento. Minhas sessões continuaram focadas, as “alucinações” com os agentes diminuíram bastante e eu estava resolvendo os tickets com muito mais rapidez.

Então, eu queria saber: “Que novos superpoderes surgiram nos últimos 6 meses?”

Passei um dia fazendo o que a maioria dos desenvolvedores provavelmente faz hoje em dia quando precisa se atualizar rapidamente: pedi ao Claude, ao Grok e ao ChatGPT que pesquisassem as últimas tendências de programação em IA e, em seguida, fiz com que eles discutissem entre si. Mas eu não estava procurando a demonstração mais recente. Queria saber o que realmente se consolidou.

Em seguida, verifiquei a validade dos resultados com cerca de 15 pessoas cujo julgamento considero confiável: diretores de tecnologia (CTOs), fundadores de startups, pesquisadores de IA, líderes de backend, líderes de equipe e engenheiros sênior que utilizam essas ferramentas em bases de código reais.

Foi isso que eu descobri.

Share the AI coding workflows and practices that have proven useful in production.Adoraria saber mais sobre o seu fluxo de trabalho de programação. Por favor, responda nesta publicação do LinkedIn .

Da Programação de Vibrações à Engenharia Agênica

Todos os dias, surgem novas demonstrações atraentes nas redes sociais. “Essa estrutura vai multiplicar por 10 a produtividade do seu agente!” “Se você não estiver usando essa nova ferramenta, já está ficando para trás!” Mas é difícil distinguir o que é verdadeiro do que é apenas exagero.

“Codificação de vibração”, a expressão Andrej Karpathy popularizou no início de 2025, revolucionou o desenvolvimento de software: programar descrevendo a intenção, aceitando as alterações geradas e ajustando o modelo até que o aplicativo funcione. É difícil acreditar que já fizemos algo diferente. O Dicionário Collins a elegeu como a Palavra do Ano de 2025. Mas equipes de produção sérias separaram duas ideias que costumavam ser agrupadas: usar IA para gerar código e aceitar código gerado por IA sem estrutura ou verificação suficientes.

O primeiro veio para ficar. O segundo é o problema. Uma análise da CodeRabbit de 470 pull requests reais do GitHub revelou que o código co-criado por IA continha cerca de 1,7 vez mais problemas do que o código escrito por humanos, com vulnerabilidades de segurança até 2,7 vezes maiores. O código funciona. Mas exige mais análise do que nunca.

Essa é a transição da programação baseada em vibrações para o que pode ser chamado de engenharia agentiva. O agente pode inspecionar arquivos, escrever código, executar comandos, gerar testes, depurar falhas e avaliar criticamente sua própria saída. Mas você ainda precisa de um processo de engenharia em torno disso. Especialmente se você se preocupa com a produção.

O que as equipes de verdade estão realmente fazendo

O ciclo de hype das redes sociais dá a impressão de que todo mundo está constantemente atualizando seu fluxo de trabalho: pipelines orientados por especificações, com múltiplos agentes, orquestrados na nuvem, conectados por MCP e totalmente autônomos.

Então, perguntei a um grupo pequeno, mas seleto, de amigos com responsabilidades importantes o que eles estavam fazendo. A maioria deles estava fazendo algo mais simples do que a internet quer fazer você acreditar: um agente de codificação robusto, uma etapa de planejamento, um arquivo de instruções no repositório, testes, revisão manual, troca ocasional de modelo e, às vezes, um segundo modelo para simulação de ataques (red-teaming).

Um diretor de tecnologia (CTO) colocou a questão da seguinte forma:

"Sempre planeje com antecedência. Nunca diga simplesmente ‘faça isso’, mesmo que se trate de tarefas pequenas, ou eles vão deixar coisas de lado."

Um líder de equipe disse:

"Planeje até que tudo pareça perfeito e, então, construa. Nada de complicações."

E uma engenheira sênior full-stack descreveu sua abordagem de confiança zero:

"Eu faço com que ele crie testes e, em seguida, faço com que ele teste seus próprios testes. Depois, recorro a outro agente da equipe de simulação de ataques. E, por fim, faço o teste manualmente. Se envolver dinheiro ou o ciclo de vida, o teste manual é sempre obrigatório."

Sua principal tarefa agora é planejar

Ficou bem claro que a maior parte da responsabilidade do ser humano agora é trabalhar junto com o agente para criar um plano perfeito. Meu manual tarefas/todo.md agora tem nomes mais sofisticados.

O desenvolvimento orientado por especificações é a versão mais clara: comece com a intenção, transforme-a em uma especificação, elabore um plano de implementação, divida-o em tarefas e só então deixe o agente programar. O Spec Kit do GitHub formalizou isso como spec.md, plan.mde tasks.md. O AWS Kiro usa especificações como artefatos estruturados para acompanhamento e prestação de contas.

Essa mesma ideia está aparecendo nas ferramentas. O Claude Code possui o /goal, que instrui o Claude a continuar trabalhando até que uma condição de conclusão verificável seja atendida: todos os testes sejam aprovados, todos os erros do TypeScript sejam resolvidos e a migração esteja concluída. Nos bastidores, um modelo avaliador leve verifica, após cada iteração, se a meta foi objetivamente atingida; assim, o agente repete o ciclo de forma autônoma até convergir ou atingir um limite de recursos. O Codex lançou o mesmo conceito, com estados como busca, em pausa, concluídoe com limite de orçamento que persistem mesmo após a reinicialização da sessão.

Essa é a versão finalizada de um tasks/todo.md: um objetivo duradouro ao qual o agente pode recorrer, agora com mais autonomia em torno dele.

É também o lugar onde a autonomia sai cara. Se a condição de conclusão for ambígua, o agente pode ficar em um loop por muito tempo e ainda assim não fazer a coisa certa. Autonomia sem limites é apenas uma maneira mais rápida de desperdiçar dinheiro.

No caso de tarefas complexas, o agente deve responder a três perguntas antes de editar o código: O que estamos alterando? Quais arquivos e comportamentos estão envolvidos? Como saberemos se funcionou?

O desenvolvimento orientado a testes (TDD) sempre foi pregado como se fosse um evangelho, mas colocado em prática com muito menos frequência. Agora, com a programação agênica, investir em testes é uma das principais tarefas do desenvolvedor. Um CTO que adotou a abordagem desde o início me disse: “Eu fico um pouco indeciso só na hora de formular o plano. Para qualquer recurso que eu desenvolvo, faço com que sejam escritos testes muito abrangentes. Assim, sei que vai funcionar quando estiver pronto.”

Se o agente não puder anotar isso, significa que ainda não está pronto para ser codificado.

AGENTS.md, Habilidades e Context Rot

Meu antigo fluxo de trabalho dependia de um grande arquivo CLAUDE.md . Eu o preenchi com regras e ênfases: NÃO SEJA PREGUIÇOSO. NUNCA IGNORE OS TESTES. TORNE TUDO O MAIS SIMPLES POSSÍVEL. A intenção era garantir que o agente permanecesse disciplinado e não tomasse atalhos.

E esse tipo de orientação deu certo. Em 2025, todos os provedores de agentes já contavam com alguma versão de instruções no nível do repo: Claude Code, Codex, Cursor, Copilot, Windsurf. O setor começou a se padronizar em torno de AGENTS.md: um guia no nível do repositório que informa ao agente as regras básicas do projeto.

Mas as pessoas começaram a encher seus arquivos do Claude, e isso teve um custo. Um estudo da ETH Zurich, de fevereiro de 2026, testou arquivos de instruções de repositórios em comparação com problemas reais do GitHub e descobriu que arquivos de contexto excessivamente grandes muitas vezes não melhoravam o sucesso das tarefas e podiam aumentar o custo de inferência em mais de 20%.

Acontece que o agente não fica mais disciplinado só porque você grita a mesma instrução três vezes. Na maioria das vezes, você só desperdiça fichas e acaba ofuscando as regras que realmente importam.

O novo modo de falha é a deterioração do contexto. Um mau AGENTS.md é pior do que nenhum AGENTS.md , pois o agente obedecerá com confiança a instruções desatualizadas.

Então, o setor dividiu o conceito em dois. AGENTS.md deve permanecer enxuto. Ele responde: quais são as regras e convenções específicas deste projeto?

Para todo o resto, existem as Habilidades. Uma Habilidade é uma referência carregada sob demanda para uma tarefa específica: como adicionar um novo endpoint de API, como realizar uma migração de banco de dados, como elaborar uma lista de verificação para lançamento. A Habilidade só é carregada quando o agente reconhece o padrão e precisa dela.

Na prática, fica assim:

Seus AGENTS.md diz:

Execute os testes com npm test. Sempre revise o código antes de fazer a fusão. Use a Skill webhook ao adicionar novas integrações.

A Skill do webhook diz:

Crie a rota, adicione tipos, escreva o manipulador, trate os casos de sucesso e de falha e atualize a documentação.

O agente não precisa executar todos os procedimentos em um contexto de funcionamento contínuo. Eles permanecem na Skill. Seu AGENTS.md permanece conciso. E, se o procedimento do webhook mudar, basta atualizar a Skill uma única vez.

A regra geral: mantenha AGENTS.md simples e curto. Crie uma Skill quando tiver um procedimento repetitivo que você acaba explicando várias vezes. E trate as instruções do repositório como se fossem código: revise-as, exclua regras desatualizadas e não deixe que fiquem obsoletas.

MCP e a CLI

O Protocolo de Contexto de Modelo (MCP) foi provavelmente o termo mais badalado no mundo dos desenvolvedores em 2025. A ideia era sólida: uma maneira padronizada de implementar integrações, em vez de código de ligação personalizado para cada ferramenta.

Então, é claro que, em 2026, “o MCP está morto”. Não é verdade. Mas o uso do MCP tornou-se mais complexo.

Um diretor de tecnologia (CTO) que entrevistei foi direto ao ponto:

“Os desenvolvedores quase não dependem mais do MCP. Eles ficaram assustadoramente bons em usar apenas a CLI.”

A questão central é a sobrecarga. Um servidor MCP padrão pode descarregar uma grande quantidade de esquemas de ferramentas no contexto antes mesmo que o agente faça qualquer coisa útil. As ferramentas de CLI são locais e combináveis, e os modelos já se adaptam muito bem a fluxos de trabalho no estilo Unix: comandos, opções, pipes, saída em JSON e logs.

Mas os agentes não descobrem os CLIs por mágica. Eles precisam de orientação, só que mais sucinta.

Se for uma CLI bem conhecida, como aws, gh, gcloudou docker, o agente provavelmente já sabe disso por ter sido treinado. Você pode dizer a ele: “Este projeto usa a AWS CLI. Você tem as credenciais. Use-as para a infraestrutura.” E o agente geralmente dá conta do resto.

Se for uma CLI personalizada ou interna, crie uma Skill. Geralmente, basta um parágrafo explicando o comando, os parâmetros e o formato da saída.

A discussão madura sobre o MCP não é “o MCP está morto?”. É “quais permissões você acabou de conceder a quem chama uma ferramenta probabilística?”.

O MCP faz sentido quando o agente precisa de acesso controlado a sistemas externos: documentos, tickets, observabilidade, bancos de dados, APIs. Mas se uma CLI realizar a tarefa com segurança, comece por aí. Se o mesmo procedimento da CLI se repetir, transforme-o em uma Skill. Recorra ao MCP quando nenhuma das opções for suficiente e trate cada servidor MCP como se fosse infraestrutura de produção: privilégios mínimos, aprovações, registro de logs e revisão de segurança.

A popular meme highlighting how AI agents have changed the day-to-day experience of software engineering, often shifting the role from implementation toward orchestration and oversight.

Os agentes estão se tornando aviões de controle

A grande mudança prevista para 2026 é que os agentes de programação não serão mais apenas janelas de bate-papo anexadas a um editor. Eles estão se tornando planos de controle.

Claude Code tem /goal, hooks, subagentes, sessões em segundo plano e visualizações de agente. O Codex oferece CLI, nuvem, aplicativos, worktrees, revisão de código e supervisão móvel. O GitHub Copilot pode transformar issues em PRs e revisar código. O Google Antigravity foi desenvolvido com foco no gerenciamento de agentes entre espaços de trabalho.

A interface está mudando de “conversar com uma modelo” para “gerenciar uma fila de trabalhadores de confiança parcial”.

Isso parece futurista, mas a lição prática é enfadonha: todo agente precisa de uma tarefa clara, um raio de ação limitado, uma maneira de comprovar que funcionou e uma pessoa responsável pela integração.

É aí que os agentes de longa duração se tornam úteis.

Imagine que você tenha uma lista de 30 dependências que precisam ser atualizadas. Normalmente, você teria que ficar ao lado do agente, solicitar a atualização de cada uma delas, revisar cada alteração e aprovar cada fusão. Isso leva horas e te deixa ocupado.

Um agente em execução contínua pode percorrer a lista: atualizar uma dependência, executar testes, corrigir falhas, passar para a próxima e parar quando todos os testes forem aprovados.

Esse é um bom caso de uso porque “concluído” é objetivamente verificável.

Exemplos em que agentes de longa duração realmente funcionam: atualizações de dependências, limpeza de testes, geração de documentação, exemplos de SDK, tarefas de pesquisa ou itens do backlog com critérios de aceitação bem claros, como “todos os testes foram aprovados”, “lint sem erros” ou “migração concluída”.

Quando dão errado de forma espetacular: faturamento, autenticação, permissões, migrações, exclusão, conformidade ou qualquer coisa relacionada aos dados dos clientes ou ao ciclo de vida deles. Essas situações exigem decisões baseadas no bom senso. “Essa migração é segura?” não é uma pergunta de sim ou não. Nem “devemos excluir isso?”.

A regra: use agentes de execução prolongada apenas para tarefas em que o estado “concluído” seja objetivamente verificável e em que o impacto, caso haja uma falha, seja mínimo. Todo o resto deve seguir o ritmo humano.

Se você mesmo estiver executando os agentes, o tmux continua sendo aquele truque simples que te salva. Agentes de longa duração são encerrados quando sua conexão SSH cai. Um multiplexador de terminal mantém a sessão ativa, resiste a desconexões e permite que você veja o histórico do que aconteceu.

Mas O tmux é a solução alternativa “faça você mesmo”, não o destaque. A tendência real é que as ferramentas estejam transformando esse padrão em produtos: sessões em segundo plano, painéis de controle de agentes, árvores de trabalho isoladas, aprovações remotas e filas de revisão.

Agentes persistentes sem critérios de sucesso verificáveis são apenas alucinações mais longas e mais caras.

Há também uma categoria paralela de ambientes de execução de agentes pessoais sempre ativos, como o OpenClaw e o Hermes. Eles são interessantes como planos de controle em torno do trabalho de programação: roteando mensagens, monitorando sessões, enviando alertas e, talvez, distribuindo tarefas. Mas ainda não constituem o núcleo do fluxo de trabalho de programação. Vale a pena acompanhar e experimentar, mas não pense que todo mundo já tem seu próprio agente OpenClaw. Nenhum dos 15 pioneiros que entrevistei havia configurado um.

A escolha do modelo é menos importante

A primeira pergunta que um gerente sênior de pesquisa em IA me fez quando mencionei meu fluxo de trabalho não foi sobre ferramentas ou estruturas. Foi:

"Qual é o seu orçamento para fichas?"

É isso que diferencia a engenharia da programação. Claro, com agentes de IA, se você investir dinheiro e tempo suficientes em um problema, provavelmente conseguirá desenvolvê-lo. Portanto, agora, todas as decisões relacionadas ao fluxo de trabalho dependem, em grande parte, do orçamento. E os diferentes agentes afetam o orçamento.

Algumas pessoas com quem conversei apostam tudo no Codex. Outras preferem o Claude. Os usuários do Cursor gostam de poder alternar entre modelos. Algumas pessoas usam o Copilot porque é o que a empresa delas oferece.

Um dos fundadores me disse que estava “lançando recursos de uma só vez, como um animal” com o Codex. Outro teve uma visão mais matizada:

"O Codex é incrivelmente bom em tudo que envolve computação. O Claude ainda tem mais bom gosto."

Mas o conselho mais sensato de um diretor de tecnologia (CTO) foi mais útil:

"Não fique preso a um modelo. A cada duas semanas, um fica ultrapassado e outro surge melhor."

O padrão duradouro é a “higiene de modelos”: use um modelo robusto para planejamento e raciocínio rigoroso, modelos mais simples para edições diretas, um segundo modelo para revisões de alto risco e instruções portáteis para que outro modelo ou sessão possa dar continuidade ao trabalho.

Isso se torna ainda mais importante à medida que a cobrança passa a ser baseada no uso. A estratégia vencedora não é “usar o modelo mais sofisticado para tudo”. É saber quando vale a pena investir em um raciocínio mais caro.

A verificação é agora sua outra função principal

Quando o código fica barato, verificar se ele funciona e se está bom fica caro. Isso não é um argumento contra o uso da IA para programar. É um argumento contra lançar código que você não consegue explicar.

Felizmente, as ferramentas estão se atualizando. Os hooks são scripts determinísticos que são acionados por eventos do agente. Eles permitem que as equipes tornem verificações específicas obrigatórias. Um PostToolUse pode executar automaticamente o lint ou a verificação de tipos após cada edição de arquivo, detectando problemas durante a execução, em vez de no final. Um gancho pode impedir que o agente declare vitória prematuramente. Essas são medidas de segurança que não dependem do julgamento do modelo e, para trabalhos de longa duração ou autônomos, essa distinção é importante.

Um bom ciclo de revisão poderia ser algo como:

1. Peça ao agente para escrever ou atualizar os testes.

2. Peça ao agente para executar o conjunto de testes relevante.

3. Use um segundo modelo para realizar testes de ataque (red-team) em diferenças importantes.

4. Teste manualmente os caminhos de alto risco.

Uma orientação útil antes da revisão humana:

Revise suas próprias alterações.
Identifique possíveis bugs, testes ausentes, casos extremos, problemas de segurança ou complexidade desnecessária.
Não modifique os arquivos ainda. Relate as descobertas primeiro.

A questão da segurança nesse contexto é ainda mais importante. Quando os agentes puderem comentar em PRs, executar fluxos de trabalho, acionar ferramentas e acessar credenciais, a injeção de prompts deixa de ser um problema do chatbot e passa a ser um problema de CI/CD.

Essa é a parte que, na minha opinião, muitas equipes ainda subestimam. Se o agente ler um problema, uma descrição de PR, um comentário no código ou um changelog de dependências, ele estará lendo dados não confiáveis. Se ele também tiver permissão para executar comandos ou acessar segredos, você passa a ter uma superfície de ataque.

Portanto, as regras “chatas” são ainda mais importantes: privilégio mínimo, isolamento em ambiente de teste, aprovações, pequenas alterações, verificações determinísticas, registros de Audit e responsabilidade humana.

Se eu fosse criar um novo repositório hoje

1. Crie um site enxuto AGENTS.md com comandos de instalação, teste e verificação de tipos, regras de fluxo de trabalho e uma definição de conclusão. Mantenha-o conciso. Adicione regras somente quando o agente realmente falhar em alguma coisa, não de forma preventiva.

   • Exige um planejamento contínuo para trabalhos complexos. Antes de começar a programar, o agente elabora um plano em forma de lista de verificação para tasks/todo.md com o objetivo, os arquivos relevantes, as etapas e os riscos.

   • Arquive os projetos concluídos em tarefas/arquivo/. Esses planos passam a constituir o histórico do que o agente acreditava estar fazendo e por quê.

   • Uma tarefa por solicitação, uma questão por diff. Diffs pequenos permitem a revisão. Diffs grandes ocultam bugs.

   • Nenhuma mudança de comportamento é implementada sem um teste. Se o agente disser que “não é necessário fazer um teste”, insista.

2. Escreva uma Habilidade na terceira vez que você explicar algo. Na primeira vez que orientar o agente sobre um procedimento, basta explicá-lo. Na segunda vez, observe a repetição. Na terceira vez, escreva um arquivo SKILL.md.

3. Utilize a CLI como padrão. Adicione o MCP somente quando o agente precisar de acesso controlado a um sistema externo e o caminho da CLI não for suficiente.

4. Utilize agentes de execução prolongada apenas para tarefas em que o estado “concluído” seja objetivamente verificável. Atualizações de dependências, limpeza de testes, documentação, correções de lint? Claro. Faturamento, autenticação, migrações, exclusão? Não.

5. Análises de alto risco da equipe vermelha com um segundo modelo. Antes de fazer a integração de qualquer alteração relacionada à segurança, pagamentos, permissões ou ciclo de vida dos dados, peça a um modelo diferente para identificar possíveis problemas.

6. Faça a parte humana. Analise você mesmo as diferenças. Execute o aplicativo. Teste manualmente os caminhos de risco. O agente faz a proposta. Você decide.

Conclusão

Fazer essa pesquisa me acalmou. As melhores práticas são apenas diferentes variações do que sempre foi verdade: seguir os princípios SOLID, buscar o TDD e redigir especificações detalhadas antes de começar a desenvolver.

O melhor fluxo de trabalho de programação com IA não substitui a engenharia de software. Trata-se, na verdade, de engenharia de software com um desenvolvedor júnior muito mais rápido, que nunca se cansa, às vezes tem alucinações, ocasionalmente estraga tudo e precisa de instruções muito claras.

Encare isso dessa forma e as ferramentas são incríveis. Encare isso como mágica e, mais cedo ou mais tarde, você terá que depurar a mágica.

O que você está usando?

Esta é minha primeira tentativa de me atualizar. Agora, quero ouvir a opinião de quem está realmente desenvolvendo com essas ferramentas. Como está seu fluxo de trabalho de programação de IA no momento?

Você está usando o Cursor, o Claude Code, o Codex, o Copilot ou alguma outra ferramenta? Já experimentou Skills, MCP, subagentes, árvores de trabalho, /goal, hooks ou agentes de longa duração? O que deu certo? O que você abandonou?

Por favor, me avise em esta publicação no LinkedIn.

A LinkedIn post asking developers how their AI coding workflows have evolved in 2026, including questions about planning, guardrails, and emerging agentic practices.Vou usar as melhores respostas para elaborar uma postagem complementar, na qual testarei os fluxos de trabalho mais importantes em projetos reais com a API da Vonage: agentes paralelos, planejamento com foco nas especificações e lean AGENTS.md mais Skills, MCP x CLI e ciclos de verificação que detectam bugs reais.

Vou compartilhar os resultados no próximo post.