Durante boa parte das últimas duas décadas, o desenvolvimento de software foi organizado em torno de decomposição progressiva. Uma iniciativa se transformava em épicos, os épicos em User Stories, as histórias em tarefas, e essas unidades menores eram distribuídas entre pessoas ao longo de sprints. Refinement ajudava a reduzir incerteza antes da execução, planning transformava backlog em compromisso de curto prazo, dailies sincronizavam trabalho paralelo e retrospectivas criavam ciclos periódicos de aprendizado.
Esse modelo não surgiu por acaso. Ele resolveu problemas reais de coordenação, carga cognitiva e previsibilidade. Mudanças grandes demais eram difíceis de compreender, estimar, distribuir e revisar, então trabalhar com lotes menores era uma resposta racional às limitações do processo de desenvolvimento essencialmente humano.
A entrada de agentes de IA começa a alterar justamente essa relação. O impacto não está apenas na velocidade de escrita de código, mas no tamanho da unidade de trabalho que consegue atravessar o ciclo de desenvolvimento mantendo contexto suficiente para planejamento, implementação, testes e documentação.
Uma feature que antes precisaria ser dividida em várias histórias pode hoje ser analisada, planejada, implementada, validada e documentada dentro de uma mesma sequência de trabalho assistida por agentes. Isso não elimina decomposição nem significa que devemos produzir mudanças gigantescas. Significa que parte da decomposição que antes precisava aparecer no processo administrativo pode permanecer dentro da execução.
É nesse sentido que o conceito de AI SDLC começa a ficar interessante.
A mudança principal está na unidade de trabalho
O ciclo tradicional costuma transformar algo abstrato em unidades progressivamente menores:
Iniciativa
↓
Épico / Tema
↓
User Story
↓
Task
↓
ImplementaçãoCada nível adiciona detalhe e reduz o escopo até chegar a algo que uma pessoa ou pequeno grupo consiga executar com segurança.
Com agentes, a hierarquia começa a assumir outra forma:
Intenção
↓
Feature
↓
Planejamento
↓
Decomposição interna
↓
Implementação
↓
Testes
↓
Validação
↓
EntregaA diferença mais importante não é terminológica. A organização passa a poder acompanhar uma unidade maior, enquanto o agente realiza internamente a decomposição necessária para executá-la.
Considere uma feature que permita alterar o endereço de entrega de um pedido antes da expedição. Em um backlog tradicional, isso poderia gerar histórias separadas para validar endereço, recalcular frete, atualizar prazo, registrar histórico e notificar o cliente. Cada uma dessas histórias ainda poderia produzir várias tarefas técnicas.
Em um fluxo assistido por agentes, a unidade de entrada pode ser mais próxima da própria capacidade que queremos entregar: permitir a alteração enquanto o pedido estiver elegível, recalcular frete e prazo, exigir confirmação quando existir impacto financeiro, preservar histórico e bloquear mudanças após determinada etapa logística.
A partir dessa intenção, o agente pode analisar o sistema existente, localizar componentes afetados, propor um plano, dividir a implementação em etapas, executar testes e produzir uma mudança revisável.
A decomposição continua existindo. O que muda é que ela não precisa ser transformada integralmente em backlog.
Esse ponto é importante porque decomposição cognitiva e decomposição administrativa não são a mesma coisa. Podemos implementar uma feature em dez passos sem precisar transformar esses dez passos em dez itens independentes que precisam ser refinados, priorizados, estimados e movimentados em um board.
AI SDLC não entra em conflito com os princípios do Agile
Quando essa discussão aparece, surge rapidamente a ideia de que IA está tornando Agile obsoleto. Essa conclusão mistura duas coisas diferentes: os princípios ágeis e as práticas que se popularizaram para implementá-los.
O Manifesto Ágil fala em interação, software funcionando, colaboração com clientes e capacidade de responder a mudanças. Ele não determina que todo trabalho precisa ser escrito como User Story, organizado em sprints de duas semanas ou acompanhado por refinement, planning e daily em uma cadência específica.
Essas práticas foram formas muito bem-sucedidas de operacionalizar os princípios em determinado contexto. Com o tempo, porém, muitas organizações passaram a tratar mecanismo e princípio como se fossem a mesma coisa.
AI SDLC pressiona justamente essa camada operacional.
Se uma equipe consegue transformar uma intenção em software funcionando rapidamente, validar o comportamento e ajustar a direção sem esperar o início ou o fim de uma sprint, ela continua operando de maneira profundamente ágil. Se consegue utilizar uma especificação viva para orientar execução e incorporar feedback rapidamente, está preservando o princípio mesmo que não produza vinte User Stories para chegar lá.
A mudança, portanto, não precisa ser interpretada como “IA versus Agile”. O conflito real aparece entre um ciclo de execução cada vez mais contínuo e algumas estruturas de processo que foram desenhadas para um ritmo diferente de trabalho.
Sprints deixam de ser uma premissa universal
A sprint resolve vários problemas ao mesmo tempo. Cria uma janela curta de planejamento, estabelece um lote de trabalho relativamente estável e oferece pontos previsíveis de sincronização e revisão.
Esse desenho continua fazendo sentido em muitos contextos. Equipes com dependências externas, fornecedores, releases coordenados ou múltiplas pessoas trabalhando sobre componentes fortemente acoplados ainda se beneficiam de uma cadência explícita.
O que muda é sua posição como configuração padrão.
Quando uma feature bem especificada consegue percorrer planejamento, implementação, testes e documentação em um ou dois dias com apoio de agentes, esperar a próxima fronteira de duas semanas para reorganizar o trabalho deixa de ser natural. O planejamento pode se tornar mais contínuo, orientado pela próxima capacidade relevante e pela disponibilidade real do sistema de entrega.
Nesse modelo, a equipe escolhe a próxima intenção, explicita critérios e restrições, executa, valida e incorpora feedback. Quando a feature termina, outra pode começar. A cadência deixa de ser definida apenas pelo calendário e passa a ser definida também pelo fluxo.
Isso não torna sprint errada. Torna sprint uma ferramenta novamente.
Esse é um detalhe importante porque boa parte do Agile institucionalizado acabou invertendo essa relação. Em vez de escolher práticas a partir do problema, passou-se a encaixar o problema dentro das práticas.
AI SDLC cria pressão para desfazer essa inversão.
Planning e refinement mudam de função
Algo semelhante acontece com planning e refinement.
Grande parte do refinement tradicional existe para transformar uma demanda pouco definida em algo que Engenharia consiga compreender e executar. A equipe lê histórias, identifica dúvidas, discute critérios, levanta dependências e decompõe o trabalho antes que ele entre em execução.
Esse trabalho continua necessário. Na verdade, ele se torna mais importante à medida que agentes ganham autonomia, porque uma especificação ruim pode virar software errado muito mais rapidamente.
O que muda é onde e como essa clarificação acontece.
Uma especificação pode ser analisada previamente por agentes em busca de ambiguidades, estados não tratados, regras conflitantes, dependências e cenários extremos. Quando a equipe se reúne, a conversa pode se concentrar nas decisões que realmente exigem julgamento humano, em vez de utilizar grande parte do tempo apenas para descobrir quais perguntas deveriam ter sido feitas.
Planning também tende a subir de nível. Em vez de dedicar grande parte do encontro à decomposição técnica e distribuição de tarefas, o foco pode migrar para questões como: estamos resolvendo o problema correto? O comportamento esperado está claro? Quais restrições são inegociáveis? Que risco estamos assumindo? Como saberemos que terminamos?
O plano técnico continua existindo, mas passa a ser produzido mais perto da execução e pode ser revisado continuamente conforme o agente aprende sobre o sistema.
Essa mudança reduz o valor de planejamento antecipado excessivamente detalhado e aumenta o valor de especificações capazes de orientar decisões durante a execução.
User Stories passam a ser uma representação entre várias
Nesse contexto, User Stories continuam úteis, mas perdem relevância como unidade universal.
Quando a perspectiva do usuário ajuda a esclarecer valor e comportamento, o formato continua funcionando bem. Também pode ser útil durante discovery ou quando diferentes histórias realmente representam incrementos de valor independentes.
O problema está em transformar toda demanda em Story apenas porque o processo espera isso.
Uma máquina de estados pode ser muito mais clara para um fluxo com transições complexas. BDD pode representar comportamento e exemplos com maior precisão. Casos de Uso funcionam melhor para determinadas jornadas. Contratos são mais adequados para integrações. Invariantes explícitas podem ser fundamentais em domínios onde determinadas condições simplesmente não podem ser violadas.
Com agentes consumindo esses artefatos diretamente como contexto de execução, a escolha da representação ganha importância prática.
A pergunta deixa de ser “como escrevemos essa User Story?” e passa a ser “qual é a maneira mais clara de representar essa intenção, seus limites e seus comportamentos esperados?”.
Isso recupera uma disciplina que o desenvolvimento de software nunca deveria ter tratado como acessória: engenharia de requisitos.
Quanto maior a capacidade de execução, maior o valor de saber exatamente o que estamos tentando construir.
Daily tende a perder valor como mecanismo de status
A daily também precisa ser analisada pelo problema que resolve.
Em equipes com várias pessoas trabalhando em partes interdependentes, uma conversa curta e frequente pode continuar sendo uma forma eficiente de revelar bloqueios, conflitos e dependências.
O problema está na daily que virou uma sequência previsível de atualizações individuais sobre o que cada pessoa fez ontem.
Em um ambiente com agentes, planos de execução, commits, testes e estado da feature podem ficar visíveis de forma quase contínua. Reunir pessoas apenas para transmitir esse tipo de informação adiciona pouco valor.
A sincronização passa a fazer mais sentido quando orientada por exceção. Uma dependência apareceu, uma decisão está bloqueada, duas mudanças entraram em conflito ou a execução revelou uma premissa errada. Nessas situações, pessoas precisam conversar.
O ritual deixa de ser o objetivo. A necessidade de coordenação passa a determinar a frequência.
Isso é especialmente importante porque IA não reduz apenas o custo de execução; também reduz o custo de tornar o estado do trabalho visível. Parte da sincronização que justificava determinadas cerimônias pode acontecer de forma assíncrona.
Retrospectiva ganha importância, mesmo que mude de formato
Retrospectiva ocupa uma posição diferente.
Quando agentes passam a participar ativamente da execução, a capacidade de aprender sobre o próprio processo se torna ainda mais importante. As perguntas também começam a mudar.
Quais tipos de especificação produzem melhores resultados? Onde os agentes introduzem mais retrabalho? Em que situações revisão humana encontra problemas que testes não detectam? Quais features conseguem atravessar o fluxo com pouca intervenção e quais continuam exigindo muita correção? Que contexto está faltando quando a execução falha?
Esse aprendizado precisa acontecer continuamente porque o próprio modelo operacional está mudando.
Nesse cenário, a retrospectiva mantém muito valor como prática de inspeção e adaptação, mas não precisa ficar rigidamente presa ao encerramento de uma sprint. Problemas relevantes podem gerar aprendizado assim que aparecem, e métricas do próprio fluxo podem alimentar revisões periódicas mais focadas.
O princípio permanece intacto: observar como trabalhamos e ajustar o sistema. A cadência pode evoluir.
AI SDLC não significa mudanças maiores e menos controladas
Um dos riscos dessa discussão é interpretar a elevação da unidade de trabalho como autorização para produzir PRs gigantescos ou deixar agentes operando por longos períodos sem checkpoints.
A ideia é outra.
Uma feature pode ser a unidade principal de intenção e ainda ser executada em passos pequenos. O agente pode planejar, implementar uma capacidade, rodar testes, validar o resultado e só então avançar. Features complexas podem ser divididas internamente em capabilities para preservar contexto e reduzir risco.
Podem existir vários commits ou até vários pull requests dentro da mesma feature.
O ponto é que essas unidades menores pertencem ao mecanismo de execução. Elas não precisam necessariamente virar unidades independentes de governança.
Baby steps continuam relevantes porque ajudam a controlar complexidade e risco. O que perde valor é a transformação automática de cada passo técnico em item administrativo.
O processo precisa acompanhar a nova velocidade de execução
Aqui aparece um problema que muitas organizações provavelmente enfrentarão.
Uma equipe passa a utilizar agentes e consegue implementar uma feature em um dia. Porém, a demanda precisa esperar o refinement da semana seguinte, depois o planning, depois entrar em uma sprint, ser decomposta em várias histórias porque o processo exige e finalmente atravessar o fluxo administrativo existente.
A execução acelerou. O SDLC, não.
Esse desenho cria um tipo novo de desperdício: agentes produzem capacidade rapidamente, mas o processo continua operando em lotes e cadências concebidos para outro custo de execução.
A resposta não deveria ser simplesmente remover controles. O aumento de velocidade torna alguns controles ainda mais importantes. Especificação, testes, observabilidade, revisão, segurança e qualidade precisam acompanhar a capacidade adicional.
A diferença está no mecanismo. Uma parcela da governança pode migrar de cerimônias e aprovações manuais para especificações verificáveis, testes automatizados, políticas, avaliações e feedback contínuo.
Isso é mais compatível com um ciclo em que o trabalho atravessa rapidamente várias etapas.
O AI SDLC pode aproximar o Agile de suas próprias ideias originais
A parte mais interessante dessa transformação é que ela não exige abandonar Agile.
Em muitos aspectos, ela reforça seus princípios.
Ciclos de feedback ficam menores. Software funcionando chega mais cedo. Mudanças podem ser incorporadas rapidamente. O processo deixa de ser tratado como algo fixo e volta a ser adaptado ao contexto.
O que começa a perder força é uma interpretação específica de Agile na qual profissionalismo passa a ser medido pela presença de sprints, refinements, plannings, dailies e um backlog cheio de User Stories.
Essas práticas continuam disponíveis. Algumas equipes continuarão usando todas elas com excelentes resultados. Outras reduzirão algumas, modificarão outras e adotarão fluxo contínuo.
O ponto central do AI SDLC é que o ciclo começa a ser organizado mais diretamente em torno de intenção, contexto, feature, execução e validação, enquanto a decomposição detalhada se aproxima da própria implementação.
Algo como:
Intenção
↓
Especificação
↓
Feature
↓
Planejamento e decomposição assistidos
↓
Implementação
↓
Validação
↓
FeedbackPor baixo desse fluxo continuam existindo tarefas, checkpoints, testes e pequenos passos. O que muda é a necessidade de expor toda essa estrutura como parte permanente do modelo de gestão.
Essa transformação também ajuda a colocar User Stories no lugar correto. Elas continuam sendo úteis sempre que forem a melhor forma de comunicar necessidade e valor. Só deixam de carregar a responsabilidade de representar praticamente todo tipo de trabalho.
O mesmo vale para as cerimônias ágeis. Elas permanecem quando resolvem um problema concreto e perdem relevância quando existem apenas porque foram incorporadas ao ritual organizacional.
AI SDLC, portanto, não representa o fim do Agile. Representa uma pressão saudável para separar seus princípios das práticas que se cristalizaram ao redor deles.
A tecnologia mudou uma das premissas centrais do processo: o custo e o tamanho da unidade executável.
Se o Agile sempre defendeu adaptação, faz pouco sentido preservar rigidamente um modelo operacional criado para uma realidade diferente justamente no momento em que essa realidade está mudando.
