Do Ágil ao Agêntico: Por Que o Desenvolvimento de Software Precisa de Uma Nova Disciplina

A prática da engenharia de software está mudando. Quando agentes de IA escrevem a maior parte da implementação, o desafio não é mais coordenar desenvolvedores humanos. É especificar o que construir, governar o que os agentes produzem e redesenhar como as equipes operam. Múltiplas estruturas de engenharia AI-native emergiram para abordar partes deste problema, desde fluxos de trabalho orientados por especificações até portais de avaliação automatizada. Mas nenhuma delas aborda completamente o lado organizacional: como os papéis evoluem, como desenvolvedores juniores crescem, que rituais devem ser seguidos, como a governança escala com confiança. Este artigo propõe desenvolvimento agêntico como uma disciplina que se baseia nessas estruturas e na experiência de desenvolvimento de software empresarial para abordar o quadro completo, incluindo pessoas e processos.

A Mudança Que Já Aconteceu

Agile foi construído sobre três premissas. Primeiro, humanos escrevem todo o código¹, então o gargalo é a coordenação entre pessoas. Segundo, requisitos são melhor expressos como narrativas, especificamente histórias de usuário que capturam intenção e deixam a implementação para o desenvolvedor². Terceiro, qualidade é garantida através de revisão por pares, onde outro humano lê o código antes dele ser publicado³.

Todas as três premissas se sustentaram por vinte anos. Nenhuma delas se sustenta agora.

Segundo o Anthropic's 2026 Agentic Coding Trends Report, desenvolvedores já usam IA em 60% do seu trabalho. Código gerado por agentes não é um cenário futuro. É a condição operacional atual. E quando agentes escrevem a maior parte da implementação, a mecânica de construir software muda de maneiras que Agile nunca foi projetado para lidar.

Considere o que acontece quando uma equipe tenta executar sprints com saída gerada por agentes. Velocidade de sprint se torna sem significado porque um agente completa uma tarefa em minutos, não dias, então métricas de velocidade não medem nada útil. Story points desabam porque o esforço não está mais em escrever código mas em especificar o que o código deve fazer e validar que ele fez isso corretamente. Standups se tornam reuniões de status sobre saída de agentes ao invés de sessões de coordenação entre pessoas fazendo o trabalho. Revisão de código não escala. Quando agentes produzem dez vezes o volume de código, esperar que humanos revisem cada linha não é diligência. É um gargalo.

Isso não é um ataque ao Agile. Agile resolveu o problema certo para sua época: como coordenar desenvolvedores humanos construindo software iterativamente. O problema é que as condições operacionais mudaram. A unidade de trabalho não é mais uma tarefa humana estimada em story points. É uma especificação executável por agente validada por portais automatizados. Essa mudança requer uma disciplina diferente.

O Que Desenvolvimento Agêntico Realmente É

Desenvolvimento agêntico não é uma estrutura. Não é uma cadeia de ferramentas. Não é uma metodologia de fornecedor.

É uma disciplina focada em pessoas e processos: as mudanças sociotécnicas necessárias quando agentes de IA se tornam participantes de primeira classe no desenvolvimento de software. Como papéis evoluem. Como equipes se organizam. Como confiança é conquistada incrementalmente. Como governança escala sem se tornar um gargalo.

As ferramentas importam, mas são implementações. Se uma equipe usa BMAD, Spec Kit, Kiro ou uma abordagem própria, as questões de pessoas e processos são as mesmas: Quem possui a arquitetura quando agentes escrevem o código? Que artefatos a equipe produz e mantém? Como um desenvolvedor junior cresce quando as tarefas das quais ele costumava aprender agora são automatizadas? Como uma organização move de supervisão humana completa para supervisão seletiva sem perder controle?

Esta distinção importa porque os termos adjacentes (programação por vibe, engenharia agêntica, programação agêntica) cada um descreve algo mais restrito.

Vibe coding é desenvolvimento sem disciplina. Um desenvolvedor descreve o que quer em linguagem natural, a IA gera código, e o desenvolvedor aceita com revisão mínima. Funciona para protótipos e scripts descartáveis. Explicitamente não é desenvolvimento agêntico. São paradigmas incompatíveis, não pontos em um espectro, porque vibe coding abandona o rigor de governança e especificação que desenvolvimento agêntico requer.

Engenharia agêntica, como Addy Osmani e outros descrevem, é uma prática individual: supervisão humana mais implementação por IA. É valiosa, mas aborda apenas o fluxo de trabalho do desenvolvedor, não a equipe, a organização ou o modelo de governança.

Programação agêntica é centrada em ferramentas: como configurar e usar agentes de programação de IA efetivamente. Importante, mas não suficiente.

Desenvolvimento agêntico é a disciplina que se situa acima de todas essas. Aborda pessoas e organizações, não apenas tecnologia. É agnóstico a estruturas por design, opinativo sobre princípios e flexível sobre implementações.

Startup vs Empresa: Mesmas Ferramentas, Disciplina Diferente

Um fundador solo construindo com Claude Code e uma organização de engenharia de 200 pessoas adotando Kiro ambos usam agentes de IA para escrever código. Mas os desafios de pessoas e processos que enfrentam são fundamentalmente diferentes, e confundi-los é um dos erros mais comuns neste espaço.

Em uma startup ou equipe pequena, a disciplina é leve. Um único desenvolvedor pode manter o contexto completo do sistema em sua cabeça. Especificações podem ser um arquivo CLAUDE.md e alguns prompts bem estruturados. Governança é implícita porque o fundador revisa saída de agentes diretamente como o único tomador de decisões. O loop de feedback é apertado: especificar, gerar, revisar, publicar. O gargalo não é coordenação ou governança. É qualidade de contexto, se o agente tem informação suficiente para produzir saída correta. Uma startup não precisa de uma Equipe Híbrida ou um Gerente de Fluxo. Precisa de boas especificações e iteração rápida.

Em uma empresa complexa, cada uma dessas premissas se quebra. Nenhuma pessoa única mantém o contexto completo. Múltiplas equipes interagem com a mesma base de código, cada uma com conhecimento de domínio diferente. Especificações devem ser precisas o suficiente para agentes executarem sem acesso ao engenheiro sênior que "simplesmente sabe" como o módulo de cobrança funciona. Governança não pode ser implícita. Quando 50 agentes estão produzindo código através de 12 equipes, alguém precisa decidir qual saída é implantada, como consistência arquitetural é mantida, e o que acontece quando um agente produz algo que passa em todos os testes mas viola uma regra de negócio não documentada.

É aqui que as questões de pessoas e processos se tornam inevitáveis:

• Papéis mudam. O Arquiteto de Contexto (alguém que curada e estrutura a informação que agentes consomem) se torna tão crítico quanto o engenheiro sênior. O Operador de Agente (alguém que monitora, ajusta e intervém em fluxos de trabalho de agentes) é um papel que não existia dois anos atrás.
• Estruturas de equipe mudam. Uma Equipe Híbrida não é uma equipe Scrum tradicional com um complemento de IA. É uma composição diferente: menos desenvolvedores, mais especialistas em contexto e avaliação, com agentes como membros de primeira classe da equipe cuja saída é governada, não apenas consumida.
• Governança deve ser estrutural. Você não pode confiar em uma política que diz "revisar toda saída de agente" quando o volume torna isso impossível. Você precisa de portais automatizados: verificações determinísticas que rodam antes de qualquer julgamento probabilístico, ferramentas de avaliação que validam saída contra amostras de referência, e caminhos claros de escalação para quando agentes ficam presos.
• O pipeline de talentos juniores se quebra. Se agentes absorvem as tarefas das quais desenvolvedores juniores costumavam aprender (correção de bugs, recursos pequenos, código boilerplate), então a organização deve intencionalmente redesenhar como juniores constroem expertise. Isso não é um efeito colateral para gerenciar depois. É um problema estrutural para resolver agora.

A disciplina do desenvolvimento agêntico deve ser flexível o suficiente para servir ambos os contextos. Uma startup precisa dos princípios sem a sobrecarga. Uma empresa precisa dos princípios operacionalizados em papéis, cerimônias e estruturas de governança. Os princípios são os mesmos. A implementação escala com complexidade organizacional.

O Panorama: Muitas Estruturas, Uma Camada Faltando

O panorama de desenvolvimento agêntico em 2026 não carece de estruturas. BMAD oferece 12 personas de agentes especializados. Spec Kit fornece um fluxo de trabalho de seis fases da constituição à implementação. Kiro integra desenvolvimento orientado por especificações em um IDE. A Agentic AI Foundation foi lançada sob a Linux Foundation para padronizar protocolos e interoperabilidade.

Toda estrutura séria converge em três princípios técnicos. Primeiro, especificações sobre prompts: especificações estruturadas e legíveis por máquina produzem melhor saída de agentes do que prompting conversacional. Segundo, contexto é a restrição. Qualidade da saída de agentes é proporcional à qualidade do contexto, não capacidade do modelo. Um modelo medíocre com excelente contexto supera um modelo de fronteira com instruções vagas. Terceiro, governança automatizada: revisão de código humana não escala com throughput de agentes, então portais de avaliação automatizada são necessários.

Essas são contribuições valiosas. Cada estrutura resolve uma peça real do quebra-cabeça: criação de especificações, orquestração de agentes, automatização de governança, padronização de protocolos.

Mas há uma camada que nenhuma delas aborda completamente: o lado humano.

Quem possui arquitetura quando agentes escrevem o código? Como equipes se reorganizam quando a proporção de desenvolvedores humanos para tarefas executadas por agentes muda de 1:1 para 1:10? Como você desenvolve talento junior quando tarefas de nível inicial são automatizadas? Como governança escala com confiança, movendo de supervisão completa para supervisão seletiva conforme a organização demonstra confiabilidade em cada nível?

Os experimentos de Birgitta Böckeler com Spec-Driven Development, publicados no blog de Martin Fowler, revelaram que mesmo com especificações detalhadas, agentes geraram recursos não solicitados e alegaram sucesso em builds falhados. As especificações estavam corretas. A governança estava faltando. Ferramentas sozinhas não resolvem o problema. A disciplina em torno das ferramentas é o que as faz funcionar em organizações reais.

Desenvolvimento agêntico como disciplina se situa acima de qualquer estrutura específica. É a camada que aborda pessoas e processos, as questões que atravessam toda ferramenta, todo fornecedor, toda metodologia.

Princípios Preliminares para Desenvolvimento Agêntico

Em fevereiro de 2001, dezessete praticantes de software se encontraram em um ski lodge em Snowbird, Utah. Eles discordavam em quase tudo exceto uma convicção: os processos pesados e orientados por documentos dominando o desenvolvimento de software estavam falhando. Eles produziram o Agile Manifesto: quatro valores e doze princípios que remodelaram a indústria por vinte anos.

As condições operacionais que tornaram Agile necessário mudaram novamente. O que segue é um rascunho, não um manifesto, não um padrão, mas um ponto de partida para uma conversa comunitária. Esses princípios são opiniosos sobre pessoas e processos, deliberadamente agnósticos sobre ferramentas e estruturas.

Contexto sobre capacidade. A qualidade da saída de agentes depende da qualidade da entrada, não da inteligência do modelo. Corrija o contexto, não o modelo. Uma equipe que investe em arquitetura de contexto (informação estruturada, curadada e versionada que agentes consomem) superará uma equipe perseguindo o último lançamento de modelo. Na prática, isso significa tratar contexto como um artefato de engenharia de primeira classe: um Índice de Contexto que é mantido, testado e governado como código.

Especificações sobre prompts. Especificações estruturadas, não instruções conversacionais. Uma Especificação Viva é um documento legível por máquina que define o que o agente deve construir, que restrições deve respeitar e como a saída será validada. Não é uma história de usuário. Não é um prompt. É um artefato durável que sobrevive ao ciclo de implementação e se torna a fonte da verdade. A Proporção Especificação-para-Código (quanta especificação existe relativa ao código gerado) é uma métrica de saúde melhor do que linhas de código ou velocidade.

Governança por estrutura, não política. Portais determinísticos antes de julgamento probabilístico. Uma política que diz "revisar toda saída de agente" falha no momento em que volume excede capacidade humana. Governança deve ser estrutural: verificações automatizadas que rodam em toda saída, ferramentas de avaliação que comparam resultados contra amostras de referência, e caminhos claros de escalação quando saída falha na validação. Confie no portal, não no memorando.

Autonomia graduada. Confiança conquistada, não delegação binária. Organizações não devem escolher entre "humano faz tudo" e "agente faz tudo". Há uma progressão: observar saída de agente → deixar agentes sugerir → deixar agentes agir com supervisão humana → deixar agentes agir autonomamente. Cada nível é conquistado através de confiabilidade demonstrada no nível anterior. Pule um nível, e você perde controle. Fique muito tempo em um nível inicial, e você perde os ganhos de produtividade.

Recuperação sobre repetição. Intervenção humana quando agentes ficam presos é uma característica do sistema, não uma falha. Uma Recuperação de Agente (um processo estruturado para um humano assumir quando um agente não pode prosseguir) deve ser projetada, documentada e medida. A métrica é Tempo Médio para Desbloquear, não se o agente teve sucesso na primeira tentativa.

Pessoas sobre automação. Redesenhe papéis intencionalmente, especialmente o pipeline de talentos juniores. Quando agentes absorvem tarefas de implementação de nível inicial, organizações devem criar novos caminhos para desenvolvedores juniores construírem expertise através de curadoria de contexto, escrita de especificações, design de avaliação e operação supervisionada de agentes. Automação sem redesign intencional de papéis não cria eficiência. Cria uma lacuna de habilidades que surge dois anos depois quando ninguém na equipe entende por que o sistema funciona da forma que funciona.

Esses princípios são um rascunho. São destinados a serem desafiados, refinados e debatidos por praticantes que estão construindo com agentes diariamente. Se qualquer um deles estiver errado, a comunidade deve dizer isso e propor algo melhor.

O Que Estamos Construindo, e O Que Vem a Seguir

A iniciativa de Desenvolvimento Agêntico é uma base de conhecimento agnóstica a estruturas construída por praticantes. Não é uma estrutura competidora. É um vocabulário compartilhado e um conjunto de práticas de pessoas e processos que se aplicam independentemente de quais ferramentas ou metodologia orientada por especificações uma equipe adota.

A base de conhecimento inclui um manual cobrindo os conceitos fundamentais: arquitetura de contexto, desenvolvimento orientado por especificações, padrões de orquestração e modelos de governança. Inclui padrões, abordagens reutilizáveis como fluxos de trabalho de Recuperação de Agente, governança baseada em portais e arquitetura centrada em contexto. Inclui um glossário que define o vocabulário emergente (de Workbench Efêmero a Fluxo de Trabalho Triangular a Loop de Desenvolvimento Contínuo) para que equipes possam se comunicar com precisão. E inclui guias, guias passo-a-passo para adotar práticas como configuração de Equipe Híbrida e implementação de ferramenta de avaliação.

O conteúdo está disponível em agentic-dev.org. Praticantes podem se juntar à comunidade gratuitamente para contribuir conteúdo, compartilhar experiência de implementação e acessar material exclusivo para membros. A disciplina é maior que qualquer ferramenta única, e a base de conhecimento deve refletir isso.

O que vem a seguir: mais padrões baseados em experiência de implementação real. Mais guias para as transições organizacionais: como reestruturar equipes, como redesenhar o caminho do desenvolvedor junior, como introduzir autonomia graduada sem perder governança. E, criticamente, mais praticantes dispostos a se juntar à conversa. O Agile Manifesto foi escrito por dezessete pessoas que discordavam em especificidades mas concordavam em princípios. Esta iniciativa precisa do mesmo: praticantes dispostos a desafiar, refinar e melhorar o que começamos.

As ferramentas continuarão evoluindo. Os modelos continuarão melhorando. As estruturas continuarão se multiplicando. Mas as questões de pessoas e processos (como equipes se organizam, como papéis evoluem, como governança escala, como confiança é construída) são as questões que determinam se qualquer coisa funciona.

É sobre isso que desenvolvimento agêntico trata. Não as ferramentas. A disciplina.

Footnotes

1. Essa era uma premissa implícita, nunca declarada explicitamente porque nenhuma alternativa existia em 2001. Os valores do Manifesto ("indivíduos e interações," equipes auto-organizadas, conversa face-a-face) todos pressupõem implementação humana. ↩

2. Histórias de usuário originam do Extreme Programming (Kent Beck, 1999) e foram popularizadas por User Stories Applied de Mike Cohn (2004). Não são um artefato do Manifesto mas o formato de requisitos dominante adotado por equipes Agile. A preferência do Manifesto por "software funcionando sobre documentação abrangente" criou o espaço para formatos leves como histórias. ↩

3. Revisão de código e programação em pares são práticas XP, não princípios do Manifesto. O Manifesto clama por "atenção contínua à excelência técnica." Revisão por pares se tornou a forma mais comum de equipes operacionalizarem isso. ↩